Updated Apr 10, 2008 by jason.p.morrison
Labels:	Featured, Phase-Design

DesignGoals

Over-arching goals that direct this project and set it apart from similar projects.

Introduction

This page details the goals for Bricklet's architecture and user interface. Specifically,

Architecture Goals

These design goals are targeted at the underlying system architecture rather than what the user is likely to see. These goals aim to keep Bricklet easy to maintain and ready to adapt to changes in its field, which, in turn, allows us to make a positive user experience possible.

1. Support a WebOfRegistries

Key Idea: Support a distributed set of installations that are aware of and communicate with one another.

2. Enable SelectivePublication

Key Idea: Let users enter data into their installation privately, and let them choose when to disclose it to others.

3. Play well with others

Bricklet software should allow users to easily insert any data they currently have, and easily export any data they store in Bricklet. "Easy in, easy out."

3.1. Expose open, simple APIs

Data stored in Bricklet should be available to the appropriate people (see: SelectivePublication) via simple and open APIs. When designing APIs, the following use cases should be kept in mind:

CAD/simulation tools
Fabrication facilities
Existing registry software
Blog/wiki embeds (especially OpenWetWare)
Bricklet Viz
Bricklet Planner

These APIs should be lightweight and easy to comprehend. Consider: REST, JSON, XML.

3.2. Decouple APIs from implementation

Bricklet Core should publish a comprehensive set of APIs that suffice for a flexible and extensible WebOfRegistries. It should also be a reference implementation for these APIs. This is not to say that it should be the only implementation. While it might be beneficial for other registry software developers to share code with Bricklet, they should be able to write their own implementations that operate as first-class citizens within the WebOfRegistries so long all participants adhere to a common API for sharing and describing parts.

3.3. Provide import/export facilities

Building on the concept of open APIs, Bricklet should provide some methods for operating with other software. Consider:

Import facilities for pulling in existing registry data or part formats
Export facilities for exporting data to other registries or part formats

Key Idea: Data stored in Bricklet should be available to the appropriate people (see: SelectivePublication) and easy to integrate with other software via simple APIs.

Encourage community development

Community members should be able to add their own features. If these features are useful for everyone, they should be shared and distributed.

An open source development model

Usability Goals

These design goals are targeted directly at the user experience. Although the underlying architecture is what enables us to maintain Bricklet, usability is what enables users to keep using it.

1. Make common tasks easy

The majority of a user's time spent with registry software will be on repetitive, similar tasks. We should identify these during the design phase, and focus the most UI development on refining these flows.

For less-common tasks, we should enable them, but not necessarily spend as much time on them. The development team should foster the open-source nature of this project, and encourage users to make changes to their installations. Bricklet enables this process by decoupling the part data model from the user interface. This allows separate installs to communicate (see WebOfRegistries) while still allowing users to customize their local installation.

Key Idea: We should focus our efforts on the most common tasks to make the most of our contribution to the community, while encouraging and enabling users to modify their installation to suit their specific needs with an eye toward submitting changes back upstream to the project.

TODO: Identify other specific ways we would like to improve the UI.