Information architecture proposal for the new platform

Workspaces Software (General)
,
1

After the call today with @Nadia and @johncoate about concepts for the new edgeryders.eu software platform, here is a synthesis by myself. It’s not exactly a summary of what we talked about or agreed on, but builds on that.

1. Basic considerations

Main paradigm. “edgeryders.eu is a collective intelligence platform for open-source everything”. Or in simpler words for the public: “edgeryders.eu is an expert community for free, open and DIY solutions for everything in life”. This is, obviously, our recent “Open Village” vision. It is also a practical value proposition as it tells people they can come and get advice on “hack solutions” for whatever they need.

Users and what they want. Nadia identified three types of users: (1) those who come to read / acquire knowledge / acquire skills (they get served finished Open Village content and instructables); (2) those who come to contribute / take action (they get served the dialogue space); (3) those who come to work with Edgeryders as a client or even a company partner (they get serves a “contact us” call to action).

Main changes to the interaction style. In contrast to now, we will have discussion sections for all areas of a “good life” open at the same time. The platform will manage to make the match between people seeking advice and the experts who can give it (in Discourse, by notifications for people who are subscribed to topics). A good idea to seed this will be to automatically make every user track between 1 and 5 categories when migrating to Discourse, according to what they could be interested in based on their previous contributions. Ideally, network analysis or AI could help with this task of “recommending” categories to be tracked by each user. Also in contrast to now, challenges will not be implemented as boards / groups (“sets of threads”), but as topics (“threads”). This was Nadias idea, and it changes the interaction style more towards the traditional “problem and suggestions” Internet forum style. This means way more challenges than right now, but with Discourse, that seems manageable.

Combination with Open Village content. The question is how a Discourse forum can be geared towards the collective development of EarthOS-style content for Open Village. We did not solve this yet, and it seems rather difficult as specifications and documentation for non-code open source projects is quite technical and complex to edit, while it has to be enjoyable for a community of volunteers to do it. The “ultima ratio” solution is to hire 1-2 editors to do it (from Nepal, it could be affordable for us). However, there should be many smaller ways to let the community contribute, which we should explore first. One nice example is that we can list relevant Open Village content packages in each section of the forum, by categorizing Open Village content with the exact same set of categories used to structure the discussion space itself.

2. Edgeryders platform components

The following is an update to the list from the “Planning for our new platform” thread.

  1. Main menu with static pages. Contains: static HTML pages. Proposed list of the menu hierarchy, with the links to static pages:
    1. Community (links to the Discourse frontpage).
    2. Projects and Events (Sub-pages for current projects only. Former project content is only available in Discourse, tagged by project.)
      1. Future Makers MENA. (Static intro page, Or whatever link, according to our current project. Links to the appropriate category page in Discourse. Entry point link to hand out, though there would be a single-page website additionally.)
      2. Open Village Festival (Basics about the event and how to join. Entry point link to hand out, though there would be a single-page website additionally.)
      3. …
    3. Open Village
      1. Vision
      2. Overview (Nadia's "aspects of wellbeing" slide, linking to selections of Open Village content. Additional graphical ways of navigating are possible.)
      3. Content Packages (The actual Open Village content, for online viewing and for download.)
    4. About Edgeryders
      1. About us
      2. Track record (List and short descriptions of all our former projects. Includes links to a Discourse tag for each project, allowing to see all the project's content at once even though there is no longer a category for it. Includes links to downloadable final reports and documents.)
      3. Privacy policy
      4. We're open (Talking about Edgeryders OÜ as an open organization and that people can "hire themselves" to join the company.)
      5. Get in touch
      6. Imprint
  2. Discourse dialogue space. Structured using these elements:
    1. Categories. The main structural element in Discourse. See below for a detailed proposal.
    2. Tags. Tags will have three separate uses in our platform:
      1. Tags for alternative navigation. Nadia's "aspects of wellbeing" slide provides an alternative means of ordering the content. We can use tags on topics to apply that order, and let users navigate to tags by clicking a node on a diagram looking just like that "areas of wellbeing" slide. The Discourse tagging system is simpler than Drupals, having only a two-level hierarchy. However we can use our own pseudo-hiearchical tags like "food→agriculture", or perhaps rather "food:agriculture". That works just as in Open Ethnographer, and provides nice hierarchical autocompletion after typing the separator character.
      2. Tags for keeping projects together. We do no longer allow users to create projects, and there will be no custom per-project categories. However, users can freely tag their content, and it is possible to follow / track tags in Discourse, just like you can follow / track categories. So tags are our new proposed way for people to keep their project-related user content together. For example, Open Insulin content would all be tagged "openinsulin". The same principle will be used for content from our own past projects, and for client projects when they finish and their custom project category is dissolved. So instead of a category "WENA Youth Platform", the content would then all be tagged "mena-yp". (And everyone who followed the category would be made to follow the tag instead.)
      3. Tags for free tagging. Some people like folksonomy tagging. It does not hurt the above uses, so no problem.
  3. Matrix chat space. Would allow realtime one-on-one and group communication, and the default chatroom could be dedicated to be the hangout space of the site. (John recommended to have this, as it's important for people to also have a relaxed space and not having to be focused on content, work and staying on-topic as everywhere else on the site.) Matrix might be better for this purpose than Discourse, as it provides pleasant real-time communication, and because this communication would be ephemeral (not archived), which provides peace of mind for people in a space where it's ok to be at times silly.
  4. Open Village toolkit. Probably a custom software, to be developed in the medium-term future. Ultimate goal is a downloadable open source package for every aspect of a good life, in such a way that all the packages work nicely together (both their digital format, and the things to build from the packages' instructions).

3. Proposed Discourse categories

The category tree is the main structural element in Discourse. If we really want to go with the Open Village “open source everything” vision, the best way to cut categories is probably “one for each area of life”. The current “channels” list is a good starter. It will finally be a two-level hierarchy of categories, with only the first level shown in the Discourse hamburger menu (may need a bit of custom code). We need two levels so that people can subscribe as “experts” to specific-enough areas of interest. In addition to by-topic categories, we’d have temporary “focus categories” such as “MENA Youth Platform”, special categories for events and the blog, and access protected “staff categories”. A rought proposal for a two-level list of categories, ordered by “growing distance from the self” (as in EarthOS):

  1. Future Makers MENA. Potentially with a better name though. Focus categories like this are temporary, provided as long as the project for a client lasts. Afterwards, their content is sorted into the usual categories above. As long as they last, they provide a sub-set of the site's content, so newcomers feel less intimidated, and more at home as they will be closer to the people gathering in this category for discussions.
    1. Co-working and co-living
    2. Alternative means of livelihood
    3. …
  2. Essential resources.
    1. Agriculture and Food
    2. Accommocation and protection
    3. Environment and nature
    4. Healthcare and social care
    5. Making and Producing
    6. Trade
    7. …
  3. Personal Life.
    1. Mental and Spiritual Resilience
    2. Personal relationships
    3. …
  4. Community, people and places.
    1. Community organizing
    2. Organizations
    3. …
  5. Society.
    1. Governance and self-governance
    2. Migration
    3. Policy-making and politics
    4. …
  6. Science and Knowledge.
    1. Network Science
    2. Open Science and Technologies
    3. …
  7. Campfire. Or whatever name. A section equivalent to the current "Agora", providing a space for relaxation and hangout. No need to be focused, working and on-topic as everywhere else on the site. A probably better alternative is to dedicate the default Matrix chatroom to this (see there for some details on that, above).
  8. Events. A category for organizing our events, with one sub-category per event. There will always be discussions regarding the event, even though we will use specialized external web applications for actually organizing tickets and logistics. Also, we need this to import all the existing content of prior events.
    1. LOTE1
    2. LOTE2
    3. LOTE3
    4. LOTE4
    5. LOTE5
    6. LOTE 6 (Open Village Festival)
    7. …
  9. Blog. (Access-protected category, only visible to members.) This is a special category. All topics created here would be shown as an infinite-scroll blog in another section of the site. The group itself is access protected, so that the blog is only publicly visible in one place on the site, not redundantly in two. The access protection also lets us select who can contribute to the blog. We'd add basically all experienced users. It should feel as an "honour" to write on the official Edgeryders blog. For example, stellar projects like Open Insulin could write some post from time to time on the blog. In more general, anything that is not the typical "challenge / problem / concept, looking for replies" format of the forums is a good candidate for the blog.
  10. Staff. (Access-protected category, only visible to members.) We should not try to force staff discussions to Open Project, as it keeps people closer to their "workplace" in a natural way when they discuss about their work on the same platform where they work.
    1. Staff: Edgeryders Company
    2. Staff: MENA Youth Platform
    3. Staff: Future Makers Global
    4. …
1 Like
2

Dear Discourse testers, please proceed on staging.edgeryders.eu

Update from the developer: “Can you please direct the test users to http://staging.edgeryders.eu/. (I have to delete and recreate the http://edgeryders.eu/ and then that site can be used to customize design and adapt settings, but without content yet.)”

So for all exploration and testing, go to the staging.edgeryders.eu Discourse installation now. Same login as on edgeryders.eu. And in a bit, we can begin to adapt an empty edgeryders.eu with the settings and templates / visuals that will stay for the live version.

3

Can you put login info in their own post?

They are buried in some comment somewhere, and it looks like it’s not indexed (I looked for admin@example.com and only got old returns). If you put them in a post or wiki called “Login info for the staging platform” you will make my life easier. :slight_smile:

4

Login data for staging.edgeryders.eu

@Alberto , I created a wiki with the login data in the admin group here.

5

Generalism and team spirit

Guys, I am heartbroken to raise doubts on all your great work, but now is the time, I guess.

Main paradigm. I have a slightly (but importantly) different formulation. We are a collective intelligence platform for building the Open Village. Of course, Open Village entails, say, wikis on how to remove the parchment from Nepali coffee. But the difference is there: it is collective action, strung together by a common narrative. And that means…

Mapping to users and what they want. … that we serve first and foremost users of type 2. This is not a stretch: it is what happens already. The most thriving, enthushiastic corners of edgeryders.eu have always been the flagship project groups.

Socially, being part of a team that is building something is very different from being a user of a question/answer website. Humans love being in teams. It provides them with an additional motivational boost to keep coming back to the website. It makes a small conversation with 10 people feel cozy and focused rather than lonely. @Matthias , you once told me that your blog has quite a lot of visits: it contains great instructable, so people search for “how to XYZ” and Google sends them to your blog. They read and go their way. Almost no one stops even to say “thank you, that solved my problem”, let alone joining your effort. Additionally, all other things being equal, focused and “fringe” websites are better at creating community than generalist ones: they serve a relatively small group very well, and that group repays them with fierce loyalty and great friendship.

Of course, you can in principle build a question/answer website (or a challenge/response one). That would be Quora (“ask anything, collective intelligence will answer” – quite similar to “a platform for open-source everything”. But this only works at humongous scales. Quora has been burning cash for seven years (160 million in VC investment) and climbed to 100 million unique visitors per month before it could even start talking about monetizing. Profit is not even remotely close.

That brings me to the interaction style. I submit that making the site feel like a lower-grade Quora would be a mistake. We know this. People come for unMonastery. People come for OpenCare, or OpenVillage. People don’t come to Edgeryders as they would to StackOverflow, to ask a well-framed question about a specific proble they are trying to solve. They come to find like-minded people and be part of their work. So, I think the higher-level entity of Discourse (categories) should be framed as projects, or actions, or something like that. Then building the project will entail, at times, writing careful wikis, and those will be picked up by Google, which will send us traffic. But hopefully, people passing by will find a thriving small community with a sense of purpose, and some will stay. As for the hardcore OpenVillagers, they will find reinforcement of the narrative: “we are building the OpenVillage. I am in a team with @johncoate and @Nadia on forgiving conflict resolution methods”, or whatever. This is very, very different from “matching my question with an expert who has the answer”, because most people have no clear question. They are looking for partners, friends, coworkers, comrades. Humans. Not information.

I have a hypothesis. It’s just a hypothesis, but I though it through and I ask you to take it seriously. This: the “encyclopedian” approach of EarthOS is one of the reasons why it did not catch up. It was undersocialized. It was a library of Alexandria, without Hyapatia. It implied that the reader’s role was to RTFM. Good for highly motivated hackers with a clear goal (if I can’t get my code to run, I just want a solution that removes my roadblock, I don’t want to discuss!), bad for people who are looking, as Matt poetically put it, “for their tribe”.

So how do you order knowledge? Same as ever: with tags. We can even make this a thing: “help reorder and maintain our body of knowledge! Make things searchable! Here are guidelines, click on this button to pick a random topic and tag it” (kinda sorta like OpenEthnographer). But I think it is important we give people the ability to participate in the OV – which has a ten year time horizon: very delayed gratification, pretty hard for most of us – by participating in a smaller, shorter project like OpenCare or OpenInsulin or Future Makers. By the way: not too sure of pseudo-hierarchical tags. Try to imagine it in a mature OpenEthnographer setting, with a code manager for researchers to drag and drop codes in a hierarchy (I don’t mean this should be writing onto the Discourse DB). This is a discussion for another day, maybe.

Sorry again. If you are really sure, go for it. But from where I stand, your assumptions on human psychology look at odds from our experience of Edgeryders.

1 Like
6

Thank you for the detailed comment. Two things happened since I wrote this yesterday:

One, I finished substantial edits right after your posted your comment, including a proposed use for tags to keep projects together. Maybe revisit the text and see if that sounds more reasonable now. (Little background: I don’t like “spontaneous folksonomy tags”, at all, and use them for nothing. But when tags are used consistently, they are useful, esp. since Discourse tags can be followed. People wanting to keep their project content together in Discourse, and send updates to their followers, would use them consistently. Plus, tags don’t clutter lists like dead projects did for the current edgeryders.eu. Which is why I really don’t want to allow users to create, or get, custom categories for their projects. Categories for a few flagship projects are a different matter, I’m not opposed to that. But most projects would be kept toether by tags only.)

Two, I realized that we call it “Challenges” currently, but what we collect are not new solutions or expert help, but people showcasing the stuff they are working on. (I think the same happens on IDEO, which was the inspiration.) People like to do that kind of thing … being a bit proud of achievements, getting some kudos and feedback, and perhaps finding some new project collaborators and friends. The exact same thing will happen with the proposed “Discourse topics as challenges” logic. This is how Edgeryders is, and it won’t change. We’ll not be a Quora / Stack Exchange style site for highly detailed questions, rather a kind of “online project expo” for non-code DIY and / or open source projects. (I hope @Nadia sees it the same way about the type of content and interaction we’ll be able to draw.)

With that said about what the content will be like, I still like “categories by topic” much better than “categories by project” (as that has lead to terrible clutterring with dead projects). Projects should get tags. But of course I might be wrong. This deserves a more detailed verbal discussion before deciding anything, so @Alberto welcome to join the next call about this matter …

Edit: Just thought that a good call to action for an Open Village themed Edgeryders with categories by topic is this: “What are you working on, and what part of the Open Village would that be? Tell us here, and meet everyone else contributing to Open Village right now.”

7

Further thoughts on topics, categories, tags and ontologies

I had a long chat with @Nadia about this, and she helped me clear my thinking. Let’s see.

  1. You can never neatly map the world with ontologies. All ontologies are unstable and incomplete, and run into the platypus problem. I highly recommend reading Shirky's forceful argument – it certainly changed my way of thinking. In terms of our own experience, what was the unMonastery  group about? Saint Benedict? Work? Matera 2019? Rituals? Individual threads were about all these things, and others. But the unMonastery group was really about unMonastery. A lot of what "unMonastery" was encoded a social relationship linking unMonasterians, not anything related to knowledge mapping. This is fundamental. Every new project will be about itself. We will keep inventing words (The Reef, OpenVillage...), and having to go back and change our ontology around.
  2. You should not point the user to dead zones. Suppose the following user story: Alice arrives on Edgeryders and is interested in this OpenVillage thing. The site seems to be about Agriculture and Food, Accommodation and protection, Environment and nature etc. Alice thinks this Accommodation stuff seems interesting so she clicks. She promptly finds out that the last update around accommodation was two years ago. She replies to Bob's two-year-old topic. Bob, meanwhile, has drifted away from Edgeryders and does not reply. Alice is having a terrible user experience! We should try to steer her to the inhabited part of Edgeryders: the flagship project groups. 

So (asks Nadia) what, in my proposal, is different from what we have now? This:

  1. We use tags (not categories) as a best effort practice, knowing they are patchy and imperfect but still improve searchability. 
  2. We use project names as tags, (as suggested by Matthias above). Any topic created within a project is tagged with the project's name. 

So, how would this work in practice? For example, now OpenCare is a flagship project. You go to discourse.edgeryders, you see the category right there. You are encouraged to join. People will be waiting to engage. All good. Content is tagged, of course. In 2018, we end the project, remove the OpenCare category (or demote it, so that it does not show up, or clearly flag it as an archived project). But all the topics are still there, still tagged. For example, this topic about open insulin will be tagged open source, insulin, diabetes, Belgium. But also OpenInsulin, and possibly OpenCare.

Suppose also in 2018 we get a contract to do work around the smart open ecovillages in Europe (not impossible). We create a new category called “Smart Open Ecovillages”; we create a list of tags that are related to the new project and we ask Discourse to bring in all the topics that are tagged with one or more of the tags. This has an added advantage: we instantly populate our new project with content.

Result:

  1. categories are unstable and follow activities.
  2. tags are stable
  3. projects are also encoded into tags.

Technical question: can the DB record tag authors?

2 Likes
8

How do you get people to do their own tagging?

Tagging works wonders if it is pervasive and everyone does it.  But peoiple typically don’t do it.  maybe at the response/comment level it doesn’t matter too much.  At the topic level it matters a lot.  Perhaps multiple choice as a set of fixed choices…

Or maybe it can be made into a requirement to start a topic…

1 Like
9

Hurray, a tag vs. ontology discusssion

Hehe … heated discussions about ontologies and tags, I can imagine. Lovely. It brings out the best in geeks. :slight_smile: And don’t even get me started about the rules for beautiful URLs and for naming files. I have some strong opinions there :stuck_out_tongue: I have to apologize in advance for the passionate argument below, but yea, I’m passionate about bringing order to information …

About your comment: I like your idea of removing a flagship project category at the end of the project, while keeping the project’s content together and accessible from its tag. It makes sense for the projects we do, which are more like named efforts to aggregate content, not resulting in a new kind of end product. All our projects’ content can mingle effortlessly, avoiding the cluttering of primary namespace (categories) with names of past activities. After all, for a user only the project’s aggregated content is interesting after the project’s end … not even the name of the project is important anymore.

Question about your take on categories vs. tags: Into what category does content go that does not belong to up-and-running flagship projects? Neither “Uncategorized”, “Archive” or “Past projects” are nice ways to tell the user about a cache of thousands of threads with potentially interesting content …

About ontologies vs. tags. For the purpose at hand, an ontology is a system of tags that are related to one another and arranged in such a way that every piece of content processed with it did fit for at least one tag of the ontology. Of course I agree that “you can never neatly map the world with ontologies” and that an ontology has to be constantly adapted. But that does not at all mean ontologies are useless. It’s not their task to map the world, but to be fit for the purpose at hand. Also from years of working with various ontologies (mostly EarthOS and a personal projects mindmap), I observed that after a time the evolution of the basic system behind an ontology is finished, and it further evolves without breaking that system. For EarthOS for example, the single best suited ontology proved to be a “physical containment hierarchy”, starting with whole equipment sets (backpack / house or truck / village / seastead) and proceeding with physical, named containers of stuff (packages of boxes etc.) and the stuff inside.

The advantage of ontologies over the alternative of free tagging (“inventing tags on the fly”) is primarily for reasons of software UX, not for philosophical reasons at all:

  • In the great majority of cases, ontologies are able to provide a complete mapping ("at least one category fits"). This makes it expectable for a user to find a fitting category for her content, which is important for a simple-to-use software. (The exception is of course the <1% cases that should trigger an evolution of the ontology to adapt to new types of content.) The result of free tagging, on the other hand, is that the user creating a piece of content has to make up a kind of "system" on the spot to decide what is worth to be used as a tag, and what not. Quite some mental workload which we can spare the user. And then every user makes up a different system, and we end up with chaos because of many undocumented, different systems of what should constitute a tag and what not. For example, in "my" system of tagging, normal keywords from the text would never be used as tags, see below. Others do it differently, and the result is just word salad, not exhibiting any of the systematic properties that people used in their respective ways of tagging stuff.
  • Free tagging with keywords leads to worse results than a site search when used for navigating a site. From the example, tags "open source, insulin, diabetes" appear somewhere in OpenInsulin project content as words, and so the project would be found with a site search. No improvement over site search here, even though human time and action was consumed. But then, since the next author would surely forget to tag a new OpenInsulin article with the same set of three tags, the results of navigating through these tags are worse than site search because results are incomplete, and there is not even an indication that they are. If a search would do that, it's a bug. That's why I never navigate sites using keyword-style tagging systems.

On the other hand, tags have a lot of justification as a type of structure in software. In the example, “Belgium” is likewise in the text, but would be a reasonable tag if we’d use placenames for tagging as a policy, allowing to provide a nice map-like overview for “What’s happening in Edgeryders in …?”. That makes using placenames as tags into an ontology, though. The same applies for tags “OpenInsulin” and " OpenCare": reasonable because they are project names, and we have a policy of tagging content by project name so that all past projects can be shown in a nice overview page. That makes using project names into an ontology, though. My main point is that tags are most useful when used in a shared, systematic way.

Sometimes, implementing this “shared systematic way of using tags” is best done by providing a pre-defined ontology to select from (like, Discourse categories). That makes less sense when there are too many elements (as in “placenames”), or elements are regularly invented and added (as in “projects” or “hashtags”). For this, I’d propose to create pre-defined tag groups in Discourse (for projects, places and perhaps other stuff), and to add a small hint to the tagging field saying something like: “Tag with project name and place names. Use other tags sparingly, but feel free to use any tag you have a usecase for.” The way Discourse works is that you can use any tag you like, including place names and project names not (yet) added to the tag groups.

And one last thought about what we could do for “projects”: Discourse also has a “groups” feature. The special thing about groups is that you can @mention a group, which sends notifications to all group members. So groups are like “teams”. They also can have a (public of hidden) group in which they can create topics. It may make sense to create Discourse groups for user-contributed projects. OpenInsulin would be a good example. It would keep project content more together than “just” a tag and provide an “identity” on the site, while still keeping categories as meeting spaces where people from different projects talk to each other.

1 Like
10

Tags are not for searching!

Yes, it’s a good discussion and we should have it. By the way: how would you like having it in public?

First, a question: are we going to implement a search-system based on strings? That was my assumption. If so, tags of any kind (both ontological and folksonomical) do not add much to searchability. In the Open Insulin post above, all the tags I mention are already in the text, but you would be hard-pressed to find a tag that is not in the text and makes some kind of sense for search. Science? Medicine? Too broad. Health? Also too broad, and in the text.

So, I have been assuming that tags are for discoverability, not searchability. This is more or less @Nadia 's channel concept: editorialized aggregations of content. We would use them to provide users with an assisted way into Edgeryders: we are talking of users that just want to see what’s up and find a way to contribute. This is very different from users wanting to retrieve specific information, who use search as usual. To a first approximation, I imagined two ways to that: a best-effort ontology and past projects. Imagine a page where you can select a tag from a high-level list of things. It’s going to look like Yahoo’s home page in the 1990s, but that’s ontology for you.

The good thing is that each topic can  be associated to more than one category. So you can have a second way in: “Past projects”, which is, like @Matthias says, another ontology mapping to the same content.

I may be way wrong, but I predict that usage of ontologies as discovery tools will not be a major thing. I tried to draw conclusions from the Behaviour Flow page in Google Analytics, but I simply do not know enough. Maybe you guys will have better results.

But tagging has another value for ER: it allows us to quickly populate a new project with existing (but related) content. This is only valuable in some cases, but in relevant cases: when we are selling collective intelligence stuff. In those cases, old content “seeds” the new conversation, giving new users stuff to engage with in the early days; and it boosts our numbers (number of participants, number of contributions) without cheating. With OpenCare, we did a bit of this manually: for example, we added Dougald’s “regeneration of meaning” post (from the Baltic Edge project) and MissyK8’s “A family of my own” (from Edgeryders 1). With tags, we could do it a bit better, just pull in all content with the wanted tags.

But here’s the thing: for this use case of tags (as opposed to discovery), the high-level ontology is less relevant. In Matt’s example above, the second level (accommodation) is better than the first (Basic needs). Not sure how to solve this.

Who does the tagging? I think we all agree with @johncoate : not the user. People do not tag, not consistently anyway. Flagship project names can be encoded into tags via code: easy. For the rest, we’ll have to use human labour. Does somebody have an estimate of how much it would cost?

I have two final points to raise.

  • One is making space for multiple, overlapping ontologies. We have been discussing two: Earth OS and project names. But some content we have is also tagged professionally (stewardship, OpenCare). We plan to keep doing OpenEtnographer stuff. If our new platform can find a way to parse tags ("Accommodation" is an EarthOS tag, whereas "unMonastery" is an Edgeryders projects tag, and "legality" is an Opencare tag), it is OpenEthnographer-ready. I think that would be great, since it is demonstrated that we can sell this stuff. 
  • The other is finding a way to track pageviews by project. This is a pain point in OpenCare: we have maybe 600 pageviews a day, but how many of those go to OPenCare-related pages? The project valuators would like to know. With (group-based) Drupal Commons, this is doable by url. Urls have the form https://edgeryders.eu/groupName/nodeTitle , so you can use RegEx in Google Analytics to make a dashboard showing only the pageviews related to projectName . 

Matthias, should I make these two requests on GitHub?

11

We’re nearly there I think …

Just some specific answers in this comment. Will post a separate one with an updated proposal that takes your considerations into account. (The major pain pont raised was actually that the primary navigation (Discourse categories) should not guide users to abandoned parts of the website.)

Regarding the specific questions:

  • I am ok with having this information architecture discussion out in public. No problem at all.
  • Yes, we're going to have string based search. It's actually a pretty fast and pretty good auto-completing search in Discourse, as judged from my limited tests.
  • Tagging use case to "quickly populate a new project with existing (but related) content": Sounds like a good use case. Can also be implemented by exploiting the similarities between the campaigns / challenges between projects. This emerged today in the MENA YP call, where it showed that many challenges / topics for outreach are closely related to prior Edgeryders work (like, say, "Mission: How to make a living"). Below, I'll propose to have challenges in the category tree, which would also cover this use case.
  • "space for multiple, overlapping ontologies": This can be done in Discourse by aggregating tags into named "tag groups" in the admin backend. So one tag group is for OpenCare, one for Stewardship etc.. Tag groups may or may not overlap, I did not test that yet. To prevent people from using (say) OpenCare tags in non-OpenCare content, it is possible to set the tag "OpenCare" itself as a parent tag of the tag group. So only after tagging "OpenCare", the OpenCare tag groups would become available in the suggestions. If this is what you want, no need for a Github issue. If you also want existing tags to be automatically imported into various tag groups, make an issue for that.
  • "finding a way to track pageviews by project": Yes, please create a Github issue for that. Pretty sure this can be solved with one of the advanced Analytics features where Ruby code hands a hidden variable to the tracking code. We'll have to look into it in more detail still.
12

Some lessons from The WELL

When The WELL was first conceived a big part of what was supposed to be its attraction was that people could read the many Whole Earth Catalogs and isses of the same org’s magazine The Whole Earth Review.  It would all be readable electronically and around that content a smart and committed group would gather and grow.  They didn’t use the word “community” partly because I wasn’t there yet (I’m the one who started using the word) but mainly because the whole community thing was an unintended consequence.  And in fact the catalogs and magazines never did make it online as part of The WELL.  And the users didn’t care anyway.  They had each other.

There is a topic on The WELL that has been going on now for more than 25 years called “Experts on the WELL” where the vast breadth of knowledge resident in the WELL members is put to excellent practical use.

However, a topic like that would not have amounted to much had the WELL users not spent a lot of time interacting, getting to know each other and cementing thir relationships first.  Sure there was adsvice available on all sorts of topics, largely technical, but other areas too.  But the ready answer to inquiries of any kind couldn’t be answered in any rigid structure.  It required enough people to spend a lot of time there for other reasons before it could work.

1 Like
13

Helpful!

Thank you John, that’s really helpful insights.

“But the ready answer to inquiries of any kind couldn’t be answered in any rigid structure.  It required enough people to spend a lot of time there for other reasons before it could work.”

And that is what we don’t have in Edgeryders yet. Few very active users, more users active around specific causes / events only, and lots and lots of people who register and do not much more (at least they do not post anything). So the “showcase what you work on” content we get now is probably the best we can hope for right now, until a time when we’d have many more committed users. Interesting that The WELL had a somehow related vision, and that people were attracted and stuck around. So the Open Village thing could really do that for us (hopefully!), beyond just providing a way to explain in one sentence what the heck Edgeryders is and does.

14

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:

  1. MENA Youth Platform
    1. 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.)
    2. Challenge: How to access healthcare in the MENA region?
    3. Challenge: …
    4. … (4-9 in total)
  2. OpenCare
    1. Challenge: …
    2. … (4-9 in total)
  3. Completed Challenges
    1. How to make a living
    2. … (30-40 more, only visible in the /categories full category listing)
  4. Campfire. (Special category, like in the original proposal at thread start.)
  5. Events. (Special category, like in the original proposal at thread start.)
  6. Blog. (Special category, like in the original proposal at thread start.)
  7. Staff (Special category, like in the original proposal at thread start. Only visible to members.)
    1. Edgeryders Admin
    2. MENA Youth Platform
    3. OpenCare
    4. … (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:

  1. 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".)
  2. Aspects of wellbeing. Referring to Nadia's diagram "aspects of wellbeing".
  3. 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.)
15

A couple of points

Nice comprehensive descriptions.

admin only can create topics in parent categories, anyone can create topics in sub-categories

I like that idea.

staff and admin categories

Aren’t they pretty much the same thing?

blog category

What is the real difference between a blog and creating a topic? I’m not sure the distinction is enough for our purposes.

moderators do the tagging

Practically speaking this is probably the only way to insure that is gets done. Labor intensive though.

16

Staff and admin categories are quite similar. “Staff” would just be a container category without content of its own, and contain several admin categories: one for the company like the current Edgeryders Admin group here, plus one for each project. We need multiple, as we need to give different people access to each, and can’t just make them all public. (If you find a way to manage the access rights with less clutter in the category namespace, I’d welcome that though.)

The blog category is just an idea, to have something similar to the current official company blog. The content structure is the same as in a category of topics, just the presentation format is different to reach out to other audiences like investors / potential clients. It would be more stylish, not like a forum, with content right on the page instead of starting with a list of topics. If we can do with just one forum category for the blog, even better, as it means less work on the software.

Final note John, all the more technical work and discussions for implementing the Discourse platform happens here: https://github.com/edgeryders/discourse/issues. You may want to join with a Github account when you see any need or opportunity to contribute there :slight_smile:

17

Agreement, then :slight_smile:

I consider the lack of outcry about this “version 3” proposal to mean we’re in agreement about the basic information architecture in Discourse.

We have since implemented it like this in the import script. Results to be visible very soon …

18

Agreement

Categorization is always going to be arbitrary to a degree. This is as good a system as any, and you have argued for its advantages.

Since we do have parallel tagging systems, I am at peace. This is what I need to implement Open Ethnographer on Discourse. Permissioning will give us some design challenges, because we want researchers to be able to reuse annotations from other researchers. So will authorship – I still don’t understand if tags in Discourse have authors or not. But the architecture is mostly there, in the sense that we can add layers of tagging without disrupting the existing ones.

19

Speed vs inclusion

Guys we are on a tight schedule. Let’s not open a community conversation we are not resourced  with enough time to take what people say seriously?

20

Is this Visual summary accurate?

I tried to integrate the primary functions of the platform and engagement engine as per what @Alberto  pointed out above…

…into what Matt and John have been proposing. I have tried to bring them together into what the interface shat user is faced with when they enter a category/project/challenge  and topic/story/challenge response… 

Is this what you had in mind?