Daniel Nacamuli is an Interaction Designer out of Method’s London studio. We’ll be pulling in some weekly posts from his Tumblr showcasing his thoughts around various user interfaces.
This week, we’re featuring his thoughts on Instapaper, an article filing service for browsers, iOS devices, and the Kindle. Daniel highlights some of the common interface problems he experiences with Instapaper, and how he imagines things could potentially be improved.
I was having a think about how to improve Instapaper’s article filing process on the iPhone. In this post I’ll go through some of the problems in the current implementation, and at the end offer a potential workaround.
Instapaper is a web service that saves articles for later reading on browsers, iOS devices, and Kindle. The service saves articles via its “Read Later” bookmarklet and presents them using a clean, minimal layout. On portable devices the articles can be read offline in the associated app. It’s a fantastic piece of software.
Articles appear in a Read Later folder, and from several places in the app can be deleted, moved to user defined folders, or archived. For the rest of this post I’ll refer to moving, archiving and deleting as ancillary actions or filing.
Filers become Pilers
I spoke to a few people and they all have a common problem with Instapaper: even though they can file articles from the reading view, they do this far less often than they would like to. This could be seen as a user problem, but if people use a feature less than they want to, I prefer to see it as an interface problem. I’ll be focusing on how we can improve the filing process when we have finished reading an article.
How filing is currently done
In the next three screens I’ll illustrate the user flow for filing articles from the reading view and highlight some of the problems along the way.
Access the ancillary actions using the Action button.
This feels a bit awkward: our thumb’s dominant role on this screen is to scroll, therefore it rests naturally on the left hand side of the screen. Accessing the action button requires that we aim for and tap the bottom right corner.
An action sheet gives access to ancillary actions.
Delete and Move to Archive can be done in one tap. The apparition of the modal overlay jars with the reading experience, and visually feels heavy compared to the app’s flat UI. Previously hidden, the status bar also drops into place for no apparent reason (though this may be a property of the action sheet).
Move to personal folder.
From the action sheet, tapping the Move to Folder… button enters another mode from which we choose which personal folder we want to move the article to.
So in the current implementation the use of an action sheet for ancillary actions has a few problems:
- Accessing it does not feel like a logical next step after reading
- Hidden behind a button its function is invisible to the user
- The filing actions take two to three taps to complete
- The transitions are visually noisy
How filing could be improved
Let’s take a look at an easier way to file when we have reached the end of an article. Going back to the first screen, if my thumb is here…
…maybe the ancillary actions could appear here too: inline at the end of the article.
This gives us a few advantages:
- With my thumb near the controls, filing feels like the next logical step after reading.
- Filing becomes modeless: no more noisy animations.
- Everything can be done in one tap.
The existing action button still gives us access to the share features and lets us file from anywhere in the article; so this isn’t mean to replace it.