Over the last few releases of the Bipsync Notes iOS app we’ve been gradually improving the usability of the note editor. With the release of version 1.10.2 we’ve reached a point where we thought it might be nice to discuss the changes, and the thought processes behind them.
This is what the note editor looked like a handful of versions ago:
There were a few issues with this design which I’ll quickly summarise.
Firstly, the note title is displayed in the navigation bar, and truncated should it exceed the available space. More often than not this was the case, especially on smaller devices like the iPhones 5 and 5s. To edit the title, one had to first tap the properties icon located in the top right of the screen in order to access a form:
This meant that editing a note’s title was a chore that involved several taps, and a couple of users fed back to us that they considered it unwieldy.
Since the title is often the first thing a user will edit when creating a note, we were concerned it was adding undue friction to a note taking process that we want to be effortless. So we clearly needed to relocate the title field to somewhere it was much easier to access.
Secondly, the properties view had grown from simple beginnings such that it now contained not only fields for basic note properties, like title and lock status, but also gateways to views that exposed the note’s sharing and tagging properties.
Adding a tag to a note involved at least three taps, plus typing to search for one or more tags to attribute to a note. The same was true for the process of sharing a note with other Bipsync users. Again, this was all much too convoluted for our liking.
Finally, we had made attachments accessible from an icon in the bottom left hand corner of the editor view. Locating attachments when a tap was required to expose them might not sound too problematic, but when you consider that our users tend to create notes that have no body text and several attachments, it made for a frustrating experience for them tapping to open a note, seeing a blank view, and tapping once again to get to the attachment list. We wanted attachments to be much more immediate, given their importance to users.
This is how the note editor looks as of the latest release:
We’ve made a number of changes which we think improves the usability of the app dramatically.
The title field has been moved into the editor itself and placed above the body text. This mirrors the editor in the web app version of Bipsync and should feel more natural to our users. We’re also able to show the title in its entirety, with no truncation. The navigation bar now looks much less cluttered and there’s more room for the back button which, depending on the previous view in the hierarchy, can contain a substantial amount of text.
The properties icon remains in the top right corner, but the view it exposes has been much simplified. Instead of a full screen modal popup, we now show a smaller popover when the button is tapped:
We were able to reduce the content of the properties view by virtue of moving the title to the editor body and adding dedicated buttons to the bottom toolbar for the remaining functional properties from the view, namely tagging, sharing and locking status. Each of these now has a presence in the toolbar (locking status sits behind a new “more actions” button) which makes them more visible and accessible. Apple’s UI guidelines suggest that actions belong in a toolbar, so we’re following best practice for the platform.
(You might also notice the new “comments” button – we added support for note comments in version 1.10.0).
Tapping the “more actions” button launches an action sheet that consists of the less frequently used note actions, like locking. At the moment locking is the only action that features in the list, but when we add support for note subscriptions in the near future that action will likely be located here too.
We may also move the delete function here eventually to free up space in the toolbar for incoming features that are likely to be popular, such as native iOS sharing. This approach mirrors the one Apple takes with their tab-based apps that have more functions than can be accommodated in the tab bar.
Finally, we dramatically changed the way attachments appear within the app. Where before they were listed in a modal view, now they’re included within the note body, in a similar way to the note title:
This change means that should a note have no text content its attachments will be front and centre as soon as the note is opened, saving the user a tap. It’s a similar approach to Apple’s own in the iOS Mail app, where email attachments appear after the email body. We expect it to make note referencing a much more pleasant experience for those users who create a lot of notes that consist solely of attachments.
We also considered the positioning of the icons in the bottom toolbar. We decided to order them left to right in order of how likely a user was to use them, based on our usage analytics. This led to an order which placed sharing ahead of tagging, commenting, deletion and locking. Overall, we feel that these changes have really improved the usability of the note editor.
In future we hope that we can continue to further improve the experience.
One change we’d love to make is to automatically focus the title field when a new note is created, so the user can begin typing right away without needing to first tap the field. Unfortunately focussing a field in the manner we use it isn’t currently supported in iOS, but we’ve submitted a bug report to Apple and asked them to rectify this in a future version of the platform.
We’re also considering changing the way the editor behaves so that it uses a tab bar rather than a toolbar to switch between functions like note taking, sharing, tagging etc.
This would mean that each function would retain its own UI state, and the user could flick between them much more easily as the tab bar would remain on screen permanently, instead of being hidden by a modal popup as it is now. There are some restrictions around the use of tab bar controllers on iOS that we’d need to investigate first, but we could potentially roll our own solution too.