Posts Tagged 'usability'

28 Things Everybody Should Know, Part XXVII

No one system will make every user happy.

Judging by the sheer number of mobile phones, third-party plugins, variations of Linux and alternatives to Internet Explorer available, it’s clear that no one system can please every user. Reading through previous entries here, I assume I’m much harder to satisfy than most others (or at least louder about it), but I’m not completely alone. Everyone has a different philosophy on the ideal user experience, and while it’s impossible to cater to the needs and desires of every last user, it is possible to allow for customization and flexible interfaces.

I use Windows XP at home, but I’ve never liked the default XP theme, with its large buttons and rounded window corners. Yes, it’s more aesthetically pleasing, but takes up a bit more real estate on the screen and demands a bit more attention that the comparatively flat look and feel of previous Windows versions. (I think of the operating system as a launcher rather than a playground–I want it to support the programs I use, but I don’t need it to blow me away with its own graphics.) Luckily for people like me, Microsoft offers a reversion to the Classic theme, which also takes less of a toll on the CPU. I’m also not a fan of animated operating systems, such as the scrolling or fading Start menu, or the moving, fading, zooming functions in Mac OSX and Windows Vista. Again, these features can be disabled for users like me, who prefer a more efficient workflow over an aesthetically impressive one.

With user diversity in mind, Apple developed their App Store to make it easy for users to customize their iPhone experience. While the operating system itself is like nothing previously on the market, they knew the full potential of their product wouldn’t be reached without allowing downloadable applications and add-ons that take advantage of the multitouch screen, accelerometer and connectivity.

Adobe applications, like Photoshop and Illustrator, start with a default, consistent shortcut scheme for their functions–Ctrl + Z will undo an action, Ctrl + W closes a document–and users may set their own shortcuts in the Preferences menu. Adobe understands that some computers, especially in studios and offices, will often have multiple users, so declaring a shortcut key doesn’t override the default setup. This way, in typical Adobe fashion, there can be several ways to achieve the same result, improving the overall experience for those who are used to a specific setup without infringing on those who prefer the default settings.

While it’s not possible to predict the demands and preferences of every user, there are a few broad categories developers can anticipate most users falling into: those who will happily use the product the way it’s intended and expect nothing more, those who will be generally happy but want a little extra in terms of personalization, and those who stubbornly stick with a product–or give up on it–because of the product’s (and the user’s) inflexibility. Unfortunately, the first camp is rarely an overwhelming majority, and the latter is largely comprised of power users who are hardly ever happy with default settings and features.

With those in the middle group, users who would like something extra to enhance their experience, who may just be waiting for the next, slightly improved model to come along, customization is the key to ensuring a more loyal user base. Even after years of constant product testing, there’s no telling what might be the next social networking phenomenon or popular time-wasting puzzle game after a product is released, so allowing future updates and downloadable content should help keep a good chunk of customers from switching to a different product or service. In the short amount of time since the iPhone was released, websites like Pandora and Twitter have become increasingly popular among users; imagine how unfashionable it would be for Apple to have included a permanent Myspace button on the bottom of the iPhone.

It’s not bad that some people are stubborn, unyielding users who have definite expectations for human-computer interaction. What’s not so good is when those people become stubborn developers and let their compulsions get in the way of the interest of the user. The best way to reach a wide audience is to understand that no one system will make everyone happy, and allow enough customization to make users feel comfortable with the experience.

Advertisements

28 Things Everybody Should Know, Part XXV

Users can play their own music on their own time.

When the internet was a little younger, its destinations more foreign and its designers less aware of what they were getting into, websites were full of splash pages and blink tags and animated gifs of spinning mailboxes that linked to webmasters’ email addresses. One annoyance in particular, which still rears its head from time to time, was the embedding of audio into web pages.

A decade or so ago, before broadband overcame dialup and bandwidth was a precious commodity, websites would embed MIDI files which saved load times, but sounded a lot like a Casio keyboard playing elevator-style renditions of radio hits. As technology improved, audio files could be compressed and included on sites, loading slower, sounding flatter and skipping if the connection couldn’t keep up. It wasn’t perfect, but we finally had auditory accompaniment to our blink tags and spinning mailboxes.

Around the turn of the century, music groups began sprouting up all over cyberspace. Most bands on the radio had some sort of web presence, from an offshoot of a label’s site to their very own domain. I used to type band names into my address bar, followed by .com, and see where I ended up. A majority of the sites welcomed me by sending the band’s most recent single through my speakers, at whatever volume they had been set to. Hardly a warm welcome, especially considering some of the stuff I listened to back then. And in many cases, there was no audio navigation to be found–no Stop, no Pause, no volume control– so I was forced to either sit through the entire song, leave the site, or turn off my speakers, and my own music along with them.

The very reason I thought to visit many of these sites was because I was already a rather loyal fan, and in most cases, I already owned the music. In fact, there was a good chance I was listening to the very band whose site I was visiting, so forcing the same music through the same speakers at the same time was a bit unnecessary.

There are several ways to embed an audio clip into a block of HTML, and while today the options have been whittled down to a handful of refined, browser-friendly choices, a few years ago this wasn’t the case: designers had to choose from QuickTime, Real Audio, Windows Media Player, a bunch of third-party plugins, and even dropping entire audio files into an HTML editor and hoping visitors’ browsers understood how to handle them. We also had CD players and radios that played what we chose to hear, especially during leisure time which we spent browsing the internet. So forcing a user to listen to a song–even by a band they would probably enjoy, given their decision to visit the site in the first place–isn’t the friendliest way to welcome new visitors.

Today we have sites like PureVolume and Myspace, both aimed (at least in part) at helping bands reach a larger audience. Myspace uses Flash Player to play songs on a band’s profile page, but also lets users play music on their own pages. By default, the music starts on its own, unless a user logs in and changes the audio settings. Essentially, browsing a dozen user profiles could lead to a dozen songs playing automatically. We also have iPods, Pandora and XM radio, offering a much larger selection of music we can play at any time, and the choice to listen to music while browsing is becoming cheaper and easier. Why disturb users with something they may not want to hear at the time?

People browse websites at various times of the day, in various moods, and in various settings. Computers are used in libraries, on airplanes, and near sleeping babies. As it’s so far impossible for a computer to determine whether or not it’s a good idea to put some music on, it’s best to leave it up to the user to press Play. And a Pause button is never a bad idea either.

28 Things Everybody Should Know, Part XXIV

Some conventions just aren’t worth messing with.

More often than not, it would seem that analyzing and redesigning a piece of hardware or software to increase productivity would be a good idea, especially if such changes include faster, safer, cheaper or simpler operation. A good example is Leo Beltracchi’s implementation of a graphical display system for nuclear power plants in the late 1980s, eliminating the need to frequently compare numbers to ensure the temperature of a reactor core is within a safe margin. This replaced confusing numerical data with a simple curved line portraying the temperature at which liquid inside the core begins to evaporate, and a dot representing the core’s current temperature. This system, still in use today, is no doubt responsible for a drastic improvement in modern power plant supervision, if not the prevention of fatal accidents that would have happened due to a couple easily missed equations.

Consumer products, such as cars, electronics and appliances, often receive updates when laws or demand calls for them. Airbags, scroll wheels, touchscreens, a fourth razor blade–these are all added features meant to improve some aspect of an existing product. Without improvements like these, consumers would have less reason to replace their products with new ones.

There are, of course, improvements to products that don’t necessarily boost their efficiency. For instance, the Dvorak keyboard, an alternative to the much more common QWERTY layout, shows a decided increase in performance with users who are familiar with its key placement. However, the QWERTY layout has been around for over 130 years, and most computer users have never seen a Dvorak keyboard. The QWERTY layout has become an established standard in computing, and to replace it with the Dvorak layout would not only mean somehow convincing the entire world to give up what they’ve grown to know and learn a completely new system, but the cost of replacing every keyboard with the updated layout would hardly be worth what little increase in typing speed would result in the change.

Similar attempts to update the keyboard have been made with keys other than the numbers and letters. Supposedly, these changes are meant to better the intuitive nature of the keyboard, but to a user who has spent a lifetime working with a specific layout, the outcome is just the opposite.


These six keys–Insert, Delete, Home, End, Page Up and Page Down–are grouped in this order on most modern keyboards. Because of their location relative to the arrow keys, they can easily be found without the user looking down from the screen. In fact, I use the Delete key more than I use Backspace, due solely to its location, and have become used to moving my cursor to the left of a character rather than the right before deleting it. As a user from the days of DOS, I still use the Insert key from time to time, as Copy, Cut and Paste all used the Insert key years ago, and many applications still have that option. The rest of the keys in that cluster are frequently used in navigating many types of documents and browser windows, and the wonderful thing is that I never have to look down to use them.


Here is a keyboard which breaks that established six-button group, eliminating the Insert key and rearranging the rest. Home and End are now left and right of each other, which makes sense when considering the direction a cursor moves along lines of text in a word processor, but not so much in a web browser. The Delete key, for some reason, has doubled in size, and the orientation of the group is now vertically arranged. Even if this layout might prove useful for certain users in certain applications, changing the layout of a conventional, time-tested setup only confuses the majority of users and breaks consistency with other keyboards on the market.


Function keys, used a bit like wildcards in computing, can serve a number of uses. Most of us know that F1 will bring up help files to assist us when we’re stuck, and we know just where to find the key. Packed together in groups of four, the function keys are easy to discern from one another without having to read their labels. As it turns out, four keys grouped together are easy to count internally, so users can quickly find, say, F8 without much hassle–it’s the last one on the second group of function keys.


Here’s how the other keyboard groups the function keys, in sections of three keys each. Even if this turns out to be slightly easier for users to use, the vast majority of keyboards group the keys in fours, and keyboards that break this rule are only confusing users who have grown accustomed to the norm. Even worse, users who switch keyboards often will find more difficulty using either layout smoothly. It’s hard to develop a productive subconscious pattern when you’re forced to break the pattern half the time.

On top of the different layout, the function keys on this keyboard don’t recognize commands that others do. F2 doesn’t rename files, F3 doesn’t search, Alt-F4 doesn’t close applications and F5 doesn’t refresh pages. They don’t even do what their labels say they’re supposed to, unless they’re used in Microsoft Office applications. What good is a new layout when it must be relearned and fights every convention we’ve established in the past?

Fortunately, changes like this aren’t as common as changes that actually improve on the user experience. Users are often reluctant to accept change, which is probably a good thing. Without sticking to a few consistent, global standards, we’d be reinventing the wheel with each new product we develop.

28 Things Everybody Should Know, Part XXI

Try to break your system before someone else does.

Product testing is often overlooked by developers whose products aren’t a threat to anyone’s safety, or for which laws don’t exist to mandate testing. But the majority of all products and services are designed for a market not comprised of like-minded developers, and users will inevitably end up making mistakes not accounted for during the development process.

Another problem with experience design is that developers often test their own products in the way they’re meant to be used, without exploring different approaches that might inadvertently–or even purposefully–cause the system to fail.

Corner cases are situations beyond those normally anticipated by developers, where a user might push the abilities of a product further than it was constructed to support. In certain scenarios, such as with load-bearing pulleys and cables, corner cases must account for wide margins (a pulley I have states its limit at 500lbs, but I suppose it will probably sustain twice that without breaking–the company probably severely understated its abilities to prevent accidents and ensuing lawsuits), whereas electronics like computers don’t need such a large safety net (many people safely overclock their systems, threatening little more than the longevity of the computer itself).

Borrowing from Murphy’s Law, wherever there is the possibility to break a system exists, someone will find it sooner or later, and it’s best to catch it and fix it (or create an acceptable workaround) before it hits the shelves and starts causing problems.

By way of example, most keyboards today only recognize four keys pressed at one time. Honestly, the keyboards themselves probably recognize many more than that, but probably refuse to relay the extra signals to the computer. I don’t know exactly why they do this, but seldom are more than three keys ever used simultaneously, and it’s possible that too many signals at once could cause some applications to go a little crazy. (In fact, it may be a Windows problem–I don’t recall experimenting on a Mac.) But with all the various programs out there, most only really dealing with one or two keystrokes at a time, limiting the operating system’s recognition of more than a handful of keys undoubtedly has solved some problems. And it’s still more than you could ever press at the same time on a typewriter.

This is a screenshot of LEOGEO, a website I discussed earlier. Under normal circumstances, the gray letters expand to display a link when the user rolls over each one, and reverts to its single-letter state when the cursor rolls away. Essentially, only one link is in its full state at any given time.

In Flash, the commands used to trigger events with the cursor rolls on and off buttons are on(rollOver) and on(rollOut). However, there are a few more states designers often fail to account for, and one in particular can result in multiple rollover states the designer hadn’t planned for: on(releaseOutside). This tells the computer how to act if a user clicks the mouse button down, drags the cursor away from the button on the screen, and then releases the mouse button. Without declaring a releaseOutside event, the button stays in its rollOver position until the cursor rolls back on and off the button a second time.

LEOGEO’s buttons weren’t scripted to handle this unexpected behavior, which can occur when a user is moving the mouse and clicking multiple buttons rapidly–or whenever I decide to test buttons to see what will happen. Once a website goes live, there’s no telling who will use it, and if every unlikely problem isn’t anticipated, it will very likely turn up at the most inopportune time.

The best way to make sure a system won’t break is by doing everything possible to break it. Automotive companies crash test their own cars extensively, using their findings to improve on future models and features. Unfortunately, many developers don’t have the mindset of a product tester, and certainly don’t think the way typical users do, so without knowing what it takes to break a system, they can’t possibly know how to prevent such a breakdown.

28 Things Everybody Should Know, Part XVIII

Drunk people are users too.

Products deemed to be potentially dangerous to the user or the surrounding environment, such as vehicles, weapons and chemicals, are tested under more strenuous conditions and held to higher engineering standards to ensure a level of personal and public safety. Cars are built with a large number of features meant only as a last resort to save lives during an accident, while household products which can’t have safety mechanisms added–bleach, for example–can only be fitted with safety switches and warning messages on their labels; of course, once the bleach has left the bottle, the label can’t follow it to warn of the dangers of its use.

Some cars are equipped with breathalysers, usually issued after a driver has already been caught inebriated behind the wheel, that won’t allow ignition unless the driver’s alcohol content is below the legal limit. Unlike seat belt, airbags and engine mounts that release the engine rather than crush passengers under their weight, the breathalyser is a precaution meant to prevent a tragedy from happening in the first place, much like the safety switch on a pistol. These all seem like common sense today, but not so long ago they were mere suggestions to the manufacturers.

Architecture is another field of design where safety is a primary concern–emergency elevators, backup stairways and fire escapes are all mandatory additions to large buildings and public spaces. But one place where safety is overlooked, sometimes to an obvious degree, is in the interior design that comes after the architects have finished their job.

Interaction design plays a major role in interiors, and in many cases, it seems, safety concerns are overlooked in the interest of artistic value. In this example, I have to again draw from my experiences at The Triple Door in Seattle. It’s not because I didn’t like it there, but because it seems the designers felt like product testing just doesn’t apply to interiors or architecture, which is unfortunate.

The upper level of the establishment is an upscale bar, complete with a giant fish tank, floor-mounted lighting and, as I mentioned in an earlier post, unmarked restrooms. There is a row of booths for private dining along one side of the bar, and surrounding these booths is a wall about chest high and perhaps five inches thick. The wall is topped with a smooth black finish, and happens to be the proper height on which to rest one’s drink while mingling, dancing, or searching for the restrooms.

In fact, the wall seems like it was meant to hold drinks. And why wouldn’t it? No sense letting that space go to waste. The only problem is that the smooth, slick finish is set at an angle–maybe 10 degrees–and does a really good job of holding a glass full of liquid just long enough to give the illusion that everything’s under control. After picking up the shattered remnants of one too many pint glasses to qualify as random user error, I discovered the angle of the wall wasn’t flat, and tested my own glass on its surface. The less liquid in the glass, the longer it would stay–an empty pint glass generally stayed indefinitely–but a full pint fell off within a couple seconds. A half-full glass was too sporadic to come to any conclusions, but more often than not, it would eventually fall in the time it would take most people to remove their coat.

And that’s considering the people weren’t already hindered by the effects of alcohol. Of course, I was sober when I did these tests–the glass I used was filled with root beer–but this being a bar, the designers should have taken into consideration the altered state of a drinker–not just your average tipsy patron, but the Friday night college student with no kids and no responsibilities. If there is a law in effect disallowing a bartender from serving outwardly drunk customers, establishments like this should put forth the effort to lessen the possibility for accidents and injuries that are amplified when alcohol is introduced. Drunkenness may be considered a corner case from an engineering perspective, but that doesn’t mean it’s less common, just less anticipated in most situations.

Interior interaction seems to fall through the cracks between the architectural and decorative stages, almost as if all safety concerns are expected to have been solved by the architects who are long gone before the next wave of designers step in. But to dismiss the safety aspects of any facet of design is to invite more hazardous situations–especially when a user’s behaviors might be altered by a factor such as alcohol. I’d go so far as to say it would be more responsible for a team of designers to hire drunk product testers to examine new interiors and user experiences at various degrees of inebriation. I’m sure there are people who would volunteer for just such a position.

28 Things Everybody Should Know, Part XII

Don’t limit options when any key will do.

Another example of meaningless button-pushing is something I call Start Button Syndrome. As a child in the ’80s, I played a lot of Nintendo games, and after the opening credits, I’d see an intro graphic and two simple words, usually white on black, urging me to “Press Start!” Sometimes with two exclamation points. Such enthusiasm right off the bat.

Many titles screens offer several options: start a new game, load a previously saved game or enter a password, modify settings and gameplay options, and maybe view the game’s credits. But those games that only had one available option–to continue to the next screen–still primarily called for the user to press only the Start button.

The Nintendo controller is generally held with two hands, one on each side, while the Start button sits in the middle of the controller, a thumb’s stretch from the comfort of the A button.

The Start button is aptly named for its intended purpose of getting things going. Other purposes, such as pausing and unpausing the game, are less commonly used and should require more effort than the more common game buttons. But when a player’s thumb typically rests on the A button, why force the stretch to the Start button and ignore everything else on the controller?

Personal computing largely worked around Start Button Syndrome early on, asking users to “Press any key” when ready. With the multitude of keys on a keyboard, asking a user to locate and press a certain button would only slow down the process and cause unnecessary frustration. Still, there are times when it makes sense to require a specific key to continue: with so many available on a keyboard, and at least one hand normally resting on a row of keys at any given time, it’s easy to accidentally bump a key and agree to something before the implications have sunk in. Certain actions–those which can’t be undone, agree to legal terms or trigger hardware such as a printer or other equipment–should require a bit more thought to activate.

Many Flash games these days suffer from their own version of Start Button Syndrome. Instead of allowing a user to click anywhere on the page to skip an intro animation or bypass the start screen, a tiny button is used when no other functional elements are on the screen. Using a button labeled “Start” clearly tells the user what will happen once the button is clicked, which may take away from the desire to allow a user to click just anywhere–but a full-screen button should enable the hand cursor, which will tell the user the entire area is clickable, and many intro screens include the text “Click anywhere to start,” which makes it much easier to begin the game, and clears up any confusion that might arise from displaying the hand cursor throughout the entire page.

The DS, Nintendo’s most recent portable game platform, has several games which still stumble into the pitfalls of Start Button Syndrome, although I’m pleased to say the problem is getting better. Many games still begin by prompting the player to push start–an action which can be even more difficult than on the original NES controller if the player is holding the stylus at the time. To rectify this, games can allow a tap anywhere on the touchscreen to substitute for the Start button.

Another problem, however, is when a game requires a tap on the touchscreen–or a specific button somewhere on the screen–and won’t accept any other button in its place. This assumes the player is holding the stylus, and can serve a purpose if it means to prepare the player for a stylus-heavy gaming experience. But since the inclusion of a stylus essentially allows for two types of hand positioning (much the same way the N64’s three-armed monstrosity led to the forced triage of at least a few of the controller’s available buttons at any given time), both positions should be accounted for when trying to get past the introduction.

Limitations serve many important purposes, but can get in the way when a user is forced to take a specific action for no apparent reason. Showing an interest in the user’s available options and taking care not to unnecessarily limit those options is another step toward strengthening the developer-user relationship.

28 Things Everybody Should Know, Part IX

Door handles should look like door handles.

I used to work at a bar and music venue in Seattle called The Triple Door. I only mention the name here because the three doors after which the place is named have some pretty obvious design flaws–dangerously obvious–and I urge anyone interested in interaction to visit and take a look at the doors in question.

After a short flight of steps down to the lower level, the first obstruction is a set of three large, black doors, which remain closed and locked to keep out those who haven’t been admitted to the theater area. Employees, armed with magnetic keys, always open one of these three doors for the guest, which only further adds to the big problem later on.

Once past the first door, the guest is in a small room with three more doors in front and a large, floor-to-ceiling window to the right, kept impeccably clean. The lights in this room are kept low, and the doors painted black, so not much is visible save for the performance through the window.

The main problem here is the design of the door handles: long, skinny poles connected to the side of each door, also painted black, with no markings to imply their affordance as door handles. Furthermore, as the doors must be pulled to open them, the hinges are on the inside–large, bulky, almost handle-shaped hinges, silver in color, to set them apart from everything else in the room. What’s more, the hinges are placed at the same height one would expect a door handle to be. So guests would frequently attempt to pull or twist these large hinges, obviously to no avail.

Because the first door had been opened for them by an employee, customers would have no idea how these doors should function. Pushing on them does no good, as they open in the other direction. Every night I worked there, frustrated customers would come back through the first set of doors (which do open outward, and can easily be pushed open) and ask for assistance, expressing embarrassment or claiming we forgot to unlock the second set of doors (which have no locks).

Another scenario, which I unfortunately witnessed several times in my short time there, was customers assuming the squeaky clean, floor-to-ceiling pane of glass was merely a walkway–it does face the dining area and theater after all–and would run face-first into the window, often causing bruises, fat lips and, at least once, a pretty big gash on a guest’s forehead.

The problem with the door handles in this cramped, nearly unlit space could be easily fixed, if the poles were fashioned to resemble handles. I made the suggestion of painting thin white lines on the poles, one above and one below where the average hand would reach for a door handle. This would easily imply the affordance of a pullable object. Nobody went for it, which is understandable. I wasn’t there to change anything, just greet guests and show them their seats.

I also suggested putting a vinyl sticker on the window–maybe the restaurant’s logo or a dinner menu–to make it clear just how solid this large piece of glass was. Nothing changed during my time there, but one day I found they’d put an event calendar in the window. I hope no more injuries had to happen to spur the change, but I wouldn’t put my money on it.

Good design turns bad pretty fast when aesthetics intrude on functionality. This establishment was designed with a certain look and feel that sets it apart from all others in Seattle, but at a cost. Along with the door issue, there were no signs pointing guests toward the restrooms–I guess they thought signs detract from the beauty of a bar with a fish tank and mood lighting–and employees must constantly point out what should be obvious to everyone in the room.

During my time there, nobody else seemed to like my suggestions–the guests were more often than not ridiculed for being too drunk or stupid to operate a simple door or find the restroom. No matter how much I explained the problems everyone knew about, how they occurred or how easily they could be fixed, I just wasn’t in the position to be listened to. Aesthetics were the first and foremost priority, and it takes a lot to spur change in such an established system, especially when design flaws instantly become labeled as human error–which is at once overestimating your market’s understanding of the system and underestimating their intelligence.