Following are some tools that may help collaborate on designing the EdgeRyders online experience. This is offered as a Wiki that we may change and refine as we discover how to best go about our work together.
The scope of design may vary but should, where possible, be clear and stated. It can be a large project such as the public facing website or as small as a single screen or interaction.
The design effort itself can have multiple purposes:
- To explore future ideas to see if they may provide us with valuable solutions we wish to create.
- To communicate within the community with clarity and specifity when exploring new ideas.
- To refine and clarify ideas "on paper" before calling upon programmers to build solutions. Programming is a scarce resource and should be used caringly and efficiently.
- To help better understand what we want to achieve when searching for ready-made solutions (such as the Drupal based Commons software that we are currently using.
The deliverables from this process may include:
- Written descriptions
- Wireframe drawing as both separate units and user experience storyboards
- Graphic mockups (graphically refined versions of the wireframes).
- Style Guides (established user experience and graphic patterns that can re-used).
The design work goes through a process of maturity.
- Purpose - working to understand what we are trying to achieve and for whom.
- Wireframe - storyboards that give rough descriptions of a user experience.
- Graphic Mockups - detailed graphic design mockups that refine selected storyboard elements to the point that they provide a fairly good preview of what an implemented design may look like.
- Style Guides - hopefully, in time, we will be able to identify recurring buiding blocks and patterns that can be re-used in future designs. These will reduce the need for graphic mockups by making it possible for programmers to re-use existing patterns.
It is useful to know where we are in this process of maturity so that our efforts can be directed correctly. If, for example, we are working on a graphic mockup then we should (a) not be raising questions about wireframes or (b) if questions on wireframes do arise we should acknowledge that the graphic mockup is put on hold and that we are backing up to revisit wireframes that we thought were completed.
The design process also goes through a process of social maturity.
- Proposal - a proposal initiates a discussion that will lead to a finalized design which hopefully (but not necesarily) represents agreement.
- Finalized - indicates that design work has been completed and is potentially ready for implementation. The discussion at this point is not about the contents of the design but about how we can move it towards implementation.
- Execution - indicates that a programmer (or a team of programmers) have elected to implement a design. The discussion as this point should focus on providing the programmers with support and assistance.
Posts & Wikis
Proposals should be pubished as Wikis to facilitate a collaborative creative process. Discussion will take place in the comments with mature ideas floated into the Wiki.
Finalized proposals and execution support should be posts. Their content should be fixed and unchanging since (a) they represent a social agreement that needs to be noted and respected and (b) programmers may be relying on them in their work and changes in this context are disruptive . Discussion will take place in the comments.
Titles of posts & wikis should be prefixed with information on the content and social maturity:
[ <content maturity> | <social maturity> ] Post Title
For example: a wiki containing a proposal for a discussion about the purpose of the public website design may look something like
[ purpose | proposal ] Public Website
For example: a wiki containing a proposal for wireframes for said public website design may look something like
[ wireframe | proposal ] Public Website
For example: a post containing an agreed wireframe design for said public website may look something like
[ wireframe | finalized ] Public Website
Possible values for content maturity are: meta* / purpose / wireframe / mockup / guide
*meta represents posts/wikis about how we work within the group
Possible values for social maturity are: proposal / agreement / execution.
The folllowing software are suggested. They are all open source so that everyone can have access to them.
If you prefer to use other tools please try to use them in such a way that others can partake in your work. For example, if you prefer to use Photoshop over Gimp (a) please try to use a flat layer structure that can be read and used by Gimp users and (b) have Gimp installed on your machine so that you can export your deliverables into native Gimp files.
More specifications on how to work within these tools and how to produce deliverables may surface as work progresses.