Epic Fail...Error Message Worst Practices (And How To Fix Them)
Error messages...the bane of users. We all dread the software crash or programmatic wrong turn that sends our productivity crashing into a brick wall. To add insult to injury, I think most of us would be hard pressed to find examples of good error messages in the software we use. Remember that one of the key goals of interface design to strive for is making the interface unobtrusive so that the user can focus on the task at hand, not on how to use the software. When users encounter an error, we are rudely pulling them out of their productive work and bringing the deficiency of our application to the front of their attention. If we can't avoid the situation that brings forth the error, the least we can do is handle it in a graceful and helpful way. Sadly, this concept seems to be the exception rather than the rule. I've often found that it's useful to perform some analysis of applications that fail to meet user expectations in order to learn better ways to do something. Let's look at some examples of error messages gone awry (the worst practices) and then figure out to fix them.
OK...thanks for that
And why, pray tell, am I not?
Eh? I don't speak Klingon.
Oh yeah...System error &H80004005. How stupid of me to forget!
Not only have you offended me sir, but you've scorched my retinas!
If only the girls at school were that easy.
The thing that all of these messages have in common is that they don't result in an action. That is, the best they do (and that is arguable) is tell the user something went wrong, but they don't address the most important part of the whole event..."WHAT SHOULD I DO ABOUT IT?!!!" If you were asked to determine the disposition of this user after encountering such error messages, what would you imagine they would say? Yeah...something along the lines of "Oh crap...here we go again with this piece of $*&@! application!" And you know what, I certainly wouldn't blame them for thinking that! Some errors are certainly worse than others. The most heinous offenders are those that only provide a very technical message that accomplishes nothing but making the user even more anxious.
The error messages that at least provide a "plain English" (or insert your language of choice here) description of the error are better than nothing, but are still not doing things quite right. Another sign of a bad error message is one that does not give any indication of whether the machine/software was at fault of if the error was due to the user's actions (e.g. stack overflow from a numeric calculation vs. user entered text in a number field). All in all, these bad characteristics and worst practices end up making the user feel stupid. Since our work as developers is supposed to be empowering users, then presenting them with less than perfect error messages means we've failed in that task.
So...now that we know what NOT to do, how do we go about fixing the problem? An important aspect of good error messages is that they provide enough information to the user so that he or she is clear about what to do next. The best error messages have some common elements:
*They tell the user what went wrong in plain English and do not make the user feel like they screwed up.
*They avoid technical jargon. If the programmer is the only person that understands the message, it is bad.
*They send an automated report to the developer (see the amazing OpenLog, created by Julian "The Genius" Robichaux. If you're not using OpenLog, you're doing it wrong!)
*Most of all, they tell the user what to do next.
That last point is critical. What the user should do as a next action will depend greatly on your environment, your policies and procedures and the error in question. Maybe it just tells the users to "Press Ctrl-C to copy this error to the clipboard and paste it into a new mail message. Send this message, along with the title of the error, to the help desk". Or it could give the user explicit instructions such as "Enter passcode 4331 into the highlighted field and press the enter key". What really matters is that the user is not left wondering what to do next. The error message should guide them to the next steps. The next action might not fix their problem, but it will at least let the user move on.
Here are a couple of good examples I swiped from the net. These messages address the criteria stated above. Notice the (in)famous Twitter "Fail Whale". No one ever said error messages had to be grey and boring.
I really love this one. It goes into extensive detail on what to do next. Do all of your errors have to be this detailed? No...but in some cases it might help.
The Fail Whale is fun and informative.
Remember that unexpected errors immediately cause users to cease being productive and often make them freak out. By anticipating possible errors and constructing good responses using the elements cited above, you'll be able to minimize the disruption and get the user on their way with the least amount of fuss.
So my call to action for you today is to review the applications you are currently working on. If your custom designed errors are more like the worst practices than the best practices, make it a point to fix them. Make them clear, helpful and actionable. Your users will thank you.
By now, if you are a member of the Lotus community in any way, shape or form, you've probably seen the great new press release that articulates the momentum we've been gaining (quarter after quarter) over our competitors. It's so great to see the commitment we've all made to this platform be validated in real world terms. I, for one, welcome our new Lotus Notes overlords. ;-)
In light of all the great press and positive upswing I've seen out in the wild lately, I thought it was interesting that I had the following conversation the other day. I was at a meeting with a customer...a large financial institution. They are a long-time Lotus customer and really do a great job taking advantage of the Notes platform. After a successful meeting, I was standing out in the hall talking with one of the VPs and he said to me, "We use Lotus Notes for so many things, especially workflow applications, but they are getting pretty long in the tooth." I was not expecting that comment, but I immediately knew what he was referring to. The thousands of applications this customer has are still providing a lot of business value, but the problem is...many of them look and feel old. In other words, the interface is what makes him think that perhaps it's time to do something new. I've been around long enough to know that this is not a new sentiment, but it's one worth shedding a little light on.
One of Lotus Notes' greatest strengths can also be its bane. With Notes, you can rapidly roll out a solution that addresses a business problem, usually faster than your colleagues that use some other technology. I've seen many of these applications continue providing great value to a company many years after they were initially deployed. The 100% backward compatibility allows these databases to keep on working version after version. This brings us to the problem of the interface, however. If an application was created in...let's say R4...that application is already over a decade old. If changes to the UI haven't been made, then of course it is going to look antiquated. Both the technology and interface conventions have changed a lot in that time and user expectations have greatly morphed in that period as well.
Here's the real truth: As developers, we no longer have the luxury of creating application that work but don't look good. You can't say "I don't do UI" any more, lest you want the Notes platform to disappear. The users of today are computer literate or at least savvy enough to know a good application experience from a bad one. The internet and Web 2.0 has established a precedent when it comes to usability and user interface design and we ignore this precedent at our own peril.
So...is Lotus Notes long in the tooth? Is it a tired platform that we need to send to the old folks home? Of course not. The fact is, the future for Lotus Notes is brighter than it's been for a long time. It is necessary, however, to start treating it like the modern development platform it is and that means that developers need to take a look at themselves and see if they have the requisite skills to create compelling UIs and usable applications on the Notes platform. If you feel you are deficient in this area, then here's my call to action:
- Start thinking about the user interface at the very beginning of your project. You don't necessarily have to use low-fidelity prototyping, but the interface shouldn't be an afterthought.
- Make usability testing a part of your standard development methodology. Then actually listen to what your users have to say and make the appropriate changes.
- Sharpen your technical design skills. Learn how to use a graphics program such as Photoshop or Paint Shop Pro. Really learn CSS and JavaScript so that your web apps can look and function like they are modern day creations.
- Stop making all your Notes apps look the same as you did 10 years ago. Yes...I'm talking to you! :-) At a minimum, begin utilizing the User Experience Guidelines for IBM Rich Client Applications. Better than that, though, is to make clean and simple interfaces that support what your users are doing in your application...no more, no less.
I know many developers think the interface is touchy feely stuff, but the reality is that our software is judged by its looks. Lotus Notes now has a pretty face. Do your applications? If your users think that Lotus Notes is "long in the tooth", then your choice is clear...start fixing those interfaces or put them out to pasture.
Do you think about the simple bits that make using your application, website, etc., easier for end users? With the continuing specialization of certain applications, both within the firewall and out, I find that users are frequently interacting with these applications for very small chunks of time. Usually it is in the context of looking up some item of data, and it made me reflect on the ways I've tried to simplify life for end users, especially in light of short transactions. Here are some examples:
Putting an address all on one line so that it is easy to copy and paste into Google Maps or another system (e.g. 50 S. Front Street, Columbus, Ohio, United States 43215). When in edit mode, you would probably split the address up into its component fields, but this is a great technique since it allows the user to initiate a copy and paste action with a single selection. This concept applies equally well to other data elements that are made up of multiple parts. I constantly look up addresses so this idea is one I really love, but I don't come across it too often.
Type-ahead for frequently used names, words, phrases, etc. If users are constantly typing in the same text over and over again, be nice and give them a type-ahead mechanism. If something prevents you from using this technique (an old version of the software, for example), be creative and try to build some way for them to easily retrieve these common values (profile docs for individual users work nicely).
Pad link targets and buttons so that your user doesn't have to use a magnifying glass to find and click on a hotspot. The guys at 37Signals provided a couple of nice examples on their blog a few weeks back.
Provide an easy way to link to the current page of information. Sending a link (be it to a web page or an internal application) is something most users do all the time. We've been spoiled with doclinks in the Notes client for so long, but if you're not in the client (or even if you are but your users don't know how to make doclinks), simplifying this with some code that copies the current address to the clipboard with a single click or a similar idea goes a long way.
When in doubt, keep it simple! I've run across many applications that should have been great, but were hobbled by poor layout and even worse...too much visual clutter on the screen. This rule applies across the board, but is really important in the context of micro-experiences. If the user is coming in quickly to get some data and get out, the more you can facilitate this experience and make it a fast one, the happier your users will be.
So those are a few of the rules I try to follow...how about you?
If there's a particular drum I bang over and over again, it's the "keep it simple, stupid" drum. This term has almost become a cliché , but hey, "if the shoe fits, wear it". (Oh sorry, that was bad...just couldn't help myself ;-)
Anyway, when I was doing project work, I was always the guy advocating for people to "take it slow", "do things in stages", "no big bangs", "Amazon wasn't built in a day", etc., etc. I believe that quick, iterative steps yield better results, less bugs and get you to the end goal faster than big, monumental projects. The problem, it seems, is that companies like to have big, monumental projects. The bigger the company, the more monumental the projects seem to be. I think this is dead wrong. It's not the way our brains work, it's not the way people are most efficient and looking at the abysmal failure of so many IT projects, it sure doesn't seem to be the way to run a business. So why do we keep doing it? I guess if I knew the answer, I'd be running a shop somewhere instead of pushing software. :-)
In my "To Read" stack of magazines, I recently came across a jewel of an article in the April 2008 issue of Baseline. The cover story in this issue was a piece outlining the failure and eventual redemption of Symantec's new ERP implementation. A classic "big, monumental project", it was undertaken without really understanding the needs of the very people that would be using it. As they found out, such an oversight almost completely crippled their business. In the end, what saved them was a new project that put the focus on the user experience.
I don't want to rehash the article here...I highly recommend you go and read it...but I do want to point it out as a prime example of a project gone wrong because the final end goal wasn't made clear. That final end goal always has to answer the question "Who is going to be using this and how will this project help them do their job". If you're not asking this question and getting the answer in your project, then you are doing your users a disservice. Keep their goals in the forefront...that's why you're there.
By now many of you have probably seen the great little comic on the "It's Just a Bunch of Stuff That Happens" site about Simplicity, but if not follow the link then come right back...
Pretty true to life, eh? I recognized the bottom example in many, many (many, many, MANY) Notes applications I have seen through the years and I'm sure you did too, which is why we all thought it was so funny in a sad sort of way. But I tell you what my friends, the idea of simplicity is sorely lacking in the enterprise software world and this causes an undue amount of headaches for our customers, for our bosses and for ourselves. Is there something we can do about it? Absolutely. We can say no to complexity in the applications that we design.
To be fair, although the comic is funny, it's not really being equitable as it compares Google and Apple to an enterprise application, but the idea is not so bad. One of the tenants I've tried to instill in younger developers as I've mentored them is that complex business rules do not necessitate complex interfaces. In fact, I think the opposite is true. We need to work even harder to streamline and simplify the interface when the complexity of the business world rears its ugly head. We're all overwhelmed with the amount of data we have to deal with on a daily basis, so we appreciate (and even long for) those things that are easy to use. If we're trying to delight our customers and make their experience in our applications a pleasant one, what better way to achieve this than to employ our skills to craft a simple solution.
Here's an example from my own experience. Some of you have seen this in my talks at Lotusphere or the View conference, but it bears repeating. I worked for a few years for a "global tire manufacturer headquartered in Akron, OH". They had a pretty mature Notes infrastructure that had been around for quite a few years and some pretty complex systems were developed in Notes by IBM consultants there. One of these was a beast of an application called Vendor Billing, but I affectionately called it the Hellspawn. (OK...I didn't really call it that at the time, but in thinking back I should have!). The Hellspan was one of those systems that you dread to come across when you're a consultant. A multi-tentacled, multi-NSF monstrosity that had become more and more bloated over time, since developers just added new features without refactoring or thinking about what future consequences their design choices might make. I don't believe anyone did this out of lack of skill or with any ill will toward future developers, but rather the reality of a complex business process coupled with a desire to make changes quickly and cheaply provided the perfect environment for such a system to come into being.
Vendor Billing...excuse me...Hellspawn, was a system designed to gather up information about all the various IT services an employee at Great Big Tire Company made use of. This was managed through a series of documents that basically captured the services a given person was "subscribed" to. In addition, other databases in the Hellspawn suite stored employee department information, billing codes, rates, etc. It also interfaced with some of the company financial systems that were not in Notes. At the end of each month, some *really* nasty and complex agents gathered up the information from the various databases, determined how large each user's mail file was, spun around twice and sacrificed a chicken to the Gods of Complexity and spit out a document for each user that listed their costs for the various services. All of this was pretty much backend stuff and this far was hidden from the eyes of the users (thank goodness!). Unfortunately, the final result, that cost document, was used in a series of views that the end users would interact with.
For a good 29 or 30 days out of the month, the users were blissfully unaware of the evils that were going on within the Hellspawn, but when it came time to for managers to review their charges for that month, there was no escaping the task to be done. At this time, a manager would open the database and navigate to the main billing view. Within this huge, *horizontally-scrolling* view, the manager could see the totals for each subscription for each of his employees. On average, each manager spent about 30 minutes figuring out their IT charges and it certainly wasn't a fun or efficient way to spend half an hour.
I was first introduced to the Hellspawn shortly after I started at Great Big Tire Company and I'll admit that I was a bit scared of it at first. Certainly the idea of Simplicity was far from the minds of the people that developed it. I've no doubt that they were smart folks. There were custom LotusScript classes to perform operations on linked lists and the like. I'm quite convinced that some programmers make things more complex than they need to be simply to show off their "mad skilz". There's certainly a place for that, but in my opinion it's not in enterprise applications. Thus, my first thought as I looked at this beast was that it needed to be simplified...greatly!
I started, as I often do, by building some quick prototypes that distilled the basic essence of the application down to a single question: "What were the charges for my department?" Once I determined that this was what this system was really trying to tell the end user, the interface became quite obvious and instead of a massive view with the ability to navigate to other massive views, it was just a single field to enter the department number a la the Google search box. When a manager entered their department (which was of course remembered for the next time) and clicked the button, the new code I wrote went out and gathered up the required numbers and showed them on a new document which functioned as the "monthly report". This was formatted in a clean and simple way, such that they really needed to spend no more than 30 seconds checking their numbers. That's a pretty decent time savings per month per manager, eh?
As I worked on the new UI, I also spent a great deal of time under the hood, trimming things, refactoring code to make it easier to read and hopefully more efficient. Even though the business rules were still complex, I strove to make the managing of those business rules as simple as possible. This is our challenge as application developers and is as much an art as it is a science. Based on the hundreds of Notes apps I've seen in my career, here are some ideas to get you started:
1. Not every database needs a three pane UI. As Nathan is fond of saying, "It doesn't all have to look like mail!". Pick the UI layout that makes the most sense for the task at hand.
2. Skinny down your forms and pages. Most developers try to cram too much into a single screen. Instead of this approach, try a more fluid design that brings the most important information for the current task to the forefront of the user's attention.
3. Use views wisely. Not only are views one of the biggest performance hogs, but it's not necessarily efficient to use a view to find what you are looking for. Provide other mechanisms to getting at the data in your app, such as a document search like in my example above.
4. Examine other apps that you find easy to use and try to determine the reason why you like them. See if you can bring some of these themes into your own applications. A great example of this is an ajax-type ahead feature. It was immediately evident when we first saw examples of this technique that it would be useful, but I really feel now that it is almost a must have. It's such a great device for simplifying data entry in many situations and I try to incorporate it into my designs whenever I can.
5. Think outside the box. Yep, it's a cliché but it's still true. Sit down with a piece of paper and make your design as simple as you can, trying to forget the bounds of what you can do within the client. Then, once your design is done, jump in and figure out how the heck you are going to do it. For me, this has been a powerful technique, as I've come up with some great interface tricks by "drawing myself into a corner". :-)
As my life and work gets busier and busier by the day, I am more convinced than ever that simplicity is one of the greatest gifts a designer, engineer, boss or politician can give us. I'm sure many of you feel the same, so strive to make the idea of Simplicity an integral concept in all of your designs and save your users (and yourself) from the Hellspawn.
I got asked a question the other day that I didn't have a great answer to. A reader wanted to know of a way to limit the number of characters that could be typed into a field (e,g. restrict the user's entry to 30 characters). I don't remember having a business requirement like that in a Lotus Notes application for a long time, but in the past I'm sure I would have handled it with some form of input translation or validation formula using @Length. I'm vaguely aware of a script library I had at some point that probably included some code to do this, but it's long lost in the catacombs of old databases from past jobs. Regardless, I knew that any of those old solutions would be far from elegant in today's interface. Nope, what I needed was to whip up a fresh approach that presented a modern UI experience. Here are the characteristics I would want if I was implementing this feature:
-Immediate feedback about how many characters I have left -Automatic trimming of my text entry once I hit the maximum number of characters -Unobtrusive changes to the UI as I enter a length restricted field -A flexible and simple way to implement the functionality multiple times on the same form.
I've seen many good examples of this in practice in web design before, so my first inclination was to use JavaScript. Of course, I'm not a huge fan of JS in the Lotus Notes client due to it's somewhat dubious support (at least in my experience), but I thought it should be able to handle this. Turns out that this is pretty easy to do. Here's a little snippet of the idea in action:
Click image for animated version
So to accomplish this, I first concentrated on putting together the JavaScript to handle the trimming and on-the-fly update of how many characters were remaining in the given field. On the web this would usually be accomplished with calls to onKeyDown and onKeyUp, but these are not exposed in the Notes object model. Instead, I leveraged the setInterval method of JavaScript. This method allows you to call a function over and over every x seconds. Using this concept, the function gets called as soon as the user enters the field and quits when they leave. Here's what I ended up with.
First, the code that does the checking. I tried to make it fairly generic.
The textLimiter function accepts the name of the field to be checked, the name of the field that serves as the counter and the maximum number of characters as arguments. In the If statement, we compare the number of characters (inputField.value.length) to the maximum allowed. If the string in the given field is longer than the max, we use the substring function to trim it to the appropriate length. If not, then we know we haven't reached the max length yet and the user can still type characters into the field. As they do so, the Else statement updates the value of the counter field by subtracting the length of the string in the given field from the maximum allowed number of characters. Pretty simple, no?
That's all that is housed in the JS Header of the Notes form. Now let's take a look at one of the fields that implements this code. For purposes of this example, I added the functionality to two fields. For each, I used the onFocus event of the field to initiate the call to the textLimiter function and used onBlur to clear the setInterval method. You can see how this appears in the "UserTitle" field below:
(Editor's Note: I used some creative editing to show the two events in the same screenshot)
As you can see in the onFocus event, I just set some variables for the given field then use setInterval to call the textLimiter function every 10ms. inputName is the name of the field you are limiting the characters in, counterName is the name of the field that is counting down the number of characters remaining and charLimit is the maximum number of characters allowed in the input field. The onBlur event includes the call to clearInterval, which means the client will stop invoking textLimiter as soon as we exit the field. (We'll skip the other stuff for now and come back to it later).
Notice in the screenshot above that I include a field to serve as the counter for each input field that I am checking. The display properties of this field are completely up to you. I chose to implement this field as an editable field with the field delimiters hidden. This allows you to update the value while giving the appearance of a computed for display field or a piece of computed text. By the way, I originally was going to use a hidden field as the counter and just place computed text where it was needed to refer to the hidden field. However, this would necessitate almost constant refreshing of the screen, which in my experience leads to a less than stellar UI performance. Keep in mind that however you plan to approach this, you need to have an editable text field somewhere so that your JavaScript code can write into it.
With just those few pieces in place, the functionality works quite nicely. As you type in the given field, the text underneath updates you with a message as to how many characters you have remaining. It's not enough to stop here, though. In order to keep the screen as streamlined as possible, I don't want any user input messages to be displayed except for when I need them. This speaks to the third point in my list of requirements. What I want to happen is for the helper text to appear as soon as I enter the field and disappear as soon as I leave it. That's where the rest of the code comes in.
I chose to implement the dynamic nature of this functionality with simple hide-when formulas. I placed the helper text on a separate line, then set it's hide when formula to hidden except when the "CheckField" counter was equal to the name of the counter's corresponding input field.
To trigger the display of the counter when the user enters the field, it is necessary to tell Notes what line we should be showing and then perform a refresh of the document (or the less expensive RefreshHideFormulas if you're not recalculating anything). That's where a little hack comes into play. See the button at the top of the form? This button has a single line of code - @Command([ViewRefreshFields]). You can trigger this via JavaScript in order to call a refresh of the document. Thus, in our example, when the user clicks into the UserTitle field, the following two lines work to display the counter:
The first line sets the value of "CheckField" to the name of the input field that corresponds to this counter and the second line "clicks" the hidden button, refreshing the doc and showing the counter line. When the user exits the field, we just do the reverse, setting "CheckField" to null and refreshing the document again to hide the counter.
When you put all this stuff together, you get a nice little bit of functionality. It accomplishes the goal of restricting user input and does so in a fairly elegant way. You also get a handy little example database where you can try this out yourself.
Now, since that's all out of the way, I'd like to hear how you would improve this. As I said, my experience with JavaScript in the client is pretty minimal and I may have missed some obvious places to make this easier. This was a pretty quick proof of concept and I'm sure there is room to make it better. For example, the "hack" to refresh the document via JavaScript is a pretty old one, but I've not come across any other solutions for it in recent years. If you have some ideas to make this functionality better, please share with the rest of the class by including a comment.
Addendum: Well, what do you know. Had I not already done the work and typed up half of this post, I would have just quit this as it turns out that Mr. Robichaux has done something very similar. Our approaches were quite alike, but I think this one has at least one advantage in that it keeps the field trimmed at the set number of characters. In any case, if you'd like to see how he tackled the problem, check it out here.
Hey...Why Should I Care About The Interface? (Or...That's Just Touchy Feely Stuff, Isn't It?)
Hi all...
Because I'm a big fan of code reuse, I'm going to shamelessly copy and paste an essay I wrote when I first moderated a forum for LotusUserGroup. It's about why I think UI design in Lotus Notes is necessary and I believe it's an important talking point. I'm finding that as organizations are getting serious about deploying Notes 8, more developers than ever are interested in the concepts of usability and interface design. I've noticed an uptick in the amount of mail I'm getting from people who have just found my site, so this also serves as a good introduction to what this place is all about. Cheers!
------------
If there is one question I have been asked most often by Notes developers, it is "Why do you spend so much time designing the interface for your applications?". The one line answer to this is "Because to the user...your interface IS the application". Because of the very nature of our jobs as developers, we tend to get wrapped up in the technical details. We love to come up with innovative new tricks, revel in writing a particularly efficient block of code and geek out when it comes to the latest and greatest technology. All of this, however, pretty much means squat to the guy or gal sitting in front of the screen trying to actually do something with your masterpiece. Users don´t really care about what´s behind the curtain. Rather, they are interested in one thing when they are using your application..."How can I get my job done quickly, efficiently and easily?!"
The goal of any good interface is that it should be unobtrusive. You´ll often hear designers talk about "getting the interface out of the way". This is your ideal to strive for. When your user can enter a flow state and accomplish the task he or she set out to do, WITHOUT having to think about how to USE the application, then your job as a designer has been highly successful. To put it another way, the developer is given the task to make the product transparent to the user. The goal isn´t to get people to like your application...it is to make it so that they don´t really notice the application at all. In the end, a clean, usable interface means happy users.
"OK...enough with the touchy, feely stuff", you say. "My users are business professionals...they don´t care what it looks like as long as it gets the job done!" Boy, have I heard this more than a few times. In a few special cases this might be true, but believe me, for the most part your users DO care. There are many benefits to designing a good interface. Although somewhat hard to put an ROI on, good UI design often saves money, since the users tend to request fewer changes. User acceptance of the applications is almost always higher than when the interface is ignored and users report greater satisfaction with the end result. Remember that it is human nature to want to use things that are functional and attractive. This fact is what makes the iPod such a spectacular hit. It´s just one of many MP3 players, so what makes it so great? The combination of aesthetics and usability (it´s so easy even grandma can use it) help it stand out in the crowd. To bring it closer to home, if you´ve ever had a user choose an inferior product over another more robust one simply because "it looks better", then you´ve experienced why interface matters. Perception plays a huge part in satisfaction.
So...if you are convinced that designing a good, usable interface is important, how do you go about accomplishing that task? There are many ways to start learning about usability. There are several great books on the subject and many websites that are great resources. I´ll post a listing of my favorites in a separate thread. My main point of advice for Notes developers would be to practice what I call an "interface first" design methodology. Basically, I use a pretty typical RAD approach to Notes development, but I have factored in UI design as a major component of that. The initial efforts that take place with an interface first design approach focus on determining what the user will see and do in the application. I am concerned at the very beginning with what the UI will actually look like because how the user will work with the interface elements usually has a direct impact on the code you have to write. As an example, I had a complex application in which multiple "child" documents had to be created for a given "parent" document. I could have simply used the standard Document and Response type forms with all the functionality that Notes provides for me, but in doing the initial UI design work, we came up with a much more elegant and simplified solution...at least simplified from the user´s perspective. In the end, the design used an embedded view/embedded editor model, which was harder to code but made the UI extremely easy for the end users, who were all new to Notes. Had we not focused on the interface in the beginning design stage, the application would not have been nearly as successful.
Employing an interface first approach takes a little getting used to in the beginning, but pays huge dividends in the end. How many times have you gathered specifications from a user, built the functionality and delivered it, only to have the user tell you that it´s not really what they wanted? Be honest...it´s probably more times than you´d like to admit. Have you ever thought up a cool design feature that you were sure they would LOVE, only to find out that they don´t use it, or worse, don´t LIKE it? I´m sure this has happened to the best of us. By using an interface first design method, you can avoid many of these problems. It´s not fool-proof, but it gets you a lot closer to the desired end result a lot faster than traditional methods.
So what does using an interface first approach actually mean? By using this method, you actually build the interface for your application BEFORE you write a lick of code. This can take many different forms, but essentially involves drawing out what all of the screens will look like as a first step. I use low-fidelity prototyping for all of my projects. This is just a fancy name for sketching out the interface on paper...using pencil, pen, crayons...whatever you have handy. Some people prefer to use HTML or a graphics program to design screen layouts. This is fine too, but takes more work. After I have gathered enough requirements so that I feel I have a good grasp of what the user is looking for, I grab a stack of fresh blank paper and jump into the design process. I draw out the fields, sections, graphics...everything that I expect will be a part of the application interface. This doesn´t have to look good. In fact, I encourage you to not spend a lot of time drawing these screens. They´re very likely to change and you might have to do this several times.
After your paper prototype is complete, schedule another meeting with your customer. Ask them to look at the screens and give you feedback. This can be formal (conducting a full-fledged usability testing session) or very informal...whatever you are more comfortable with. Take time to explore different scenarios. If your database is for entering customer complaints, ask the user to take the role of a customer service representative and have them walk through what they would do while looking at your paper prototype. Ask them to talk out loud as they do this, explaining each action. You´ll be amazed at the insight this gives you into the mind of the user. When you find something that doesn´t belong on the form, cross it out with a marker. Need to add some new fields? Just draw them in with a new color. See why it´s good not to spend a lot of time tweaking your prototype? You´ll end up changing them a lot.
When you come back from your initial paper prototype session you may be surprised at how much has changed. If you nailed it the first time, good for you! More often than not, however, you´ve got some changes to make. Quite literally, you should go back to the drawing board and build the next iteration. For a typical application, I will build about two or three paper prototypes. This may seem like a lot of work, but in reality doesn´t take too long.
So...you´ve built your paper prototypes, gone through some iterations with your users and have a pretty good feel for what the interface will look like and how the application will function. Now what? Now, go about your business...doing what you do best. Start slinging your code, basing it not only on the business requirements, but also on the interface requirements that you´ve collaboratively developed along with the user. By designing the interface first, you are already halfway to user acceptance and in my experience, have also made the users more passionate about the application. They feel invested in it much more than in traditional programming methods, where you may have only met with them once or twice. When you finally deliver that application, I guarantee it will be almost exactly what the customer asked for...and that, my friends, is exactly why we do this!
I've not read a lot of the "Dummies" series, but whenever I've picked one up, I've been impressed by the quality of the product. "Web Usability For Dummies" is no exception. In about 300 pages, the authors do a good job of laying the foundation for a solid understanding of the important aspects of usability. It looks like this book might be out of print now, but you can probably find a copy at your local library or via Amazon.com.
What I particularly liked about this book was the focus the authors give to the Usability Design Cycle. This is a process that helps answer questions about designing for usability and is broken into six steps that are performed in an iterative fashion. The usability design cycle starts with "Study the user", then leads to "Set goals", "Design", "Build", "Test" and finally "Deliver product". It's truly a cycle since the process should be iterative, each part building upon the previous step. As the authors state in the beginning of the first chapter, there are many good books out there that focus on the "build" part, but not nearly enough on setting goals, designing or testing, which arguably are the most important. Thus, they make this the thrust of the book and why I think it's worth picking up.
Chapter 1 begins the book with an overview of what web usability is all about. This leads into a discussion about studying your users (the first part of the usability design cycle) in Chapter 2. Sharp readers will remember that Mary Beth and her team kicked off the whole Notes 8 project by doing this very thing...studying what the users of Lotus Notes wanted, how they interacted with the software, etc. While the focus of this book is clearly on web design for external websites, there are enough nuggets of information that you can use for internally driven sites or application design in general. I liked the section in Chapter 2 that dealt with actual customer visits. I think this is something more developers need to do and this part of the book might help you become a little more comfortable with the process.
Chapter 3 looks into the whys and wherefores of setting goals for your website. This includes issues such as determining what needs of your users you really want to meet, creating actual business goals, using metrics and setting goals for the site's usability. This chapter rounds out the first part of the book.
Part II of "Web Usability for Dummies" (Chapters 4-6) is all about the design of usable sites and includes topics such as organization and site navigation. Part III (Chapters 7-9) explores the concepts involved in creating usable web pages. Since this book is several years old, there are bits and pieces which aren't really relevant anymore, but as a whole the ideas are still pretty solid. If you're a Notes developer who is just interested in usability in general, you can probably skip these parts of the book, as they are pretty specific to the web.
The final parts of the book deals with "Reaching a Broad Audience" (Part IV, Chapters 10-12) and "The Part of Tens" (Part V, Chapters 13-16). Subjects touched on include broadening the appeal of your site as well and several nice lists such as Do's & Don'ts, ten cool tools for usability, etc. Chapters 11 & 12 are my favorites since they deal with (surprise, surprise) usability testing! The authors feel that this subject is important enough to warrant two chapters and this book is probably worth tracking down just for their advice on the matter.
When all is said and done, "Web Usability For Dummies" is a fun, quick read presented in the standard Dummies fashion. Experienced designers may not find a lot of new material here, but this book would serve as a great introduction to many of the important concepts in the field of usability. With used copies available on Amazon for as little as $3.20, it wouldn't be a bad investment to add this to your reading pile. While certain chapters may not directly pertain to the work you are doing, the first part and last part of the book provide a very compelling case for usability and are certainly worth the cost of admission.
You've heard me talk about simplicity quite a bit on this blog and in my presentations. It's really one of the most important things I stress to designers. The easier you can make your software to use, the happier your users will be.
For a bit of fun and some insight into the art of simplicity (and some enjoyable Microsoft bashing as well ;-), check out this great TED Talk featuring David Pogue, tech writer for the New York Times.
One of the must have books on my reference shelf is "Don't Make Me Think, A Common Sense Approach to Web Usability" by Steve Krug. I've recommended this book to many people, so I thought it was about time to give it a proper review.
One of the things that first drew me to this book when it first appeared was the subtitle. I've said it again and again, but it bears repeating...much of the "science" of good UI design is just common sense. This begs the question as to why some people find it so hard, and I think the answer lies in the idea of common sense in our society. We are so busy being busy that oftentimes we don't slow down enough to really *think* about a problem and thus the common sense solution eludes us. A book like "Don't Make Me Think" is a great way to make you put on the brakes a little and examine the fundamental principles of usability. For those of you that aren't web developers, don't be scared off. Although the focus of Mr. Krug's book is web design, most of the concepts are equally extensible to other design work, such as building a UI in the Lotus Notes client.
If you've not read any books on interface design or usability before, this book provides the perfect intro into that world. As he mentions in the forward, this book is for those people or companies that don't have a usability professional on board or can't hire one for some reason or another. If you're like most Notes shops, you probably have a small budget since we can do so much with so little. By taking the ideas introduced in "Don't Make Me Think" you can be on your way to doing this work yourself very quickly.
The author's writing style is both casual and witty and he follows the advice of his title when explaining new concepts, breaking it down so you can understand the underlying psychology without getting bogged down in terminology or theory. Chapter 1 begins with an introduction to what the author calls "Krug's First Law of Usability": "Don't Make Me Think". Simply put, this means that your ultimate goal is to design your interface so that when you look at it, it is immediately evident what you can do and how you go about doing it. In this chapter, Krug explores some of the elements of design that put more cognitive load on us than is necessary and then demonstrates ways to reduce this load. This is done through both the narrative as well as excellent graphics which simply but elegantly display his point.
Chapters 2 through 5 begin the exploration of how we really go about using an interface and set forth the guiding principles we need to be thinking about when designing. First, Krug talks about the difference in what we design for (reading, more reading and even more reading in a set pattern) vs. the reality of how people scan through an interface in a seemingly chaotic way. He then extends on the lessons learned here by helping you understand the techniques you can use to design interfaces for scanning rather than reading. He addresses five important things you can do to achieve the goal of capturing user eyeballs as much as possible: creating a clear visual hierarchy, breaking pages into clearly defined areas, minimizing ui noise, making clickable elements obviously clickable and taking advantage of established UI conventions. This first section wraps up with a discussion of why we like "mindless" choices and the importance of good copywriting and how you need to omit all but the essential words in your design.
Chapters 6 and 7 focus on the elements that Krug believes you must get right in your design. Chapter 6 is concerned with laying out the fundamentals behind good navigation. Since this is an area I call a lot of bad designs out on, it's one that I really enjoyed. Krug discusses some of the basic concepts of navigation and why navigation is so important to a user. He deconstructs various navigation conventions and explains why they work or don't work effectively. He also addresses the good use of search, page names, breadcrumbs, and the tab metaphor. Chapter 6 ends with a number of great graphics which show several sites as they were designed and the author's analysis of what was wrong. He then shows a revised version based on what he would do and in some cases also shows the company's own effort at making some improvements. As they say, a picture is worth a thousand words, so it would be good for the reader to spend some time pouring over these excellent examples. Chapter 7 is devoted to the design of the homepage and how to best design that important first impression. As in Chapter 6, there are a lot of great "before and after" examples to round out the theory.
The next two chapters of "Don't Make Me Think" are concerned with how you make sure you did the right things in your design. That is, they focus on one of my favorite topics, the idea of usability testing. In particular, Krug wants the user to walk away after reading these chapters realizing that usability testing is within reach of every single developer out there. Sure, in the ideal world we'd all have a department of usability experts that are there to critique our designs and help us craft the most user-friendly interfaces possible, but we all know that our day to day jobs are far from the ideal world. Still, Krug argues, you can find value in any amount of testing you can do. Krug espouses some common sense thoughts about usability testing, such as the idea that it is an iterative process, that you should test early and often and that testing even one user is better than testing none. Once he convinces you of the importance of usability testing, he presents some simple to follow instructions on how you can carry out your own tests. As he points out, it doesn't have to be expensive or fancy. You really can do this stuff on a shoestring budget. Chapter 9 ends with a sample excerpt from a test session, which in my opinion is probably worth the cost of the book right there.
Krug wraps up the final chapters of the book with a focus on the larger concerns of interface design, such as why usability should be considered a common courtesy, where accessibility comes into the picture and how to deal with a boss that "doesn't get it". If you just want to cut to the chase and start improving your designs right away you can skip these chapters, but they do a nice job of summarizing at a high level many of the salient points of the book.
All in all, "Don't Make Me Think" is a thoroughly enjoyable read and a very practical book for those that aspire to create better interfaces for their users. Coming in at just under 200 pages with lots of clear illustrations, you can probably read this book in a couple of evenings, which is great for those of us intimidated by the 1000 page tomes that populate the computer section in most bookstores. Probably the best part of "Don't Make Me Think" is that it applicable to the work you are doing today. You can read a chapter or two and immediately start putting the concepts into practice and the value you'll get as you do so far exceeds the book's cover price. "Don't Make Me Think" is highly recommended and I hope you make the decision to add it to your reading list today. You don't even have to think about it! :-)
If you've been around here for awhile or seen any of my presentations, you've heard me speak a little on the concept know as flow. When building your interface, the absolute ideal that you should be striving for is helping your users achieve a flow state, that frame of mind in which everything else seems to fall away and you become completely immersed in your task, distractions are eliminated and time flys ("I've been doing this for 5 hours??? It seems like 5 minutes!"). There's a new article on A List Apart that describes this much more elegantly than I can, so you may want to head on over there and check it out.
So...some interesting results from the last post. I think that more people counted 14 passes than anything, although I think it is really 15. There's one hand off that's a bit hard to see. In any case, the number of passes really doesn't matter. What does matter is the fact that a lot of you didn't even see the gorilla walk through the video while you were intent on your task of counting passes of the basketball.
(If at this point you are saying, "What Gorilla???!!!", go ahead and watch the video again, not focusing on anything in particular this time, and be amazed. :-)
So, why did so many of us not even recognize the fact that a guy in a gorilla costume walked through the middle of the clip and beat his chest? The answer lies in how our brain works. In particular, it demonstrates a phenomenon called inattentional blindness...not being able to see things that are actually there.
There's a lot of good information available on the internet and in books on this subject, so I won't rehash it here. What I do want to point out is that you can use your knowledge of this phenomenon when you are thinking about the design of your applications.
Doug hit the nail on the head in the comments when he said "Or in Notes-land; What do you mean, you didn't see that grey button on the grey background sitting right there in front of your face at the top of the screen mixed in with all of that color and action on the rest of the form? You know the one that says 'HELP'? Weren't you LOOKING????"
I have found on numerous occasions where a user missed an important interface element due to innattentional blindness. In every case, the UI was so cluttered and complex that they really had to concentrate on accomplishing the task at hand. When they needed a certain function (that big button in the middle of the screen flashing "Click Me...Click Me"!), they completely overlooked it because their focus was elsewhere.
Being that I'm operating on only a few hours of sleep over the last couple of days, I'll cut to the chase. This experiment that you just went through should help reiterate the fact that your interface needs to be fine tuned so that the users can see and find the elements they need when they need them. For me, I'm a big fan of the concept of "less is more". As I'm working on a prototype, I make elements fight for their lives to get on the page. I attempt to keep things as basic and streamlined as possible. When you can get rid of a lot of the visual noise and concentrate on designing the flow of the form so that it guides the user where they should go, amazing things happen.
Keep this video in mind as you work on future designs so that your users will clearly see the "monkey in the middle". And if you want to hear more of this UI mumbo jumbo, make sure you come to BP214, BP216 and BP217 at the 'sphere! P.S. If you have an app that needs some help, bring it to Lotusphere and maybe someone can help get you started down the right path. Details in the next post.
Hello, my friends! Long time, no see. That's because my new employer has me signed up for so many training courses, I can barely come up for air! :-D One thing I can unequivocally guarantee...if you work for IBM, you will never be bored...haha!
Anyway, my next couple of posts will be asking for your help. I really think (and hope) that you will be able to come through on this one. Here's the deal. I am working on a new project and am looking to gather examples of really bad user interface designs. Now, bad color choices and related types of problems are pretty prevalent in Notes applications (and I certainly welcome those), but what I'm really hoping to find are those things that go beyond the surface. Do you have an application that is just incredibly hard to use for one reason or another? Is there a particular interface element used in a way that completely goes against its intended purpose? Basically, if the UI is poor in any way, I'm interested in seeing it. The worse it is, the better for me! :-)
Here are the ground rules:
1. All information you send me will be kept completely confidential. I'll credit you as contributing to the project if you'd like, but things will be modified so that the original design won't necessarily be identifiable when I show it.
2. Make sure you delete any company data from the application. Send me a clean database copy and populate it with some fake data if you can (just enough so we can see the problem).
3. If you want, go ahead and clean out any identifying company logos, names, etc.. If you don't want to do this, that's fine...I'll make sure I do it in Photoshop when I create my screenshots.
4. Send all submissions to chris@interfacematters.com. Please use the subject "Bad UI Design Submission".
Basically, this project will be something that can be shared with the community and will be for educational purposes. The intent is not to point out bad developers or anything of the kind. I'm sure *ALL* of us can find some applications that we'd rather hide in the closet than let anyone see today. However, I think they'll be some great benefits that come out of this, so I really welcome and respectfully request your submissions. That's all I can say about it for now, but I think it will be fun.
If you have any questions about this, please let me know, either in the comments here or via e-mail. Thanks in advance for your help!!! :-)
One aspect of usability that I haven't spent a lot of time exploring here is accessibility. Depending on your company or industry, this is a subject that may or may not mean a lot to you. A simple definition of accessibility is that it is concerned with making all of the functions of your application readily available to as many people as possible, regardless of ability. This may take the form of a well-designed webpage that behaves properly when accessed by a screen reader device for a visually handicapped user or making sure that if you design a drag & drop feature that there is an equivalent way to carry out the action for a user that is unable to use a mouse. Certainly making your applications completely accessible can add an entirely new dimension of complexity to the design process, but you can start by taking small steps when you are working in your prototype phase (you *are* usingLFPs, right?). When you are working on an initial design for an application, take some time to consider any challenges various user types might encounter when working with your application. Then, try to figure out ways to mitigate these challenges while still providing a compelling experience for the majority of your users.
Let's take a very common example from Lotus Notes applications. Almost everyone can find at least one app in their environment that has views that utilize colored icons to denote some kind of status. Maybe it is a project tracking program and the adherence to the project schedule is represented by a red, green or yellow icon. Pretty standard, right, and easy to understand? Yep, most certainly...unless you are color blind. In this case, those icons might all look the same and without some other type of indicator, that user cannot determine which projects are in trouble and which are doing well.
How might we rectify this situation for our color blind user while maintaining our simple paradigm of using icons to denote status (which allows us to effectively use our screen real estate to show other important info)? One idea would be a slight redesign to use different shape icons in addition to different colors. Thus, our initial design becomes:
With this very simple tweak, we can still make effective use of icons to relay document information, still use color (which in this case is a powerful metaphor) and enhance the accessibility of our application for our visually challenged friend. Not a bad day's work for a small investment in time.
Accessibility is, as you would expect, a very broad topic and I've just scratched the surface with a simple example. What I hope to accomplish with this post is to get you thinking about the topic so it can be in the back of your mind the next time your start working on a design. Anytime you can overcome these small hurdles, your application is on its way to better usability. Good for you!
UI Best Practice: If They Can't Do It, Don't Show It
Following up on my post regarding UI best practices, here's one of my favorites:
If you have a certain action, section, field, etc., that should only be accessible to a certain user/role, then please, please, please do not show that construct to someone that doesn't have the rights to do something with it.
I cringe every time I encounter a database with an "Edit" action button always visible when I know full well that there is security enabled and most users will click this button only to get an error message. It's really very simple...Spend the extra few seconds/minutes it takes you as a developer to write a hide-when formula to make sure that only people that can really edit the document see the button.
Did you ever want to include a little icon or picture directly next to a document in a view that you could click on to initiate an action? You see this on the web all the time, especially in the "Web 2.0" world. This tip will show you how to accomplish this within the Lotus Notes client. I think it's a pretty cool little trick and I hope you will as well.
Here's the scenario. Remember the Super Burrito Configurator? Well, one part of this (over the top) demo is the ability to construct your meal by dragging the ingredients to the burrito image. This generates a list, which is just a folder that you are adding new documents to. Since I'm using an embedded folder, I didn't want to pollute it with action bars, selection margins or other view riffraff. What we are looking for here is a nice, clean and obvious solution. Notes views don't provide many affordances. Unless you are trained in the software, you don't know that you can select a document, go up to the Actions menu and select Folder - Remove From Folder. Even if you know how to do it, who wants to??!!! It's too cumbersome. So, what I ended up with is something that looks like this:
Notice the icon with the word 'Delete' directly next to each burrito filing? Clicking on the icon does exactly what you would expect...deletes the ingredient from your burrito. In Notes terminology, it just removes the document from the folder. Pretty cool, eh?
The secret here is to take advantage of the view's InViewEdit event. When you click on an editable column, the code in this event will run. Since I'm just removing the doc from the folder, it's very simple LotusScript: I don't have to mess with the various cases that you typically encounter with InViewEdit and I don't have to worry about doing any kind of validation. All that matters is that when the user clicks the column, the code runs. Here it is:
Sub Inviewedit(Source As Notesuiview, Requesttype As Integer, Colprogname As Variant, Columnvalue As Variant, Continue As Variant)
Dim doc As NotesDocument Dim caret As String
REM Get the CaretNoteID - exit if it does not point at a document caret = Source.CaretNoteID If caret = "0" Then Exit Sub
REM Get the current database and document Set db = Source.View.Parent Set doc = db.GetDocumentByID(caret)
REM OK...we can ditch it Call doc.RemoveFromFolder(Source.View.Name)
End Sub
This LotusScript was converted to HTML using the ls2html routine, provided by Julian Robichaux at nsftools.com.
To configure this for your own use, just follow these steps:
1. Add the above code to the InViewEdit of your folder
2. Select the column you want to use for the action and set it's properties for "Display values as icons" and "Editable column"to true
3. Set the value of the column to the icon you want to use (either the number or the name of an image resource)
4. Bask in the glory as your users tell you how awesome you are! :-)
That's all there is to it. This is another seemingly trivial but very high value technique. It allows you to simplify the UI greatly and follows the rule "don't make me think!" to the letter. Of course, you're not limited to just removing the document from a folder. Basically you can code anything you'd like in the InViewEdit. How about marking the document as a favorite? Adding the author to your address book? There are probably a lot of cool uses for this idea. Now it's up to you to try it and figure out where it might work for you. If you use this technique in an innovative way, please let me know so I can share with everyone.
There are so many packaged products that have this problem, but it's pretty sad when it's a company that obviously has a usability staff! :-)
If you start out frustrated even opening the box, the user experience is already tarnished. Try to remember this fact, as it is true for what we do as well. In our case, it might be the initial way your customer contacts you, the first meeting you have with them, your website, etc. First impressions mean a lot...make yours the best you can!
Hive Mind: What's Your Favorite User Experience Tip?
Hello Friends! I thought it would be fun to try a little experiment here and develop a group writing project that would allow us to define best practices around the user experience using the Lotus Notes client. While I don't believe in absolutes, there are many ideas which will almost universally improve the user experience. Let's see if we can document some of those.
Here's what I propose. Like all the things I work on, this is pretty simple! ;-)
1. Pick one (and only one) idea or technique that you'd like to represent as a user experience best practice. What we are looking for here is to focus on the Notes client, as there's tons of stuff out there regarding UX best practices for the web. (Many of those are applicable in any software environment, actually, so it's good to be aware of them).
2. Share this idea via your blog, leave a comment here, or send me an e-mail. I'll create a special area (perhaps a wiki?) where this information can be consolidated after people have had a chance to comment on the various concepts.
This will be a community controlled effort to get the initial entries together, so if your entry generates a lot of "boo hiss", we'll choose to leave it out. If we get enough people to participate, we'll end up with a nice little resource that the entire community can use.
I believe a focus on the user experience from the standpoint of the everyday Notes developer is even more important now than ever before due to the efforts that IBM is putting into this area. The last thing we want to do is expose our ugly old apps in the beautiful new Notes 8 shell. It will be like "putting lipstick on a pig"!!! Perhaps this group resource will be a place where developers can go to draw inspiration for their next project.
Along with the "Best Practices Guide for the User Experience", I was thinking of creating a "Lotus Notes Interface Gallery". Think of this as a place to show off your best work, again with the goal of providing inspiration (and perhaps some bragging rights) to other developers who might not be comfortable in anything other than the 3-pane UI model. For all its warts, there are some excellent examples of Notes UIs out there, and I think it would be cool to get them all together in one place. What do you think? A dedicated sub site here or something more generic, such as Flickr? Let me know your thoughts and feel free to send me submissions.
Well...This is a community all about collaboration and it's what we do best. So, please, if you are interested, consider playing along. This could be fun AND educational! Cheers...
Deconstructing The User Experience: A Website Download
A few days back, I found a good example of what NOT to do when providing a download on your website. Unfortunately, this was on an IBM site, but then again, I don't think that will really come as a shock to anyone here. Too much of the IBM web presence seems like it was designed by engineers. Of course, much of their target audience are tech heads, but that's still not an excuse for a poor user experience.
In this particular instance, I was going to get the Lotus Connections Reviewer's Guide (which I'm really glad they made available). Below you can see the actual download page. My annotations are on the screen shot. To be clear, this isn't a criticism of the Reviewer's Guide...just the mechanism used to distribute it (which I'm sure the Connections team has no control over).
Just by looking at it, you may not see all the problems you might actually experience, so if you'd like, head on over to the download page and check it out. Here were my immediate thoughts when I got there.
1. First, I believe most users would figure that a link called "Get the download" would actually do just that. Instead, it's actually an anchor link which jumps down to the true download area. This has a jarring effect that leaves many users confused about what just happened, especially if they were anticipating something entirely different (e.g. the dialog to ask them where to save the file).
2. While the table is potentially useful, I imagine that the general user doesn't really care about the filename at this point and they may or may not really care about the file size. On other IBM pages, this table sometimes has multiple options, giving the user the choice of a PDF, Powerpoint file, Word doc, etc. What really irks me about this setup, however, is the "Download method". Here we see we only have one option: HTTP. You might also have the choice of FTP, but the real question is this: How many users actually know what this means? The term is meaningless to most people and even if they know what it means, there's nothing here that indicates that there is an action to be taken. Having only one option here is advantageous actually. Can you imagine the average user seeing two links, one for HTTP and one for FTP. My guess is that this would generate a call or have a high abandonment rate since users would be unsure of what to do. If you confuse your users or make them think too hard, you've failed the user experience test.
So...let's have a little fun with this shall we? We'll do a redesign, but we'll keep it very simple. Assume that we can't really modify the layout of the page other than the links. If I could make that one simple change, I would probably start with something like this:
A subtle change, but one that improves the user experience quite a bit. First, we give the user a chance to get in and get out by providing a download button as one of the first things they see after the title. If the user chooses to stick around a little more, they can still use this button after they've read the first couple paragraphs on the page. The button is repeated in the "Download" table as well. Notice I eliminated the choice of download method. I really see no use for giving the user an option here. The actual text for the buttons is debatable but what is important is that the text implies an action. There's no ambiguity here. That is, the button and text combined make it obvious that this is the way you get the item in question.
At this point, if I was designing the site, I'd open it up to usability testing. So, let's do that. Please leave your thoughts in the comments. If you want to be a little more ambitious and redesign it even more (don't forget all the politics usually involved in something like that! ;-), then feel free to send me a screenshot or post a link in your comment. Cheers!
Usability Testing...Uncover The Flaws In Your UI (Part I)
Usability testing is the second of the two incredibly powerful development techniques that I suggest you add to your design arsenal. The first, which we covered in my last big article, is low-fidelity prototyping. Even though they are powerful concepts on their own, if you actually combine these techniques together and use them in conjunction with one another, I guarantee that you'll start delivering higher quality applications to your users, at least as far as the user experience goes. *
So...what is usability testing all about? Usability testing, in its simplest form, is all about testing whether the design of your application meets the needs of the users from a UI perspective. This test will uncover if your design is simple and easy to use, if there are glaring errors that prevent the user from accomplishing their work or even the more subtle things that might make the user's job easier or harder. Whereas traditional software testing is used to determine if your application does what it is supposed to do with the data it is given, usability testing is concerned with whether the user can successfully get the data in (or out) in the first place.
Usability testing is quite often relegated to second class status as far as testing goes and many times it is left out of the design process entirely. This is a real shame, since this form is testing is really the most critical. By testing your UI, you'll have the opportunity to find the troublespots that will trip up your users before you let them start using it (i.e. roll it out to production). Remember, the sooner you can find and fix errors, the cheaper it will be. If you can do this before you even write a line of code, you'll be making significant progress in reducing costs and boosting quality. Best of all, you will improve user satisfaction by performing usability tests and this is perhaps the most important metric of all (unless you don't really care about them...in which case you should stop reading and go flick the server on and off several times ;-)
Usability tests can range from really high tech (think two-way mirrors, video cameras, fancy labs) to really simple (e.g. a user & developer meeting in a conference room). Most of is aren't lucky enough to work in a company with a dedicated usability group, so it will fall to us to conduct the tests. I advocate a fairly simple approach and I tend to keep my methodology fairly lightweight. If you try to get too process heavy in this stage, you run the risk of subconsciously making up reasons to skip it ("We don't have enough time!", "There are more important things to work on!"). For a typical Lotus Notes business application, I think you can get some pretty useful data with a handful of users, somewhere on the order of three to five people. Of course, the larger your app and the more users you can test, the better your data set will be. Use your best judgment here. You'll get better with practice.
Once you have some users on board, what do you test? To be effective and to allow you to make logical comparisons with the data sets, usability tests should be task-based. That is, your test users should have a predefined goal to accomplish within the application. By using a defined task, you are setting the boundaries and restricting the users' choices. This helps keep them from ambling around the app without a purpose.
During a usability test, your most important job as a developer is concentrated observation. You should be recording notes on all the action the user is taking as they are working on their task. Pay particular attention to times when the user pauses or looks puzzled. It is perfectly OK to question the user when they perform an action or when they seem confused. The whole purpose of this process is to find errors or difficult aspects of your UI and these notes will serve as the main data you will analyze. Don't be shy about drilling into the user's thought process and let them know that it's OK to be brutally honest. Yes, sometimes the truth hurts, but it's best to hear about likes and dislikes now rather than later.
One important note here: When you are performing a usability test, be sure you make the user feel comfortable and insure them that you are testing the application not their skills. When things go wrong or a user does something you didn't expect, first tell them that it is OK. After all, this is why they are helping you. Then, question them and find out why they did what they did. Some really interesting data usually comes out of the things that are broken or when users try to use elements in ways you did not expect.
In the next article, we'll explore the actual mechanics of the usability test. For now, let's just assume we conducted a test and we have several pages of notes covering the specific task we studied. What do we do now? Now, we pour through the notes and attempt to analyze them. Look for common patters or themes across the various users. You are trying to identify the elements of your application that are broken or that caused significant delays or user frustration. If you did a good job with soliciting the users' thoughts as they carried out their task, you most likely have a good idea of why a particular component didn't work for them or why they got frustrated. The trick now is to take all of this data and fix the troublespots. (You can look for the good things too. If users really liked the way you implemented a certain feature, make sure you find out why and use this knowledge in the future).
Besides fixing the obvious broken stuff, a usability test is valuable in exposing an inefficient or cumbersome UI. As a developer, it is very easy to overlook the complexity we sometimes build into an interface because we are so close to the design. The usability test gives us an opportunity to take a step back and see things through the eyes of our users. Personally, I found this to be very valuable in making me more empathetic about the applications I build. After conducting a few usability tests, you'll begin getting a really good sense for what users find simple and what is difficult or annoying for them. You can leverage this knowledge in your next design and I believe you'll find your skills around designing UIs will start to improve!
Usability testing is most effective when used in an iterative manner as part of your overall development process. Although doing a usability test at the very end of the dev cycle is still better than not doing it at all, the biggest benefit (saving time and money up-front) is lost. The best usability tests uncover the flaws before you enter the coding phase, which is why I find testing with a low-fidelity (i.e. paper) prototype such a powerful development trick.
Testing a low-fidelity prototype is really not much different than testing a real, working prototype. Instead of having a computer to interact with, the users will interact with the individual pieces of paper that represent the screens of your application. In a low-fi usability test, the user will utilize a pencil or pen as their input device, rather than a keyboard and mouse. Instead of a computer providing the necessary prompts and results, this will be carried out by a human participant playing the role of the computer. Other than these relatively minor differences, the end goal is the same...capture notes on the system usability so that you can fix bugs and simplify the UI. The big "bang for the buck" in low-fidelity testing is the fact that you haven't written any code yet, so changes are really easy and really cheap. To redesign an entire screen requires no more than grabbing another sheet of paper and your markers! After you go through two or three iterations of your design and test cycle, you will have a great blueprint for how the application will work and increased clarity on how to move forward (no more staring at a blank screen wondering, "Where do I begin?"). Best of all, you're much more likely to deliver an application that your users will love to work with right out of the gate.
So now you've got an idea about what usability testing is and why you might do it. I hope that you see it is really just a logical component of good UI design and that it can allow you to produce a higher quality product than you might otherwise deliver. Next time, we'll look at some of the specific techniques involved in usability testing. I think you'll find them very simple to do while yielding very important results.
*No actual guarantee is implied, inferred, suggested, etc., etc. You're on your own here, pal! ;-)
(One final post before I head off for ILUG2007 just because I love you guys! :-)
For all of it's usefulness, the signal-to-noise ratio on the forum at Lotus developerWorks (i.e. notes.net) is quite low. When you do find a really useful nugget, though, you want to share it with the world. I found just such a nugget, which is related to my blog topic from the other day.
If you remember, on the homescreen of my application is a field that allows the user to enter a number and immediately get to the applicable document. I wanted to allow the user to not only use the hotspot to trigger the action, but also to be able to just hit enter and have the action execute and open the document. Unfortunately, I've never found an acceptable solution to this in the client...until now. So, for further proof that there are waaaay smarter folks out there than me, check out this innovative use of JavaScript in the client to accomplish this feat (thanks to Peter Smith!!!):
So what's going on here? The Reader's Digest version is that when the user enters the search field, the JavaScript function runSearch is triggered and every 1/10 of a second checks the value of the field. If it encounters a press of the 'Enter' key [ if (sString.indexOf(newline)>=0) ], then it clears the newline and presses the button to trigger whatever action you've setup.
So...in my case, I changed the hotspot link to a button. The button contains the LotusScript that does all the work of finding the document and displaying it to the user. Then I simply placed Peter's code in the places he notes in the posting above, and et voilà! Now the user can click the button or hit enter. A simple and elegant solution to a problem I never had solved before.
One tip. If you use an OS-style field, make sure you 'Allow multiple lines' for the field. If you don't, pressing the 'Enter' key won't generate a newline and the JavaScript will never execute the button press.
One other thing you might consider is to clear out the field when the user executes the search. This will depend on your situation, but in my case, the last thing the LotusScript in the button does is clear the field. That way, if the user returns to the homepage by closing the document window, the field will be ready for them to enter the next number.
Every time you design some new functionality for an application, you have the opportunity to delight your users by focusing on making the task easier or you can frustrate them by making things more difficult. Obviously, most of us want to achieve the former, but sometimes in our rush to simplify OUR lives (shorter development time, easier maintenance, etc.), we tend to gravitate toward the latter. Especially when we are building something that we've done 100 times before, our inspiration may be low and it's difficult to overcome the inertia of "let's just get this finished as fast as possible". One way I've found that helps me overcome this feeling is to take a step back and look at the functionality through the eyes of the user. I try to imagine what scenarios might be playing through the user's head as they sit down and see the screen I've designed. Is the layout clean and simple? Are elements labeled appropriately or is the form laid out in such a way that the purpose of each element is intuitive? Does the new functionality I've just designed make their lives easier or do they need to exert more effort to get what they want. In other words, am I doing the heavy lifting or are they?
The answers to these questions can sometimes be very enlightening and can help you frame the context of your work in a more user-friendly way. Here's a recent example from my own experience:
I'm putting the finishing touches on a simple workflow application. It actually has a few neat and unique features, but most of it is the standard stuff. It happens to be a sister process to another application that is already in production, so it made sense to design the look and feel of the app to match the existing one. All of this makes for fairly tedious design work. Once most of the application was complete, I took a step back to review some of the functionality. One of the first things that struck me was that I had a really great feature on the main screen but I fell into the trap of making the user do the heavy lifting.
Sticking with my common theme of getting the user to their data as quickly as possible, I have a data entry field on the main screen that allows the user to input the unique identifier for the document, which takes them right to the form in question (assuming it's found).
For this particular application, documents are numbered according to the last two digits of the current year, followed by a "-" and then a three-digit sequential number (e.g 07-006). In my initial incarnation of this functionality, I just took the value the user entered into this field and did a lookup by key. If I found a match, I opened the doc, otherwise I told them there was no such document in the database. After spending a little time reflecting on this, I did some research into how users actually use these numbers. When communicating about a particular EWR, did they say "O seven dash O O six" or just "six"?
Turns out (not surprisingly) that there's a lot of variation about how people remember these numbers and communicate about them. This fact made me go back and rethink how to write the code so that it would simplify the act of finding a document for most of the users. With just a little extra effort, I was able to modify the code so that users can type in a variety of different formats and the document will be found. Using the example above, they can now type in:
07-006 006 06 6
If the user leaves off the year designation, then I assume it's the current year. They can choose to enter just the significant digits of the EWR number and in the code I simply manipulate the string they enter to use as my key in the lookup. I even check for ambiguous entries, so if they enter something like "06-", I then bring up a dialog box showing all of the 06-xxx documents. Overall, I tried to address the main ways a user might enter a number so I don't have to bring up a nasty error message telling them their document couldn't be found. I know it's really frustrating for me when I use an application and I am sure something is out there, but I just don't have the correct syntax to find it. It's empathizing with this frustration that inspired me to go back and work on the lookup functionality. Fairly trivial? Yes, it is, but add up the small gains like this and you end up with a much better user experience. With the new functionality, the user doesn't have to spend time thinking "what is the format I need to use to find a document?". Instead, they can just enter the number in the format that they are used to and they'll be whisked away to the document.
I encourage you to try this the next time you are building something new or tweaking an existing design. Try to find those places where you are asking the users to do more work than is necessary and then use your skills to make it easier for them. After all, as the developer, you've got all the muscle.
Check out the Avis website in IE. Try to hover over one of the tabs and then make a selection. Whoops! If their intent is to just show what is available in each section, they should have used a different mechanism. Is anyone not thrown off by how that's working now?
Hi Friends! Today, I thought I'd take a little respite from writing my normally long-winded articles (translation: I'm wiped out from this weekend and I need a break! :-). Instead, I'm going to ask you to help me provide some ideas to another reader.
I got a great response from my post On Not Using Views and I really appreciate all of the feedback and e-mails. In that thread, Keith asked a very relevant question. I started writing a reply, but then I thought that this was important enough to get some discussion going. Here's what he had to say:
"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."
This is a sticky wicket for sure, since he has presented a scenario that makes it difficult to definitively select one construct over another. Keith, you may never be able to come up with the perfect solution in this case, but here are some thoughts:
Can you change the taxonomy somewhat so that it will easier to make the relevant selection? For example, maybe the 200 choices are logically grouped into a subset of 10 or 20. You could then have two drop downs, one to select the main category and the second to pick the sub category. In that way, both sets of drop downs are relatively small and easy to handle.
Another thought is that maybe there is some info you could gather before the user opens the form that can help narrow down the list of choices. For example, perhaps your embedded view shows a list of sales calls by branch. On document open, ask the user what state the report is for and use that to show just the relevant branches for that state in the drop-down.
Sorry I don't have a better answer for you. Sometimes you are just stuck having to present a big list. There's nothing inherently wrong in this, however. In my mind, the key is to weigh this against the alternative and see which one works best. (Hint: Although it's tempting, don't try to answer this question yourself. This is the perfect time to enlist the aid of your customers and do some usability testing. Trust me, they'll tell you exactly what you need to know! :-)
So...perhaps some other people out there have come up with alternate solutions that might benefit Keith (and everyone else here). If you have an approach that you'd like to share, please leave a comment. Thanks in advance! Oh...and Keith, let us know what you end up doing.
Last time, I talked a bit about programmable tabbed tables. They really come in handy and are a powerful interface construct, especially when used for certain tasks, such as progressive disclosure (more on that in a future post). Programmable tabbed tables make simple work of seemingly complex tasks, such as constructing a multi-step wizard to walk a user through a process. I think by now that most developers are familiar with the techniques behind programming a table, but did you know that you could use the same idea with embedded outlines? If not, please read on...
When you have an embedded outline and you click a link on the outline, you can, of course, have Notes highlight your selection.
You: "Yeah, ok, great...tell us something we don't know".
Me: "Wait...don't go away...this will be cool I promise. Did you also know that you can programmatically set the outline selection?"
You: "Duh...no need, it gets highlighted when I click it"
Me: "Ah...that's true. But...what if you go about selecting the element associated with a certain outline element WITHOUT clicking on the outline?"
You:(in a Homer Simpson-esque way)* "Hmmm...go on..."
Here's the deal. I've had several developers ask me through the years why there is a 'Name' property for an embedded outline. This is the one I'm referring to:
The name in this case can be used programmatically, just like in a tabbed table. When you place the outline on the form and create a document based on that form, a new field called "$OUTLINE_NAME" (where OUTLINE_NAME is the name you provide in the embedded outline properties) is added to the document. This field holds a number that corresponds to the outline entry currently selected. The outline entries are labeled 1 through (max number of entries) in the order that they appear in the design (see below).
Thus, if you wanted to highlight the fourth entry in the embedded outline, your code would be a simple:
At this point, you might still be wondering why you would actually use this. Let me show you a scenario from one of my production applications that should help illustrate the idea. In the last post, I told you about an application in which I use a programmable tabbed table and embedded outline to display various sections to a user. The sections on this form can vary based on document status, user input, etc. The embedded outline is used to make navigating through the sections easy. That is, if the user wants to jump from the first section to the last, they can just click the appropriate link in the outline. But many times the user wants to progress through the form in the logical way that was designed based on business process rules. In this case, the user is certainly free to use the outline, but we have also provided them with simple 'Next and 'Previous' links that allow them to navigate one section at a time (see the screenshot below).
In order to make sure that the appropriate link is highlighted in the embedded outline (which is another visual reminder to the user of where they are) when these links are triggered, we make use of the programmable nature of the outline using the simple formula language snippet detailed earlier.
I think this is pretty slick on Lotus' part. What about you?
Don't forget about the fact that it might be desirable to reset the outline highlight to the first entry the next time the user opens the document (as I discussed for programmable tables in my last post). You can handle this scenario in the same way. Either set the $OUTLINE_NAME field back to 1 when the user saves the document or do so when the document is being loaded in the UI.
Finally, there's one little 'GOTCHA' to be aware of when using this technique. The number you use to highlight a particular outline entry can actually change based on the entries that are displayed in the UI, so you have to account for this in your code. For example, assume that you have an outline with six entries. In a particular scenario, the first two entries on the outline are hidden. In this situation, the third entry is considered entry number 1 as far as programmatic access is concerned. This can be a bit tricky if you are showing and hiding things a lot. If you are careful and put some thought into the way the entries are arranged on your outline, this usually isn't too bad...nothing a simple @If can't handle, but it's important you know about it so you don't end up pulling out your hair!
OK...that's it...another short and sweet post. If you weren't already aware of this technique, I hope it comes in handy for you some time in the future. As always, feel free to leave your comments or drop me a line if you have any questions. Cheers!
*Disclaimer: I am not implying that my readers are like Homer Simpson...I just like when he says that! :-D
I ran across two different applications yesterday that used programmable tabbed tables. One was a table in which the user could choose the tab and one did not display the tabs but allowed the user to pick between them with links. Both violated one of my cardinal interface rules in that you should avoid disorienting the user when presenting information to them. In both of these applications, the state of the tabbed table was retained when the document was saved. That is, if I was on the third tab of the table when I clicked the save button, the next time I opened the document, the tabbed table would still be on the third tab. Now, this could be perfectly good functionality in certain applications. Often it is great to take the user back to the exact place they were when they left off. This provides them with a mental reminder of what is was they were working on. In the case of the two applications in question, however, this was not desired functionality, especially since Notes provides no built-in mechanism for retaining the state information for a given user. In these applications, it makes more sense for the tabbed tables to display the first tab when a document is opened, since this tab contains the key metrics for the document. You see the problem here, right? If Joe opens the Account document and leaves off on tab 5, when I open the doc that is the information I will see. Since I'm not expecting this, there is a momentary feeling of being lost. Even though it is short-lived and I am able to quickly recover from the problem, leaving the user with an unsettling feeling, no matter how brief, does not engender a good user experience.
One of these applications, I'm embarrassed to say, was one of mine. This was merely a sin of omission on my part, since I have addressed this issue in many applications in the past, but I still felt a bit sheepish when I encountered it. Fortunately, the fix is very simple and is a good practice to get into if you are creating programmatic tabbed tables. Here's the scoop...
As you recall, you can make a programmable tabbed table by selecting the proper settings in the table properties dialog box.
To select a particular row in the tabbed table, you use the $table-name field and set it's value to the appropriate row. The $table-name field is created for you when you name the table and the row value is obtained from the row tag name. Both of these values are defined on the Table Programming tab.
You can see in the picture above that I've called the first tab "Tab1" and subsequent tabs are named in a similar fashion. Thus, at it's most basic, the formula to switch from this tab to the fourth tab in this table would be
This is a great feature, since it works in both read and edit mode. A programmable tabbed table has many uses. One example is displaying conditional information. I have an application in which usually only certain tabs should be shown, based on user input. By using a programmable tabbed table along with an outline, I provide a nice method to navigate among the various tabs, skipping over those that are not necessary. You can see an example screen below.
If you look at the document properties for a document with a programmable tabbed table, you'll actually see the $table-name field included with all of the other document fields.
Here's where the (potential) problem occurs. When a user edits the document, the current value of $NavTable is saved. So if I save and close when I'm on Tab4, that's the tab the next user will see when they open the document.
In order to avoid this problem, I simply use the code above in the query save event to set this field back to the first tab. Alternatively, you could reset the value when the document is opening. I needed to do this once when I was retrofitting some functionality into an existing application. Rather than mess with the QuerySave event (which had a huge mess of ugly LotusScript), I simply created a CFD field on the form called "SetTabbedTable". The formula for this field was:
This insured that the user was always presented with the first tab, whether in read mode or edit mode.
Well...that was a really simple tip and I probably provided way more background than you needed, but better to be thorough I say. In any event, this is an easy fix to apply and although it seems rather trivial, remember that the small things add up when we're on the way to user experience nirvana.
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.
You Only Get One Chance To Make A First Impression
Scenario: It's the day of the big application rollout. You've spent countless hours designing one of the best apps you've ever built. Not only have you written some great backend code, but you've worked hard to construct an awesome UI that you're sure will win the users over. The business process owner has asked you to inform the user community of the availability of the new program. You have your trusty admin sidekick (sorry..."hero support*") tweak the ACL and you're in business...the app is live! You click the 'Send' button on your e-mail message and off it goes around the country, perhaps around the world. Your colleagues start receiving the message and open it up, only to be greeted by the following:
Inspiring? Ummm...not so much. Think they are excited to get started using it? Probably not...you'll be lucky if it doesn't go right to the trash.
As Nathan and I discussed at Lotusphere, when we talk about the user experience, we're not just addressing the UI of an application, but all aspects of the user's interaction with it. This means the help file, bug reporting, community discussion, and yes...even the introductory e-mail. In fact, this e-mail can be one of the most important things you design. Let me explain.
With the cognitive overload that most users experience when looking at their inbox, your message needs to stand out and gain their interest. Kathy Sierra once talked about how companies get things backwards. They spend a lot of time and money making really cool, slick glossy brochures to sell a product and once you get it, you open the box to find a boring, black and white manual. This is somewhat analogous to the introductory e-mail. You may have impressed the application owner with your "mad skillz" and got them quite excited about the app, only to disappoint them when they see the mail you've sent to everyone in the company. How many times have you sent a link to a user and later heard something like "oh...I didn't know what I was supposed to do with that, so I just threw it away"? This is to be avoided if you hope to build a passionate user community around your application.
Unless you work in a very small environment, chances are that most of your application's audience will not see the actual application until the day of release. In fact, many of them may not even be aware of the initiative and your e-mail will be the very first contact they have with it. Thus, it's really important that the e-mail contain some key details. At a minimum, you should include:
* Name of the application * A brief description * Name of the application owner * Instructions for getting started
Depending on your user audience and their skill level, your e-mail may need to include more details and step-by-step help, or you might be able to get by on just the basics. As with all of the things I talk about, it's up to you as the developer to make a judgement call to determine what is best for your given situation.
Here's an example from an application rollout I was involved with to give you a better idea of what I'm getting at:
Notice that some care was taken to build this e-mail. Attention was paid to the layout and some nice graphics were added to give it a more professional appearance. In this example, a new database was being deployed and a training session for the application was planned about a week out. It was desired to have a hands-on training session, so it was important that the end users have the database locally replicated to their laptops. In this scenario, they were well aware of the application and it's purpose, so this e-mail was intended to assist them with the process of creating the replica, setting up the bookmark, etc. It was divided into a series of easy to understand steps, so that even new users (of which there were several), could figure out what to do. We even performed some quick user testing on the e-mail and some small modifications to the text were made as a result of the tests.
The extra time it took to construct this e-mail was negligible when viewed as part of the overall project, However, the initial impression it gave to the future users was that this was a professional initiative. Post rollout feedback was very good and the ease of performing the initial setup by following the e-mail instructions was mentioned by several users.
When all is said and done, this is just another small step you can take to improve the user experience in your applications. It doesn't take much effort and may seem to be rather insignificant in the grand scheme of things, but remember that the little things can add up and you'd rather have them add up to a positive than a negative.
*A little reference to "Sky High"...a great Disney movie for the family.
Earlier today...in between all the chores :-)... I took some time to listen to the latest "Taking Notes" podcast. As usual, Julian and Bruce did a great job. This episode had a very nice interview with Mike Rhodin, Lotus General Manager. I was specifically pleased with how he talked about Notes 8 and its "outside in" focus on the UI. This is one of the core points of the "Interface First" design methodology that I use in all of my projects, and it is great to hear (from yet another source), that IBM is making such an effort on this front.
For Notes Developers, it's going to be important to take advantage of the new tools and templates that will be made available to us. I think it will be crucial for our community to place a renewed effort on UI design. As Julian mentioned, it will be pretty bad from a user standpoint to have this beautiful and slick new UI, only to pollute it with ugly apps or apps that have not focused on usability. This is exciting to me, since I think it will make the stuff that Nathan and I have been talking about lately even more relevant.
Besides all of the recent press from the IBM folks, I take it as a positive sign that Notes developers are actually reading this blog and others like it. It's also heartening to know that the interest is enough to warrant sessions at popular devconferences. Yep...I think UI design in Notes is finally getting its due...and that is a very good thing!
Thoughts about Collaborative Technologies and User Interface Design...
About Me
Name:Chris Blatnick
By day, I work as a Collaborative Technologies
architect and champion the cause of usability and user interface design. But don't judge me
by my blog...I'm using a template. Cobbler's children and all... ;-)
Click the icon to be notified automatically every time I add a new post.
Get Social
Search
Disclaimer
Since I work for Big Blue now, I'm compelled to say “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.” So there...
or 
I've not read a lot of the "Dummies" series, but whenever I've picked one up, I've been impressed by the quality of the product. "Web Usability For Dummies" is no exception. In about 300 pages, the authors do a good job of laying the foundation for a solid understanding of the important aspects of usability. It looks like this book might be out of print now, but you can probably find a copy at your local library or via Amazon.com.
One of the must have books on my reference shelf is "Don't Make Me Think, A Common Sense Approach to Web Usability" by Steve Krug. I've recommended this book to many people, so I thought it was about time to give it a proper review. 
(If at this point you are saying, "What Gorilla???!!!", go ahead and watch the video again, not focusing on anything in particular this time, and be amazed. :-)
Usability testing is the second of the two incredibly powerful development techniques that I suggest you add to your design arsenal. The first, which we covered in my last big article, is low-fidelity prototyping. Even though they are powerful concepts on their own, if you actually combine these techniques together and use them in conjunction with one another, I guarantee that you'll start delivering higher quality applications to your users, at least as far as the user experience goes. *
In the next article, we'll explore the actual mechanics of the usability test. For now, let's just assume we conducted a test and we have several pages of notes covering the specific task we studied. What do we do now? Now, we pour through the notes and attempt to analyze them. Look for common patters or themes across the various users. You are trying to identify the elements of your application that are broken or that caused significant delays or user frustration. If you did a good job with soliciting the users' thoughts as they carried out their task, you most likely have a good idea of why a particular component didn't work for them or why they got frustrated. The trick now is to take all of this data and fix the troublespots. (You can look for the good things too. If users really liked the way you implemented a certain feature, make sure you find out why and use this knowledge in the future).
