Myles Braithwaite [beta]

Tags are metadata about a post. They’re added keywords or a way to add a little bit more description to a piece of content.
Categories, on the other hand, are more structural and usually used more for navigation. You put a piece of content into a category. You add a tag to a piece of content.

Well, I'm so glad everyone here is having such fun at our expense. Have a ball.

I don't know who everyone here is, whether you're developing for the iPhone, have ever developed for any handheld platform, or are just iPhone users (actually one of the comments elsewhere online was clearly made by someone who wasn't even that). I'll tell you who I am. I've been making a living as an independent software developer for 20 years, developing and selling software for Mac, DOS, Windows, Palm, and now iPhone. Our company's user database consists of more than 100,000 users.

I'm not saying this to brag, or to “pull rank” on anyone. I'm saying it to point out that maybe, just maybe, we know SOMEthing about software design and development after 20 years in the business, including 10 years of designing for a handheld platform.

I'm not going to respond to every specific complaint, I don't have the time or inclination. I'll also say that no one claims this is a perfect interface, or can't be improved, or won't be improved in future iterations. It does, however, have the advantage for iPhone owners that starting July 11, they'll be able to use it to record their deductible (or reimbursable) trip mileage. Is this the most elegant interface we've ever designed? Hardly. Is it more cluttered than we'd “like”? Certainly. But there are reasons for that, SOME of which I'll discuss below.

I would like to make a few general observations that maybe some of you haven't thought about:

1) An iPhone screen isn't bigger than a Palm screen. OK, that was deliberately false. For data DISPLAY applications, like photos, or maps, or such, the 460x320 screen (460, not 480, because except for games you're advised against hiding the status bar) is obviously bigger than Palm's 320x320 screen (actually again in that case, a bit less height because of the generally-used title bar), and the iPhone screen is physically bigger than many Palm screens as well (certainly the Treo or Centro). But Palm apps are designed for buttons and other UI elements to be tapped with a stylus, and iPhone by fingertip. On a Palm app, a “standard” button height is 26 pixels (actually 13, because Palm apps are typically programmed for the original 160x160 resolution, but let's call it 26). In 300 vertical pixels, that would be 12 buttons one above another. Apple recommends that buttons and similar features be 44 pixels high, resulting in a “10 1/2 button high” screen. Of course, you CAN make things smaller, and if you use Safari on the iPhone, you know that MUCH smaller features can be tapped successfully, but in general, larger features are required. This means that for a data ENTRY application, as opposed to a mere data DISPLAY application like Photos or Weather or the like, the iPhone has just about the same constraints as a Palm.

2) An iPhone is not a desktop Mac, or even a Palm. It doesn't have menus, or drop-down menus (or lots of other things, like copy, cut, and paste, either). This is rather significant. If I were designing this app for a desktop, or even a Palm, those two gray “+” and “Edit” buttons wouldn't be there cluttering up the interface at all; they'd be menu items reading “Add Frequent Trip” and “Edit Frequent Trips” respectively. But there are no menus on iPhone. One COULD actually simultate them, but that would be at the expense of having a very non-standard interface using “non-Apple” elements, something which IN GENERAL (certainly not always) is to be avoided. Likewise the entire “frequent trips” section and its scrolling list of frequent trips. That COULD be, as it is in our Athlete's Diary application, a simple drop-down from the word Destination, where a user would tap on a downwards arrow to the right of “Destination” and that list would appear and let the user choose from the available choices. Again, something that COULD be simulated, but that isn't a standard iPhone UI element. And, as I'll discuss in a minute, maybe not the best choice in any case.

3) This is the most important point: THE FIRST AND MOST IMPORTANT WORD IN “USER INTERFACE” IS NOT “INTERFACE.” IT'S “USER.” An application should not be designed to please “UI experts,” or reviewers, or Apple snobs. It should be designed to please its USERS, and, in the case of a productivity application, be designed to make them maximally efficient at accomplishing the task at hand. An interface can not be judged indendently. It can only be judged IN CONNECTION WITH the task that it is intended to accomplish.

What is this program trying to accomplish? It is trying to make user of the fact that a person will always have their iPhone with them, and it wants to not only allow but, as much as possible, facilitate their recording of every deductible or reimbursable trip. That's why we never wrote a desktop application to do this, or even a Palm application. But with an iPhone, you're almost guaranteed to have it with you, so the goal of this application is to have someone record their trip BEFORE THEY EVEN GET OUT OF THEIR CAR. Now to do that, there is really only one criterion - speed. The quicker they can pull out their iPhone, look at their car odometer and transfer the information into TripLog, the better. If that time becomes too long, the application becomes useless.

Now let's look at this interface a bit. The “frequent trips” section takes up quite a bit of room. Why? Because we judge that most users will be of the type who take certain trips with regularity, be it a visit to the post office to pick up the company mail, a visit to their branch office, etc. Even if the destination varies, for example in the case of a travelling salesperson, the “purpose” might always be “Calling on customer.” So making sure the user never has to enter the same thing twice becomes a critical function of the software.

So back to the question of time. I just got back from a trip to the Post Office. I pull out the iPhone, tap on the icon to start TripLog. When it appears, I tap “Post Office” in the Frequent Trips section, then “Save Data,” and…that's it. Two taps and I'm done. I timed that. From “home screen to home screen” (i.e., including entering and exiting the app), that was 10 seconds (Incidentally, if we DID simulate, or Apple provided, a drop-down menu, that would now be THREE taps, not two, so the drop-down quite likely wouldn't be the best choice anyway).

What if the user has to enter more? First they dial in the mileage. One thing you can't see in this shot, although you can in other shots in the online manual (http://www.stevenscreek.com/iPhone/triplog.h tm), is that the screen is arranged so that the keyboard comes up to just below the “Purpose” field. That means once you tap in “Destination” and enter that, you can just tap in “Purpose” and continue entering that information, and only then dismiss the keyboard.

Now there's another area that takes up a bit of room that is probably confusing - the “Latest” section on the bottom. After all there's an entire log you can view by tapping the white arrow in the blue circle (which, since someone here makes fun of it, I should point out is an absolutely standard iPhone UI element entitled “UIButtonTypeDetailDisclosure,” used, for eample, in the YouTube app. It's hardly something we invented). So why are we taking up 15% of the screen real estate showing just the last three entries (and, and an unfortunate side effect, pushing the “$ Spent” button out of line with the other two buttons)? There's a very simple reason, which we know because we've been selling our Athlete's Diary software for logging a different kind of mileage for nearly 20 years. It's because when you start up the software, half the time you'll be scratching your head saying, “Did I remember to enter yesterday's ride (or run)?” If you have to go to a SEPARATE screen to answer that question, and then back to the data entry screen, that's a waste of time. So you want to be able to answer that question immediately, with just a quick glance down to the bottom of the screen.

One more thing which seems to have everyone's knickers in a twist - the background color. First of all, so much of the screen is covered with other elements it's a pretty minor feature anyway. Second, the background has to be something which contrasts with white (the table of frequent trips and the list of the latest entries), gray (the data selector on top), and allows labels of the different elements (which are done here in black). We COULD have used a black background with white letters, which is more or less what we do in our Athlete's Calculator app, but in this app that didn't look so good, particularly as it loses the ability to set off the distance “picker”. We could use the gray background Apple uses in many apps, but again with gray buttons we felt a pastel kind of color “worked better.” Is that something we might change in the future or even allow user selection? Could be, but it's not our first priority. Incidentally, if you think Apple is so great at selecting colors, take a look at the “Stocks” app. “Ugh” is my reaction to that. And of course pastel-type backgrounds are also used by Apple, as in the “Notes” app. Funny enough, in the thread over at MacWorld, one guy simultaneously defends that as “simulating a pad of paper,” and then denigrates the odometer in TripLog even though it simulates a car odometer (which, by the way, isn't the primary reason we chose that, but it is, we think, a nice visual element).

Well, I could say more about every single feature of this interface, but that's about all I have time for (actually much more). It's real easy to criticize. It's even easy to write software with a simple, elegant interface. What isn't so easy is to write software that accomplishes the task a user needs to do, particularly when it involves lots of data entry on a handheld, small-screen device. As somebody wrote over in that MacWorld thread again, look at the iPhone contacts app. It's certainly attractive. But if you want to enter a new contact, and just include name, email, phone, and address, you go through 8 screens (four of them the same as you return to the main entry screen) to do so (on a Palm, by the way, that's all accomplished on one or two screens, depending on how you define a screen, since it's really one long screen that keeps scrolling up).

This app COULD have used the same approach as the iPhone contacts app. But it didn't. Because this app is designed to be used EVERY DAY, whereas most people only enter new contacts on their iPhone (as opposed to their desktop) rarely, if at all. And when you're using it every day, going through multiple screens to accomplish a task is simply not acceptable. And if you want to do it on one screen, as we did, things are going to get a bit crowded. That's life.

Steve Patt
Stevens Creek Software