Tuesday, March 27, 2007

Out Of Office

Hi All! I'm in Munich this week, hence the radio silence. If you are waiting for an e-mail reply, please bear with me. I will endeavour to get back to you as soon as possible. Thanks for your patience! :-)

I'm way behind on blog reading as well, but I did catch what was happening over on 'Creating Passionate Users'. It makes me sick and I hope that swift justice comes to those *#&^% that are causing Kathy such pain.

Ugggh...it's almost 2 AM...time for bed. Cheers!

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

Sunday, March 18, 2007

...And We're Back

Hi Everybody. Sorry about the unscheduled downtime. My provider was moving their data center and screwed up big time. I *think* all of my material is still here, but I still need to go back and verify everything. In the meantime, if you find any broken links or the like, please let me know.

Hmmm...perhaps it's time for me to consider a Domino-based blog template, eh?

For those of you still here...thanks for sticking around and not immediately deleting me from your feeds! ;-)

I'll leave you with some interesting links I've run across recently:

  • Michael Bierut gets honest...This is My Process. Sounds a lot like my approach (not sure if that's good or bad).

  • Ferdy Christant points out a cool open-source project intended to provide you with royalty-free standardized icons and desktop guidelines. Check it out at the Tango Desktop Project.

  • Kathy Sierra shares her Seven Blog Virtues.

  • Last, but certainly not least, a new blogger who is very well known in the Domino community joins us here in the blogsphere. Probably everyone knows this by now, but in case you missed it, Andre Guirard is blogging now. I'm thrilled about this, as I've learned many great tips and tricks from Andre over the years. Welcome, Andre!


Monday, March 12, 2007

No Notes 8 Love For Me??? :-(

Bummer Number 1...I was actually feeling quite ill this weekend, so I was up early on Saturday morning (not being able to breathe and all). I downloaded the Notes 8 beta but as of yet, I still haven't had a chance to play with it. :-(

Bummer Number 2...I mentioned here briefly a few times that my company is currently undergoing a very large merger. My team had a conversations with our new boss today. He seems like a very cool guy...quite knowledgeable about IT, programming background etc. The good thing is that he sees the value in Notes and says it is not going away, at least not for apps (the e-mail question is being evaluated now). The bad thing is that he believes we need to take an internet-centric approach to our applications. Indeed, this is not a bad thing at all, but I did mention to him that our team bleeds yellow and that it will be hard for us to move away from our focus on the client, especially in light of Notes 8 coming along. There are still many decisions to be made and many uncertainties, but my gut tells me we will not be deploying the Notes 8 client. And that, my friends, is truly sad. :-(

Monday, March 05, 2007

Quick Tip: Collapse All In Embedded View

For all of the great things that embedded views offer us in terms of interface mechanisms, there are some gotchas which are a real pain in the (neck, ass, {insert body part of your choice here}). One of the more annoying ones is the inability to set an embedded view using "Show Single Category" to automatically collapse when the container document is opened. This is especially troubling if there is additional categorization in the view, since everything opens expanded.

There are several hacks and work arounds that people have come up with over the years to address this, some better than others. This tip is an enhancement to one of the hacks I found in the ND 4/5 forum on developerWorks. Originally posted by Andes Mygind, this technique opens the embedded view to the category in question, collapses all the entries, expands the first entry and then closes the window. The result is indeed successful, with the embedded view collapsing nicely, as seen in the figure below.

From a user interface perspective, this solution is less than perfect though, since the act of opening the view and performing the necessary actions can actually be seen by the users. It only takes a second or so, but it is visually jarring as the screen quickly changes. To address this UI problem, I decided to apply an old web trick to hide the "behind the scenes" stuff from the user. That is, I used a frameset with two frames, one of which is set to a height of 0. I then just needed to add one additional line to the code, setting the target frame in which all of the actions should occur. I set the properties of the form in question to open in the specified frameset.

Below is the code, which I have found works beautifully:

REM {I placed this code in the PostOpen event of the container form so that the embedded view is collapsed immediately}:

REM {We don't need to do anything if this is a new document...};

REM {First, set the target to the hidden frame...this is where all the action happens};

REM {The first line opens the view to the value we are using in the Show Single Category option};
@Command([OpenView];"YourEmbeddedView"; txt_Key);

REM {This is a call to an agent which doesn't really do anything. I have no idea why this is here really, but this technique doesn't work without it. This agent contains just a single line of code...@Success};

Bonus Tip: When you are testing this in the client, make sure you close the form in design mode. If you don't, the embedded view will continue to stay open and the collapse will never work!

The other neat thing about this technique is that you don't have to place the code in the view's action bar. It can actually be on the container form, which opens up more possibilities for extending the code or for different formatting options.

Finally, in addition to "Collapse All", you can do an "Expand All" in the same way:

@Command([OpenView];"YourEmbeddedView"; txt_Key);

If you have thoughts on this approach or ways to improve it, I welcome them in the comments. Cheers!

Sunday, March 04, 2007

Interface | Matters World Tour 2007

Conference and user group season is in full swing, so here's an update on my upcoming speaking gigs. Of course, we kicked off the year in style at Lotusphere, where I was very honored to be chosen to present in the Best Practices track (thanks Rocky!) and it was doubly cool since I got to do it along with Mr. Freeman.

I forgot to mention the Northeast Ohio User Group Meeting on Feb. 22nd. Thanks for all who attended and listened to me drone on. In case you were looking for it, my presentation can be found here.

This Wednesday (03/07), the good folks at the Central Ohio Notes/Domnio Users' Group asked me to come down to Columbus to give the modified version of BP101 from Lotusphere. I say modified since it combines elements of my sessions from the View as well as the Lotusphere one, minus the really cool demos that Nathan showed (proprietary client stuff). Check out the full agenda for more.

In May (24th-25th), it's across the ocean we go for ILUG 2007! I'm sure most people know about this by now, but if not, hurry to the website and register while you can. This is a FREE event featuring some of the best speakers in the Notes community. Somehow, through a gross error, I got included on that list as well! :-) It's like a mini-Lotusphere in Dublin...how cool is that!!!

Finally, at least for now, is the Lotus Developer2007 conference in Boston June 4 - June 6. This is another excellent event and is being held in conjunction with Admin 2007. I'll be presenting five four sessions including "JavaScript Best Practices", "Creating Dynamic Domino Applications with Advanced CSS", "Leveraging Interface First Design for Top-Notch UIs", and "Advanced Lotus Notes Client UI Techniques" (session titles subject to change).

I hope to see you all at one or more of these events. If you make it, please stop me in the hall, at the dining tent, in the elevator, etc. and say hello.

Update: I'm combining two of my sessions into one for Lotus Developer2007, which leaves me with four sessions total.

Thursday, March 01, 2007

"CoolMail" Demo Deconstructed

OK...A couple of people asked me about the post from last Friday, so I thought I'd detail the technique here. There are a couple of other things going on in that movie which I left out and also a reader suggested a neat trick which I have some future ideas for.

The actual implementation of this functionality is fairly simple. First, you add the buttons, drop down box, , etc., to the form. In the picture below, you see the button to add and remove the star and a combo box.

Remember that these elements are on the form and will be exposed in the embedded editor. Thus, the code should be written with this frame of reference in mind. For example, the code behind the "Remove Star" button is simply:

@SetField("Star"; "0");

On the UI form of the application, I have a simple embedded view/embedded editor combo. Again, there's really nothing special happening here, just the standard functionality where the embedded editor is wired to the embedded view. The only difference is in the way the form is exposed. Usually, you think of embedded editors exposing fields that the user can edit text in. In this case, I'm just showing some controls to do something to the underlying document. All of the design elements on the embedded form are hidden when embedded except for that top line with the buttons.

Et voilĂ !

Here's something you might have missed. See the links on the side and how the highlighted element blends right into the container for the embedded view? This is kind of like the idea of vertical tabs. Unfortunately, doing this with a tabbed table isn't so easy. I think the implementation in the Notes client is not really that good. Instead, I did this with a simple embedded outline. This is a nice technique, since it affords you so many formatting options. I placed the outline in a table and abutted it to the container cell, then just used an image well to color the selected element. The sweet thing about Notes, of course, is that you could do this in several ways.

I was also asked about coloring the lines in the view, so here is my approach. First, I created a color column in the view and set the value to the field called "num_ViewColor". This is a field on the embedded form whose value is computed. The formula behind the "num_ViewColor" field is:

colRed := 255 : 225 : 220 : 0 : 0 : 0;
colBlue := 224: 241: 255 : 0 : 0 : 0 ;
colGreen := 224: 255 : 223 : 0 : 0 : 0;
colYellow := 255 : 255 : 208 : 0 : 0 : 0;
colClear := "";

@If(MoreActions = "More actions...";

Choice := @Right(MoreActions; "...Set ");

Selection := "col" + Choice;


Basically, what this formula is doing is checking the "MoreActions" field, which is the combobox exposed in the embedded editor. If the "MoreActions" field is set to its default value, then the formula just keeps the value of "num_ViewColor" as is. If, however, the user selects a new color from the combobox, the color name is extracted from the user's choice and @Eval sets the new value of "num_ViewColor" to one of the options defined at the beginning of the formula.

One other trick is happening here. If you make a change to an embedded editor and then try to select another document in the embedded view without saving, you get the following error message:

To avoid this, I save the document on PostRecalc event which gets triggered on every change of the combobox. In addition, to make sure the combobox gets reset to "More actions..." after each time the user makes a selection, the QuerySave event includes the line @SetField("MoreActions"; "More actions...").

To wrap up, I wanted to share an idea that was sent to me by Marcos Romero. He commented that you could also perform the action to turn the star on and off by clicking on it, just like in Gmail. To do this, you would use an editable column and InViewEdit feature of the view. To get some insight into how this works, check out the "Rules" folder in your mail file. The icon that denotes whether or not a rule is enabled can be clicked to toggle the rule on or off. This is a cool concept and I have a few ideas of where this could be really useful.

I hope this helps and I look forward to hearing from you on how you might use similar techniques. Until next time...