How to co-design the Edgeryders online space

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:

  1. To explore future ideas to see if they may provide us with valuable solutions we wish to create.
  2. To communicate within the community with clarity and specifity when exploring new ideas.
  3. 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.
  4. 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).

Content Maturity

The design work goes through a process of maturity.

  1. Purpose - working to understand what we are trying to achieve and for whom.
  2. Wireframe - storyboards that give rough descriptions of a user experience.
  3. 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.
  4. 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.

Social Maturity

The design process also goes through a process of social maturity.

  1. Proposal - a proposal initiates a discussion that will lead to a finalized design which hopefully (but not necesarily) represents agreement.
  2. 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.
  3. 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.

Did you see the user stories posted online during lote3?

The contents of videos recorded by different participants were synthesised in writing here  and Leo has the actual videos if you want to use them. Maybe helpful?

thank you - user stories

I saw one of them (not quite sure how I arrived at it) but did not know they were all scripted. There are a few more preliminary steps I’d like to take the time to go through before delving into them.

Thank you very much for that link.

[leo] if you’re out there … I would be grateful if you could make those videos available to us?

[matthias] is there a way to setup a shared file storage places for this group (or any group for that matter)?

File storage for groups

The best way to add files to groups (so far) is creating a piece of content of type “Document” in that group, and attaching one or several files to it. File types are restricted currently, but that can be extended to include new file extensions according to demand. However I’d suggest to not upload large videos this way, as there is no embedded player for them, and it also greatly inflates the storage size of the platform (bad for backups etc.). So I think the Edgeryders YouTube or Vimeo account are better for storage, and afterwards embedding their player in Edgeryders content.