Highway 61 revisited

As I sit here with a Cesária Évora CD on in the house, I have an update to the car AV system issue, wherein it couldn’t stop playing Bob Dylan. That is, I found out why it’s playing a disproportionate amount of Dylan.

I noticed, as it played more songs, that it was not just playing a lot of Bob Dylan and the Beatles, but that it wasn’t playing anything beyond C in the alphabet. I have the files on the microSD organized in folders (directories) based on the artists and albums, so at the root level there’s a Bob Dylan folder, and that has sub-folders called Blonde On Blonde, Blood On the Tracks, Desire, and so on. In those folders are the MP3 files for the songs. I used the touch-screen interface to look in the folder of the current song, then went up to the artist level, and then to the root. I scrolled the list of artists, which should have gone from 10,000 Maniacs to Youssou N’Dour. But the list stopped somewhere near the end of the Cs.

Ha! There appears to be a limit to the number of directories. And with only around 1000 songs active, instead of the 4000 on the chip, the chances of Dylan had been multiplied by 4 for each play. No wonder I was getting so much! OK, I can work around that limit.

I took the chip into the house, put it in my computer, and wrote a script to pull all the files out to the root level, so there are no directories/folders. /Bob Dylan/Desire/03 Mozambique.mp3 became /Bob Dylan-Desire-03 Mozambique.mp3, and now I have 3984 files in the root directory, and no folders. Pop the chip back into the car system, and try it out.

Great! There’s a D... now an L... a G. Much better!

But it didn’t take too long to notice that it never played anything beyond L. I went to the list and scrolled again (and was happy that one can scroll backward, and it wraps around).

This time, it was easy to tell exactly: the files in each directory are numbered sequentially by the system, and with everything in the root directory I could see what the actual limit is: 2500 files, exactly. That’s horrid!

2500 files might be a reasonable limit when microSD chips only went up to 2 GB. But that was a while ago, and it’s perfectly easy to have 8000 files or more now, and higher-capacity chips are coming out all the time. It’s absolutely ridiculous to build in limits like this, considering how the technology is moving forward. Any reasonable file system has tossed such limits away long ago.

I’m trying to delete 1500 files from the microSD card, but it’s tough: the music on my computer is already selected from my far more extensive CD collection, and represents my favourites. How do I pick 1500 favourites to eliminate? The first 500 went gradually, but it wasn’t too awful. The second 500 were a real challenge. I’m still working on the last 500, and it’s very tough!

I’ll be writing to Pioneer, to express my displeasure and to see if there’s anything that can be done. And I guess I’ll go back to streaming the music from my BlackBerry, which still has all the songs, and for which there’s no such limitation.

---

Update, 4 p.m.: Pioneer's customer service gave me a prompt response, which confirms what I saw:

The maximum number of files on USB or SD that this unit will support is 2500. Currently there are no plans to change that specification. Your feedback is appreciated and will be passed along to product planning.

Web-page mistakes

I don’t understand, sometimes, how people put together their web pages. Who really thinks that, say, pink text on a red background looks good? Seventeen different typefaces on one page? A background image that makes people’s eyes cross?

One can argue that those are all matters of taste, and, after all, à chacun, son goût. And anyway, those things are easy enough to fix: one can apply a custom style sheet right in the browser, and override all those size and color and font and background things that were specified in the web page. There are instructions and bookmarklets floating around on the web... just stick one in your browser’s bookmark bar, and then click it when you encounter a retch-inducing or simply unreadable web page.

But there are lots of web-page problems you can’t fix up in your browser, because it’s the people who put together their web pages who don’t understand, and it’s not just in matters of personal taste. Perhaps one of the most annoying of these is what I call the lazy thumbnail error.

You’ve encountered these, surely: you’ll be looking at a web site for a business or organization, and you’ll click on a page labelled The Christmas Party, or Our Staff... and the page will take forever to load. You can’t see why, though: the Our Staff page shows maybe 20 people, from the company president to the secretarial staff, each with a small photo, a name, and a short paragraph by way of a bio. No big deal here. The photos are all tiny, something on the order of 100 by 120 pixels, like my mug at the top of these pages. What’s the problem?

The problem is that the photos aren’t as small as they look, because the webmaster was lazy about creating thumbnails for the staff pics. She asked everyone to send her a snapshot, and she put them all up on the web page with HTML like this:

<img src="staffPics/jane.jpg" height=200 alt="Jane Smith">

There... that makes all the photos the same height, 200 pixels. If someone sent a larger one, it gets scaled down, nice and small. Makes for a uniform look, and the page looks great.

What the webmaster doesn’t understand is that the scaling is not done at the server, but in the user’s browser. When the browser loads the page, it sees all these IMG tags, and it requests each image URL (such as staffPics/jane.jpg, in the example above). But it has no way to tell the server that it’s only going to display it 200 pixels high, and the server has no way to know. If Jane sent a high-res portrait, eight megapixels huge, the whole thing gets sent to the browser. And then the browser has to do the scaling itself, when it renders the page.

If ten of the twenty staffies have sent large photos, that simple Our Staff page can wind up being tens or hundreds of megabytes in size, despite how tiny the headshots look in the browser. Plus, there’s a load on the browser, which has to store the full-sized images and resize them for rendering — you can sometimes see that effect when scrolling the page is sluggish.

The solution is for the webmaster to take the time to create images of the right size (or close to it) from the start. If someone sends you a 2400 x 3200 portrait, scale it down to 150 x 200 yourself, and just put that image on the web page (there are programs available for this, which make it easier to handle a lot of photos). If you want to make the larger one available for clicking, something like this will do:

<a href="staffPics/full/jane.jpg"><img src="staffPics/thumbs/jane.jpg" height=200 alt="Jane Smith"></a>

The height=200 still ensures that they’ll all be the same height, in case the thumbnails aren’t all exactly the same size (there’s no harm in letting the browser do a small amount of re-scaling). But now people won’t have to grab all those high-resolution photos unless they actually want to.

“Friendly” user interfaces

It’s long been a peeve of mine that some computer programs are programmed to try to sound friendly, cheerful, or just colloquial. It seems out of place to me, forced, overly artificial. I don’t mean that I want all the output from computers to sound like the stilted science-fiction stuff, saying affirmative instead of yes, and the like. But neither do I ever want to see (or hear) things like Oops!, Hurray!, nor even I’m sorry, coming from my laptop, mobile phone, car, or washing machine.

Some examples:

It’s common when you’ve finished installing new software on your computer for the installation package to wrap up with a message like, Congratulations! You’ve successfully installed the Frobozz Magic MP3 Converter! Perhaps the folks at Frobozz should be congratulated for having sold me the software, but I neither need nor merit kudos for having run the installation program without spilling my coffee on the laptop in the process. Just stick with telling me that the installation was successful... and skip the exclamation points, while you’re about it.

If you look at your Spam folder in Gmail, and it’s empty — most likely because you’ve emptied it — you will see the message, Hooray, no spam here! Again with the unnecessary emphasis; let’s skip the bangs. Writer D. Keith Mano has been quoted as saying, of exclamation points, They may be used only in dialogue, and then only when the speaker has just been disemboweled. But more than that, skip the fake cheer, as well. It’s not as if I’m magically spam-free: I just trashed it, so of course there’s no spam here. Just say that, or, better still, say, This folder is empty.

Gmail’s new Priority Inbox feature does something similar if your Important and Unread group is empty: Woohoo! You’ve read all the important messages in your inbox. Please, forgo the Woohoo!

New York City’s public radio station, WNYC, recently had a talk program about Computers and Language, to which there’s a comment by one Amy, from Manhattan, who seems to agree with this point:

It’s not so much having a computer try to sound human that bothers me. But when an ATM screen signs off by saying It’s a pleasure to serve you, I find that very irritating. It’s a machine. It doesn’t get any pleasure out of serving me. I guess its programmers think that comes off as polite, but it doesn’t to me.

Exactly. So dispense with oops and I’m sorry, and don’t tell me that Flickr is having the hiccups.

Clifford Nass, a professor at Stanford University, has a new book called The Man Who Lied to His Laptop, and he’s been on the talk-show circuit with it. He was on Science Friday last week, and here’s an item from the Wall Street Journal about the book.

His research shows that many people do respond in interesting ways — favourably or un- — to computer communication. From the Science Friday discussion (starting around 2 minutes in):

Ira Flatow: You start out in the front of your book talking about... that German car makers would not put a female voice into the GPS.

Clifford Nass: Well, even worse, BMW did in fact put a female voice in their GPS, and they actually had to have a product recall, because German drivers would not take directions from a woman. And what was particularly striking was, even after the help desk, when people were calling in angry, tried to explain that in fact it wasn’t a real female in the car, and in fact that all the people who had designed the GPS and the directions were male, nonetheless, people were unfazed, and insisted on changing the voice.

Maybe those people who objected would be mollified by deferential stuff inserted into the GPS speech. Excuse me. I don’t mean to be pushy, but didn’t you tell me earlier that you wanted to take the next left onto Löwengartenkinderklammerkleinenvolgelstrasse? Maybe.

As for me... nein, danke.

Usage issues with OAuth

OAuth — a proposed Open Authentication standard — fills a significant gap in cross-application authentication. It’s common in a world of myriad web-based services for one service you use to want to access another service you use, in order to make things better or easier for you.

For example, you might keep contacts in your mail service, and you might want your photo service to see if people you’re in contact with have photos that you might share. We’ve generally done that sort of thing in one of two ways:

1. Manual: you go to your mail service and tell it to export your contacts to a file on your computer, and then you go to your photo service and tell it to import contacts from that file.
2. Automatic: you give your user name and password for your mail service to the photo service, and it logs in and reads your contacts directly.

It should be pretty clear that the manual mechanism is annoying — perhaps to the point of being infeasible for inexperienced users (the Barry’s mother problem) — and that the automatic mechanism is risky, handing your login credentials over to someone else. You might trust your photo service, but what if there’s a problem that results in your email login credentials getting stolen?

Some folks developed an alternative mechanism, called OAuth. Essentially, it works like this, in the example case above:

1. While you’re using your photo service, you click a link that says something like See if your contacts have anything to share.
2. The photo service redirects your browser to your mail service and tells it what it wants to do.
3. Your mail service shows you a screen asking you to approve the action.
4. If you approve it, your browser is given a token, and is redirected back to the photo service.
5. Your browser gives the token to the photo service, which uses it to connect to your mail service and retrieve your contact list.
6. Your photo service shows you the shared photos from your contacts, just as you wanted.

The advantages of this scheme are:

1. It’s simple for you; you just click on the Do this for me, link on one service, see the approval screen from the other service, then see the result of the action back on the first service.
2. You can verify that the intermediate approval screen is legitimate, because all the security indicators work. The screen really does come from the second service (the mail service, here), and you interact with it directly.
3. Your login credentials are only sent to the service you’re logging into, and are never give to anyone else.
4. You authorize only the actions needed by the requesting service, and no more. If you give away your credentials, the recipient can do anything. But with OAuth, you can authorize the photo service to read (and not change) your contact list, but not your mail. You can authorize a send to a friend service to send email on your behalf just once, but not to read your existing mail. And you can authorize an archive service to read your mail always, but not allow it to send mail.

The only problem with the system involves presenting you with an approval screen that makes sense to you, and making sure that you don’t approve something you shouldn’t (or don’t mean to). Let’s look at that:

In this example, the approval screen should say something like this:

The Frobozz Photo Service would like read access to your contacts. Do you approve this request?

Yes        No

But suppose, instead, that the photo service asked for more access than it needed, either carelessly or, perhaps, maliciously. Suppose you got an approval message like this:

The Frobozz Photo Service would like full access to your contacts. Do you approve this request?

Yes        No

Or like this:

The Frobozz Photo Service would like full access to your account. Do you approve this request?

Yes        No

Would you realize that there was something wrong? Would you know it was asking for more access than it needed? Would you say No? Would my mother?

At the recent IETF meeting, I brought this up with the OAuth chairs, Area Directors, and others, and stressed that a key part of making OAuth work is getting the user interfaces right, and that we can’t leave that to arbitrary implementations. Even though the IETF doesn’t usually do user interfaces, in this case the UI is an integral part of the security of the system. We need a document that lays this out and makes it clear what the potential problems are, perhaps working with UI experts and giving advice on ways to handle it (and ways not to).

And today, the folks at F-Secure point out a case in the wild. Twitter has been using OAuth for a while, and now requires it as the only way applications can get access to Twitter accounts. That’s good, but see this real example:

Is the person who clicked on whatever caused this...

1. ...expecting such an authorization request?
2. ...aware of what it means to approve access and update authorization?

Would that person know enough to say Deny? A great many Internet users — perhaps the majority — are not aware, and would choose Allow, giving their Twitter account over to a spammer, just because they happen to like Lady Gaga and think that this is associated with her, and perhaps that it will give them access to her tweets, music, videos, or whatever.

F-Secure wants a quick way to rescind the authorization, once the victim realizes what’s happening, and that’s a fine demand. Yet, would most users even make the connection between their granting of this authorization for Lady Gaga and the appearance of unrelated spam tweets from their own Twitter accounts? Would they even know what they should rescind, even if they knew that they could (and how)? I doubt it.

As good an idea as OAuth is, this is a real sticking point. We have no idea how to solve it, but we must try.

Getting the user interface right

I’ve talked about user interfaces in these pages a few times before. The thing is, I’m not a user-interface expert. But, as with wine and art, I know what I like.

And, while not being an expert, I’ve often been called upon to design a user interface nonetheless, or, at least, an part of one. It’s what sometimes happens with programmers. I always hope that my UIs will be reasonable — I like them fine, and, as I said, I know what I like. But will they suit the general public? Qui sait?

My first general rule, and what I prefer when I’m using other people’s interfaces, is to make sure that the things one would most commonly need to do are quickly and easily accessible, and obvious. The same goes for the important things, which might be less common but which you have to get to quickly when you do need them. Second priority goes to a set of likely actions that will be used less often. Everything else can be hidden behind an Advanced button, selection, or tab.

This stuff’s especially important on mobile devices, which have smaller screens and more limited means of interaction.

What are the most common and most important things you’ll need to do right after you place a phone call? I think they’re these:

1. Hang up. You called the wrong person, or hadn’t intended to place a call at all.
2. Select between the handset and the speakerphone modes.
3. Switch to another program or view while continuing the call. Maybe you need to refer to an email message, or a calendar or address-book entry, as soon as the person answers.

I had occasion to place a call on someone else’s phone recently, and I realized that it was set up perfectly for this. The phone has two buttons, on the left and right, and the screen displays the functions that these buttons will perform. There’s a button that always activates the phone’s menu, and there’s another that always hangs up a call. One of the variable-function buttons is, while you’re on a call, labelled Speaker or Handset, and will toggle between them. Switching to speakerphone mode, which is what I needed to do, required a single button-press, and was instantaneous.

That’s one thing that bothers me about the BlackBerry’s UI when I’m making a call. To toggle speakerphone mode, I have to press the menu button, find Activate Speakerphone on the menu, roll down to it, and click it. That’s not terrible — I know where it is, and it’s easy enough to do it. But it takes several seconds, during which time I can’t hear the phone. A function such as that, which is one of the top three most likely things you’d need to do, should be even easier. It should be a single button, or a tap on a touch-screen.

What’s more, the BlackBerry menu is busy and cluttered. Here’s what the menu looks like when I’m on a call:

Help

---

End Call
Hold
Enhance Call Audio
Mute
Notes

---

New Call
Call Voice Mail

---

Activate Speakerphone

---

View Address Book
View Calendar
View Messages

---

Switch Application
Home Screen

Those are all things I’m likely to want to do, so that’s good. But several of them can be done in other ways (there are at least two ways to end the call, three ways to switch to the home screen, and two ways to switch applications; also, I can view my address book, calendar, and messages by going to the home screen and selecting them there). I’d prefer having Speakerphone and Mute as functions directly on the phone screen. But, oddly, there’s nothing on that screen to interact with, once you place a call.

The BlackBerry folks get so many things right. But they miss on some basics.

More user-interface follies

In days of old, when knights were bold, and they kept their data on large reels of magnetic tape, the tapes were stored in a central tape library, and were mounted by request on mainframe computers. Each tape in the library was given a volume serial. One requested a tape by its volume serial, which was six characters — letters and numbers.

Once in a while, one might need a fresh tape to write information to, which one would then read back in the same program, and the tape would not need to be kept in the library afterward. These were called scratch tapes, and the volume serial “SCRTCH” was reserved for such requests.

Now, if you needed a scratch tape and made the mistake of requesting it as “SCRATCH”, the program that handled the mount requests would see that you used seven characters, and volume serials could not be more than six. But more than that, it actually recognized the specific name “SCRATCH” and gave an error message similar to this:

Error: Scratch tapes should be requested as "SCRTCH".

And you had to re-submit the request with the “correct” volume serial.

This was just stupid. The computer knew what you meant. There was no question about it. So why complain and make you re-submit? Just do it!

There was a lot of that sort of thing back then. But, hey, those were the old days, and we’d never do that any more, right?

Well, not right. We still do it plenty.

We’ve all gotten automated email that said, somewhere in it, “Please do not reply to this automatically generated email. Instead, direct any questions to frobozz@example.com.” Now, there’s a header field called “Reply-To” that can be put into any email message, and that every email program understands, which controls what address the reply goes to. All they had to do to make replies work the way they and you want them to was to put this into the headers of the message:

Reply-To: frobozz@example.com

But they didn’t. Lazy programming, poor human factors.

On the other hand, it might be intentional: they might actually not want you to reply, and by making you take the extra step of manually entering the reply address (or even using copy/paste) instead of just clicking “Reply”, they may be discouraging it.

But, then, the other day I got the online proxy materials for the 2010 IBM Stockholder Meeting. It includes a control number that allows me to vote my shares online, and it looks like this:

Proxy Login Details:
Control Number:1234 5566 7788 999

Note: When voting your shares, please DO NOT cut and paste the 15-digit Control Number. You will need to enter the 15-digit Control Number without the spaces.

Yeah, that’s just stupidity, unmitigated. It’s pretty likely that a good number of folks will transcribe a 15-digit number incorrectly, and it’s an avoidable situation. They could include the number without the spaces, so it can be copied and pasted. Even better, the web server could simply strip out spaces, dashes, or whatever, before passing it on to the proxy-vote handler. And in this case, they want you to do it and get it right, so the issue with the Reply-To doesn’t apply here.

More lazy programming, more poor human factors.

[I copied-and-pasted the number into a text editor, deleted the spaces, then copied-and-pasted that into the web page. It worked fine. But I suspect most people would just type it in, and then utter discouraging words if they typed it wrong.]

We need to think about this stuff when we provide user interfaces. Stop making every user do the work. Take an extra few minutes to help them out.

The conflict of simplicity vs glitz

When one is writing computer software that one’s company will put out as a product, one has to consider what the user interface will look like — how will the software appear to, and appeal to, the user? Large companies, and even some small ones, hire human/computer interface (HCI) experts to study the interactions and design a graphical user interface (GUI) that they think will work best.

In GUI design, we balance function with form, looking to present a visually appealing result that’s also easy to use. We don’t always get it “right” the first time, and there are usually iterations of the design in subsequent product releases. That’s all as it should be.

But “visually appealing” and “easy to use” mean different things and have different relative importance, depending upon the purpose of the software.

A web browser, for example, will generally have a UI that’s optimized for displaying a web page, and the bulk of the window is devoted to this. Other UI elements serve to facilitate navigation — through bookmarks, browser history, search, forward/backward controls, tabs, and the like — or to give progress or status indications, and we mostly want them to be accessible but not obtrusive. Some users might enjoy a browser “skin” that presented child-toy-sized buttons with animated graphics, but most would rather have them small and simple.

A calendar, on the other hand, has to balance more UI elements, giving the user a choice of different views (by day, by week, by month, as well as perhaps by work-week, two days at a time, and so on), a navigable inset that shows a selected month (that might or might not be the current one), a selection of categories or sub-calendars, access to other users’ shared calendar or free-time information, ... the list can go on. It’s very likely that colour and icons will be important here, to distinguish one type of entry from another (meetings, anniversaries, travel, reminders), and that sort of thing.

At the other extreme, consider the software that sends printed output from other programs (the web browser and the calendar, say) to your printer. You might need to interact with it, to reprint a mangled page or to cancel a multipage printout that you’ve decided you don’t want after all. But for the most part, you want it to be out of your way. You want it to quietly send your stuff to the printer, and you don’t need it annoying you with popups or any sort of fancy GUI.

That brings us to the BlackBerry Desktop Manager, a program that’s used to do synchronize, back up, and load software onto a BlackBerry device from a Windows computer. These days, much of that can be done over the air, but if you want to do it from your own computer, you use the Desktop Manager.

As with the example of printer software, most of the time you want the Desktop Manager to be unobtrusive. You plug the BlackBerry in, and it automatically synchronizes. No flashy UI is necessary, nor wanted. At least, not by the user.

But Research In Motion, the maker of the BlackBerry (and the Desktop Manager software) apparently decided that it does want a flashy UI. Here’s what we had in version 4.2 of the Desktop Manager (shown here at half size; click for full size):

And here’s version 4.6 (also half size):

Much bigger, much glitzier... and no longer resizable.

Sigh.

Consistent user interfaces

I love my BlackBerry™. I'm not addicted to it (and I find it rather annoying when people chuckle at calling them “CrackBerries”). Rather, I find it an excellent tool, which I can use how and when I want. It makes my life easier; far from making things more stressful by having me always “connected”, it reduces stress by giving me more options.

It's also a marvel of engineering, in a number of ways. They did amazing things with the power-consumption profile, such that its battery lasts far longer than one comes to expect from such devices. The roller-wheel on my model (I've had a 950, a 6230, and now an 8700) is a simple and elegant way to navigate — for a right-handed user. I'm eagerly awaiting the availability of the new 8300 model for T-Mobile (it's been initially released for AT&T only), which has a center-mounted roller that moves the cursor in four directions, instead of just two). Its audio quality is crisp, its Bluetooth support works seamlessly, and its handling of email makes me happy.

But there's one glaring flaw in the user interface: the menus are not consistent.

And this drives me crazy, short drive though that may be.

Windows™ generally deals with menu items that are unavailable in the current context by “greying” them — they're still in their normal positions, but you can't select them. Leaving those unavailable items in their normal positions means that the other items are also in their normal positions. That's very handy. But that's not optimal for a small device, where one might want to remove the clutter by not including things that can't be used anyway.

The result of the clutter removal, though, is that things are not predictable when one is moving quickly and doing things by “reflex”. The best example of this is in the email application, when one wants to delete a message or a group of messages.

Select multiple messages, click the wheel, and you get a menu that looks like this:

Help

---

File Messages
Mark Unopened
Save Messages
Delete Messages

---

Compose Email
[...etc...]

(The option “File Messages” is selected by default, as I show by making it bold.)

But if the most recent message you've selected is a call-log message, rather than a normal email message, the “File Messages” option is not available and is removed from the list. And what option is selected by default?:

Help

---

Mark Unopened
Save Messages
Delete Messages

---

Compose Email
[...etc...]

This is maddening, because it means that when I've selected batches of messages for deletion when I no longer need them, how I have to spin the wheel depends upon which messages I happen to have selected. And that means that I can't do it semi-automatically, but have to pay more attention to it than it ought to require (what usually happens is that I wheel down, away from the selected “Delete” option, and then have to wheel back to it).

The point here is that user interfaces should be designed so that there's as much consistency as possible among related functions. It's not likely that my default choice of how to dispose of six email messages will differ from my default for disposing of five email messages and a call-log message. And a difference in the user interface for those two cases will be an annoyance every time.

Still, if that's what annoys me the most about the BlackBerry, it's doing pretty well by me, isn't it?