Wax Show ‘n’ Tell
Hindawi Limited & Coko Announce Partnership
Coko & eLife partner on first PubSweet fueled journals submission & peer-review platform
Seeding a New Ecosystem: open infrastructure
Take Editoria for a spin
Making decisions in a small team and keeping it fun
A look at the future of journals with xpub
Editoria 1.1: Meet the Automagic Book Builder
A sneak peak at what’s next for PubSweet
Travel the long and winding road to PubSweet
Ink 1.0 is here!
Baby steps to user-centric open source development
Why we’re all in open source now
Getting Started with Coko
Editoria 1.0 preview
Preprints won’t just publish themselves: Why we need centralized services for preprints
INK – the file conversion engine
How we’re building the ‘mountain chalet’ of complex conversions
Sowing the seeds for change in scholarly publishing
Open Source Alliance for Open Science
Editoria Newsletter Out Now!
INK client upgrade
All About INK (explained with cake)
Track Changes (Request for Comments)
Book on Open Source Product Development Method Released!
Italics, Buenos Aires and Coko?
Editoria Update
Where we are with File Conversion
A Typescript for the Web
Coko Celebrates Year One
Editoria – Scholarly Monograph Platform
Adam Hyde’s Blog
Introducing Christos
Introducing Yannis
New PubSweet release
Attribution in Open Source Projects
Open Source for Open Access
Reimagining Preprints: a new generation of early sharing
Introducing Stencila and Nokome Bentley
Reimagining Publishing
Introducing Charlie
PubSweet 1.0 “Science Blogger” alpha 2
PubSweet 1.0 “Science Blogger” alpha, INK 1.0 alpha RELEASES!!!
Collaborative Product Development
Publishing for reproducibility: collaborative input and networked output
Substance Consortium
UCP & CDL Announcement
Release 0.2.0 is here!
CKF receives funding from the Gordon and Betty Moore Foundation to transform research communication
Technology Slows Down Science
[tech post] CSS and Drop Caps
Vote for the pubsweet logo!
Introducing Substance
Digging Collaboration and Cooperation: Code for a New Era
Coko 2015
PubSweet 0.1 Release
Coko Resources
Making science writing smarter
What I Have Learned About Building Community
Introducing the Tech Team
Knowledge and Communication
PKP and CKF Strategic Alliance
CKF Launches
February 13, 2017

Track Changes (Request for Comments)

We would like some feedback from you!

In a recent Design Session, Cindy Fulton and Kate Warne (University of California Press) determined that their Editoria workflow required a ‘track changes’ feature. 

Their basic requirements were clean and simple:

  1. If the user adds text to the document: mark the text as an addition, and give it some color.
  2. If the user deletes existing text: annotate it as a deletion, and put a strikethrough line over it to show that this part has been deleted.
You can see the above 2 requirements implemented in the following animation:

As you can see, a third requirement is that users must also be able to resolve these changes by “accepting” or “rejecting” the suggested change. 

We looked into a lot of different ways to solve these requirements with this additional design restraint: the interface for resolving changes should be in close proximity to the change itself to reduce the amount of cursor movement required to accept or reject a change.

In the image below you can see our first attempt to solve this problem:

As you can see, each change has a small area underneath it that gives you two options: “accept” and “reject.” These areas are always displayed and serve as a visual cue that something has been changed – allowing the user’s eyes to quickly identify all changes in a document. A possible disadvantage is that this may be overwhelming to the eye. More importantly, the ‘accept/reject’ texts tend to dominate the interface and the space needed for these items demands that the document’s line spacing is doubled, which may look a bit awkward to some.

Our second approach did not stray far from the first idea, but rather aimed to ‘tone it down’ a little as you can see below.

There is still an “accept / reject” area underneath the change, but it is only visible for the selected change. With this approach, the interface is cleaner and the line height only needs to change for the line with the active change, keeping things tidier.

But both versions above have a possible limitation. It is possible that future versions will need to display more information about the change. We can easily see why the user would like to see who made the change and when, as this is information that could influence the decision on how to resolve the edit. So, perhaps, we need to think ahead a little. In our next attempt, below, we tried keeping all actions and information in a tooltip. 

Even though some complexity is introduced in the above prototype (especially regarding the potential display of multiple tooltips), it introduces an important new possibility: ‘information space’ where we can display additional options or information related to the change. We can also make the tooltip as large or as small as needed and adjust with minimal effort in future iterations.

The fourth and final version was more consistent with the way annotated comments work in the Editoria editor. This breaks the proximity-to-the- change constraint, but perhaps not by too much.

As you can see, instead of displaying the buttons right under the change, we display a tool with “accept” and “reject” icons on the right edge of the document. This is the least intrusive approach that we could imagine. The problem, however, is again, space. There is minimal area to add new elements in the future without using up the area to the right of the document, which is normally reserved for easily readable comments.

Of course, designing in anticipation of possible future features is also, perhaps, a problematic approach but we enjoyed exploring this a little. We would love to hear your thoughts on all of the above. Please join the new Editoria list below and have you say!!forum/editoria-development

The post written by Yannis Barlas. The track changes prototypes created by the Coko Athens team; Yannis, Christos Kokosias and Alexis Georgantas.

UI in the prototypes by Julien Taquet.

Many thanks to Adam and Alex, since their work with UCP is what made this feature come to the table in the first place.