Lotus Notes, A Lesson in Poor User Experience

As a longtime Outlook user, I've had the exciting experience of learning how to use Lotus Notes. When first starting to use it I was shocked at how "clunky" the user interface seemed, but wrote it off as my long familiarity with outlook. Recently, however, I started to realize that I was being too generous. Notes is full of user experience bad enough that I feel I need to point a couple out lest any young engineers try to design user interfaces based on them.

These things are actually a combination of how Notes works as well as pretty poor administration of the tool. There are some settings which, when you log out of a tool, your personal preferences are reset, but others where they are saved. As two quick examples, I give you the following:

Yes,No,Cancel

By default, when sending email, Notes prompts with the following dialog:

By itself, it is not a HUGE problem, we're not only giving you the option to save or not save in "sent items", but also cancel what you were trying to do.

The problem is that this is a pointless dialog and reflects something that most people answer 1 time in their entire life and never want to think about again. Asking them for EVERY single email is a waste of time and mental energy. There should be a checkbox that indicates "Save my response" and then the user should never see this dialog again. If they should change their mind, they should go to their preferences, dig around, find the setting, then change it. This is a subtle case of overengineering the user interface for edge cases instead of optimizing the routine flow.

Buttons, Buttons, and more Buttons!

This next example is so funny, I actually laughed out loud at work

If you start writing an email and try to close the message without saving it, you're prompted with the following dialog:

I give the engineer who thought this was a good idea, high marks for completeness (he missed discard & save, which is only slightly less confusing than this dialog), but they seriously missed the mark on simplicity and usability. Every time this happens I have to stop and read every nondescript, equal sized button for a cue on which one I want.

In this example, closing the message without sending or saving really should elicit the following question ONLY: "Would you like to save your message before closing?" This dialog should have two buttons, "Yes", and "No". Any other buttons, prompts, or information is too much. period. I MIGHT be able to be convinced of a cancel button, if it was less prominent or located away from the other two, but that is iffy. It is an example of the mentality in the first screen shot taken to larger proportions.

These well intentioned dialogs are examples of trying to accomodate edge cases by detuning the "normal" flow. This ends up creating a system that supports neither as well as it could. Putting questions in front of a user that they answer 99% the exact same answer is often just as bad as not prompting and doing destructive actions without warning them in the big picture. In the case of closing an email without saving it, I've done it, I've lost emails... Well, not in Gmail because it autosaves and I NEVER have to worry about this problem, I just go to my drafts folder to look for something I haven't sent yet.

Comments

Anonymous said…
"Would you like to save your message before closing?" This dialog should have two buttons, "Yes", and "No".

I beg to differ. The dialog should have two buttons, "Save" and "Don't Save."

Good post overall. A keeper!
Mike Mainguy said…
Good point... I agree, "Save" and "Don't Save" are a much better option.
Adam said…
This is a Mail Preference Setting on Mail->Sending and Receiving, you can choose always save, don't save or ask me.
Wetware error not software error.

Second example is trying to guess what the user wanted, if they clicked "send" or "save as draft" buttons this message is not displayed.

Wetware error.

Over 100m users do not find this difficult ... ah bless

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

the myth of asynchronous JDBC

The difference between Scalability, Performance, Efficiency, and Concurrency explained