Inkling – Review Edits

Inkling – Review Edits

Background

At the start of the project, Habitat already had a way to see changes in a document since a previous version – with the Compare Versions feature. However, users only had 2 paths to undo changes – either reverting entirely to a previous version and redoing the approved changes, or manually editing the text to undo the changes they didn't like.

Project Managers were so concerned about the hassle of letting people make changes and having to manually undo what they didn't like that they removed Edit access from some editors and forced them to leave comments requesting their changes. This led to duplication of work – an editor would describe a change, and then a PM would have to go in and make it. Some customers said they had reverted to copy/editing in Microsoft Word, and 1 major publisher (of the 5 we had) was at risk of leaving.

Project Goal: Give project owners insight into changes other users have made, and allow them to easily undo them

The existing Compare Versions. No way to undo individual changes :(

Early Ideas

There was a limited amount of engineering time available, and the PM on the project already had the idea of creating "Suggested Edits" – an interface like Google Docs' Suggestion Mode that would let users without edit access highlight a bit of text and create a suggestion for what to replace it with. The PM or head editor could then approve or reject the suggestion. The approach was desirable from a PM perspective because it could be built on our existing comment system as a subtype of comments.

I sketched out possible interactions for this approach, found behaviours I wanted user feedback on, and turned them into clickthrough prototypes in InVision. I created a list of research questions, and worked with a user researcher to set up research sessions with customers.

We had 2 major insights in our research.

Insight #1: Many suggestions involve formatting changes.

Our comment system used plaintext comments, and it was a huge project to build rich-text editing. I suggested using syntax to explain formatting (e.g. _italic_ or "ital" to suggest making the selected text italic). However, there were myriad possible ways to change formatting, and users did not want to learn a special syntax for them.

Insight #2: There are hundreds of changes per page with each round of editing, of which only a handful will be rejected.

Users asked about being able to "bulk accept" changes, and then undo the ones they didn't like because it would be less work. Everyone referenced Microsoft Word's "Track Changes" feature.

Result

I realised it would make less work for users if they allowed their editors to change the document, and they could review and reject individual changes. It would also allow tracking changes to formatting because Habitat's editor allows rich text.

Iteration

Since we already had the Compare Versions feature that showed the edits since a previous save, it seemed like the logical place to put the ability to undo individual edits. In the first round of research, our publisher customers said this is where they'd look for the feature.

Another approach was to build a layer on top of our regular editor that showed changes like Word's Track Changes. Talking to our engineering team, I discovered that this would be more dev work. However, if users wanted to undo edits and have regular editing capabilities, it'd be much easier to display the changes in our editor rather than building editing capabilities into the Compare Versions modal.

I mocked up both solutions and shared them for feedback in another round of user testing. The users provided numerous examples of times they'd wanted to reject an edit and tweak the text differently, especially on longer edits. Having to switch between Compare Versions and the text editor frequently wouldn't make their workflow any easier.

So we decided to build a layer on top of the editor.

Sketch of the Compare Versions UI with ability to undo individual edits

Design Details

I mocked up wireframes and turned them into clickthrough prototypes to test. There were some complex details to work through – could the reviewing user drop a cursor in text that was marked as edited? Why might it be helpful to show different people's edits in different colours (if at all)? Where would users expect to activate the mode? What info did they need to indicate that they were in Review Edits mode?

We found users had the most trouble in 2 areas:

What does comparing against a save mean? Did selecting the save to compare with mean you were seeing changes since that save, or including those committed with that save? We found that users expected to see the changes including those in that save.

Finding the right save to compare against. This was connected to the previous problem. Because Habitat is a cloud-based editor, we train users to save frequently. For some, that means saving as much as every minute. However, the typical use case is for a PM or editor reviewing all the changes made by whoever worked on it before them. Trawling through a list of 100 saves to get to the right one was annoying.

Wireframe of how undoing an edit would work. Each user's edits are colour-coded – something we found wouldn't scale on projects with 10+ users (not uncommon).

Grouping user saves into "sessions", and using the timeline to indicate that the changes made in these saves would be included.

My solution to both of these problems was to collapse consecutive saves by the same user into "sessions". Clicking "Review Edits" on one of these would show all the edits committed with all of that person's saves, in line with user's mental model of "I want to see all the work that Justin did". It also reduced the length of the list of saves to choose from.

Final Design

After a few more rounds of user testing for usability and review by the design team and engineers, the feature went into development. There was some back and forth with engineering about edge cases I hadn't considered and the specifics of animations.

A big design compromise I had to make was dropping the ability to see who had made a change from V1, with plans to release it quickly afterwards as part of V2 along with other UX changes that we discovered after people had played around with it. My logic was that users cared about what content change they liked best and less about who had made it. As it turned out in the feedback we got, that assumption only held for some users (mostly the ones making corporate learning materials). For publishers, there was a big difference in how comfortable they were rejecting a change by a copy editor made compared to an author. For them, not attributing a change restricted the usefulness of the tool.