Wednesday, March 21, 2007

On Not Using Views

At the risk of losing this content in the post-Notes 8 beta buzz, I present to you a purely theoretical, completely opinionated post on working with views in the Notes client. :-)

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 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 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 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.


Nathan T. Freeman said...

"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."

Actually, page turning is EXACTLY what the user would be spending all their time doing. ;-)

Y'know, it's almost not worth telling you great job anymore. Brilliant article, as usual. ho hum. Genius is SOOOOO last January.


Rob McDonagh said...

Dude, you rock.

Rich Waters said...

Well done as usual.

Any recommendations on how to steer clients away from wanting/requesting a million different views?

Richard Moy said...


That was a very good discussion. We just complete working on fixing an application that was developed by another company that had over 50 views in it. As you can imagine, the performance was not very good. Unfortunately, we were not allowed to redesign it but were hired to make additions to it. I have seen a lot of views being used for reports which can easy be replaced by a document generated on the fly using HTML or DXL. We are evern trying to avoid using embedded view and replacing them with DXL generated documents.

Mark Stevens said...

Good stuff as usual. Two questions/ideas I want to throw out to get your thoughts on in regards to embedded views. First, how have you dealt with sizing embedded views for different screen resolutions? In applications where the embedded view is not in a table I have used the "Fit To Window" for height which takes advantage of the additional screen space for users with higher resolutions. For other applications where I have used this in a table I have had to size it specifically for 1024x768 which leaves whitespace for users with higher resolutions. I have just started experimenting with using a Frameset, Form, View, and @SetView Info to do a similar interface as an embedded view. The Form is in the left frame where I compute the list of to 20-30 accounts that are assigned to the user. In the right frame is a view (categorized by account name) and when the user selects an account in the form I use @SetViewInfo to show the category in the right frame. Haven't tested performance yet but do you have any lessons learned/recommendations in this area?

Richard Moy said...


I had the same issue over a year go. It is easy for Notes to resize correctly the embedded view width but the height is never right. After experimenting for a long time, I decided to use regular views in frames and framesets. I had no problems with @SetViewInfo, but you need to reset it in the view if you jump to another view. If not, the @setViewInfo still applies to the new view. I did not see any performance issues, but the size of the view that I was showing was not very large. It only had about 300 to 500 documents in it.

Chris Blatnick said...

@Everyone...thank you! :-)

@Nathan...LOL, so true about the page turning. Maybe we SHOULD try to build in Notes. I think that would be a good challenge! :-D

@Rich...I think the users that ask for a million views probably are familiar with other Notes apps and how they work. Thus, the onus is on us to show them better or alternative ways to display data. In my opinion, the best way to influence them is to build a prototype and demo that they can get all the data they want from your new idea, only better! We have to overcome the momentum of years of Notes applications that were designed exactly the same way.

Chris Blatnick said...

@Richard...neat idea about the DXL generated documents. DXL is definitely an area I need to start wrapping my head around.

@Mark...You bring up a great point and a major downfall of embedded views. As Richard mentions and you've experienced, controlling the width works great but the height is a real problem. Unfortunately, I don't have much to offer in the way of a good solution. I just try to layout the form so that it minimizes the passive whitespace as much as possible.

As far as @SetViewInfo goes, I think it is a great command and I believe your idea has a lot of merit. I have to admit that I've only tried that technique once, but it worked quite well. I may do some comparisons between embedded views and using @SetViewInfo within a frame and see if there is a noticeable difference. If I do, I'll report back here.

Martin Perrie said...

Hi Chris, Another great post.

I wonder if you have any thoughts on presenting search results back to the user where multiple documents could meet the search criteria. We have a number of applications where the user is presented with a search criteria screen. They fill in as much (or as little) as they want and a full text search places the returned documents into a private on first use folder which is then displayed. I think this technique was obtained from something in the sandbox on

Is this the best (only?) solution to this or can you suggest a better way?

Nathan T. Freeman said...

@Martin - Check out my Haystack alpha application on for some ideas on this.

@All - the embedded view not expanding to the height of the available window issue has been reported to IBM. I've got their internal documentation reference number, but I don't think I have a true SPR just yet. I've reported it to multiple people on the Westford team, and I know for a fact that they care.

You might be glad to know that coupled with that issue is having embedded views respect form formulas.

If/when I get an SPR, you'll see me blog about it. :-)

Richard Moy said...


Is this a new SPR request? The height problem has been around for a long time since Notes 6 and maybe even Notes 5 and so has the form formula issue. Also do you know if they are going to fix the problem with defining the database and server from which the view is coming from. This was been a very annoy issue that I have.

Nathan T. Freeman said...

Richard, the height and form formula items seem to be acknowledged as bugs by the people I've talked to in dev. Referencing embeds by server/database, while incredibly desirable, is definitely a feature request. So Bob Balaban is who we have to keep on about that one. :)

Dan Soares said...

Great article Chris... You can bet I will R & D from it :)

I just deployed a new database at work and used a graphical email introduction to it (based on one of your blog entries).

Keep em coming !

Thanks !


Keith said...

I've started creating apps with fewer views and experimenting with displaying data differently. But my problem is customers are wanting drop down boxes that may contain 200 choices. Once they pick a category from the drop down the pertinent documents are displayed in an embedded, single category view. Is there a better way to choose the categories other than having a drop down with 200+ choices? I've made it where they can start typing the category and it'll move accordingly, but it's still kind-of extreme.


Stefanie said...

I'm still having some issues using this methed. It works ok with a regular view but does not collapse single cat.

Now I have a programmable table and on one tab is the embed view with al entries and the 2nd tab has the single category embed view. This way I can view all vs. individual, etc. (Hope this makes sense)

Any suggestions

tlbriley said...

Where I think that you might be off the mark is that you write that there are better ways to find a Notes document than a huge view. Which implies that the main use of a view is to get to a specific document. But over the years, that's not what I see as the main use of a view. What I've seen in my five years of consulting is that the main use of view is for reporting. Managers LOVE to use views as pseudo reports.

Since views are easy to build, the main downside to using them as realtime reportsis the load on the server. On those views that are for reporting only, I'm now saying "fine you can have your 57th view. But it will only update when you hit the refresh button". They seem to be okay with this.

If you think this is a bad idea, that's okay. But how do you do reports?

Chris Blatnick said...

@Timothy...Certainly these thoughts are not "one size fits all" and as always "your mileage may vary". However, I think these points are valid in most cases after having experienced the benefits of this approach time after time. I, too, always used to explain the concept of views as "dynamic reports". Indeed, views are great for showing you the state of documents at that instant in time. Depending on the business application, a report sometimes needs to list all the individual detail and when that is the requirement, views are definitely where it's at. However, I've learned to spend a lot of time drilling the managers on what it is they really want. I want to boil it down and get to the essence of their business problem. More often than not, they are looking for summary information, not line item detail. In these cases, I'll shy away from a view and create a dynamic summary via script, presenting the results as a report "document".

I certainly don't want to give the impression that I never use views for user-facing functionality. I just want developers to think about whether or not its a good idea to actually use them as the default interface element for everything.

tlbriley said...

Well Chris, there's the rub. Getting to the actual person who wants the report without first be tackled in the hallway by the manager you report to because "they already know the answer" is pretty difficult to do at almost any company I did consulting work for.

"What will really hurt you isn't what you don't know. It's what you are convinced that you do know, but happen to wrong about"