rulururu

post Reinventing the wheel

March 15th, 2008

Filed under: UI, UI foible, coding, programming, usability — mike hall @ 12:50 am

Does HP do this on purpose? I don’t know if HP just likes to reinvent the wheel or what, but this just seems crazy. But let’s back up a bit before I go on any further…

I was at my brother-in-law’s house tonight and I was “privileged” to take on the role of family IT guy. What that meant tonight was diagnosing “Active Desktop disabled” errors along with random blue-screenedness. After a little investigating and some scrounging through the event logs, I saw that some services failing to start and other weird errors, so we decided it was time to wipe the slate, or in this case drive, clean.

So we backed up the stuff from his laptop (since no one ever backs up) and popped in the Windows XP install CD (this was back when HP actually gave you CDs). I reformatted the drive, reinstalled Windows and then moved on to the driver CDs. These are the custom gems provided by HP to return your laptop to the tip top amount of crapware that is on them by default. After the second driver CD, I was presented with this:

Um… huh? Ok… so I have the choice of both restarting my computer now and not restarting now? So I click on the restart later checkbox and now only the restart later checkbox is checked. I click on the restart now checkbox just to make sure and again only the restart now checkbox is checked. Hm… how come this smells like another control I so often encounter?

I’ve already talked about my previous dealings with HP software and them using the wrong controls at the wrong time. Here is yet another instance. This leaves me with a couple thoughts neither of which are very uplifting. Either the programmer at HP didn’t know about radio buttons and so reinvented the wheel by using exclusive OR checkboxes, or he did know about radio buttons but choose not to use them. Talk about a case of “Not Invented Here” syndrome. What gets me is even if the original programmer didn’t know to use radio buttons, do they not do peer reviews? or testing? Did these dialogs not get looked at by anyone else down the line? I’m just amazed that this slipped through the cracks.

But for whatever reason it was, this managed to get released as is. Whether because of the programmer, project manager or whatever force it was, this is how it is. But no matter what the reason, it’s not good…

post Always communicate status… just don’t lie about it

October 27th, 2007

Filed under: UI, UI foible, coding — mike hall @ 12:04 am

I recently received a new PC at work (that 1GB of RAM just wasn’t cutting it) and today I finally got around to installing Visual Studio 2005. Shortly after I started the install and UAC graciously allowed me through, I saw this dialog:

It’s telling me that it’s doing something, but other than the wait cursor, I don’t know if it is actually doing anything. It may be frozen. It may be in an infinite loop. I just don’t know. Not very user friendly. An updating list of what it’s doing or the constantly updating text showing the current task would work. Even a status bar in marquee mode would be better than nothing at all. At least I know the dialog is actually doing something. Then suddenly a regular progress bar appears with the text “Gathering required information..”:

Great. Now it’s gathering information? What was it doing before when it was in limbo? After it’s done gathering required information, I get a timer telling me the time remaining:

But the time remaining to do what? The “gathering required information” progress bar completed, so it can’t be gathering required information anymore. Now I’m just being shown the time remaining, you know, in case I need to know how much time before I’m shown the next confusing bit of UI.

So first I had 7 seconds remaining, then 9, then 13, then 10, then 15, then 12, then 9, then 10, then 7, and now 0 seconds. Boy, I’m glad that wasn’t confusing or misleading. Not to mention the displayed time remaining didn’t really reflect reality at all. And now I have 0 seconds remaining… and I’ve had 0 seconds remaining for the past 45 seconds…

I’ve talked before about ui foibles involving communicating status via checkboxes, but this is a different beast altogether. This is simply communicating wrong status, communicating incomplete status and communicating no status… all at the same time. You don’t need to tell the user everything. Sometimes you just need to tell them the overall task. Sometimes you need to tell them a little more. But you always need to tell them something valuable. So just remember…

when communicating status to the user, do it extensively, do it truthfully and do it appropriately.

post Don’t use a control if you really don’t mean it

September 14th, 2007

Filed under: UI, UI foible, coding — mike hall @ 9:11 am

I recently got a new laptop. Our previous one was a little dated and missing a few keys (it’s not a good idea to let your dog or your baby near the keyboard), so it was definitely time. I decided to go with an HP dv9428nr laptop. It had a decent Windows Experience Index, 17″ widescreen, and was the right price. The last few computers I’ve bought were all HPs, not because I’m a fan but just because those were the best I could get for the money. They’ve generally been good, so I don’t mind getting another.

However, recently HP started stealing part of your hard drive in order to store the recovery disc data. They partition off part of your C drive and store the recovery data there so that then they don’t need to create and ship the recovery discs with your new computer. You get to make your own! It’s a nice project for you and the kids on a lazy Sunday afternoon.

Anyway, so I fire up the the system recovery disc creation utility. I tell it I want to use DVDs, click next and then come across this gem of a dialog:

As you can see in the third checkbox, the checkbox highlighted when I hovered my mouse over it. It was clickable. It wasn’t disabled. What the heck would happen if I clicked on? As I mentioned yesterday, that is one of my biggest pet peeves. I could have tried clicking on it, but I wouldn’t want it to screw up my recovery discs. And since I can only make one set of recovery discs ever, I may never know:

Anyhow, I see (at least) two things wrong here:

1) Checkboxes are being used to show progress. It’s much better to just use a progress bar instead, so that something like this:

…becomes something like this:

Users don’t really care about seeing the specifics of their progress, they just want to know how much is left to go. A progress bar gives them that.

2) Checkboxes aren’t disabled. Progress is controlled by what stage the application is in, so it’s not clear what would happen if you clicked the checkboxes.

A much better choice here would be to give the dialog two progress bars: one to indicate the current task’s progress and one for overall progress:

…or at the very least remove those darn checkbox controls and put up some non-clickable bitmaps!

post Is that checkbox a button? I’m not sure. Let’s click it and find out.

September 13th, 2007

Filed under: UI, UI foible, coding — mike hall @ 5:19 pm

That is probably one of my biggest pet peeves. It totally irritates me when I check a checkbox and something wacky happens (since any action or command (other than simple UI control hiding) that is fired off when you check a checkbox is wacky). A checkbox is supposed to represent a state: on/off, true/false, yes/no… or in the case of mixed state checkboxes: yes/no/kinda, true/false/true-for-some-but-not-all-but-you-don’t-know-which. You get the idea:

As the Windows Vista User Experience Guide for Check Boxes explains:

Don’t use the selection of a check box to:

    • Perform commands.
    • Display other windows, such as a dialog box to gather more input.
    • Dynamically display other controls related to the selected control (screen readers cannot detect such events).

What those three points basically sum up to is don’t do anything that isn’t obvious just by looking at the dialog. If you have disabled subordinate controls beneath an unchecked checkbox, it’s pretty obvious that checking that checkbox will enable the subordinate controls.

Now it wouldn’t be obvious if checking that checkbox also popped up a modal dialog, or sent an email to your boss telling him that you’re leaving work early.

ruldrurd

Powered by WordPress, Theme based off the "I'm Okay" theme by Laurentiu Piron

Creative Commons License This work is licensed under a Creative Commons Attribution 3.0 United States License.


Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.