15 October 2009

Unexpected error

If you aren’t a computer programmer, no doubt you’ve been really frustrated by an unhelpful error message. Actually, programmers get frustrated by it too.

The thing is, when you’re developing software you often run into places where an error could happen, but you have no idea what could cause such an error. You might know a low-level, programmer-speak reason for the error, but you aren’t aware of the bigger picture that would allow you to write an error message that would be useful to end-users.

This lack of context isn’t for a lack of trying to understand. It is because our computers are very complex system with lots of hardware and software created by many different people and many different organizations. It’s just too complex to know all the different behaviors that can emerge. Not to mention that you will expect my software to work with hardware and other software that I don’t even know exists.

Even when you have the context to write a good end-user error message, there’s a good chance that the same error will happen in a completely different context that you couldn’t have anticipated, which will make your helpful error message misleading instead.

So, often, the best you can do is write a message that will help you know what went wrong. Then when the customer calls, you can figure it out. Then you can fix the problem for that customer and make sure you have a more helpful message in the next release.

There’s still a good chance, however, that a completely different circumstance will then trigger the same error and this helpful message will end up being misleading for those users.

Since error messages that are useful for debugging end up frustrating end-users more than generic error messages, they tend to get discouraged. So we end up with the worst of all worlds: Error messages that are completely useless to everybody.

14 October 2009

Flex-Able

Discussion about my recent post on Van Halen’s 1984 brought up Steve Vai, who worked with David Lee Roth after he left Van Halen. Which brought to mind this blog post started in April that I’d never finished about another album that was released in 1984.

I originally had Steve Via’s Flex-Able on cassette tape. Must’ve been around 1987? I think my guitar teacher told me about it. Earlier this year, I reäcquired it in digital format.

This album isn’t your typical shred-guitar solo album. It’s not like Vai’s other albums. At least, to the extent that I’ve heard his other stuff. None of it that I’ve heard has appealed to me like the stuff on Flex-Able.

I think this album was one of the reasons I bought my first four-track recorder.

Guitar World did a 25th anniversary piece on the making of the album. While working for Frank Zappa, Steve built his own studio to record this album. He promised his friends who helped him out that one day he would pay them scale with interest for working on the album, and he eventually did. He refused to sign the deals that the record companies offered and did it all the work of releasing the album himself. Quite an accomplishment in 1984.

13 October 2009

Flatland, 10/GUI, and SEO

A trio of interesting things found today. (All thanks to Daring Fireball, I believe.)

In “Flatland”, Lukas Mathis presents a very good rebuttal to some of Tog’s viewpoint. I think I may agree with everything Lukas says there.

Lukas’s blog then pointed me to 10/GUI. I think they hit the nail on the head with the idea that the next step in GUIs is not from two-dimensions to three but to fewer dimensions. I don’t know if they have the answer, but I know that the answer involves the user spending less time managing windows.

In “Spammers, Evildoers, and Opportunists”, Derek Powazek says that “search engine optimization” is a racket, which has been my gut feeling about it. Although, I suspect that the things he calls “obvious” are—sadly enough—not obvious to a lot of people. Those things, however, aren’t really about SEO. They’re just about making a good web site.

12 October 2009

Mac file types and creators

Mac OS X 10.6, a.k.a. Snow Leopard, no longer uses an old Mac method of deciding which application to launch when you open a document. The upshot of it is that, by the old method, a document would usually be opened by the application that created it. With the new system, all documents of the same type will be opened by the same application regardless of which application created the document.

Also, the system will ignore the older way of marking the type of the file in favor of filename extensions. (Which are the “.html”, “.txt”, “.doc”, &c. at the end of a file’s name.)

There is still a way to tell the system to open a specific file with a specific application, but this can only be done “by hand” through the Finder. Other programs cannot safely do this.

Metadata madness” by John Siracusa does a good job of explaining it all in more detail.

Personally, I avoid letting the system choose what app to open files with unless I am very sure of what it’s going to do. I can’t disagree with those who say that the functionality of creator codes ought to be restored, whether in the old form or a newer one. I won’t personally miss it, though.

I think something like Quicksilver is the future. Quicksilver is an application that allows you to quickly find documents and specify what you want to do with them. Even better, it learned from the user and was expandable. Google Quick Search Box seems to be the successor to Quicksilver, though it hasn’t caught up with all of Quicksilver’s features yet.

The biggest problem with the old Mac creator and type codes is that there was never a user-friendly way to manage them. Users could easily get into a situation in which they needed to set or modify the type code for a document, but the system didn’t give them a way to do it. There were utilities to do it, but they typically exposed the codes directly rather than providing the good user-interface you’d expect on the Mac.

UTIs are fine upgrade for type codes. Although, I’m ambivalent about UTI’s depending upon filename extensions. Filename extensions are an awful way to store file type metadata. Yet, I can’t argue with their practicality.

Examining the contents of a file to determine its type is often better than any type of metadata, though there are times when metadata is better. (Mac OS X actually comes with a Unix command-line utility that determines file type by contents.) I think a combination is probably the best choice.

Putting aside the issue that the system doesn’t use bundle identifiers in the same way, they are a fine upgrade for creator codes.

11 October 2009

iPhone dice

One of the interesting things about iPhone dice apps is that the accelerometers give them a source of true randomness. (Or, at least, more random than your average pseudo-random algorithm.) The shake-to-roll feature need not be merely a gimmick.

10 October 2009

The spinner lie

To make software user-friendly, we added progress meters whenever the computer performed a lengthy task. Often, this was more work than you might think. It’s usually easier to just start doing the work and notice when the work has run out than to calculate how much work there is to do so that you can report the “percent done” as you go.

Sometimes, though, we’d run into something where we really didn’t have any way to know how much work there was to do. So, we’d use some type of spinner or throbber. The user didn’t have any idea as to how long the operation would take or how far along it was, but at least they could see that progress was being made and if progress stopped.

Then we’d get lazy. Even when we could calculate how much work there was to do, we’d not bother and just throw up a spinner instead of a progress meter.

Then came the lie. The spinner became an animation that continued whether progress was being made or not.

09 October 2009

Mac/PC apps = trouble; iPhone apps = fun

Bruce Tognazzini—Apple employee #66—developed the first version of the Apple User Interface Guidelines. In “Restoring Spring to iPhone Springboard” he writes:

Unlike the Finder or Desktop, rather than giving access to as many apps as you could possibly want, the current Springboard limits you to 180 apps. Paradoxically, this would not be a bad upper limit on a Mac or PC, as apps tend to equal trouble and the more you have, the more trouble you’ll encounter. On the iPhone/iPod Touch, however, 180 apps is terribly limiting as iPhone/iPod Touch apps translate to fun, not trouble, and the more apps you have, the more fun you can have.

It’s funny because it’s true!

Ever since I bought a Pilot (the first name of the Palm PDAs), I have thought that it presented a pretty good model for how the “next Mac” should work. Besides a lot of legacy stuff that the Mac has naturally accumulated, even it has always forced the user to deal with some concepts users shouldn’t even have to know about. For me, while the iPhone has made some advances, it has also made some steps backwards from the Palm OS.

That’s another post, however, that is sitting around amongst my blog drafts.

You can argue that the user-interface for a PDA or phone is too simplistic for a general-purpose computer, but I’m not convinced. Both my Palm devices and my iPhone come awfully close to being general-purpose computers, and I think that for a great many people, their user-interfaces would be more than adequate on a desktop or laptop machine. (We already have plenty of options for geeks like me.)

Back to Tog’s article: He proposes some changes to the iPhone “home screen” app—internally called Springboard. While I like Tog’s proposal, I think he’s too quick to dismiss search. While I’m not a fan of ditching “browsing” interfaces, I’m seeing search becoming more and more primary.

With maybe a dozen exceptions, I’m more likely to google for a web page rather than go looking for it in my bookmarks. Even back c. 1995, I was more likely to use the Finder’s search to locate files than by browsing. Now, it’s Spotlight. Amongst all the brouhaha around Mac OS X 10.6 (Snow Leopard) no longer supporting creator codes, I’m thinking more than ever that something like Quicksilver is the future.

Of course, I’ll be the first to admit that I’m not the average user, but I think Google’s success shows that average users—when given a really good search capability—will use it.

Time spent improving the app search on the iPhone would give more bang-for-the-buck than Tog’s proposal. So, that’s what I’d do first if I were Apple.

And one mistake Tog made: Using dots to indicate vertical scroll position. This should use the standard iPhone scroll “thumb”.

08 October 2009

Flash on the iPhone

So, Adobe has given Flash developers the ability to build stand-alone apps for the iPhone. There will still be no Flash support in Safari or any other web browser. If you want to write an iPhone app, you won’t want to use Flash; but if you have a Flash app you want to port to the iPhone, then this looks pretty good.

Honestly, I really like this situation. The type of Flash content I’d like to see on my iPhone are the things that are essentially apps. Not having access to Flash used to make annoying web sites doesn’t really bother me.

07 October 2009

Van Halen’s 1984

I recently got Van Halen’s 1984, which is an interesting album. It’s a transition. It’s the last album before David Lee Roth left the band. It has the band’s first (& only?) #1 hit.

There were four hits off this album: “Jump” (#1), “I’ll Wait” (#13), “Panama” (#13), and “Hot For Teacher” (#56). The first two were quite a change for the band, being synth-driven instead of guitar-driven. In fact, I saw concert footage of “Jump” in which Eddie even replaced the guitar solo with a keyboard solo. Looking at the albums and singles that followed, it seems clear that their synth-driven songs were more lucrative than their guitar-driven songs.

Which is kind of funny, because I remember a friend arguing that people wanted to hear Eddie play guitar and that they were going to make less money if he kept playing keyboards. To which I argued that I’d rather listen to music made by following the muse than that made by following the dollars. (Should that be called “lucric”—from “lucre”—instead of “music”?)

Anyway, this raises a couple of questions in my mind:

Were these songs more lucrative because they were synth-driven? Or is there some other difference between the songs Eddie wrote on keyboards and those he wrote on guitar?

To the extent that the instrumentation was a factor, was it a function of the times? i.e. Are keyboard-driven still songs more lucrative today?

04 October 2009

Don’t let the misunderstandings win

This weekend, Andrea (my soon-to-be-ex-wife) made a nice gesture to me. One that was, in fact, very hurtful. I don’t think she intended it to be hurtful. (In spite of the fact that experience has taught me to assume the worst where she’s concerned rather than the best.) I don’t think she understands me enough to realize that it was hurtful.

So, no big deal. I’ve shrugged it off. I’d like to explain to her that it was hurtful and why. That’s what I would want if the roles were reversed. I know now that there’s no point in that.

If the roles were reversed, my experience tells me that she wouldn’t be able to see beyond the hurt, and she would silently resent me for it without my ever knowing.

I also know that, if she were reading this, she would at this point assume that I’m just trying to insult her. Which is not the point at all. The point is that our different natures and expectations led to misunderstandings.

The successful couples aren’t the ones that have no misunderstandings. Every couple is going to have these kind of misunderstandings. The successful couples are the ones that don’t let this kind of little stuff win. They have faith, don’t give up, eventually learn to understand one another better, and come out the other side stronger.

To me, that has always been the whole point of the vows.

At least, that’s what I believe. Make sure that you and your spouse understand that you’re going to run into stuff like this. Promise each other that you won’t let it win. Promise each other that you won’t even think the word “divorce” until you know that you fully understand the issues and that they are worthy of that action. Misunderstandings aren’t worth tearing your kids’ family in two.

When you feel like things aren’t going well, don’t be quiet! You can’t defeat misunderstandings without communication. Don’t think that you can fix it yourself. You can’t fix a relationship without at least enlisting the aid of the other person. More than that, though, don’t hesitate to go to a counselor because they can help you see when problems are really just misunderstandings.