Topic Archive: User Interface Standards

A case study in Flash UI annoyances: style-card.com

Brian Dillard, Tuesday, May 20, 2008 @ 2:16 pm

Maybe I read too much Victorian literature, but I've always wanted a personal calling card. Recently, I decided to get one: a little something to help new acquaintances remember my phone number, email address and important URLs. Based on a recommendation from Time Out Chicago, I turned to Style Card, a slick consumer service that promises a less generic riff on the basic business card.

Here's how the company describes its product:

It's a social networking card created by you for the purpose of sharing your details and your style. Let people get to know the real you – or the not-so-real you.

Sure, I could have fired up an Adobe product, used a commercial printing service and gotten 1,000 copies of my own design for about $25. But owing to my lack of graphic design mojo, I decided to shell out $59 (plus shipping) for a mere 80 shiny, round-cornered Style Cards. The 3,000 percent markup is ridiculous, but I wanted to see whether I could benefit from the company's idiot-proof design interface. Besides, I figured I could get a blog post out of the experience. I wasn't wrong.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

37signals and the pain of the below-the-fold button

Brian Dillard, Wednesday, April 30, 2008 @ 3:03 pm

Google Notebook finally got a feature I've been asking for since the beginning: The ability to remember whether I want my notebooks sorted alphabetically or by date of last update. When the service launched, notebooks were always sorted by last update. When they finally added the option of alphabetical sorting, they left out the ability to make your choice sticky across sessions. This little wrinkle annoyed me almost as much as the Google Calendar search box's default action of searching public calendars rather than my own. I can't believe what a difference it makes in your relationship with a webapp when you don't curse out loud every time you use it.

Many users have the tendency to get bent out of shape about deficiencies in a tiny, tertiary portions of an application - or, for that matter, an operating system. Mac users devote entire forums to complaining about changes to, or lack of changes to, the Dock. PC users are still cursing those stupid Windows XP "You have unused icons on your desktop" messages. When we spend increasingly endless stretches of our lives in front of a terminal, tiny annoyances add up.

I call this the Disproportionately Annoying Detail Syndrome, or DADS. It has a tendency to flare up worst when you're working late on a short deadline and your computing environment fails to read your mind.

A couple of years ago, when I first started abandoning desktop software for cloud computing, I gave Ta-Da List a shot. I couldn't get over the placement of the "Add another item" command. Instead of putting it at the top of the list, they stuck it at the bottom. Every time I wanted to add a task, I had to scroll down to the bottom of the page before I could start typing. I worked with this system for about a week before jumping ship to Remember the Milk, where I can hit the "t" key to add a task without ever picking up my mouse.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Delighting the user with the tiniest of details

Brian Dillard, Wednesday, March 26, 2008 @ 12:50 pm

Building software people love involves learning to read minds - or at least learning to think like your users. In the world of free, web-based software, there will always be 10 versions of every application: 10 different to-do lists, 10 different dictionaries, 10 different bookmark organizers. It's not enough to meet users' expectations about features; you've also got to delight them if you want to win market share. If you don't think through every interaction and use case, you're probably annoying the hell out of people without even knowing it.

That's why it's important to actually watch users in action with your application. It's a maxim in user experience design circles that you, the programmer, are not the user. Sure, you should eat your own dog food, but remember that the experience of using software that you wrote - and whose every shortcoming and compromise you understand from the inside - isn't the same as chancing upon that software in the wild and giving it a shot. Look at your software through the fresh eyes of users who didn't write a single line of the code. That's when you'll actually learn what you've created and how to improve it.

... all of which proselytizing serves only to introduce one rant and one rave about free software I use every day. Neither of these are web applications, but both of them are tied directly to the 'net.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Agile User Experience: If you don’t have a user, invent one of those too…

Noel Rappin, Thursday, January 24, 2008 @ 2:35 pm

Following up on Brian's point...

A customer proxy of one kind or another is also important in integrating Agile practices with User Eexperience Design.

One of the long standing issues in combine Agile development with User Experience Design is just the differing time cycles between Agile developers, who are running on a test, develop, refactor cycle that could be mere minutes long, and the UXD designer, who is working on a longer, perhaps more traditional, cycle.

The problem comes in when the developers start making coding decisions for the interface. Without immediate feedback from the UXD designers, the developers are often left to their own devices for the initial versions, with revised designs coming weeks or months later.

Our goal is to keep the development team moving forward with current feedback from the design team. For exactly this reason, the original XP book listed Onsite Customer as a core XP practice. However, that's not always feasible, and in any case for User design you want the user's feedback, which may not be the same as the customer's.

What we try to do is use the idea of a customer or user proxy to allow us to have incremental refinement of design, and allow the development team to get quick feedback and continue with the next fine-grained task.

When a developer has a usability question, the developer asks a team member acting as a user proxy. This is either an analyst on the project or one of the designers. The user proxy makes a decision on the question -- if not a final decision on all details of the problem, at the very least a consensus on some aspect of the problem that the developer can do next. While the developer does that task, the user proxy goes off and consults with the design team and the customer.

Ideally, by the time the developer is ready for the rest of the task, the user proxy has more detailed requirements and design for the developer. The key is making sure the developer's next step is always covered.

This does require some effort from your team -- the developers have have awareness of usability issues and concerns and the design team has to have the ability to respond to developer concerns quickly. Again, though, the design team doesn't need to have all the answers at once, they just need to be able to give incremental details to the developer.

(The image of the floor appearing directly underfoot is from the ad campaign for Gatorade G2)

Have I mentioned my upcoming book Professional Ruby on Rails, yet? Available mid-February wherever fine computing books are sold.

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

A UXD Lesson from the Gas Station

Dietrich Kappe, Thursday, January 17, 2008 @ 5:38 am

This past weekend I was up on Howell Mountain in Napa, tasting the ultra tasty wines there and taking in the gorgeous views. On the way back to SF, we stopped at a Shell gas station. It took me a good 20 minutes to gas up. Why? Lousy user experience. Let me explain.

This was a new, fancy pump. It had a TV up top, a 4"x6" LCD screen just below crotch level (I'm 6'4"), a numeric keypad with a credit card reader about a foot to the right, and three fuel selectors another foot above. It was about 11:30, and the sun was shining right at the LCD screen. First I thought the TV was saying something relevant about my fueling my car. The Doppler effect of several other TV's saying the same thing at slight offsets around the gas station was also a little disconcerting. I finally figured out that the TV was just polishing the Shell brand and flogging sitcoms (aren't the writers on strike?).

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Lessons in usability from a trio of remote controls

Brian Dillard, Monday, January 14, 2008 @ 1:08 pm

I wasted eight hours trying to set up a high-end universal remote control last week. In the process, I was reminded that usability matters as much in the world of physical gadgets and desktop software as it does in the web-browser ghetto.

My new Logitech Harmony 670 Universal Remote was supposed to replace the dusty old universal remote I've been using for the past eight years. The old remote - a Home Theater Master SL-8000 - was state-of-the-art for its time, but I could never get it to replicate the functionality of my Tivo Series 2 DVR remote, perhaps the most ergonomic and usable remote control ever designed. I was happy enough with my two-remote setup till I saw the Logitech, a programmable universal remote especially designed for the DVR aficionado. It was shaped like a Tivo remote, so I figured it would combine the simplicity and elegance of my Tivo remote with the universality of my Home Theater Master.

Fat chance. Thanks to terrible software and abysmal hardware design, the Logitech sent me scurrying back to the comfort of my two existing remotes. Here are the five reasons why:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Usability review: Amtrak.com checkout process

Brian Dillard, Wednesday, January 9, 2008 @ 2:20 pm

Many large ecommerce sites work beautifully as long as users do what they're supposed to. The minute users make mistakes, however, the UxD falls apart completely. Case in point: Amtrak's online checkout process, in which poor choices about error handling can make it a real hassle to check out successfully.

Amtrak's first mistake was to create an email address verification field. Plenty of usability experts have decried this silly device for encouraging error-free user input. The annoyance would be minor, however, if Amtrak at least autofilled the email verification field for returning visitors. It doesn't. When you log into an existing Amtrak account and try to purchase, your address is autofilled in the main email field, but it's not autofilled in the verification field. Because there's only one field in the entire "Contact Information" section of the page that doesn't get autofilled, it's easy to breeze past and not realize that input is required. You go on to enter your credit card information and click "purchase," only to end up with an error. Until recently, that error wasn't caught by any client-side validation, so you had to wait for a round trip to the server before being notified. Recently, though, the interface has been updated so that you get a 1999-era JavaScript popup telling you to fill in all required fields. It's nice that Amtrak at least reduced the annoyance of this bug, but why not just fix the root problem by either getting rid of the email verification field altogether or autofilling it for returning customers?

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Plug: Designing Invisible Interfaces Webinar

Dietrich Kappe, Friday, November 30, 2007 @ 10:42 am

My colleagues Matt Nolker and Shalom Sandalow have put together a nice little webinar entitled "This Won’t Hurt a Bit": Designing the Invisible Interface.. For those of us writing Web 2.0 applications, there are some key insights here, such as: "interacting with the software is not the primary goal or responsibility of the user." So when you use those nifty Ajax widgets, think about whether you are placing a usability burden on the user or are using the power of Ajax to make the interface disappear.

Technorati Tags: uxd, webinar, invisible interfaces, usability

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

Luke W on Web Form Design Best Practices: no need to wait for the book

Brian Dillard, Wednesday, November 21, 2007 @ 11:50 am

In my coverage of An Event Apart Chicago 2007, I enthused about the work of Luke Wroblewski, whose presentation on web forms was one of the conference highlights. If you care about UxD and you're not keeping up with Functioning Form, his blog, you're missing out. His book Web Form Design Best Practices won't be out till next year, but Wroblewski regularly updates his blog with slideshows, conference notes, insightful thought posts and raw material for the upcoming book. If you're still slapping your web forms together without much thought, you should definitely check out the wealth of material he's released on the topic and keep tabs on the book's publication date. It's good stuff.

Technorati Tags

• web forms
• user experience design

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Ajax and UI Standards

Dietrich Kappe, Tuesday, August 15, 2006 @ 9:00 am

I think it was some time in the early 1990's that Apple released it's Human Interface Guidelines (HIG). What are HIG's? From the Wikipedia:

Human Interface Guidelines (HIG) are software development documents which offer application developers a set of recommendations. Their aim is to improve the experience for the users by making application interfaces more intuitive, learnable, and consistent. Most guides limit themselves to defining a common look and feel for applications in a particular desktop environment. The guides enumerate specific policies. Policies are sometimes based on studies of human-computer interaction (so called usability studies), but most are based on arbitrary conventions chosen by the platform developers.

Human User Interface guidelines will dictate a set of rules for general usability. They often describe the visual design rules, including icon and window design and style. Frequently they specify how user input and interaction mechanisms work. Some describe the language style.

A number of HIG's exist for a variety of platforms, including the GNOME Human Interface Guidelines, the KDE User Interface Guidelines, the Apple Human Interface Guidelines, the Microsoft Windows User Experience guidelines, and the Java Look and Feel Design Guidelines.

At the time, for a designer of Unix command line applications, these guidelines seemed interesting if incomprehensible. After all, command line interfaces were pretty limited and thus very familiar to our users. But as I began to develop GUI apps, these guidelines became an important touchstone, even when I moved beyond the world of the Apple desktop into Windows and X11. To many designers of web applications, these guidelines must also seem somewhat foreign. Until recently, the very limitations of the browser made the typical web forms interface familiar to our users. Now comes Ajax and with it a new love affair with the DHTML/Javascript widgets that were disdained not even two years ago. The web is moving from a primitive forms-based interface to a rich interface experience. Building frameworks and widgets and applications without any thought to some common experience is a common occurance.

I've been interviewing Ajax framework developers and asking them what the biggest problem is with Ajax. If I put the question to myself, I'd have to say that a lack of User Interface Guidelines is a burgeoning threat. If everyone has widgets that sort-of works like the corresponding desktop widget or, worse yet, doesn't work like them at all, users will rebel. That's just what happened in the early days of the Mac and Windows, when developers and software publishers just had to do their own thing. Very few of these mavericks remain.

So, who is thinking about HIG's for Ajax now? Not too many people, it seems. One person who has been wrestling with this questions is Luke Wroblewski (note: Luke has worked with my company in the past). His article on Ajax and Interface Design is well worth reading.

Technorati : ajax, human interface guidelines, usability, user experience

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax