As you may have heard, we're writing a new editor for PublicLab.org -- in fact, I'm using an early prototype of it to write this post. Why are we writing a new library? For a few reasons:
We're very interested in what makes an editor welcoming and intuitive to first-time posters. Wikipedia's 2013-present Visual Editor project cited broadened participation from new contributors as one of their top goals, and that's true for us too. A good UI design need not reduce usefulness for experienced contributors in order to make editing easier for newcomers, but it takes some serious design work to accomplish this, beyond just the rich text input area itself. We're hoping that a good UI will do more than attract new contributors, but may diversify the kinds of people who feel comfortable and interested in posting on PublicLab.org.
Rich text editors are changing a lot
We've long wanted to switch to a "what you see is what you get" rich editor, but a lot of progress has been made in the past year or so, between projects like ProseMirror, Woofmark, and others tackling the challenge of a "better editor" and bringing some new ideas to the table as well. (Check out, for example, this interesting post by the folks at Medium.) We're not looking to compete with these, but rather build a rich and complete editing environment around them, with a fleshed-out look & feel, and due to all the work going on, it's a good time to do this.
One thing we're looking to do is to create staged complexity (a bit Edward Tufte-style) -- to show only the most essential features first (to avoid clutter), but make it intuitive to find and use more advanced features. Slack is pretty good at this -- there are lots of features available, but the displayed interface isn't overwhelmingly complex. One thing I like in Slack is that extra information is often shown only when you begin interacting with something -- like when you begin typing, hints appear just below the text box:
Likewise, some menus are only shown when you hover your mouse over an element:
In our prototype, we've used this idea to show/hide helpful tips, so that the page isn't overrun with advice, and you're only being prompted with assistance related to the area you're focused on. If you wait a couple seconds, you can see this simulated in this gif -- or try it out yourself.
Anyhow, we're currently only prototyping different ways of creating a hierarchy of information, and not yet at the stage where we're ready to begin actually writing good, helpful tips.
One more thing -- we're breaking the editor up into smaller modules: zones for the title, the main image, the body, and the tags, for example. We're hoping that this model of development will enable us to re-use large portions of this for different things, like a comments editor or, more importantly, a wiki editor (a project we'll start this summer). Modules will also make it easier to develop and maintain more complex behaviors, such as those which may make up part of our upcoming Q&A system
We also hope that other communities may be interested in an editor which is designed from the ground up to be friendly and welcoming to authors and contributors. Although we're targeting our own website, PublicLab.org, the editor as a whole will be adaptable to other platforms, and we've talked about making a WordPress plugin available. If other communities use it, others will potentially share the burden of maintenance and of improving and refining the editor. So if you're looking for a rich and friendly editing experience, drop us a line!
And while I'm at it, here's a link to the repository where we're developing the editor:
Muki's recent post on the European Citizen Science Association workshop explores web tools for collaborative science writing, references Public Lab's research notes, and attempts listing the roles available to people in a collaborative writing project: "authoring text, fact checking, reference checking, chart and graph design, map design, translation, checking for comprehension, proofreading, reviewing, checking the statistics for mistakes and possibly more." The workshop came up with roles for science communicators and contemplated stages of collaboration -- a development-mode of collaboration and a final document prep mode.
Overleaf is a proprietary interface based on LaTeX that has added realtime collaboration, document templates, and pop-up help that's specific to specific document sections. Examples of document templates include: "project / lab report" "academic journal" "bibliography".
Here's a link to an Overleaf document so people can check it out as a point of reference: https://www.overleaf.com/5301306pddhyp#/16733130/
Reply to this comment...
Log in to comment
Login to comment.