A few colleagues have pointed me to the article by movie director-sounding blogger Matthew Paul Thomas entitled “Why Free Software Has Poor Usability, and How to Improve It.”

I’ve given you the link to the original Thomas article, but I’m more interested in discussing Johnathan Gruber’s take on it. Says Gruber in this post:

I posit that the usability and elegance of any product, software or hardware, tends to reach and seldom surpasses the level that satisfies the taste of whoever is in charge of the product. This applies universally, not just to free and open source software. For example, it explains why Microsoft produces such crummy software even though the company employees [sic] thousands of talented programmers and even designers — Microsoft’s decision makers have no taste. But the problem is endemic to open source.

The people in charge of most free and open source software products tend to have poor taste in user interfaces; people with good taste in user interface design are seldom in charge of open source software projects.

Put another way, if you have to ask for better design, you will lose. You need to be in a position to demand it.

Yes. (Adding some more later in the day…) Aside from the comment about Microsoft’s decision makers having “no taste” - undoubtedly a reference to Steve Job’s comment about Microsoft - I have personally seen what can happen when leaders demand better design…and what can happen when they don’t.

Design leadership *has* to come from the top. It can’t be, as Cooper said in February at IxDA 2008 - an “insurgency” driven from below.

Matthew Paul Thomas :: Why Free Software Has Poor Usability, and How to Improve It

<Blowing own horn>

Check UBlog out at http://ui.alltop.com/.

</Blowing own horn>

A few days ago in this post I mentioned that I was writing my UXmatters Magazine column on the drawbacks of the file/folder metaphor. I just completed that article and you can find it at this URL. Or click the title below.

Where’s My Stuff? Beyond the Nested Folder Metaphor :: UXmatters

Blogged with Flock

Ars Technica is reporting that several patent reform advocacy groups have banded together to collaborate on the effort to abolish software patents.

Says Ars:

Supported by the Free Software Foundation, the Public Patent Foundation, and the Software Freedom Law Center, the End Software Patents (ESP) project aims to challenge the legal validity of patents that do not specify a physically innovative step. In addition to helping companies challenge software patents in the courts and in the patent office, the ESP project will also work to educate the public and encourage grass-roots patent reform activism in order to promote effective legislative solutions to the software patent problem.

This is an important effort, and one that UX professionals should support. As I described in my article a few months back in UXmatters, software patents do more harm than good. They stifle innovation rather than protect and nurture it. As I wrote in UXmatters:

The sad fact is that companies often file for and the US government actually grants patents for user interface and interaction design “innovations” that are either strikingly obvious or have appeared before in other systems—that is, when prior art exists, as someone in the field of intellectual property would say. This means, as user experience practitioners, we are at risk of litigation every time we design an application. Each time we fire up Visio or Photoshop, create a new design, then put it out into the world, there’s a good chance we’re infringing on someone’s patent.

I hope that those of you who are active in the user experience field will learn more about this issue and choose to stand with the ESP project. Even if you don’t agree with me (and them), it behooves you to learn more about the issue. It’s quite easy to ignore - until you find yourself staring down the barrel of an injunction or subpoena.

Patent Reform Coalition Aims to Abolish Software Patents

Blogged with Flock

Tags: patents, open source, law

Just thought I’d point to my latest UXmatters article. My idea for this article is that people get stuck at a certain point of understanding a system, and fail to progress beyond a few areas of a rich application.

 After initially becoming somewhat familiar with a system, people often continue using the same inefficient, time-consuming styles of interaction they first learned. For example, they fail to discover shortcuts and accelerators in the applications they use. Other people learn only a small portion of a product’s capabilities and, as a result, don’t realize the full benefits the product offers. Why? What can operating systems, applications, Web sites, and devices do to better facilitate a person’s progression from novice to expert usage?

It’s an idea I’ve been kicking around for a while. Since I owed UXmatters a column, I thought I’d explore it a bit. I’m still working it out.

Hopefully this won’t read too much like a Twitter post…I’m on my way to Beijing China to speak at and attend User Friendly 2007, the annual conference put on by the China chapter of the Usability Professionals’ Association.

The title of my talk is “Changing Processes and Cultures: Setbacks and Successes On The Road To Building Customer-Centric Product Teams.” I’ve posted a slightly longer version of the talk to UsabilityBlog at this URL, if you’re interested in looking at it. (The longer version is what I presented last week at the Atlanta chapter meeting of the IASA, the association for software architects.)

The talk is a three-year retrospective on the process of incorporating user-centered design at Sage Software in North America. Here’s the blurb from the conference site, if you want more information about the talk:

We in the user experience field know that user-centered design and usability activities have the most positive impact when they’re carried out early in the product/service ideation, design, and development cycle. And our stakeholders - those colleagues in neighboring disciplines such as product management and product development - are often eager to become more customer-centric, and would like UX practitioners to help achieve this. However, our colleagues, and more importantly our executives, don’t always know just how disruptive it can be to successfully integrate UX processes and people into the organizational culture.

This presentation will describe the setbacks and successes experienced by the UX group at Sage Software as we drove the adoption of user-centered design and user research processes across multiple product teams in North America over the last three years.

Enjoy. -Paul

Check out this article by David Pogue at the New York Times. He points out a number of usability flaws in Windows Mobile 6.

(If nytimes.com asks for a username and password, be sure to try Bugmenot, a site for generating username/passwords and skipping registration on annoying, intrusive sites.) 

Reaching for Apple, Falling Short

(Originally posted June 2005 - P.S.) 

In the last entry I argued that enterprise software often falls short of the mark when enterprise vendors don’t pay sufficient attention to the specific wants and needs of the intended users.

I claimed that this happens because enterprise software vendors don’t set goals for the learnability and usability of their systems, and because the enterprises themselves don’t hold vendors to high enough standards of application learnability, usability, and efficiency.

In this entry I’ll relate some case studies where negative outcomes could have been prevented. I’ll also discuss why the factors that contribute to these poor outcomes seem to be persistent.

In the next post, I’ll provide examples of how to justify usability for enterprise software, and discuss a model for creating and deploying enterprise software that will result in more positive outcomes.

In the last entry I argued that enterprise software often falls short of the mark when enterprise vendors don’t pay sufficient attention to the specific wants needs of intended users.

I claimed that this happens because enterprise software vendors don’t set goals for the learnability and usability of their systems, and because the enterprises themselves don’t hold vendors to high enough standards of application learnability, usability, and efficiency.

I this post I relate case studies where negative outcomes could have been prevented. I also discuss why the factors that contribute to these poor outcomes seem to be persistent. Finally, I relate a model for creating and deploying enterprise software that will result in more positive outcomes.

Case 1: The “Business Intelligence” System
The technical support group for a major financial software application was responsible for generating weekly and monthly reports on calls to the help desk. Statistics on call burden, call reasons, call resolution time, hold time, post-call work time, and other statistics tracking cost and rep productivity were summarized for management. The process of producing the reports was mostly manual: the data resided in three separate systems, data was extracted via complex (though mostly repetitive) queries, and reports were generated and formatted in a spreadsheet application.

Other groups within the organization - product management, development, user-centered design, and quality assurance - frequently requested custom reports and raw data from the amalgam of systems. Individuals within technical support and the IT group were sometimes overwhelmed trying to deliver their regular reports and comply with “outside” requests.

The business decided to deploy an enterprise-level application enabling support to centralize the data, automate data retrieval and report production, and provide outside groups with the ability to self-service their data and reporting needs.

Upon deploying the application the business discovered that, even after support and IT staff trained to proficiency, it took 5 to 10 times as long for staff to extract data and produce reports. What these groups discovered was that the application’s user interface, which was presented via a Web browser, only allowed users to drag and drop date ranges, field names, and other delimiters into a “reporting wizard” form. Complex queries that previously took 5 -10 seconds to type now took 2 or 3 minutes to drag, drop, delimit, and run. These users, with considerable technical abilities and expert-level knowledge, were essentially forced to interact with the system as if they were neophytes).

Furthermore, the reports were formatted into static HTML. Once produced, users were unable to reformat, rotate, or otherwise adjust the output. Although the simplistic process of query-building proved easier for occasional users from outside groups, the inability to manipulate the output proved frustrating. As a result, support and IT staff were again forced into a bottleneck role, laboriously creating reports to comply with outside requests for reports. Within six months, the technical support group had brought their old systems back on-line, and reverted to their previous process.

Case 2: The Expense Reporting System
A large telecommunications equipment manufacturer decided to move from spreadsheet-based expense reporting to a system that enabled users to input expense information directly into the company’s accounting system. The application promised to eliminate manual steps, including double entry of data, remove data entry bottlenecks, and streamline the accounting process.

Employees at this company had an inkling that the new system might pose difficulties when, two weeks prior to the system rollout date, HR disseminated a 50-slide training presentation to all employees. This was followed up by a mandatory, all-employee desktop video training session in the use of the new system. The training session, developed jointly by HR and IT, was 1.5 hours long.

The productivity lost to training for the new system was a significant expense, as was the projects related to producing training. These expenses were dwarfed by the time and expense lost when the system went live.Everything about the application’s user experience was a mess. The process employees followed to enter, describe and categorize expenses was confusing, long, and ill-thought out. The screens to capture the data were poorly designed. The terminology used throughout the application, while familiar to finance and accounting professionals, was opaque and unclear to most other employees. Information was presented in illogical formats; users were forced to scroll through 200-item drop down lists with nonsensical ordering.

Successfully submitting an expense report, which had previously taken only a few minutes, was now a half-hour undertaking fraught with error and frustration. As a result, productivity and morale suffered. Worse, compliance waned and systemic errors were propagated through the accounting system: some employees simply stopped expensing small purchases, or assigned expenses to accounts that appeared near the top of long account lists.

The Vendor’s Lament: If You Build It, They Will Complain
With their page-spanning feature matrixes, long lists of supported platforms and databases, ROI calculators and downloadable case studies, the enterprise application provider makes fantastic promises. However, many enterprise software development environments don’t adequately incorporate users’ specific wants and needs until too late in the engineering process (if at all).

So why weren’t the users’ wants and needs represented earlier in the development lifecycle? There are many reasons. They can be boiled down to this short list:

• The application is built to satisfy the vendor’s perception of users’ needs, not users’ actual needs.
• Engineering groups own too much responsibility for user interface design.
• “Featuritis”

The vendor is not the user: Often, applications are built without incorporating the perspective of actual user groups. Product managers, requirements analysts and engineers make assumptions about users, instead of observing them and asking the users themselves.

Gathering users’ wants and needs is not difficult, but it’s important to do it right. It’s remarkably easy to gather user needs poorly or incompletely, resulting in a biased or incomplete perspective of users’ wants and needs.

The key to developing an accurate picture of user needs is to distinguish the main user groups (and how the groups differ), then identify the users’ skills, tasks, and needs in the role they assume while using the application. It’s also helpful to usability test conceptual prototypes with actual users from the target customer groups. In this way, early concepts and designs can be tested and iterated very inexpensively.

Engineers are not the users: In many development organizations, engineers are given responsibility for transforming requirements into user interactions, process flows, and screen designs. What results is a user interface that reflects engineersâ’ mental models. Their models for how things work differ drastically from users. Consider this example:

• The engineer: “It’s a state-persistent container for database objects…it requires authentication and setting of cookies, etc etc…”
• The user: “It’s a shopping cart.”

Indeed. To the engineer, it is in fact a “state-persistent yadda yadda.” But not to the user, it ain’t…

Featuritis: Featuritis is a pernicious malady. Both vendors and purchasers contribute to this disorder. Here’s what typically happens on the vendor side of the equation:

• “Competitor A has these 5 features…competitor B has those 10…we’d better put them all in our next release.”

This kitchen sink approach leads to a mishmash of features, with no organizing principle or overarching information architecture.

And purchasers, well, they buy applications with undocumented usability in the door because they don’t know any better. The evaluation and decision-making process for enterprise applications usually looks like this:

• The need for a better, more scalable, faster, etc. process is identified.
• The business case is established.
• The IS organization sets technical and feature requirements (often informed, in somewhat circular fashion, by vendors’ application feature lists).
• Vendors are solicited, and sometimes asked to respond to a Request for Proposal, or RFP.
• Vendors are evaluated on the basis of their responses, and a short list of vendors is generated.
• Vendors’ systems are often brought into the enterprise’s test labs for performance and technical trials.
• A vendor is selected, and the deployment project is undertaken.

This process typically does not provide methods for evaluating the goodness of fit between the enterprise users’ processes, wants, and needs and the vendor’s solution. Many a rollout disaster could have been avoided simply by usability testing a vendor’s solutions with employees during the trial phase.

Solution:
I propose that user-centered design methods and usability testing can aid both applications producers and application purchasers.

Application vendors can utilize user centered design methods as a competitive advantage, to produce solutions that meet the enterprise users specific wants and needs.

Enterprise customers can utilize usability testing to ensure that the IT investments they make deliver fully on their value propositions.

In the next post on this topic, I’ll provide examples of how to justify usability for enterprise software, and a model for creating and deploying enterprise software that will result in more positive outcomes.

A colleague from my old company passed on a link to OS GUI timelines. You can see release dates, versions, and (of course) screenshots from different OS’es.

What’s fascinating is how little GUI’s have changed in 25 years. For example, look at these screenshots from Apple’s Lisa Office System. Check out the desktop in particular (below). How different is that than your current desktop? Not so much, I’d venture to guess.

(Click picture to see full-sized)

If you’ve read my post and followup about how I think the desktop metaphor is broken, you’ll understand my mixed feelings about this stability. Like I say in those posts, I think the desktop metaphor is tired. Both MS and Apple (and various versions of *nix, for that matter) have tried to improve the basic desktop metaphor, but at best their efforts have only made slight incremental improvements to the desktop experience.

I believe that the major players in the OS and productivity app spaces have a fundamental misunderstanding of what would improve the computer desktop. It’s about workflow and managing your “projects”, whether your project is a software application, the bowling league, or your kid’s carpool schedule.

(Originally posted April 2005 - P.S.) 

Enterprise software products are complex, powerful tools. This complexity is one of the reasons businesses sometimes don’t fully realize a positive return on investment from these products.

For enterprise employees who must use the enterprise application, their complexity poses a considerable challenge. When an application is deployed, users are expected to learn the new system, integrate it into their existing work processes, and become proficient enough to allow the organization to realize the system’s full benefits. Far too often, however, enterprise employees find these new systems hard to learn, hard to master, and difficult to integrate into existing processes.

Enterprise software, which broadly encompasses functions such as enterprise resource planning and management, customer relationship management, supply chain management, project portfolio management, and business intelligence, is a multi-billion per year industry Well-known vendors include BMC, Business Objects, Hyperion,  PeopleSoft, Oracle, SAP, and Siebel, to name a few.

Most Fortune 500 companies have multiple enterprise software products installed and many mid-sized business are either actively considering or have implemented solutions. As the market has matured and vendors have searched for new growth opportunities, even small businesses with fewer than 100 people have options available to them from enterprise software makers.

To the growing company, enterprise software promises to convey benefits in a variety of areas, for example:

• Centralizing customer information from sales, marketing, customer service, and support to improve customer service and enable better prospect identification.
• Identifying and managing enterprise-wide resources needed to receive, process, and account for orders.
• Gathering, storing, analyzing, and providing access to data to enable enterprise users make better business decisions.
• Tracking and organizing information related to project planning, tracking, and resource management for multiple projects, enabling an enterprise-wide view of project scope, resource allocation, risk, cost, and performance.

Complex stuff.

From the CTO’s and IT Director’s perspective, these promises assume that the internal user groups can and will learn the new systems and incorporate them into their work processes. But these outcomes are far from assured. Some of the problems and pitfalls:

• Some businesses find that their employees’ productivity decreases because common or critical processes actually take longer using the new application.
• Others fail to realize an application’s benefits because users “vote with their fingers” and don’t adopt the new system.

Businesses can also experience reduced employee morale and increased turnover related to the imposition of new systems and processes. There will always be employees who resist change in any form. However, if the business mandates process changes and deploys systems that users perceive as difficult to learn, use and remember, the user population will see it as a change for the worse. In this situation morale will decline, and the sufficiently disgruntled will leave.

IT organizations responsible for supporting an enterprise application can find themselves overwhelmed as they struggle under unexpectedly high numbers of support requests that often accompany an application rollout. As anyone who’s worked the help desk knows, rollout day for a complex application often seems like the perfect storm for Level 1 support staff.

Why do these scenarios play out in organization after organization? I argue that two factors are driving these outcomes:

1. Enterprise software developers don’t pay sufficient attention to the specific wants needs of the internal user groups.
2. Enterprises don’t hold their vendors to high enough standards of application learnability, usability, and efficiency.

In my next post, I’ll discuss:

• Some case studies where poor outcomes could have been prevented.
• Why the factors that contribute to these poor outcomes seem to be persistent.
• A model for creating and deploying enterprise software that results in more positive outcomes that these products can deliver.

This is a few weeks old, but I did want to point to this article. It reviews a number of “web tops”, or web-based desktops. Calling them web OS’s is a bit grandiose, but if you accept for the moment the idea that to many people, the desktop *is* the OS, then you can get by this bit of semantic overreach.

What still consistently amazes me is that so many offerings simply recreate the tired old desktop/file/folder (and now “widget”) design. Some do it better than others, but it seems like everyone is stuck in this metaphor. What happened to 3D spaces where you could organize your “stuff” in nooks and crannies? What about more integrated views of people’s frequently used data?

Web As Desktop: 20 Web operating systems reviewed - Lifehacker

Blogged with Flock

One my regular reads - I think it was /. - pointed to a story on Space.com about the awe-inspiring discoveries made by the Mars Rovers, Spirit and Opportunity. The story is in the ever-popular “top 10″ format.

I’ll read anything about the space program, so I clicked on over to the story. And was bummed out to find some usability whoppers that seriously impaired my enjoyment of the story.

Here’s my “top three” list of usability issues I found. Follow this link or the one at bottom and see if you agree (or can find more).

Say it with me now…chromatic aberration and low contrast
The text in the story is rife with term-related hyperlinks. Nice of Space.com to define unfamiliar words, yes. But, the link color is blue and the background is (presumably a Mars-like) brick red. It’s nearly impossible to read the text links because there’s not enough foreground-background contrast.

Plus, the juxtaposition of blue and red causes your eye to attempt to simultaneously focus on short wavelengths (whose focus point falls short of your retina) and long wavelengths (which are most in focus at a point beyond your retina). This fatigues your eye because it’s trying to simultaneously accommodate to two disparate signals. As a result, the blue text appears jumpy or shimmery. Look at those links for a few minutes if you want to give yourself a headache.

Tiny aperture for reading the text
Why oh why did the designer choose to put the text of the story in a (yes I measured it) 440-by-100 pixel scrolling box? Well, I can guess; they were probably slavishly adhering the now-mostly-discredited “below the fold” decree. I wish they hadn’t done this. It’s like trying to read by looking through a keyhole.

Designers, I’m talking to you: it’s MUCH better to give the text room to breathe instead of stuffing it inside a tiny little box. If the content is interesting, people WILL scroll below the fold. Really, they will.

Small pix
This issue is not just about *strict* usability, it’s about enjoyability: the pictures accompanying this story are just too damn small! If we’re being asked to read a story about exciting findings from the Mars Rover missions, a key part of the story is showing us the wonderful pictures snapped by those intrepid little anthropomorphized vehicles. But the pictures are dinky little 240-by-170 thumbnails. Yes, I tried to click on them. It’s a no-op.

Sorry, Space.com, but poor design has put a big hurt on the user experience of this story. But please publish more articles…I just love ‘em.

Mars Rovers’ Top 10 Most Amazing Discoveries

Blogged with Flock

A friend pointed me to a whiny screed from one of the normally smart-and-perceptive folks at Adaptive Path.

In “Why Usability Is A Path To Failure“, one Todd Wilkens makes some interesting claims. One suspects he had a bad client day, and just couldn’t take one more client asking whether their design was going to be usable. Here’s what he said:

So, why oh why do people in this day age still hold up “usability” as something laudable in product and service design? Praising usability is like giving me a gold star for remembering that I have to put each leg in a *different* place in my pants to put them on.

It touched off a poopstorm of comments (which I suspect is one of the other reasons he wrote such an inflammatory post), the best of which comes from Jared Spool:

Todd, I think you have a very narrow notion of what “usability” is…Usability, like all design when done well, becomes invisible. People don’t talk about the positive case. (Well, except for designers who constantly need to bring attention to their work.)

…

Usability is foundational, such as having good content and providing reliable uptime. It’s only *not* a differentiator when everyone has equal amounts of it. If yours is better than everyone else’s, it become a differentiator.

Usability can be measured on a scale of extremely frustrating to extremely delightful. Since different designs competing for the same audience can occupy different locations on the scale, you can differentiate one design from another using it. That’s the broader definition of usability that most of us tend to use.

Props to Jared who very articulately explained why the writer was wrong. Still worth a read to gawk at the mile-long trail of comments.

http://www.adaptivepath.com/blog/2007/07/17/why-usability-is-a-path-to-failure

Someday I’ll tell y’all about my feelings toward the Yahoo! Messenger install, which is sneaky AND ugly.

Make sure to follow the link to Flickr so you can see screens 2 and 3.

A Little Expectations Mismatch Between Amazon and I

Amazon barfed on my search string, and offered up some product in lieu of results. Course it didn’t help that I misspelled “solar system”. (It’s my fancy new wireless keyboard’s fault…really….)

It took me a minute to realize that they must have been keying on my previous purchases, not on matches to substrings of my search strings, like “space solar system” or “space picture children”.

I definitely did a double-take when this screen showed. I mean, zombies? And project management? How are they similar to my search string?

Oh duh, they’re not. It’s just that I recently purchased “How To Survive A Robot Uprising” and some project management book, is all.

Body Text, Body Text, Body Text, Char

My apologies to MSFT if this has been fixed in Word 2007. But I just could not resist showing off this classic of poor usability.

Here’s a quiz for my half-dozen readers: how many usability issues can you find in this screen grab?

Winner gets two crisp United States dollar bills, mailed to them in a No. 5 security envelope with an Elvis stamp affixed to it. (Fat Elvis only, sorry.)

The nice folks at UXmatters offered me the opportunity to write a column, and I said yes. My first article just got posted. Follow this link to see it, or just look on the front page. It should be there for the next few days.

In a post somewhat related to my “the desktop metaphor is dead” diatribes, my favorite open-source pinko commie has written about how and why the desktop OS is inching its way to irrelevance.

I think I agree. Google and a few other web-based productivity tool vendor are either furiously working on or already releasing beta versions of their software that allow the user to work in offline mode.

The day is coming when you will start your computer thusly:

• You turn on your machine.
• A very lightweight OS is loaded; it could be GNU/Linux, Open BSD, whatevah. It doesn’t even necessarily have to have a significant amount of GUI itself; it only needs to be able to display a browser via a GUI.
• The OS loads a TCP/IP communications stack, device drivers, and searches for a (wired or wireless) connection, authenticating itself as appropriate.
• An (open-source of course) browser opens, and presents some or all of the projects, documents, spreadsheets, etc. the user is working with.
• The user works. Through the magick of AJAX all the user’s content is implicitly saved.
• If for some reason the user’s PC goes offline, the applications automatically go into offline mode, saving up the changes the user has made, and adding them into the document when a connection is reestablished.

I truly believe it’s that simple. Of course this is basically the idea behind the network appliance that was touted by many a guru at the turn of the century. It didn’t pan out then for now-obvious reasons: the online productivity apps weren’t mature enough. Well, now they are.

CNET’s What’s Hot Grid

I honestly don’t know, and I’d like your opinions. (All 30 of you - I checked my Google Analytics yesterday…that’s how many visitors I’m averaging over the past week…)

Is this useful? If yes, is it usable?

Here’s a little more about this tool, quoting CNET:

What’s Hot gives a visual snapshot of which stories are most important on CNET News.com right now. What’s Hot is updated every time a story is published, or at least once an hour…

The bigger the block, the hotter the story. The brighter the block, the newer the story. Bright yellow means the story was just published.

I definitely appreciate their attempt to innovate in this space. And I’m not trying to damn it with faint praise. I really do think it’s kinda neat. But I’m wondering about a few things as I look at it…

• Scan: From the gestalt p.o.v., is the image as a whole conducive to quick scanning and accurate parsing?
• Use of font, position on grid, and color for encoding importance: I’m all about multi-encoding to impart information, but are these encoders working together, or interfering with one another? Maybe they’re not doing either. There’s just something that’s not hanging together for me, and I can’t put my finger on it.
• Color: Warning, snarky tone approaching…this thing’s color scheme is what my wife always accuses me of doing when I dress myself: thinking that putting on nearly-identical colors is a good thing. When I go to work with a medium-blue shirt and jeans, she tells me I look like a plumber. CNET’s What’s Hot looks like, well, a Burger King employee. Plus, the palette as a whole is way too saturated.

There’s a lot more I could say about this, but I encourage you to check it out and provide your feedback. It has a couple of other neat features that you may want to play with.

You can check it out in context by following this link. Look on the right side, about halfway down the page.

Readers of UsabilityBlog have probably gotten the impression that I’m a whiny b*tch. I do tend to slag on designs that aren’t immediately learnable.

OK, I’ll own that. I am a bit of a whiner. But it really does cheese me off when products make implicit claims of learnability and usability, but in fact possess neither attribute.

So it’s with all this in mind that I’d like to talk about the incredibly high usability and utility of the GUI’s ancestor, the command line interface (CLI).

CLI: Not “Walk-Up-And-Use”
Let’s be clear about one thing: in most circumstances, a CLI is NOT a “walk up to and use” interface like the touch-screen kiosks at the airport check-in counter. Using a CLI requires that the user possess *some* understanding of both the syntax and command set, AND the general concept of interacting with a computer via a command line interpreter or shell.

But once a person takes the time to learn a particular CLI, they possess the ability to perform tasks and accomplish their goals in an incredibly efficient manner. It’s the old tradeoff, learnability vs. efficiency. It’s not exactly a zero-sum game, but these two attributes are often in opposition.

Let me give you a real-world, personal example of how learning just a little bit about a command line interface provided me with an incredibly powerful, comprehensive, customized, and trustworthy method of regularly backing up my and my wife’s data.

The CLI and I
First, a little bit about my situation and goals: ever since grad school I have been obsessive about backing up my data. I make (somewhat) up-to-date redundant backups of my and Susan’s data files to two large external drives. And yes, I even maintain an offsite backup, although the drudge of carrying that drive from work to home and back again means that the offsite backup is hardly ever as up-to-date as the onsite backups.

Lately, with the pace of work picking up for both Susan and I, I’ve been feeling the need to keep the backup stores as up-to-date as possible. And I had grown tired of running the backups manually.

Finally, since Susan and I have both become avid podcast consumers, I have noticed that the backup drives are filling up with unwanted podcasts. So my goals are:

• Back up my and Susan’s critical data safely and redundantly.
• Automate the execution of backups.
• Conserve space on the backup drives by deleting files that we don’t need anymore (i.e., old podcasts).

Now I’m sure that I could buy a software product that would make periodic, maybe even continuous incremental backups. And I bet that a premium product might even let me specify which data can be discarded. In fact, many external drive manufacturers provide “lite” or even full versions of backup software with their drives. But I build my own external drives from empty enclosures and drives I purchase from eBay or Newegg. So that’s not an option for me.

I first started using computers back in the dark days of DOS 6x, so I know a little bit about Microsoft’s CLIs. Not much, mind you, but just enough to accomplish some rudimentary tasks.

So about four years ago, I started opening up a command line window in Windows 2000 (and later, XP) and entering DOS commands to copy all the data in the directories holding my data (as well as all subdirectories underneath) to another directory. (I always split my laptops’ drives into an OS partition and a data partition, so in essence my D: drive is the first line of defense. It keeps a backup of the contents of my user folder.)

The command I used was xcopy.

Using various options provided by xcopy, I could specify that I only wanted to copy files that had changed, and suppress confirmation prompts (”Are you sure you want to overwrite foo.bar”) as well. Pretty powerful.

I soon grew tired of entering the backup commands manually (yes, I kept the syntax on a post-it on my monitor…), so I put the xcopy commands into a batch file, and then executed the batch file whenever I remembered.

Obviously, I’m much less reliable than a computer, so about two years ago I decided to schedule the execution of the batch file using the scheduler feature of Windows XP. If you want to find it, go to Start / All Programs / Accessories / System Tools / Scheduled Tasks.

So about two years ago, my batch file looked like this:

Filename: Backup.bat

REM Copies Susan’s Favorites to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Favorites\*.* D:\Susan\My_Docs\Favorites /s /d /e /i /r /y

REM Copies Susan’s desktop files to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Desktop\*.* D:\Susan\Desktop /s /d /e /i /r /y

REM Copies Susan’s My Documents, Outlook data file, and desktop files from the D/: drive to the USB drive backup folder.
xcopy D:\Susan\Desktop\*.* U:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* U:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* U:\Susan\Outlook /s /d /e /i /r /y

You probably noticed that I used the 8.3 name for the “Documents and Settings” folder. A bit of trial and error taught me that xcopy will indeed preserve long folder and file names at the destination, but doesn’t always recognize long names in the xcopy command itself. So I used the 8.3 name for “Documents and Settings,” which is (usually) “DOCUME~1″.

Podcasts Improve - And Complicate - Our Lives
This little batch file served me well until last summer, when we both started downloading podcasts. This lifestyle change was definitely for the better; as we no longer had to listen to any of the incredibly annoying local radio stations. But it had one unintended effect: every time the backup batch script ran, it would back up all the podcast files that happened to be sitting in “My_Docs\My Music\iTunes\iTunes Music\Podcasts.”

Even though Susan and I erase listened-to podcasts on the source drive, they started piling up on the backup drives. I needed a way to regularly clear out the contents of the podcast folder on the backup drives so the backup devices didn’t become overrun with stale copies of “This American Life” and the Battlestar Galactica podcasts.

So I went prospecting in the Microsoft KB, and found that the RMDIR (”remove directory” or RD) command has some very useful options. For example, “RD D:\Foo\Bar /q /” will delete the folder “Bar” and all its contents, without asking me for confirmation.

I added some RD goodness to my batch file, and this is what I ended up with:

Filename: Backup.bat

REM Copies Susan’s Favorites to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Favorites\*.* D:\Susan\My_Docs\Favorites /s /d /e /i /r /y

REM Copies Susan’s desktop files to the D:\ drive.
xcopy C:\DOCUME~1\Susan\Desktop\*.* D:\Susan\Desktop /s /d /e /i /r /y

REM Deletes the old podcasts from the backup drives before kicking off the current backup.
RD U:\Susan\My_Docs\MYMUSI~1\iTunes\ITUNES~1\Podcasts /q /s
RD S:\Susan\My_Docs\MYMUSI~1\iTunes\ITUNES~1\Podcasts /q /s
RD O:\Susan\My_Docs\MYMUSI~1\iTunes\ITUNES~1\Podcasts /q /s

REM Copies Susan’s My Documents, Outlook data file, and desktop files from the D/: drive to the USB backup drive.
xcopy D:\Susan\Desktop\*.* U:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* U:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* U:\Susan\Outlook /s /d /e /i /r /y

REM Copies the same data as above to the secondary backup drive.
xcopy D:\Desktop\*.* S:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* S:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* S:\Susan\Outlook /s /d /e /i /r /y

REM Copies the same data as above to the offsite backup drive (when I remember to bring it home that is).
xcopy D:\Desktop\*.* O:\Susan\Desktop /s /d /e /i /r /y
xcopy D:\Susan\My_Docs\*.* O:\Susan\My_Docs /s /d /e /i /r /y
xcopy D:\Outlook\*.* O:\Susan\Outlook /s /d /e /i /r /y

So there you have it. It’s not rocket science, but it works pretty well for me. It’s usable - provided you have some working knowledge of CLI’s. And I didn’t have to buy a separate application.

What did we learn today kids? First, the command line is your friend. Second, it can save you money.

Slagging on software EULA’s (”end user license agreements”) goes in and out of fashion. Since I’m perpetually the third-to-last guy to hop on a bandwagon, I figured I’d at least be consistent and join this party late as well.

So let’s get right to it: software EULA’s are broken. They’re unusable. And not just for the reasons you might think. Pretty much everything about the EULA experience is horribly, horribly wrong.

Let’s start with the legalese. I’m aware of how and why legal writing has become so impenetrable and difficult to parse. (For more on this, check out this Wikipedia article.) Defenders of the language and style of legal writing point to the need to disambiguate as much as possible and cover all potential contingencies when writing law or a contract. But that argument is specious. Bloated, meandering legalese is created by lazy people who can’t be bothered to express their thoughts and intent clearly and succinctly.

Here’s an example of laziness in action (now *that’s* a contradiction in terms…) that I just encountered while attempting to install a software application I was interested in evaluating. For the curious, I was installing the open source version of SugarCRM, an application for managing customer and sales information. Let me be clear about one thing: I am NOT singling out SugarCRM for extra-special vituperation. They’re just doing what everyone else does. Their EULA experience is really no better or worse than any other vendor’s.

I started the SugarCRM install, and in one or two clicks was presented with this screen:

I don’t typically give the EULA screen more than a nanosecond of thought, but something spurred me to actually check out the license agreement. I started scrolling the text box, but quickly grew frustrated. So I put my pointer in the text box and pressed CTRL+A (”select all”) to highlight the EULA text. I planned to copy it and then drop it into a Word doc.

Surprise… the text didn’t highlight.

Now I know a usability issue when I see it. My curiosity was piqued: just how bad *was* this user experience? So I manually highlighted the EULA text on the first line, and then dragged my pointer downward. Sure enough, the text started highlighting. I figured I’d just keep my index finger down for however long it took to highlight the entire text, then try CTRL+C (”copy”).

The scrollbar indicator was taking an awfully long time to move downward. Then I noticed just how small the scrollbar indicator rectangle was… and I knew this might take a while.

After a solid 2 minutes, I had finally selected the entire block of text in SugarCRM’s EULA screen. Of course, upon pressing CTRL+C I received no indication that the text block had actually copied to the clipboard. But I took the chance, opened up Word, and pressed CTRL+V (”paste”).

When Word stopped grinding, the first thing I did was look at the page count at the bottom left of the status bar.

It said the document was SIXTY PAGES LONG.

Back in the day, I had occasionally seen Word spaz out on a page count; so I hopped to the end of the document then back to the beginning, thinking that the page count would settle down to a reasonable number.

It stayed at sixty pages.

Sixty single-spaced, twelve-point, Times New Roman, one-inch vertical by one-and-a-quarter-inch horizontal margined pages.

Guess how many words?

It has 18,284 of ‘em.

I’ve posted the EULA here so you can revel in its repulsiveness.

So let’s review: the application’s EULA is sixty pages long in Word. The text box on the EULA screen is 470 pixels wide by 135 tall (less if you subtract the gutters). And you can’t easily copy/paste the EULA into an easier-to-read format; you’re expected to read it in this tiny 470-by-135 aperture. Here’s the kicker: it’s written in dense legalese, with seemingly random switches between sentence case and upper case.

Sucks, doesn’t it?

It’s almost like they DON’T WANT you to read it. Typically, the only people who want you to agree to a legal contract without fully understanding it are slimy car salespeople and dishonest mortgage loan officers. Now I doubt that anyone at Sugar actually thinks like that; a quick perusal of their site shows that they’re committed open-sourcers who do much for the development community. In short, they seem like good people.

So why the unusable EULA? Probably the typical reasons: the developer who coded the installer forgot to enable right-click select/copy/paste in the EULA text box. And the Sugar legal team undoubtedly just concatenated the separate boilerplate licenses for the open-source components installed with SugarCRM, then added in a bit of their own liability-proofing text for good measure. In other words, they were lazy. What resulted is an unfriendly, unusable mess.

Now I was even more curious, and I wanted to do some comparative EULA-gawking. So I played around with the next two apps I had occasion to install: Windows Live Messenger and the iTunes 7.1 update.

Windows Live Messenger

Microsoft’s instant messenger app had a surprisingly readable EULA, but was a snooze-inducing 12 pages and 6,343 words long. The EULA text box was super tiny at 415 by 100 px, but it did permit both keyboard and right-click select/copy/paste.

I’ve posted the EULA here for your edification and enjoyment.

iTunes

Apple’s iTunes EULA experience was not considerably better or worse than the other two. While (relatively) brief at five pages/2,091 words, it yelled at me (i.e., was in all caps) at random times. Guess that famed Apple user experience doesn’t extend to the EULA. Here’s a screenshot showing the generous-for-this-crowd text box aperture:

The EULA itself can be found here. It too suffers from a bad case of boilerplate-itis.

Usable EULAs

This is the part of the rant where I should tell everyone how to create a better EULA experience. So without further ado…here are my recommendations for more usable EULAs:

• Content: Lose the legalese. Lawyers, say no to boilerplate. Say yes to plain language. And try your best to keep it brief. Not only will you communicate more effectively, the lay community might hate you less.
• Readability and flexibility: Display a bigger text box, provide easier ways to select/copy/paste, provide a print button, or (preferably) do all three.

And while we’re on the subject of readability… I also recommend NOT SHOUTING AT YOUR READER. PEOPLE REALLY DON’T LIKE READING IN ALL CAPS. Sentence case is much more civil, don’t you agree?

So that’s all I have today about the EULA experience. I know several other people have written about the sorry state of software EULA’s, so here’s a few links for you. And thanks for listening to my EULA kvetch.

More about EULAs at:

Boing Boing: ReasonableAgreement.org - the anti-EULA
Ben Edelman: EULAs Gone Bad
EFF: Now the Legalese Rootkit: Sony-BMG’s EULA

No, it *wants* my attention. There’s a difference.

Adobe, you’ve been annoying me and interrupting my train of thought for 9 days now. Enough already.

And the worst part is your demanding tone. Language does matter!

I’m not the only one who thinks so:

This guy agrees.
So does this guy.
And this guy.
And this guy too.

My favorite take on this is the commenter to that last blog who referred to the update manager as an “attention whore.”

Oh. My. God. Amazon.com actually updated the price of “Usability Success Stories“.

Maybe some peeps will buy it now…

I just noticed that the article I wrote for UXMatters.com was published yesterday. The title of the article is “Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent.” Quoting myself:

As UX professionals, we have many tools and techniques available to us, and we contribute to our product teams in many ways. However, while having good UX skills is necessary, it is not alone sufficient. No matter the size of our organizations or the domains we work within, our most valuable contributions are not our design or user research efforts. Rather, our most valuable contributions occur when we function as change agents.

I had fun writing. I hope you have fun reading it. The full article can be found here.

Friendly Error Message From Overstock.com

Say what you want about the paranoid CEO of Overstock.com. He’s evidently built a culture that encourages communicating with customers in an amusing and entertaining way.

I liked seeing this message when I received it (while trying to buy yet another tech toy). It made me feel actively good toward Overstock.

Some people may see this and feel that it’s too flippant. But those people need to loosen up a smidge.

Wait a sec… oops, I meant to say that “Usability Success Stories” is ranked #1,272,131 on Amazon.

And don’t ask me why it’s still $115 at Amazon…sigh…(pounds head against wall).

(If you want to see the Amazon rank - and the insanely high price - for yourself, follow this link.)

I just read Jakob Nielsen’s Alertbox column from December 18th (”Usability in the Movies — Top 10 Bloopers”).

His main point:

User interfaces in film are more exciting than they are realistic, and heroes have far too easy a time using foreign systems.

I agree with this assertion. I also like his descriptions of the typical problems with cinematic depictions of user interfaces. (He refers to them as bloopers; god am I sooo tired of that word…)

But he’s way off base in his conclusions. At the end of the piece he says the following:

In the film context, unrealistic usability is only to be expected. Still, I see two real problems with it:

Research funding and management expectations are subtly biased by the incessant emphasis on unrealistic UI design such as voice, 3D, avatars, and AI. When you see something work as part of a coherent and exciting story, you start wanting it. You even start believing in it. After all, we’ve seen 3D and voice so often that we’ve developed an implicit belief in their usefulness.

Users blame themselves when they can’t use technology. This phenomenon is bad enough already; it’s made worse by the prevalence of scenes in which people walk up to random computers and start using them immediately. We need people to start demanding easier design and blaming the technology when it’s too hard to use. Movies make this change in attitudes more difficult.

I actually don’t disagree with his claim that fictional depictions of user interfaces bias funding and management expectations. But I disagree with his implicit assertion that this is bad. Technological progress is intimately entwined with depictions of future technologies in books, magazines, movies, and other media. Many of the technologies we are familiar with today were first conceived by an imaginative science fiction writer.

To say that depictions of not-yet-existing user interfaces to technology leads to unreasonable (or useless, as Nielsen would have it) desires ignores the positive relationship between today’s fiction and tomorrow’s reality. It also short shrifts the idea that innovation happens in fits and starts, often with many blind alleys and unfruitful developments.

Do we really want to live in Nielsen’s utilitarian utopia where no UI is created without strict adherence to today’s principles of usability? I understand the design world’s issues with Nielsen when I read pieces like this.

Regarding the second conclusion (”Users blame themselves when they can’t use technology”): does he *really* think that unrealistic depictions of usage has any real effect on peoples’ strong tendency to blame themselves for poorly designed UI’s? I highly doubt that cinematic depictions “make it worse.” That’s just a red herring. When it comes to using technology, every practitioner knows that people come to the interaction with a strong predisposition to attribute their own performance to internal factors. Do movies somehow make this bias toward self-attribution any stron