@unteem and I met to discuss some issues with the various parts of oscedays.org and came up with some ideas to improve it. However, we need more input and ideas!
Here are a few of our feelings and assumptions, based upon our own experience and a few conversations with users:
- Design is not particularly clean or unified
- No clear overview or signposting about how the website works overall, or the role of different tools.
- Separate sign-in for each function is annoying, feels disjointed
- Too complex for the simple role it should play
- Confusing backend for editors/posters (slider etc)
- Documents app lacks a lot of functionality
- Collaborating on offline documents is also too difficult
- Calendar/contacts app is probably superfluous to our needs
- can't preview SVG(!)
- users are unclear of its purpose and structure
- folder structure could be optimised to avoid automatic syncing of large media folders.
- very little functionality when not logged in.
Etherpad (pad.oscedays.org) :
- can't hyperlink text (!)
- no clear overview of existing pads
- not as smooth an experience as Hackpad or Google Docs
- not very pretty
- Users don't know where to post or to find relevant info. (structure & signposting issue)
- 'search by tag' functionality could be greatly improved.
- 'Make Wiki' option is hard to find & admin-only.
- a topic's wiki status is not clearly visible
...well, there's a bunch more, but you get the idea!
Some of the key concepts which we would like to move towards for a new improved OSCEdays website are:
- single sign-on for all OSCEdays tools - anyone have experience with this? Do we look into OAuth?OpenID?
- Publish blog posts, project intros and local chapter pages directly on Discourse, with this content dynamically mirrored in a clean-and-tidy format on the main, read-only website. (Only the first post in a topic - click through to see or add comments and discussion on the community forum)
- Text formatted as Markdown wherever possible, across all sections of the website.
- host our own Hackpad (now open source) for real-time collaborative text editing.
- experiment with real-time chat with themed 'channels' allowing users to quickly and easily post questions and answers - it should be more useful during events, have a lower barrier to entry than writing forum posts and give people more of a feeling of being part of something... in theory. It may spam their inboxes and turn them away. (does anyone have experience with Zulip, the open-source Slack alternative from Dropbox?)
- set up a Gitlab repository on the server to host and track changes in important documents (eg Foundation statue, OSCE definition), project documentation, software (custom website code, any OSCE software projects we develop), design files...
In general we would like to have a more dynamic setup, e.g where we can edit a Markdown file in the git repository and it will update wherever on the web platform it may be linked. Similarly, if we choose to publish particular topics from the forum to the main website, rather than copying and pasting, we should be able to link dynamically and any changes will also update.
Here is a diagram illustrating how we imagine the structure and interaction of such a website working.
Green means it's read-only content, i.e. our main website, designed to be read and shared by the general public. Currently our Wordpress installation serves this purpose.
The yellow parts are the core elements we imagine that most users will interact with most of the time: The community forum, their user profile and a real-time chat application.
Dark blue sections are complementary tools which provide space for collaborative editing (Hackpad), file storage & sharing (ownCloud or Cozy) and an RSS feed of open source circular economy articles and news (tools or ideas, anyone?).
A coloured arrow means that it should be possible for data to be automatically updated in this direction, a white arrow means that input or copying of data between these elements would likely be manual.
Our vague idea of having our public hackpad and discourse content mirrored as markdown documents in the gitlab repository is that (we assume) it might be useful to have this information in a flexible, easily machine-readable format so that it can easily be used for interesting open source projects or research in the future. We may be wrong though
Please be diplomatic and constructive about any other idiotic assumptions we may have made...