In-platform events treatment is unrealistic
Building a comprehensive solution for events would be very expensive, and we only would use them a few times a year. For this I would use third party SaaS.
1 Like
Agree with Alberto. And, OpenProject ready to test.
I have to agree that it’s unrealistic / economically not meaningful. I think I got carried away avove 
Anyway, if anyone wants to test drive OpenProject for event and / or project mgm, I installed it today and you can test it like this:
- URL: http://projects.edgeryders.eu/
- login name: admin
- password: 6%4a,cc07wkgEWQ
- you may also sign up yourself on the platform and only use the admin account to confirm your account, if you like
I’m in doubt if that kind of software would be useful for us. But the complexity of projects like the MENA Youth Platform one is indeed a challenge …
Looks good
I checked it out - nice.
Hmmm
Our main use case is: we are making a complicated proposal like OpenCare, RECODE, or MENA YP. We already had to use GanttChart several times in these cases. Larger consulting contracts require it, and frankly we need them to get a feel of what we are proposing and not paint ourselves into a corner.
OpenProject seems to go beyond making Gantts, however. I am not totally sure how we would use any other functionality. I only watched the one tutorial! It seems one advantage is a project lead can create a work package and then assign it to someone else to specify, etc. Would need to try it.
One important feature of Gantts in our use case is aesthetic attractiveness. GanttProject is so-so, but OpenProject does not look much better. If no one has made a Gantt for MENA YP yet, I am up for trying.
In that case, try Office Timeline
@Alberto , I did not yet make the Gantt chart. Wanted to use OpenProject for that, which seems the best available open source solution. But since it’s not beautiful, it’s not adequate …
So you give it a try. For Gantt charts with visual appeal, maybe try Office Timeline. Basically the only beautiful Gantt charts I saw, but I can’t try it for lack of MS Office. For an online solution with at least somewhat beautiful Gantt charts, see Vizzlo. Needs a paid plan (14 USD/month) to be able to do PDF exports, though.
Edit: Just saw there are also multiple ways to create Gantt charts with R. Some are quite sophisticated, but none of them is beautiful by default …
Edit: Since OpenProject has too much complexity and we only need Gantt charts, my current favourite is now Twproject Gantt. Quite beautiful output, and (what is quite astonishing), the resulting PDFs can be edited with Inkscape very well to beautify the output further. If we want to use it right now, we’d use their free SaaS. The JavaScript component is open source software though (repo), so we could later make it into a fully collaborative application on our server with 2-3 days of effort, by adding a Ruby-based server side application for storing, importing and exporting the data. For data migration to that, there is a hack: call saveGanttOnServer() in the developer tools’ JavaScript console of the Twproject Gantt SaaS application and copy out the JSON of the resulting HTTP POST query generated by this. So no data lock-in, in case we want to go this route …
1 Like
OpenProject
I do not use Office. Let’s stay with OpenProject for this project, it’s worth a try. How do you know their Gantts are not beautiful? We never made one!
Demo project
I looked at the demo project inside the projects.edgeryders.eu installation. And you said “OpenProject does not look much better”. But of course, we can try. If you would create the diagram inside OpenProject, I can then convert it to PDF, and make edits with a vector oriented drawing software as needed. One more option to get more beautiful results, then.
Done with TeamGantt
Twproject was a mess for me to use. But this is not so bad.
Tentative Gantt for MENA YP: https://drive.google.com/open?id=0B_vWawrKpTaFRjF5UE9QdEFINkU
1 Like
Confused
@Matthias , now I got confused. Is it Twproject or OpenProject? Do I have to do it or will you?
One thing I am sure of: doing manual beautification is overkill. The good thing about GanttProject etc. is that they draw the Gantt autoatically from a database of activities. This is essential, because you keep tweaking activities as you build your proposal or plan, but you do not want to leave the Gantt to the last minute. “Beautiful” in this context only means “tidy, legible”.
You, OpenProject 
@Alberto , you should do it, using OpenProject (because that’s all we have up and running right now). I can still care for PDF conversion, or similar, if there’s any need.
The Twproject Gantt section is just there to inform our future software development goals (SDGs). I almost confused myself though. So many alternatives for Gantt charts, and none of them truly great 
Thredded or Discourse
They don’t seem to be “threaded” format (a la Reddit) but rather more linear. BoingBoing uses Discourse: https://bbs.boingboing.net/
Thredded looks a lot simpler.
Do you have a preference with these Matt? I think Discourse could be made to present better. I don’t know which one of them is easier to find where the action is if you don’t have much of a patciular agenda on any given day but still want to converse. (A weakness of ER as it is today).
Discourse, except if too hard to extend
Regarding favourites, Discourse is clearly the more sophisticated one. It has its own approach to threaded comments (relevant to @Alberto ). To me, it seems compatible for our conversation analysis needs (where we want “comment a is reply to comment b” relations). Even better, it also offers using quotations, and seems to keep the semantics intact (knowing where the quotation comes from). So with multiple quotations in one reply, we could (in the future) decuct relations like “comment a is reply to comments b, c, d”.
The only reason not to choose Discourse would be if it offers way more features than we need (“the Drupal fallacy”), which would make it too complex to integrate our custom code with reasonable effort.
1 Like
Discourse installation ready to test
Well then, this is for the alpha tester team, esp.: @Alberto , @Noemi , @johncoate , @Nadia . Also Patrick of course (but no expectations, just if you like to have a look). With our developer Daniel, we have set up a quick demo installation of (not-yet-customized) Discourse here: https://edgeryders.eu/. (Edit: Login credentials are in the admin group here. Also, remember that the demo installation for testing things out has now switched to https://staging.edgeryders.eu/ – please do not change stuff on edgeryders.eu for the time being.)
This gives you admin privileges, so you can also access the admin backend from the top right. Happy playing around! All content there will be erased again, so move and create and delete whatever you want. We have to answer the following questions in order to move forward with the development. It’s all about mapping our current data structures to those of Discourse:
- How to implement challenges? Our current proposal: Challenges become categories. This is nice, because unlike tags, categories are visible in the Hamburger menu. Alternative proposal: Challenges become Groups in Discourse. In Discourse, categories are presented as the typical "forums / boards" of discussion software, so this seems the closest match for our challenges.
- How to implement channels? Channels are the multi-select field in the challenge response form, then is presented like this. Proposal: channels become tags. That allows one thread to belong to multiple channels (like now). So it's better than using categories, since a thread only belongs to one category in Discourse. Edit: However if we are ok with only importing one channel value per post, we can also use categories. Categories can be used to implement challenges and channels at the same time, as they are hiearchical.
- How to implement supporters / multiplicators / collaborators? These are fields in the challenge response form, allowing folksonomy input of multiple tags per field. Proposal: these fields become tags. Tag values can be free-form like now, or pre-defined.
- How to implement challenge chains / projects? This is what keeps challenges grouped together, and also we need it as a data structure to keep content of different projects separate enough for analysis etc..
No proposal yet. Maybe also tags, with some sort of auto-tagging? Like: Everything posted to this challenge will be tagged "WB MENA Platform".Edit: A proposal is to implement this as parent categories, with all the challenges of a project being the child categories. After a project ended, parent categories may be dissolved, and challenge categories assigned to a parent category "Completed Challenges".
Feedback from own tests
Just a collection of observations from my own testing:
- I found a feature that allows registered users to post anonymously. This solves the spam problem (as users can only post after login) and also the operational security problem (as the platform does not record who posted when posting in anonymous mode). Like many of the innovative features in Discourse, this one seems to require a warped brain to invent. I like it.
- There are per-category access rights for "See & Reply" only. Applying these seems perfect for archiving challenges. People who find these old threads can still add their replies, so the discussion keeps being latently active and useful, but people cannot create new topics (challenge responses in our terms) in these categories.
- Heart buttons for potential PayCoupons integration. I just had this crazy idea: for an entrepreneurial community with a strong P2P spirit, it makes complete sense that "Likes" for valuable content are not just a digital event, but are worth something. Namely, if users go to their settings and connect their PayCoupons account, each like will be worth a donation of a standard value that the user can configure (but similar to Flattr). After clicking the "Heart" button to like something in Discourse, a field may appear where the user can increase the donation amount for this liking, but that would be optional. For users who do not connect their PayCoupons account, liking works as normal. For users who receive PayCoupons-enabled likes but have no PayCoupons account yet: they will receive the PayCoupons transfers automatically once they create and connect their PayCoupons account. In addition, all users would have fields in their profile to tell (in short) what services they offer for PayCoupons.
Tiger team testing
- Discourse takes the idea of a "ladder" of user levels from web forums of the 1990s: https://meta.discourse.org/t/what-do-user-trust-levels-do/4924/2 . I am not too happy about the idea of automatic demotion of users (from level 3 up).
- Also badges: are we sure about all this gamification? I am more sympathetic towards a relaxed approach to online communities.
- I don't understand, @Matthias : are "categories" the same thing as "boards"?
That’s all for now.
categories = boards
- Yes, categories are conceptually the same as boards. Every thread (=topic in Discourse speak) belongs to exactly one category, and categories are used as the main structuring element in Discourse. I think they name it "catagories" only because posts from all categories appears in the same list on the homepage. It's not like "being in a board / sub-forum", where you could then see only the content of that board / sub-forum.
- We can of course disable the whole badges system (it's in the admin settings). I'd also recommend we don't go down that gamification path.
- Likewise, we may want to not use trust levels the way they are intended to. We might want users to start at level 1 or 2 instead, and disable automatic demotion of level 3 users by setting leader_promotion_min_duration to infinity (setting is mentioned here).
So there is some flexibility in the Discourse settings to adjust how it works, and I hope it will be enough for us. What I like (a lot) about its UI, after an hour of adjustment, is that all the content is accessible from the homepage. What you get there is a simple query interface to see the posts you are interested in. No more diggingin sub-forums / groups / projects etc. without knowing if you have seen it all or if there is more.
Suggested topics
Is there any logic to it? It looks random to me which makes it clutter.
Visual summary of conversation so far as UX flow?
Hi John, it feels like we are at risk of getting lost in tech details of the new platform at the cost of having a coherent, actionable proposal for how the platform should look (Ux, IA and Interface design). The differences in our respective communication patterns are not helping.
I for one am having a really hard time integrating all the above into a coherent set of specifications and actionable instructions. In part it’s because my cognitive bandwidth focused on other tasks (e.g. me: business development, client relationships and sales).
You are the most experienced out of us all - can you help?
Discourse as part of the platform
Am I correct that we’re looking at the details of how Discourse works, but that is all a subset of The Platform, which will be developed using the Ruby/Rails CMS?
If that is the case then I am curious if Discourse can weave in with the other content on the Platform - something today’s ER site does well. Or if you have to stay within Discourse if you want to converse with people.
To the larger question, it is my understanding that we have in our proposal for MENA YP that we will start out right here on “ER classic” and migrate over to a new Ruby-based platform once we get it set up. Am I right?
If so, then what do we want the new site to do that we can’t do now? Is it not a matter of how much functionality but rather functionality that is both easier to maintain and manage as well as easier for the user to understand? I am pretty sure that is a main driver of going away from Drupal, based on what I remember Matt saying.
It seems like we’re a little stuck in nomencalture. And for me, the ER site already has a lot of that. Posts, wikis, blogs, events, challenges, stories, projects, channels and others I am surely leaving out. My first question is do we want to retain and present that kind of complexity to the MENA YP people and do we want the Platform we develop to have all those choices presented in the farily simultanous way that we do now? One has to sort of wrestle with the ER platform for awhile to get it, to really grasp it. I find that it rewards people who come in and don’t know that much about what is going on yet (we help with “start here” and “tell your story” and “what’s new” etc), and real power users who have worked out some of their own efficiencies on how to get work done using the site. I wind up leaving a ton of tabs open and going back to them, often wondering, “what’s this one about again?”
So now we have Discourse that wants to call certain things by certain names. Thus, more nomencalture discussion over what we call something. But really, it’s how do we want to present the site and its tools to people? We have worked on the UI of the current site and as I recall it is not fully to where you want it to be. We don’t want to reinvent the wheel here if we want to keep good design and ideas, but it is also an opportunity to change things. But that will be within the boundaries of the Ruby/Rails CMS environment and its templates and added applications. I set up and ran a Joomla site for the radio station and I don’t think it is terribly different from Ruby as a manageable CMS system.
So do you want us to come up with a visual map of what it is we want and see if we can get Ruby/Rails to do it?
1 Like
@johncoate , I’ll (try to) answer below
You are right that Discourse will provide a subset of the platform’s features (let’s say 80-90%). Discourse would be our new base software and Ruby on Rails our new programming language, just how the current platform uses Drupal as a base software and PHP as a programming language.
All conversation would happen in Discourse (forum style) and Matrix (chat style). About the if and how of the Matrix integration I am not yet clear … it may be possible to also use Discourse itself for chat-style communication if it supports realtime updates of threads (“topics” in Discourse speak). Anyway, there is no real need to weave in with the other content of the platform, since all existing content (incl. wikis, posts, challenge responses etc.) will be imported into Discourse itself, into a few static pages (“Abouts us”, “Legals” etc.). I am not yet clear about where to put the Edgeryders Admin group content in the future: either into Open Project, or into a private board in Discourse.
That is correct, that’s the original plan. (Daniel hinted at the possibility to do the migration earlier, namely in time for the MENA Youth Platform’s prototype. The time plan for that prototype would be 2017-07-15 (one month after contract start). To be discussed.)
Right Drupal is a CMS for publishing content, it is not good at anything related to interaction, and it is not a specialized conversation software. When you click through the Discourse admin backend (login credentials see above) you’ll see how this is much more advanced software for managing conversations. It’s a pity Discourse was not around in late 2012 …
Exactly my concerns as well. The Discourse based platform should be much simpler to navigate and understand. We will not have all these different types of content there, they are largely a legacy of past experiments before settling on the challenge-and-response format. The beauty of Discourse, which will be the main interface, is that all functionality and all threads are accessible from the homepage. No need to navigate to some hidden sub-forums (like “Projects” on the current Drupal site) to see everything. Just use the filters on the homepage. In addition there are some static pages for “About us”, “Legals” etc., all of which would be accessible from the main menu (which we’ll add to Discourse). And that’s it.
All existing content will be imported into Discourse boards (“categories” in Discourse) and threads (“topics” in Discourse), and they will be consistently called “challenges” and “responses”, respectively. Actually, I am still looking for a better wording than this. “Challenges” and “stories” maybe? Do you have an idea? I think it’s quite important to get these two words right, as they will be used throughout the software, and should evoke the right connotations. For example, in the light of the Open Village vision, people should be aware that it is ok to write content about open source developments / inventions created by others, if it answers to the “challenge”.
Ruby on Rails is not a CMS, but a programming language. So that’s quite different from a CMS. I intentionally don’t want a general-purpose CMS as base software anymore, since CMSs suck at interaction, and are not optimized to handle online dialogue. So beyond Discourse (and a Matrix chat client should we add that), there are no pre-defined features as “boundaries”. We can add whatever features we want by programming them in Ruby, and that is much faster than extending Drupal with self-developed modules written in PHP. However, as always, if we can get around programming something, we take that opportunity. So the question is rather “How can we map the features we want to what Discourse provides?”. Plus, of course, “What features do we have to write in Ruby because Discourse does not provide them?”. I provided an outline of a potential answer to the first question above, and any feedback and counterproposals would involve digging through the Discourse backend. In addition, everyone is welcome to propose essential features to add that Discourse does not have. You can use a visual map for that, sure.