Public Lab Research note


Early design ideas for the Rich Editor project

by warren | April 29, 2016 18:43 | 45 views | 9 comments | #13050 | 45 views | 9 comments | #13050 29 Apr 18:43

Read more: publiclab.org/n/13050


There've been LOTS of great ideas posted, both in response to my recent ask for input on the new Rich Editor project, and in response to @liz's post on peer review -- that have relevance to the ongoing design of the new Rich Editor.

There's really too much to tackle all at once, but I've been working on sketching a number of ideas for designs and/or features that I wanted to put out there, especially in advance of Monday's OpenHour on Public Lab's research culture.

Here's the big sketch, which covers a lot of different ideas:

Public_Lab_Rich_Editor_design_(1).png

Keep in mind, as always this early in the design process, that this is more about layout, flow, and features, than about graphic design or typography specifics. Let me walk through a few of these

Step-wise authoring

As we add new features and make the Editor more powerful, we add complexity. We can use design to "stage" this complexity, so that more advanced features are available, but aren't cluttering the display for newer authors who might be overwhelmed.

Organizing the Editor by clearly-separated steps helps situate each feature in the overall process, though they take more space to display in steps. But steps can also have helpful guidance and tips that doesn't all run together into a big block of text the way it does in our current editor.

Screenshot_2016-04-29_at_2.32.02_PM.png

"Type" selector

There are already a few types of post -- events and questions vs. basic research notes -- and we've talked about making one specific to the blog, or for other uses. A type selector could display a different "flavor" of the Editor for different purposes, and could also be used to categorize posts a bit, if we wanted: "exploratory" posts vs. "data analysis" or "narrative" ones, though we'd have to figure out how to clearly refer to these different types.

Screenshot_2016-04-29_at_2.32.25_PM.png

A text area that grows

The text area that you type the body of your note into will be a WYSIWYG (what you see is what you get) "rich text" editor, of course. But one improvement over the current one is that it could scale vertically to accommodate your text. As you type, there's more space in the left column, so we could display additional tips, perhaps relevant to someone authoring a longer piece -- including encouraging them to break it up into a series of posts (we can explore better ways to present a series of posts, too).

Screenshot_2016-04-29_at_2.33.13_PM.png

Inviting others into your work

One big priority is to provide some tools for authors to build collaborations -- from asking others for help, to proposing that others replicate work, to soliciting review of a draft.

There are suggestions of this throughout the mockup, but one big one is the "I'd like feedback/help on X" selector next to the Publish button. The options in it are just a few suggestions -- chime in if you have your own -- but the idea would be to specifically ask for interaction from your readers.

Screenshot_2016-04-29_at_2.33.37_PM.png

Miscellaneous

The mockup also includes lots of small feature ideas -- note the suggested placement of auto-saved "drafts," the "suggested tags" and the "recent tags" drawn from your own recent posts (or tags you've followed, perhaps).

Feedback welcome

Of course, this doesn't begin to cover all the various needs and use cases the Editor will have to address, but it's an early exercise to see how it might integrate into an overall design.

I'm curious -- what do people think of this basic layout:

  • in terms of approchability
  • is there too much information? Too little?
  • how it would read to newcomers vs. long-time contributors?

Thanks in advance for your thoughts and suggestions as this design process moves forward!


9 Comments

Looks like a good starting point. For the moment, I'd first suggest incorporating some form of sub-topic list for the 'Body/Content' section which might have a different set for each general category. By this I mean that the selector for note/question/event/etc would each prompt an appropriate set of sub-sections in the body to be covered. A research note would require a different set than an announcement of an event. I acknowledge the existing Note format includes a few suggested questions to answer, but at least in the case of research, that list is insufficient and authors appear to need more guidance. Other types of submissions can have parallel missing material.

Reply to this comment...


Thanks for the input, Dave.

I had another idea -- we've talked about asking for things after someone presses publish (like, for example, tagging) to reduce the upfront requirements and present a simpler form.

Some of these could go at the head or foot of the note itself, once published. Like "now, invite others to reproduce your work -- be sure youve provided a materials list and instructions" or "add this to a series of recent research" or "mark this as an open challenge" or whatever.

Reply to this comment...


Yes, procedurally (for the form) reminders are generally easy. However, I'd suggest (or remind ;-) ) that such action items would mandate that each have some web functionality to back it up. For instance, 'add to series of research' would 1) still require the submit process and 2) there would have to be some form of 'note series linking' in existence.

Help with tagging is fine, but it is frequently either ignored or abused rather badly by some so I'd suggest 1) the tagging process needs to be redesigned and 2) if tagging is to be used at all, existing note tags need to be cleaned up. I realize this is a bit drastic, but maybe #2 could be initially automated a bit -- do an automated search of all existing notes and compare words used in the body of the note to words in the tags and remove all but the top 5 matching tags. For notes with no tags, the same process could add 3 tags based on the same word predominance within the body text.

Reply to this comment...


I think being able to explicitly save and return to drafts, invite others to collaborate are my priority features here. What do you think about saving a "shared" draft such that more than one person can work on drafting/editing a note? Right now multiple authors can be tagged but only one can edit. Can the invitation to share a draft include an invitation to edit?

The Stepwise editing that gives a 'template' for a post is helpful now, I like that it will be expanded to have event/question framings too.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


We have two distinct ideas of "draft" which I want to try to reconcile -- one is to simply publish a post normally, but it'd be marked "draft" (kind of like a preprint preview on arXiv or something):

  • it'd show up in the normal feed (we could offer option to filter)
  • it might specifically list input requested

Another is one which is not published, or not visible to anyone except those allowed by original author.

  • it might be more complex since we might have to include notifications, tighter access restrictions

In either case, we could make the final publication date distinct from the draft publication date. I like the model of A better, but curious it'd meet the needs of the B scenario too, or if they're really quite distinct?

In any case, we can add multiple author access using the with:coauthor tag.

Re: edit history, the faster way to complete it would be to store drafts in the browser localStorage, but this would mean you could not begin editing on a phone, then pick up on a laptop (a use case I'd really like, for adding images from my phone, but authoring on my laptop). So I have to consider whether a server-side edit history is possible (and worthwhile) in our timeframe. Another solution to this would be to have a "recent images" selector so it doesn't matter if you're editing the same draft, you can upload from your phone no matter what, and see images uploaded from any source when placing them.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


At the Open Hour today, we brainstormed allowing users to flag a post with "the information in this post has been superceded by a newer research note" and submit a link to the newer note.

In this way historical info can be preserved, new users can find up to date procedures, and new users and other editors can help in the co-creation of organization :D

Reply to this comment...


Jeff, I'd like to suggest that 'notes' have generally taken the form of either 1) "completed" sets of information or 2) focused topics of "open-ended" inquiry. One might find another basic form as well; however, all could likely be served by the same basic tools.

In #1, the work has largely been completed so the submission is mostly a process of careful documentation; the 'draft' is the pre-publish stage and the final doc requires review.. In #2, the work starts by publishing the 'draft' which forms the kernel of an in determinant project and is never classified as reviewed. A type #2 document might, but is not required to, end in a separate type #1 document being submitted. Type #2 remains a 'draft'; just one which has evolved. Either type could be singular or collaborative but #1's tend to be singular and #2's tend to be collaborative.

The above is describing the structure of each 'root' PLab 'field of interest'; which should be pre-defined because there's a small, finite number of them -- eg. Mapping, IR, Water, Air, Spectrometry, Oil, etc. This strongly suggests that while one PLab page might show all submitted notes (it's just one cross-sectional view of all notes - latest first for easy review), that is only a programatic view of the site which contains separate categories for each area of interest. Selecting a root topic therefore filters out most of the obviously un-related material which simplifies topic search. Yes, a programatic view option of search could provide related material.

Reply to this comment...


Hi, all - I'll probably post another set of sketches on this soon, but a few followup ideas:

Research note sequences

I've mentioned this before, but the idea would be that you could mark your post as a certain portion of the research, and the published note page would prompt you to (and/or others) to continue the sequence of posts with the "next step" which could be determined from the step you marked this one with.

Connect to other work

A small search form to search for and link to other work this relates to, to better interlink posts.

Charts

A way to input some data in fences (like code) but that would form a graph, maybe like this:

````chart

Reply to this comment...


Very early prototype code here, for playing with a more interactive mockup: https://publiclab.github.io/PublicLab.Editor/examples/

Reply to this comment...


Login to comment.

Public Lab is open for anyone and will always be free. By signing up you'll join a diverse group of community researchers and tap into a lot of grassroots expertise.

Sign up