Information architecture proposal v3
Following the feedback by @Alberto and @johncoate above, and by @Nadia in the call today, here’s my proposal for the information architecture. Main difference is using project names of current projects as categories, to clearly mark the most active areas of the site.
The main advantage of the proposal below is that, in contrast to the prior version, now the primary navigation system does not steer people to “dead places” on the platform.
Edgeryders platform components: Same as in the original proposal at the thread start.
Proposed Discourse category system: The principle is to use project names of current Edgeryders projects (OpenCare, MENA Youth Platform, …) as first-level categories, plus another one called “Completed Challenges”. All of these first-level categories group together “challenges”, which we implement as second-level categories. Now “challenges” we define as “common, focused efforts around a topic, set of issues, or project”. This definition allows to have second-level categories for “traditional” challenges like “How to make a living”, but also for user-created activities like Open Insulin. (Users would not be able to create these second-level categories for challenges themselves, but users serious about that will know how to get in touch to request we do it. And we don’t want categories for non-serious user-generated projects anymore.) The naming scheme for challenges has to be discussed. For example, if we decide it should always be a short question, “Open Insulin” would appear as “How to make Insulin cheap and accessible?” for example.
Once a project ends, the challenges it contains are re-assigned to parent category “Completed Challenges”. The name “Completed Challenges” is much nicer than “Archive”, as it points to an achievement. People would still be able to comment on existing topics there (while being aware these topics are not really active), but could not create new threads in there. All existing content of former projects would be sorted into 30-40 finished such “challenges”.
This two-level category system has the advantages that (1) it tucks away no-longer-active content into one category “Completed Challenges”, so mostly out of sight, (2) it makes Discourse provide a category page for a current project, listing its challenges as sub-categories, and its most recent topics and replies. We would extend this page to be the project’s landing page, by including custom intro text and graphics. By letting only admins create topics in the first-level category (but letting everyone comment on them), this category can be used for instructions and meta-level discussions about the project itself, while all actual content goes into second-level categories (challenges).
Edit: Regarding category names, there is a little problem that Discourse expects them to be very short (2-3 words), cutting off the rest when presenting them in the menu etc… However, it also shows a longer 200-character description below the name in the category list page. A proposal would be to use two-word and three-word category names (“Healthcare Challenge”, “Food Growing Challenge”, “Accommodation Challenge”), and longer question-style descriptions in the 200-character space provided for that.
Proposed list of categories to illustrate, with MENA Youth Platform and Open Care as the current projects:
- MENA Youth Platform
- Challenge: Building us an online home (The place for co-creating the Discourse platform based on the first prototype. Nice to frame this as a challenge.)
- Challenge: How to access healthcare in the MENA region?
- Challenge: …
- … (4-9 in total)
- OpenCare
- Challenge: …
- … (4-9 in total)
- Completed Challenges
- How to make a living
- … (30-40 more, only visible in the /categories full category listing)
- Campfire. (Special category, like in the original proposal at thread start.)
- Events. (Special category, like in the original proposal at thread start.)
- Blog. (Special category, like in the original proposal at thread start.)
- Staff (Special category, like in the original proposal at thread start. Only visible to members.)
- Edgeryders Admin
- MENA Youth Platform
- OpenCare
- … (coordination groups of past projects here)
Proposed Discourse tagging system: We use tags for “aggregating editorialized content” as Alberto proposed. “Editorialized” would mean that normal users cannot, or at least normally would not, do any tagging. (So there will be no tagging field in the reply form. This can be implemented by setting “Settings → Tags → min trust level to tag topics: 4” and “Settings → Tags → min trust to create tag: 4”, making these accessible only to manually promoted users of the highest trust level – which only mods / admins would get.)
So, moderators / admins, and mostly our soon-to-be-hired content organizer, do the tagging. Alternatively, we can allow users to also add tags, but would keep their tags separate from the higher-quality ones created by moderators / admins, and only use the latter for providing alternative means of navigation on the site in the form of diagrams etc… There will be a policy telling how to tag: Either select tags from our three taxonomies (project names, EarthOS, wellbeing), or create a new one (that fits the requirements) and add it to one of these three taxonomies.
We’d employ three different tagging systems in parallel using tags, providing three alternative ways of navigation in addition to the Discourse category system:
- Project names. As proposed above. Keeps project content together even after the project ends and its category is dissolved. Ordinary users may be able to tag with project names. (Can be done by configuring the parent tags of all other Discourse tag groups as "staff tags".)
- Aspects of wellbeing. Referring to Nadia's diagram "aspects of wellbeing".
- EarthOS ontology. This is based on a "physical containment hierarchy" of all equipment needed for a complete Open Village. This navigation system expresses the focus on the Open Village vision. (At a later date, this tagging system would be presened in the form of an interactive diagram, using custom Ruby code. Parts would unfold as the user drills down into the hierarchy more. At each node of that diagram, it would be automatically shown how many topics, Open Village specs and Open Village packages belong here, with links to them all. That would be all that's needed to navigate the Open Village system, so there would be no alternative ways to reach specifications and packages.)