If you've seen any of my presentations in the last year or have been reading my blog posts, you probably have heard me say something along the lines of "one of the great things you can do from a usability perspective is get rid of views in your applications." This statement usually elicits quizzical looks and I am often asked what I actually mean by this. This post is an attempt to explain this idea in a little more detail.
We all know that views are one of the biggest drains on performance in an application. The more views you have, the larger and slower the database becomes due to all of the view indices that need to be maintained. If you are an experienced developer, you've probably run across a few applications developed by Notes newbies that have a million views, one for every possible field in the database! :-) Heck, we all probably made at least one of those databases when we were starting out, unless an experienced developer was around to guide us and show us the error of our ways. I'm not going to go into the performance aspects of eliminating views here. Let's just take it as a given that the more you can reduce the number of views you have, the better off you'll be from a pure performance standpoint. Now, what about doing this from a user-centric point of view?
I often think of views as the "plumbing" of an application and as a plumber who cares about his craft, I want to hide the plumbing as much as possible. I like to use views where they make sense, such as providing users with a dynamic list of data within the database. However, when you take a step back and think about the work users have to do in your application, it's interesting to find that "browsing through a long list of documents to find the one I want" is not a part of that work. I like to use the analogy of Amazon.com. Technical limitations aside, what if you could build Amazon in Lotus Notes? Would you use views for your list of books, CDs, movies, etc.? I can just imagine the user scrolling through 1 million plus entries. Hmmm...probably not the most efficient way to find a good page turner. :-)
Business cases are often unique from one application to the next, but one of the fascinating things I found upon introspection on this topic is that I could probably redesign the UI of a great many of my Notes applications to eliminate user-centric views altogether. Most of the time, when a user enters one of my applications, they are doing so with a targeted objective, much like when I browse over to Amazon.com. I don't go to Amazon to "look around". If I want to do that, I'll head on down to my local bookstore. Instead, I use Amazon when I have a specific need. I know I can go there and almost always find what I need with a quick search. Herein lies the key, my friends. I can find what I want quickly and easily because the UI makes it so.
"So if you are not going to use views, how are users supposed to find their documents?", you may ask. The answer to that question is where your creativity as an application designer comes into play. Search is certainly one method available to you, although this generic solution is not always the most effective for business applications. If I think about the typical Notes app, it's some kind of workflow tracking system and the user probably has a key value that they are looking for when they open the database. It might be the customer name, a help ticket reference number, a specific date, etc. If you map out the work process that the user must go through, the most efficient way for them to target a document usually becomes clear. You can then use this information to design your UI around that fact. If the customer account number is the key for your CRM suite, then perhaps you should design a facility to open the account document by this number. This is simple as adding a field in a prominent place in the application UI, somewhere that is always visible and readily available, much like the search box at Amazon.com. You need to write a little code to find the document and then present it in the UI, but this is trivial. What's important here is that you have made the user much more efficient.
Back when I first started this blog, I talked about an application redesign I was involved with in which the general user had access to at most three documents in the whole database. Because of our corporate standards, this database looked like all the rest, with multiple views that might have made sense for the managers that had access to more that three documents, but they were completely wasted on the general end user. Even for the management team, the layout of the views was rather clunky and didn't allow them to find the information they were after easily. As I described in that old post, the whole process was reimagined, and the way users targeted documents was radically changed.
Instead of using views, the end user had three graphical representations of his documents and the color of the graphic would indicate if the document was completed or not. To open one of the document, the user had only to click the button. The users had no need for the views...they just needlessly complicated the UI. True to my form, if an element doesn't have an explicit purpose to be on the screen, it's outta there. Thus, no more views. I did the same thing for the managers (shown above), designing a slightly different implementation but still with a focus on what information they really needed and an emphasis on usability. Good UI design is all about simplicity and I think this case study is a great representation of that idea in action.
This is a good time to throw in one caveat. I shy away from using regular views when they are not necessary, but you know from past posts that I love working with embedded views. Embedded views are an important design element in Lotus Notes. Used properly, embedded views allow you to keep the user engaged in the context of their work, which is one of our goals in designing usable software.
So what are some of the guidelines you should follow when determining if you should build your database with user facing views?
Find vs. Browse: In my mind, the most important thing you need to do is map the user's work process as it relates to the application. This will allow you to answer the question of whether they will mostly browse for content or perform a targeted search process. If the majority of work will be targeted search, then you won't need many (or any) user-centric views. Instead, the UI should allow the user to open a specific document with a minimum number of clicks (e.g. enter the part number and click 'Go').
Don't make users do the hard work: If you use views in your application to summarize data, consider tossing the views in favor of a "report". I was involved in an extensive application redesign that was used by all managers around the world to get their monthly IT costs. Managers had to go into these enormous views, find their department and then reference all of their total spend. When I conducted user interviews based on this process, I found that the majority of managers just wanted to know one value. If they stayed within their budget for the month, they didn't care about anything else. Rather than continue the inefficient process that the old application used, I redesigned the application UI to make it a simple two step process...(1) enter your department and (2) get a nice summary document with the pertinent details. I created this document in the backend via LotusScript. It was a little more work for me, but the managers loved the time savings. I was able to make these modifications without changing the underlying plumbing of the database but made drastic usability improvements (and eliminated the use of views in the process)!
Learn to say No: A former colleague of mine was recently wondering about this concept and how to handle the users who demand everything. She said, "My customers always seem to want a million views - By status, by date, by requester, by priority, etc." My response to this is pretty much encapsulated in this article, but it brings up one important point which is true of software design in general. Sometimes, you just have to say 'No'. The reality is that we are the subject matter experts when it comes to application design, so we shouldn't just blindly do whatever the customer asks us to. It's in their best interest (and ours) to design simple, attractive and usable interfaces. Often this means having features fight for their lives. If the users are asking for a million views, question them on this. Ask them why they need them and what they are really looking to get. You may find that you actually do have to include all of these views and that's fine. But you might find that they are just used to Notes applications and think "that's the way it has to be done". Maybe they just want the totals at the bottom of the view. In that case, present the numbers in a nice dashboard or summary screen on the homepage and eliminate the view all together.
Look at other successful applications: As much as I sometimes hate the hype surrounding the term "Web 2.0", one thing is clear: There are lots of new applications out there that are redefining user interface development. Some of these apps, while perhaps somewhat trivial, are a joy to work with. Tom Duff talks about the importance of R&D...Rob & Duplicate :-) and I couldn't agree more. If you find an application that just works, spend some time analyzing it and ask yourself what it is about the app that turns you on. Then, go back to Notes and cry. Just kidding...actually, go back to the Notes client with an open mind. Allow yourself to be creative and see if you can replicate some of these great features in your design. If you look at many successful applications, they don't really have anything that looks like Notes views.
I hope this post has given you some food for thought. These concepts represent one of the tenants of Notes design that I've developed over the past few years and have seemed to serve me well. What do you think? As always, I welcome your comments and opinions.