"Try rapid prototyping some of your interface improvement ideas, using the techniques covered in the course.
The First Draft of your design that is due need not be very good, but you must submit something by the deadline. The deadline coerces you to get started. Then you'll find it much easier to make several more redesigns before the final deadline.
You can use paper, a drawing package, or any software you feel comfortable with. It is expected that as you iterate you will move up to using technologies that permit greater simulation of functionality. You do not have to end up with a working system however, just pictures to enable you to talk through the improved interface. "
The primary conceptual consideration for the first design draft is dealing with the issue of space. Evernote's web interface attempts to fit all of its content and functionality into multiple panes on a single static screen, and many of the difficulties and confusions revealed by heuristic analysis and user testing spring from that decision. This design will attempt to divide up Evernote's functionality into multiple screens or dynamically-generated views, allowing both for better user focus on the task at hand, and for a more transparent and straightforward interface.
This is an initial framework that should make it easier to fix many of the smaller task-based problems encountered in testing in future iterations.
This would be the default view when you log in to the application. More customizability in term of pane proportions, sorting of content, default levels of detail about content, etc are envisioned here. This is also intended to allow for more of a guided / faceted iterative search process taking place in the Right pane, which will be detailed in a later version.
Screen 1: Default View, Content Retrieval and Selection.
You get the view below when you click on one of the edit buttons. Similar new screens will be generated for other actions.
Screen 2: Edit View
For the second iteration, it seemed appropriate to try to address some of the cross-platform issues found in user testing by examining how Evernote works on other platforms, and seeking ways to integrate and regularize the web-based interface with the others. Additionally, examining the mobile and tablet interfaces in particular seemed like it would be a rich source of inspiration and ideas for implementing the more minimalist and task-focused approach outlined in Iteration #1
Evernote Tablet Interface
Investigations into the desktop and iPhone interfaces for Evernote offered small hints as to design changes, but ultimately the former had too many of the same problems as the web interface, and the latter was so minimal and stripped-down that it drastically impacted functionality. However, Evernote's tablet interface was an intriguing balance of minimalism and function, and turned out to share a lot with the ideas sketched out in the first iteration. It pointed the way towards a better and more specific implementation for many of the concepts sketched out above.
The reading/editing mode from the tablet was particularly influential on this iteration, as it suggested a clear way to separate tasks and divide the interface up modally.
Read/edit mode on the tablet app.
The tablet application's retrieval/browse mode was also intriguing, especially for its far-less-cluttered implementation of browsing as compared to the web application. Elements of this (especially the slick pane view for individual notes and the easy collapse/expand functionality for the columns) will make the final iteration, but a wholesale lifting seems unwise in light of the transparency and obfuscation problems that even the busy web interface has.
Note-based browsing on the tablet app.
Notebook-based browsing on the tablet app.
Examination of the tablet interface suggestion an approach that divides the interface and its functionality into two broad modes: Retrieval/Search, and Read/Write. The retrieval/search interface would retain more of a traditional desktop/sovereign posture, while the read/write interface would be specialized and transient. The minimalist WriteRoom
application on the Mac was also an inspiration for this decision, as both reading and writing are more discrete tasks that require intense and focused concentration, and thus removing interface distractions for these two tasks was a desireable course of action.
In this implementation, the search and retrieval interface from Iteration #1 is retained.
The search/retrieval inteface. Same as iteration #1.
While the reading/editing interface is replaced by a popup/overlay, that pushes focus solely to the task at hand and minimizes everything else.
Concept for the new read/write overlay.
The final iteration will complete the browsing and retrieval parts of the interface, and create a fully fleshed out, screenshot-quality mockup of the interface that uses the framework laid out in the first two conceptual mockups to address the specific issues identified by the heuristic analysis and user testing.
Iteration #3 fleshes out the browsing/retrieval interface, shows how the whole interface would work together, and addresses some of the specific design loose ends left over from the testing and analysis stage.
Browsing and Retrieval
The new browsing interface combines the best elements of the previous web interface and the tablet interface. Many interface elements that were previously hidden or non-transparently labeled are now easy to find and use. Multiple different views are available for browsing content, and the panes can be collapsed or adjusted for easier browsing. Removing reading and editing from this view means that space can be used more efficiently, and thus the design is less cramped and busy than before, allowing larger excerpts, different content views, and ultimately enabling more content to be browsed and scanned efficiently and comfortably.
The browsing interface. (Click for full size.)
The reading interface is now a separate popup/overlay, invoked whenever the user double-clicks on a note excerpt in the browsing interface. The popup interface focuses the user in on the task of reading, and removes the distractions and clutter that used to be ever-present when reading happened in a pane within the browsing interface. This also allows the edit functions to be segregated from browsing as well, and the reader's options for working with a given note are now clearly delineated at the top of the reading interface. Sharing is also integrated at the level of reading a particular note, which is the most sensible point in the workflow to place it.
The reading interface. (Click for full size.)
The editing interface is just a state-change of the reading interface, and has all of the same advantages over the previous setup that the reading interface had. Other particular fixes here are getting all of the content organization tools in one, non-hidden place, changing the "Done" button to "Save" to make the invoked action clear, and fixing the autosave indicator to be crystal-clear about the current state of changes.
The editing interface. (Click for full size.)
The fully integrated layout in both browsing and editing mode. The only changes not noted in the above breakouts are the addition of a "Home" link to the menu bar, an a reduction in the size of the Evernote logo.
The Full layout, in Default / Browse mode. (Click for full size.)
Clicking on a note excerpt or the "New Note" button causes the read/edit interface to pop up and overlay the default / browse interface. The opacity effect applied to the background page helps focus the user in on the reading/editing task at hand.
The Full layout, in Read / Edit mode. (Click for full size.)
Design Issues Not Addressed Above
The only major issue from testing not addressed above is the failure mode when an edit is in progress and the network connection is lost. The interface behaved very inconsistently in this state, sometimes warning the user when they tried to take an action without network connectivity, sometimes not, and sometimes only warning when the "Back" button on the browser was pressed after the user got stuck on a screen.
A simple solution for this would be to have the application poll for connectivity on every autosave attempt, and when connectivity is not present, to always invoke the dialogue box (pictured below) that was only inconsistently invoked before, and to change the wording to indicate that current changes have not been saved, and indicate what the best course of action is to ensure no data is lost.
The Network Connectivity Lost dialogue box.
Several concepts from Cooper at al's About Face: The Essentials of Interaction Design
were integral to the conception and execution of this project.
The first concept is platform, which is the technological and physical medium that an interface "runs on" and/or controls. Evernote has a presence on a variety of platforms, from phones to tablets to desktop applications to a web application, and each version is doing different and not altogether complementary things. Although this exercise only involved Evernote's interface on one platform(the web), platform was ever-present in this work, as much of it was about trying to tease out which of the design decisions were platform-constrained, and which were just made for the sake of aesthetics or convention or out of inertia. Looking at implementations on other platforms also helped for design inspiration, and it's clear that the constraints involved in some of those platforms inspired Evernote's designers to more innovative and elegant solutions than the less constrained web application environment did.
Posture is another key concept from Cooper et al. Posture is primarily about attention. Is this application designed to be a primary locus of user attention, like a word processor that might be used for hours on end to write a paper? Or is it more of a helper application, that pops up, does its thing, and then goes away again? These two modes are called sovereign
, and for the note-taking use-cases involved here, it's not always so easy to make a clear-cut decision about which posture is appropriate.
Some note-taking apps are obviously transient. The ever-present Sticky Notes apps on a variety of platforms are a classic example of this. They're invoked, the user jots down a quick note, and then they go back to the background again until they are needed.
A classic transient Sticky Notes app.
However, lots of other note-taking and organization apps behave more like sovereign applications. DevonThink for the Mac is a good example of this. It's more like a combination of a note-taking app, a file explorer, and relational database, and it aims to suck in and organize/relate basically all of the content the user reads or creates, and ultimately to organize her life.
Devonthink, a note-taking app with a sovereign posture. (Click for full size.)
What about Evernote? Is this a sovereign application that the user is supposed to be spending a lot of primary time in, or is it a transient helper app? Often Evernote seems conflicted about whether its primary mission is to supplement other applications or to be a main and attention-hogging locus of user activity. The balance between these postures also varies across the platforms, but not in a way that indicates assigned roles on each platform (e.g. minimal mobile platforms are used on the go to feed info back into a centralized desktop or web application base, and retrieve small bits of content on the run when necessary, or another such platform-specialized implementation.) This is another way in which it's clear that the cross-platform design process wasn't very unified.
One answer to this question is that it is both, but at different times. The note-writing, reading, and editing process is more transient, collecting and dispensing information supplementally while the user is working primarily in other sovereign applications like browsers, email clients, and word processors. However, the browsing, search, retrieval and organization components do behave more like a sovereign application, and when the user periodically dives into their note database to organize and tag things, set up saved search queries, or do deep research in a given area, they will be paying primary attention to Evernote. This was the inspiration for the decision to separate out the interface into two separate modes, one for reading and editing, and the other for browsing and retrieval.
This brings us to the final key concepts from Cooper et al, modality and flow. Modality is about how interfaces change modes (or don't change... sometimes elements are re-used, or sometimes many interface elements are all present in the same static mode) to fit the tasks they perform, and flow is about the smooth and intuitive transition between those modes. Evernote's web application is not very modal, and tries to fit every task into one minimally-changing single-screen view. The tablet and phone apps are much more highly modal, with discrete popup or overlay interfaces for most tasks. This obviously has something to do with screen space constraints, but those constraints also made the developers and designers think a lot harder about modality and flow on those platforms than they had to for the desktop and web interfaces, with correspondingly better and more innovative results.
This redesign consciously turned the Evernote web interface into a multi-modal interface, with clear transitions and flow between different tasks. This allowed the interface elements for each discrete task to be labeled and displayed much more clearly, opened up space in each task-specific interface to give the user more room to work with, and removed unnecessary distractions that might hinder the user in acomplishing a given task.
Other note-taking apps can be either very modal and task-centric, or very non-modal. The distinction seems to be whether the primary focus is on the note-taking act itself (modal, like lightweight popup sticky-notes apps) or on organizing and reading your notes and research (like DevonThink or other heavy-duty database apps that mimic desktop email client interfaces and file explorers). There are many tradeoffs involved here, but Evernote seems to be aiming somewhere between those two models, and so adding some modality and breaking up the interface into a few discrete elements was the best way to get some of the advantages of specialized, modal interfaces, while still retaining some pieces of rich, multi-task functionality, especially in the browsing/retrieval parts of the interface.
Two major issues for future work would be an overhaul of the advanced search interface and work towards even closer cross-platform interface integration.
The browsing framework from this redesign was conceived with faceted searching in mind, with the facets to be located in the left column which would change the notes displayed on the right. Time and resource constraints prevented a full implementation of this, but in principle this would have worked to de-obfuscate the search process and the interface options inolved in the same way this was done for the browsing and sorting process.
This design also made some progress towards cross-platform integration, bringing the web application more in line with the tablet application, and also somewhat closer to the desktop application (which is rather less cluttered and more transparent than the web application was). Still, ideally all of these interfaces would behave somewhat more consistently across platforms. Obviously each platform has its strengths, weaknesses, and constraints, and some specialization must occur to account for these, but an examination of Evernote's current offerings does not points towards a unified design process that diverged where necessary and appropriate.
Rather, it looks as if the applications were designed by separate teams who were not in close communication with one another, and who did not strive for a consistent user experience across platforms and mediums. A process with more time and resources would have taken in Evernote on all platforms instead of just the web interface, and done its best to integrate these interfaces as well as possible within the contraints of the platforms and the designers and developers.
Cooper, A., Reimann, R. and Cronin, D. "About Face: The Essentials of Interaction Design, 3rd Edition." Indianapolis, IN: Wiley Publishing, Inc. 2007.
Lewis, C. and Rieman, J. "Task-Centered User Interface Design: A Practical Introduction." 1993. Retrieved from http://hcibib.org/tcuid/
Molich, R. and Nielsen, J. "Improving a human-computer dialogue: What designers know about traditional interface design." Communications of the ACM, 33 (March 1990), pp. 338-342.
Nielsen, J. "Finding usability problems through heuristic evaluation." Proc. CHI'92 Conference on Human Factors in Computer Systems. New York: ACM, 1992, pp. 373-380.
Nielsen, J. "Usability Engineering." San Diego, CA: Academic Press, 1992.