Learning from "bad" UI (37signals on TripLog) | Hacker News Reader

Learning from "bad" UI (37signals on TripLog)

37signals.com

84 pointsbdotdub34 comments

Very nice article. I'm in agreement with the sentiments of TripLog's author; the #1 impediment to this kind of data entry is convenience. The goal here is to have users spend as little time as possible using the application.

It could definitely use some improvements visually... but for that application, function should trump form if the two conflict.

True, but I feel there are better approached to include both.

Does anyone who has knowledge of the iPhone SDK know if you can make a regular window scroll?

That would allow the "Latest Trips" to be slightly below everything, so its a quick swipe to check.

Not with a normal window, you can only modify the views inside the window but I guess you could create a new class but it's an overkill.

Yes, you can have views that scroll inside a window. It makes perfect sense for long list of repetitive items (such as the list of videos in the youtube app). It would be counterintuitive to have controls that are hidden, and you have to scroll down to see them. Many users might not notice them.

BUT, I still think that ui is poorly designed. The iPhone SDK, has a plethora of ready views and controls, or you can even make your own customized view, if you think what the iPhone SDK is providing is not good enough.

So, I think the author of the app didn't want to go the extra mile, to create something that is both useful and appealing.

And how does the gigantic spinning odometer thing improve function, exactly? Besides wasting space and leaving the rest of the interface horribly cluttered?

Because it means you don't have to bring up a key pad to enter numbers?

Honestly, I think if the colors were just better picked it wouldn't look so awful at first glance. It's designed for speed, but that doesn't mean you have to make it bright and oddly colored.

One of the things I learned while playing Warcraft was the importance of scalable interfaces.

When I first started, I was lucky to get my character to move across the screen in a straight line. I didn't know what a mod was, I just wanted to kill squirrels.

By the time I joined a guild and we were raiding high-level instances, I had to have a screen full of mods that tracked every nuance of my characters (and raids) performance. Without them, I would have felt naked and nearly unable to play.

As developers, I think we often forget that folks go through a very rough period of learning how to use an app to being able to quickly navigate it. Once they hit the latter period, there would be no harm in offering them additional power.

Blizzard does not offer additional power, it's only through the use of third-party add-ons that you have it.

Blizzard offers the Lua scripting interface which facilitates the add-ons. It seems to have been a successful strategy.

I'm going to repost here what I did there, so sorry to anyone who reads both:

I’m sorry, but I’ve read his defense – and this analysis – and I still say FAIL . If speed’s the primary concern, why would you use the scrolling widget to enter the mileage? That’s going to be measurably slower and less accurate than a simple text field that pulls in the dialing/numeric keyboard.

My impression is that they’re operating entirely without user testing – their intentions are correct (make if fast, etc.), but they’re unwilling, unable, or too rushed to verify their decisions by watching people use various alternatives.

I agree with the criticism of the scrolling odometer widget; that part sounds like it would be better handled with the keyboard.

I'm willing to cut them a little slack on the "lack of user testing" angle; it's not like there are many App Store enabled iPhones available for real-world usability testing. That will limit a potential test pool to people the developer knows well... because I doubt he'd be comfortable handing his iPhone to someone less than a trusted friend to provide feedback.

Well, that's true. In this case, however, testing with novice users isn't exactly critical. The target audience here are repeat users, after all, so learnability is probably a lower priority than raw performance for a regular user. That means that the devs themselves could have tested, and I sincerely doubt that they would find the scrolling odometer faster OR more accurate than keyboard entry.

My impression is that they’re operating entirely without user testing...

So are lots of developers, I assume. At this point only certain selected individuals are allowed to transfer their iPhone app to an actual phone, right?

(Unless they're using unlocked phones and the open development kits... which might have been a good idea. But let's assume they don't have the time or inclination to build an entirely separate app with a separate toolchain just to get an early start on user testing.)

So for all I know that wacky scrolling widget will be quite usable. We should strive to suspend judgement.

It was bound to invite ridicule, though, when viewed in a mockup. The odometer widget is such an obvious "duck" (to borrow a Tufte term [1]) that it's hard to avoid the suspicion that it was designed primarily for its looks, with usability as a distant second.

It's also huge. It's hard to believe that's an efficient use of screen space.

[1] "duck": a huge piece of distracting, nonfunctional decoration that's been applied to your graphics, generally for crass marketing purposes. Named in honor of a photo in Tufte's book depicting a roadside stand in the shape of an enormous bird.

The odometer widget combines an entry mechanism with a display mechanism. That saves space. If it responds well enough to touch it might be nice to use.

Maybe. The scrolling widget has some advantages over a keypad. It has strong association with the physical odometer in the car (not all cars have odometers like this, mine does not, but it is a very strong association). The user doesn't have to find the label 'enter mileage here' -- it's obvious how to enter mileage, and if it spins (I don't know, but I hope so) it would be intuitive. The user doesn't go through a context switch away from the main screen to use a number pad.

On the other hand, a power user is going to eventually associate screen locations with actions and never read the labels again. That form of association may be the reason for the brightly-colored buttons.

Hrm-- it'd be interesting to time the two options.

With a text field you have a tap to edit, a tap to switch to the numerical keyboard (unless you can start there with the SDK), a tap for each # (say 3 on average), and a tap to save the record and send the keyboard away. That's 5-6 taps with a fair bit of distance between them on the screen, assuming that you don't have to drag the largely keyboard-obscured screen around to see other data ("I know I it's a few miles further than the post office... What did I enter in for that?").

OTOH, I just tried to simulate the odometer with the alarm clock setting controls on the iPhone (which is similar) and the flick-tap that it allows is pretty damn fast with zero major screen changes.

I find the iPhone keyboard to be a PITA and typos abound, even after practice. Editing a text fiend would bring up the keyboard, obscuring a LOT of info.

I'm not disagreeing, per se-- just saying that it's not so cut and dry that I wouldn't test the two side by side for speed/learning curve.

At least with iPhone web apps, you can bring up the numeric keyboard by default - and with two fingers, it's much faster and more accurate for entering digits than the scroller (I use alarm clock quite often, and can't stand it - overshooting numbers all the time, for instance).

You're correct that the keyboard would obscure the rest of the interface, but you shouldn't often need to see the rest of the screen when entering mileage. If it's a frequent trip, for instance, you'd just use the frequent trip shortcut.

The one thing that stands out for me is that TripLog has inadvertently generated a ton of publicity (and maybe a bunch of people willing to offer free help). The next version will have a professional UI and sell a gazillion copies.

I'm begging 37signals to take a crack at an improved interface. Sure TripLog will get even more free PR but I'm really curious to see how they can improve it.

Put your UI skills where your mouth is.

They did demonstrate their UI skills, by deconstructing the logic behind what the TripLog interface was trying to do and showing the logical groupings of related info. Translating that into visuals is simply the next step - scroll down to sanj's comment or go to daringfireball's followup post for links to visuals the 37s discussion sparked - and unfortunately, many people see it as the only step.

The one thing I noticed from the Flickr comments, 37signals comments, and the 2 threads here is that there's a lot of feedback from programmers to programmers.

Fine. Lots of good data. Maybe even some that will go into product improvement. It's a necessary but not sufficient step.

What we really need is feedback from paying customers, legitimate prospects, and monetizable eyeballs. We can critique each other's stuff all day long, but sooner or later, we need to get this in front of the users.

There's a pretty good tradition here at hn called, "What do you think of my app..." There's usually a lot of good feedback, but don't get fooled into thinking this is anything other than pre-alpha.

After reading all of this drama surrounding TripLog, now I'm curious what the real users think.

(My customers always have additional and sometimes very different feedback from "hackers". One of their biggest differences is regarding the mouse. Some of them never want to touch it during heavy data entry sessions. Talk about something drastically changing the UI...)

I thought hackers despise the mouse more than anyone else.

Right. But they think everyone else likes it.

I have a customer with 2 call centers, one on GUI and one on green screen. The green screen center consistently beats the the GUI center by 2 minutes per call every month. Drives him nuts. He can't move people from the green screen center to the GUI center or they quit in a week (too much clicking to get anything done). He asks me why it has to be that way. I say it doesn't, but whoever wrote it probably didn't know any better.

What's a green screen? You mean like a terminal with green characters?

Yup.

Just imagine this with 80 columns, 24 rows, a black background, a lime green foreground, and no mouse:

  |==========================================================|
  | 21:33             CALL CENTER SYSTEM            07/09/08 |
  |                                                          |
  | ENTRY TYPE: __                          OPERATOR ID: 127 |          
  |  CALL CODE: __                            SHIFT NBR: 2   |
  |   CUST NBR: ______  ____________________ AGENT MODE: 3   |
  |                     ____________________                 |
  |                     ____________________                 |
  |                     __________, __ _____                 |
  |                                                          |
  |   CHANGE CODE: __                                        |
  |     CALLER ID: ___/___-____                              |
  |  REQUEST TYPE: __ ______________                         |
  |       MONITOR: ___                                       |
  |                                                          |
  |  COMMAND: _____________________                          |
  |                                                          |
  |==========================================================|

"When we talk about “usable” or “intuitive” interfaces, Apple devotees and the web app crowd (myself included) tend to bias toward the first-time user."

The sort of thing that pains me, in so much as I will not always be a first-time user; my time as a first-timer is nothing compared to time being an experienced user.

I'd rather have to spend a bit of time getting going it if pays off in being able to do things fast and reliably down the line.

Ideally there should be ways to switch from the Newbie UI to the Old Hand UI, but most of what I see seems to forget that second part.

Well, all I can say is that I hope to release an app with this much free publicity one day. I'm sure it's going to help his bottom line.

I honestly believe a contextual UI for TripLog would be an order of magnitude easier to use.

Gmail makes GREAT use of contextual UI elements.

with all the furor, it seems like its only a matter of time until someone actually redoes this guy's interface for him.

Ah, you're giving people too much credit. Collective bitching is easy and fun, constructive work is hard.

Turns out he's not:

http://img65.imageshack.us/img65/6351/iphoneua8.jpg

http://img518.imageshack.us/img518/6964/triploggw5.png

http://ralovely.com/downloads/triplog1040.png

wonder how many copies have been sold so far

Reply on news.ycombinator.com