Annotate.

Rethinking our desktop experience to extend the way students annotate and discuss our vibrant content on mobile devices.

Client

Next Thought

Role

Lead Designer

Contributions

Concepting

User Flows

Wireframing

Prototyping

UI Design

Shipped

Problem

Annotation is a natural process people perform to consume complex information, elevate important ideas, and create new meaning. In the analog environment, or physical world, we annotate through the use of highlighters and writing instruments, but for online courses, there must be an easier and more constructive way to make notes and keep them.

The mechanics of annotation can be simplified to two behaviors:

  1. Marking up existing information.
  2. Writing reactions to information.

At Next Thought, only our desktop webapp had supported both of these behaviors. It did so by using mental anchors as vantage points for creating comments or making changes. A mental anchor could be a single word, a phrase, a sentence, or a paragraph that elicits a reaction or can be remembered easily. After selecting a specific fragment, an interactive tooltip emerges above the cursor where you can either highlight in one of three colors or leave a comment for yourself or others. Although, this was the core functionality that facilitates annotation across the platform for all content in our courses, it was not a viable option across all technologies. The question became, “How might one select these options on a mobile app or iPad version if there is not a cursor involved?” In August of last year, I was tasked with creating an adaptation that could transfer from device to device.

Process

Meet with Key Stakeholders

I sat down with our Lead Mobile Developer Jonathan Grimes and Head of User Experience Aaron Eskam to get their initial concerns and hopes for the project. On the development side, there were some initial concerns about the placement of the action bar. On desktop we position the action bar above the cursor after a passage of text is selected. On a mobile device, it seemed less optimistic that an action bar could be positioned reliably above the highlighted text without causing problems for our developers. I had already been thinking about positioning it in another location anyway to avoid collision or prevention of the native action bar that Android and iOS display above selected text. On the design side, our main objective was deciding on a scalable solution, adapted for touch devices, with limited differences with our desktop web application. While adhering to these objectives, it also needed to be a simple interaction that would be intuitive to our users.

Ideate, Iterate, Prototype

The earliest, most pressing challenge was deciding where action bar would appear. After some exploration, and considering the top was already dedicated to navigation functions, I decided that the bottom of the browser was the best location for it. This placement, while being more manageable, had the tradeoff of being more off-set and distant from the selection. I made a note later that I would need to introduce motion to the solution so that the entrance of the action bar on screen would be noticed. After this, I began to sketch user flows to decide how someone might add a highlight, remove a highlight, start a new conversation, start a conversation on a highlight, view conversations, and other actions. After the flows were worked out I quickly created some click-through prototypes to get feedback. After a direction was decided, I began iterating through how to visually treat the various states of the UI.

Document the Solution

Following the initial sprint to design all the states and their appearances, I needed to work through state transitions and produce a high-fidelity prototype to show Jonathan so all the micro-interactions were less guess work. After showing the high-fidelity prototype to Jonathan and Aaron, I got signoff for the design to go into production.

Build Together

Something I learned while working at Next Thought was that more often than not design is still happening during the build out phase. Sometimes it is quality control to make sure the developed product matches the design. Other times it is humbly encountering a challenge you did not foresee or the realization that your solution is not working as intended.

On this project I encountered all three. I had designed a solution that was dependent on a stack of scroll behaviors and was causing my mobile developer to pull his hair out. One issue was when writing long comments your cursor could end up positioned under the keyboard. This presented an unfortunate experience where the user would have to swipe down every additional line they added. Because this was not ideal and the way forms work in mobile safari, it required some javascript mastery to prevent. On it’s own it might have been fine, but we were locking the scroll of the underlying content area so your could return to your reading without losing your place. The share with widget also had scroll behavior to see smart suggestions and to expand on scroll. In the end we had to simplify. Instead of making the compose view a modal on top of the content area, we saved your current scroll position and seamlessly re-rendered the view with the compose dialog.

Outcome

The ability for students to select text and highlight it or start rich conversation shipped out to all of our clients’ production environments last fall. We are still waiting to gather analytics to assess how successful the solution has been with our users.

Thanks
for
reading.