Archive | November, 2007

16 November 2007 ~ 0 Comments

Collection Overhead (eBay)

In a previous post, I commented on the complexity of eBay’s message management when no messages were present. What about when we have one or a few messages?

This is a frequent problem many interfaces suffer from, one that we’ll refer to as “Collection Overhead” for lack of a better name. How do you present yourself when you have few or no items to manage?

We programmers think in terms of 1s and 0s – binary. There is effectively no difference between one message and 10 messages. They’re both greater than zero.  Wouldn’t it be great if we could just have one interface that supported anywhere from zero to hundreds of messages?  Sure!  Yes!

In this case however, there are unfortunate side effects.  To view and delete a single message, eBay presents me with eighteen controls.

Eighteen.

To make matters worse, the interface is cluttered with explanatory elements that are not very useful when there are few messages:

  • “Messages (1-1 of 1, 1 unread)” – not very helpful.
  • There’s a legend that’s effectively meaningless to me (none of the icons appear in the display).
  • There are several sentences of text to explain the interface.  This is a very bad smell (to borrow from Fowler’s book on Refactoring).
  • I’m viewing Page 1 of 1.  If that’s the case, pagination is irrelevant.

There are a few strategies for dealing with Collection Overhead:

The first and most obvious is to remove overhead unless absolutely necessary. Don’t present a legend explaining 3 types of icons, none of which appear in the interface!

Your biggest gain however, will come from realizing that you don’t need to support an arbitrary number of items in your collections.

In eBay’s example, do expired messages clean themselves up regularly enough to ensure that 80% of people have less than 25 messages at any given time?

To a programmer an interface is robust if it can handle 2 messages and 2000 messages.  To a user who only ever works with about 15 message at a time, the management overhead is overkill.

Continue Reading

15 November 2007 ~ 1 Comment

It’s Our Problem, Never Theirs

While I dig the new Yahoo! Mail interface, this is positively dreadful.

No matter how good your error messages or how easy it is for someone to communicate the content of the error, this is never appropriate:

In case the text is too small for you to read:

The server failed to send back valid XML. Please contact Yahoo! Customer Care and let them know what you were doing when you saw this message. Thanks!

Method: ListFolders, HTTP Status: 502, Status Text: Connection refused

XML Parsing Error: junk after document element Location: http://…/ Line 2, Column 1.

Yikes.

Imagine this conversation:

Rob: “Hey Jim, I just realized something about those reports I sent you.”

Jim: “Oh? What’s that?”

Rob: “I made some typos…”

Jim: “That’s too bad.”

Rob: “Yeah it sure is. Say, could you send me an email telling me I made some typos? But I’m not going to tell you my email address or phone number. You’ll have to figure that out.”

Jim: “Are you out of your mind?”

Yahoo! on the other hand, thinks Jim would respond like this:

Yahoo! Jim: “Sure Rob, I’ll stop what I’m doing to write you a detailed email about exactly what you did wrong. I’ll also take time to find out your email or phone number even though you opted not to tell me when you told me to contact you.”

These reports are the worst possible examples of excise. In no way is performing an error reporting step part of any conceivable goal.  Asking your users to do things servicing the application (and not themselves) is a form of disrespect like no other.

If your application is capable of detecting an error state, it’s capable of doing something about it.  Don’t ask your users to do your job!

Don’t do this.

Ever.

Continue Reading

12 November 2007 ~ 0 Comments

“Rich, Modeless Feedback”

Has it been a week already? Yikes!

Throughout About Face, Cooper makes uses of the phrase “rich, modeless feedback” to describe passive communication of information without requiring navigation through an interface.

For example, in Microsoft Word:

At a glance you know your place in the document, how many pages there are, etc. Simple and effective.

iTunes takes this to a whole new level:

Good grief! Look at all this juicyness!

At a glance, I know:

  • I’m busy downloading something.
  • I’m busy downloading ’1′ something. What it is isn’t really important, since I initiated the download, I know what it is. This level of granularity suffices. Although perhaps a % indicator would be more useful.
  • My “Grey Nano” is charging.
  • My “Grey Nano” is syncing.
  • I have the ability to eject the “Grey Nano”.

All of this is done within about a square inch of screen real estate (depending on your resolution) and without requiring any special navigation.

Phenomenal.

Not all information should be presented at this level. For example, word and characters counts are not readily available in Microsoft Word, instead requiring navigation to the Tools | Word Count pull-down menu:

Deciding which goes where requires insight into your users and their goals (of course!)

The mistake many developers and designers make is forgetting the difference between data and information, and spamming users with everything but the kitchen sink…

Which is effectively nothing.  Get this right!

Continue Reading

04 November 2007 ~ 0 Comments

UI 360s

Over on the right navigation area, you’ll notice a new section has been added: “UI 360″.

A 360 is a more in-depth look at a particular site or application. The focus will be on understanding and examining a UI’s strengths and weaknesses. The motivating factor is improvement! What and how can we take steps towards making things better?

This is different from a “review” or a “critique”. Reviews are typically more breadth oriented, examining all that an application or web site is capable of. Critiques are great at pointing out problems but not so great at coming up with solutions (typically reviews and critiques are similar, with the former being a superset of the latter).

The Memeo LifeAgent 360 will hopefully be the first of many.  Have a look, let me know what you think.

If there’s a site or product you’d like me to have a look at, shoot me an email!

Continue Reading

03 November 2007 ~ 0 Comments

Dantz/EMC Retrospect Backup – A Study in Dialogs

I dedicated one of my external hard drives to Time Machine. As such, I need to reschedule some backups using Dantz Retrospect.

By the time you’re able to reschedule a backup, this is what the screen looks like:

And what dialog-laden application would be complete without the coup de grace – the unnecessary confirmation dialog. Not to mention confusing: what’s the difference between “Cancel” and “Don’t Save”? And the lack of any significant alignment along with an opaque background on the info bubble, gives the whole thing an amateur look.

What can we learn from all this? Apart from the overall design, which I really, sincerely hope was not the work of a trained interface professional from any domain here are some general dialog issues:

  • Inconsistent Modality – Only some of these dialogs are modal; inexplicably so.
  • Inconsistent or No Terminating Actions – Only some of the dialogs have “OK” and “Cancel” buttons.
  • Placement of Terminating Actions – Western reading order is from top-to-bottom, left-to-right. The least effective location of “OK” and “Cancel” will be in the top-right corner.
  • Minimal Saved State – If I took the time to carefully position these windows, it would be worthless because the application fails to record this information. It appears to save the position of some of the windows, but not all. Again, inexplicably so.
  • Arbitrary Depth – In general, a single nested dialog is as deep as we should go (i.e. a dialog within a dialog). Retrospect seems to have no practical limit on the depth of the dialog rabbit hole.

I haven’t used Retrospect for Windows, but perhaps its interface got a little more attention. Judging from this PC World Review, I doubt that’s the case.

“Regrettably, the sweeping overhaul that I’d envisioned didn’t materialize in the shipping version of the $129 program. Instead, I found a new set of wizards that step users through basic chores such as backing up, restoring data, and duplicating a partition. Though the wizards are nice, they don’t make up for the application’s continued use of arcane terminology such as “sets” and “volumes,” or its odd workflow decisions such as splitting file selection into three nonconsecutive steps.”

Whatever my criticisms of Memeo’s LifeAgent (which I’ll address in a future post), it suffers from nowhere near the amount of navigational excise featured in Retrospect.

The only reason I’ve used Retrospect for so long was its price tag (free with my Western Digital drive), but if that’s your only strong suit, you’re leaving a lot on the table.

Sayonara Retrospect, we had a good run.

Continue Reading

02 November 2007 ~ 0 Comments

Deliver Us From Scrolling

In a dialog-laden application, ensuring proper resizing behaviour can be a considerable undertaking. It becomes even more time consuming (and less fun!) if you haven’t taken resizing into consideration during initial design and layout of each form.

What’s the answer? Lock the dialogs of course!

Here I am, setting up a new “Backup Plan” with Memeo’s LifeAgent software – it came bundled with my Buffalo 500GB external drive, which I’m using for Apple’s Time Machine.

I have a 30″ monitor that I donated a kidney and a toe to pay for. Don’t force me to squint to see the most important bit of information I can think of: what files are being backed up.

What’s interesting is how simple the strategy for resizing would be!  In this mockup, I expanded the original width and height by about 40%.

Label-like controls retain their initial alignments, tables consume all available horizontal width and the backup table consumes all vertical width.

Scrolling isn’t the end of the world, but it sure is a pain. Spend the extra few minutes giving your dialogs proper resizing behaviour and deliver us from this interaction.

Continue Reading