Tag Archive for 'HFE'

Google Mail attachment guidelines: tell it like it is!

Published
by
Nathan Zeldes
on July 19, 2009
in Bad design and Improvement
. 12 Comments

I sent a friend an email with an attached Zip file. It bounced, with a message from “System Administrator” that read

Your message did not reach some or all of the intended recipients.

Subject: xxxxxxxxxxxxxxxx
The following recipient(s) could not be reached: xxxxxxxxxxxxxxx …

552 5.7.0 review our attachment guidelines. u14sm9443132gvf.20

I figured maybe the note is from my friend’s system – maybe the file was too large? So I resent it to him to another mail address, with the same outcome. Then it occurred to me to mail the file to myself… long story short, eventually I went to the source of all wisdom – ironically, Google – and discovered that Google Mail, through which I was sending, has a policy forbidding any zip file that contains an executable (which my attachment, quite lawfully, did).

So I sent the file via yousendit, and that was that. But it did occur to me that I would’ve saved a lot of time had Google Mail elected to phrase their bounce message in human-friendly informative terms, such as:

Your message did not reach some or all of the intended recipients.
– – –

It was blocked by GMail’l outgoing mail server, because it has a zip attachment containing an executable file. GMail does not allow this. For more info, see http://…..

Not as succinct as u14sm9443132gvf.20, but rather more useful, don’t you think?

Sygnet handsfree design flaws, part 2: Control overloading

Published
by
Nathan Zeldes
on February 17, 2009
in Bad design and Improvement
. 0 Comments

Sygnet Handsfree with stickersBack to my Sygnet Bluetooth Handsfree Carkit model BTS600. We saw its problem with cloaking the controls and indicator lamps… but on top of that, the people at Sygnet played a trick that is becoming very common in this digital era: they overloaded the controls and the lamps.

I use Overloaded in the Object Oriented Programming sense: the use of one operator or function name to perform several different functions depending on context.

The Sygnet device has three operating buttons and more than a dozen actions; so each button can do many different things. For example, the “-” button rejects a call if pressed for 3 seconds while the phone is ringing; it initiates voice recognition dialing if pressed for 3 seconds when the phone isn’t ringing; it cancels the voice recognition if pressed until a beep is heard; it cancels bluetooth device recognition if pressed for 6 seconds; it reduces audio volume; it mutes/unmutes a call when pressed concurrently with the “+” button; and it starts a conference call if pressed for 3 seconds while one call is active and another waiting. The other buttons likewise do a great many things; it’s so complicated that I carry the instructions in the glove compartment at all times! Needless to say, the captions on the device merely identify the buttons, not their functions.

The two indicator lamps, meanwhile, are similarly overused: The blue lamp blinks 3 times every 2 seconds to indicate an active Bluetooth link; it blinks rapidly together with the red lamp when the device recognizes the cellphone; it blinks every 2 seconds when bluetooth is inactive; it stays lit with the red lamp during charging, and without it when charging is completed. So now you need a stopwatch to figure out what it means…

To illustrate how excellent this human engineering is, consider its application in a ballistic missile situation: “Hey, Joe, does two blue blinks followed by a long beep mean a 3 second push on button D launches the missiles unless you first tap on button A, or does it mean the Mr. Coffee needs maintenance?”

So, what can we do about this? Well, by now you know my style. At least I could make the cloaked buttons eminently visible…

Sygnet Handsfree with stickers

Sygnet handsfree design flaws, part 1: Control cloaking

Published
by
Nathan Zeldes
on February 14, 2009
in Bad design
. 1 Comment

Sygnet Bluetooth HandsfreeWhen I got my Nokia E71 smartphone, I also bought a hands-free device for it: the Sygnet Bluetooth Handsfree Carkit model BTS600. This actually works quite well – it wirelessly identifies the phone on my belt when I get in the car, and until I leave the car all calls are routed to this device. Throw in voice recognition based dialing, and it’s convenient indeed.

Still, the controls of this elegant space age device – it really looks like a miniature flying saucer, doesn’t it? – embody some basic human engineering errors, ones that are all too common in other products; we can call them control cloaking and control overloading.

By control cloaking I mean making controls that are all but invisible and indistinguishable from each other. The BTS600 has only four controls: a power switch, and the three marked with +, – and a handset symbol. The user needs to identify the last three rapidly, at a glance, while driving a motor vehicle. So what would you do to make this easy?

I know what I would do: I would design large, obvious buttons, each differing markedly from the others in color (for daytime use) and in shape (for night time driving). Something like the three skyscrapers in the Azrieli Center in Tel Aviv – one round, one triangular and one square, and all impossible to miss…

Not so the good engineers at Sygnet. They made the three buttons flat, and blended them into the device’s surface so elegantly that you can barely make them out – with tiny labels that are hard to read even when parked. And the device’s perfect circular symmetry makes it impossible to locate the buttons by their positions relative to its edges.

Sygnet Handsfree controls

And then there’s the matter of indicator lights. The device has two lamps: blue and red. You’d expect these to be visible from all angles; which would be the case if they protruded outside the casing. But instead they are sunk deep inside, under the clear plastic ring around the speaker grille. Again, very elegant – but quite invisible unless you look straight in.

Don’t miss the control overloading post coming up next!

Adobe Photoshop’s little infamy

Published
by
Nathan Zeldes
on January 23, 2009
in Bad design
. 2 Comments

It’s hard to speak ill of Adobe Photoshop. Even its painful price tag is well justified by this application’s incredible power, which I’ve been barely scratching in my many years as a faithful user. Still, there is one inexplicable sin its designers have committed.

Tastes vary, which is why Microsoft have included in their Windows OS the ability to customize the GUI’s elements. For my part, I do three things whenever I install Windows for my use: get rid of that incongruous green hill on the desktop, revert to the more businesslike classic (“Windows 95”) look, and make the menu font easier on the eyes by turning it Bold and, on high-res screens, enlarging it by a point. Since the whole idea is that this font tweak affects all programs running under Windows, I’m all set.

So what happens when I upgraded from Photoshop CS to version CS2? The menus are a tiny, skinny Normal font. The good folks at Adobe decided to violate the basic guideline that all apps must comply with the Windows UI preferences. The user’s preferences. My preferences. “So why do we care”, they say, “if you get a headache from peering at a tiny font? That’s none of our concern!”

Photoshop CS and CS4 Menus

But that’s not the end of the story; because in CS2 they also added the option, in Photoshop’s Preferences, to choose the UI Font Size! What Adobe hath taken away, Adobe now giveth back! Hallelujah! I select Large, restart the application as directed, and… various elements of the UI – Palette captions, for instance – are indeed larger. Except the menus. They remain tiny. Looks like they applied this “UI Font Size” setting to only part of the UI but not to the one they initially messed with.

And now I moved ahead to CS4, and I was hoping they’d seen the error of their ways and given us back control over our menus, one way or another. So I was hoping… but of course they hadn’t.

Take note, Adobe… that is bad, bad programming practice.

The opposite of Human Engineering

Published
by
Nathan Zeldes
on January 16, 2009
in Design history and Design principles
. 0 Comments

The key idea of Human Engineering is to design the product to fit the humans using it. Makes sense? Sure does, but there are also cases of the opposite approach; Select the human to fit the task or the product!

Obvious examples abound in sports, as with the physical attributes of the horse racing jockey and the basketball player (and while we can’t change the horse’s reaction to a heavier load, we could actually lower the basket if we were designing it to fit the average human…)

A technological example would be the Soviet solution to giving battle tanks a low silhouette: make the tank low, and recruit soldiers of short stature to Cray Wiringcrew them.

But an example I really like has to do with the construction of the Cray 1 supercomputer in the 1970s. This elegant computer was built in a round form with the electronics modules on the outside and a central cavity surrounded by the wiring connecting them (the same idea, more or less, is used in the human brain). The wires – huge numbers of them – had to be soldered correctly in the narrow central space, a nightmare task. So how did they manage it?

I once met a veteran of Cray Research at the Computer History museum and he explained it to me. Cray hired women for this task – ones selected for their patience and precision – and they put two of them on each machine: a tall girl to solder at the top of the structure and a short one to work the bottom. Unbelievable? Look at these photos!

Cray Wiring

Cray Wiring

No, I don’t know anyone in the Ashmore Islands!

Published
by
Nathan Zeldes
on January 12, 2009
in Bad design and Improvement
. 1 Comment

Two of the least pleasant-to-use GUI controls are the scrollable list box and its cousin the drop-down list, especially when they have many items listed. Of course, that’s exactly when they are indispensable… you can’t use radio buttons for 50 choices, so if you need to let the user choose a state of the union, a drop down list is inevitable. Likewise for countries of the world, or for their currencies.

But the way these geographic-oriented controls are implemented in software and web sites is really annoying.

Drop-down List of countriesTake the image at right, the list you have to go through to select a country for a new contact in Outlook and other applications: it opens on a list of ten countries, of which one – Argentina – may be even remotely likely to be inhabited by business contacts of yours. You can scroll down, of course… and in the next ten you find even greater concentrations of business partners, like the entry for the Ashmore and Cartier Islands, which are a group of small uninhabited tropical islands in the Indian Ocean!

Not that I have anything against the inhabitants of Ocean islands, or of Angola, Antigua, or Anguilla, but given the statistics, why should I have to scroll past them – and past Cook Islands, and Namibia, and Nauru, and Palmyra Atoll, for that matter – on my way to find the US, or the UK, where I really have many more contacts and affairs?

Or look at the next screen grab, from a web site for computing currency exchange rates. Do I really need to have Equatorial Guinea’s CFA Franc, the Eritrean Nakfa, and the Ethiopian Birr pushing down the Euro and the US Dollar farther away from the British Pound, just because of the accident of alphabetic order?

List Box of currencies

Obviously, the people of Estonia do care about the Kroon (and I care about the Israeli Shekel, also far from the heart of global finances). But what is needed is a list that gives the most common choices – the Dollar, the Pound, the Euro – by default at the top of the list, where 99% of users will benefit. And then we need personalization, so each of us in the rest of the world can put their country, or those they deal with, at the very top.

This can be done in many ways. One’s home country can be extracted from Windows Regional settings and put up front. Web sites may use cookies to remember which currencies you converted last time. Local software tools can keep my choices in the Windows registry. Smarter tools may learn from your past choices and bump them up the list in future. The techniques exist; it’s just that someone should step out of the silly box and dump the alphabetic order in favor of what makes users more productive and less annoyed!

The infamous Caps Lock key

Published
by
Nathan Zeldes
on October 24, 2008
in Bad design, Design history and Improvement
. 5 Comments

Caps lock key on a modern PC keyboardEveryone knows that the QWERTY keyboard layout sucks, because it carries a legacy from the early typewriter days; still, we’re all locked into its use and live in oblivion of what we’re missing. But we have another legacy from mechanical typewriters that is hard to forget because it bites us daily. i REFER TO THE cAPS lOCK KEY.

It is interesting to trace the history of this design infamy. Originally, it made a lot of sense: in a mechanical typewriter the Shift keys did just that: they shifted the type mechanism vertically so the type bars would hit the paper with the uppercase letters; and the Shift Lock key would keep the keys locked in this position. This key had to sit right above the Shift key, because it physically latched it in a depressed position; hitting Shift again would release the lock. It was very easy to see (and feel) whether Shift was locked or not, because both keys would be depressed when the lock was engaged. The photos below are from an antiquated Royal typewriter; you can see how the Lock key holds down the Shift key on the right (and note the quaint caption on the latter key – Shift / Freedom, in allusion to releasing the Lock).

Shift Lock in an old typewriter

Early computer keyboards carried this idea forward, with a Shift Lock or Caps Lock key that had two physical positions: depressed for Lock, and flush with the other keys when released. You could therefore tell when you were in Caps mode, and would notice immediately if you hit the lock accidentally while touch typing. The delightful Commodore 64 had this feature, among others; the photos show a keyboard that came with the collection of homebrew boards described here, from the late 70s.

Two-position Caps Lock in a 1970s keyboard

Later, as keyboard makers sacrificed quality for cheap manufacturing, the more complex and different two-state key was replaced with a momentary key like all the others, with electronics to implement toggle action. Gone was the tactile feedback. Now a simple brush of the finger could accidentally lock you in Caps mode. Worse still, the position of the Lock key next to the left Shift key, which made sense a century ago, was retained – placing this relatively little used key right in harm’s way.

I don’t see manufacturers giving us back the 2-position key (it would cost them a few cents, after all), but the least they could do is move this stupid key to the top row, next to the Scroll Lock, where it will remain unused, unnoticed, and harmless.

So, what can we do about this? Well, one thing we can do is disable the offending key. No need to tear it out – I used KeyTweak, a free key remapping utility, to disable it on my Windows XP system. Good riddance!

Also, if you use MS Word, you may be unaware that depressing Shift+F3 repeatedly will change any selected text to lowercase, uppercase, and sentence case; a very useful feature after YOU’VE ACCIDENTALLY HIT sHIFT lOCK AND CONTINUED TYPING.

One hand!

Published
by
Nathan Zeldes
on September 4, 2008
in Good design
. 0 Comments

Here is an absolutely trivial product feature that turns out to be very nice. This is the latch release for the more recent IBM (now Lenovo) Thinkpad notebook computers.

I’ve been through more models of Thinkpad than I remember, and until the T4x series they all had two latch releases on the front edge of the lid. Then came the T40, and it only had one, on the right, which actuates both latches through an inner linkage. When I first saw this I was disdainful: who cares, after all? But when I started to use a T41, I realized how useful this feature is. These days we mobile users run around the workplace from meeting to meeting with our notebook; and until someone comes out with the secondary displays we’ve seen on futuristic promotional videos (but never in reality), we often have to open the notebook to check details of our coming meeting while walking towards an elevator… and with the single-latch arrangement, you can hold the machine in your left hand while opening its screen with the right.

Like I said, a trivial detail, but it really is useful. A nice piece of design from IBM!

Invisible writing on medicines

Published
by
Nathan Zeldes
on August 11, 2008
in Bad design and Good design
. 0 Comments

Here is a box containing some medicine. As the law requires, it has the lot number and expiration date clearly marked. Well, OK, not clearly… in fact, the information is barely visible at all. The law, one can guess, says nothing about the information having to be Legible.

Medication box

It’s not like making the text visible is so difficult… as the next photo proves.

Medication Box

Backlit cellphone keys – not such a good idea!

Published
by
Nathan Zeldes
on July 14, 2008
in Bad design
. 0 Comments

Have you had the experience, as a child, of discovering the optical properties of oiled paper?

I remember it well… I was an avid reader as a kid, and when a smudge of oil from some snack would get onto my books I’d notice that the translucent oily spot that looked darker than the paper would become lighter when you held the page up to the light. Before long it occurred to me that if the shade of oiled paper can go from darker to lighter as you raised the page, there must exist an intermediate position where the spot would become invisible as its shade became identical to the dry paper’s. Sure enough, so there was!

We met the hard to read keyboard on my Nokia 6230i before. Well, apparently the keyboard designers at Nokia were also trying to emulate the oil/paper experiment from my childhood…

Nokia 6230i keys in daylight

Like many handheld devices these days, the keyboard on this phone is backlit. The numbers are translucent, and a strong white light can shine through. Seemingly a great idea, for night time use. Now in bright daylight this works fairly well. The backlight gets washed out in the sunlight and although the transparent digits are of a lower contrast than a black ink would have provided, you can see them well in dark gray on silver (since the keys are silver and reflect ambient light in unpredictable ways, the contrast admittedly varies, as seen in the photos; I’ve already commented on the advisability of plain black on white for optimal viewing). But once evening starts to fall…

Nokia 6230i backlit keys in low ambient lightThe third photo shows what happens in lower ambient light. There is an intermediate light level when the transition from dark numerals on bright silver to white backlit numerals on dark silver just evens out, and the numbers become almost invisible. In fact, since the backlight source is localized, different keys reach this point at different light levels; in the photo the “7” is in day mode, the “0” is in night mode, and the 5 is barely visible – just like the oil spot on those old books.

Now imagine trying to distinguish these keys while driving, with the phone in a hands-free cradle, where you can’t touch-type and you need your attention on the road.

So, what can we do about this? Well, we could prefer black keys with white digits – then the day and night contrast would be the same so there would be no crossover point of invisibility. Another good idea (which I recall seeing on some devices) is to make the backlight come on only in truly low light conditions. And of course, we should test the devices we buy in all situations, not just in the bright showroom where we normally make buying decisions…