Here’s an e-mail I received this morning, a legitimate e-mail:
“Travel Planner Email”, from “Airlines”
????
Huh?
We’re planning a brief vacation that requires a bit of air travel, so before I hit delete, I paused to see what the spam e-mail said – and then realized it was not spam at all.
Note to programmers: ….
Aw heck.
Just stop doing stupid anti-human stuff.
Michael suggests…
It’s easy to look at the world today and say that web applications have won. This is web developer arrogance. Stupidity is to think that web applications have won because web applications are superior to desktop applications. Smarter, but probably still arrogant developers would point to web applications as disruptive technologies. This involves admitting that web applications are inferior, but good enough, and present enough other "cheaper" advantages to compensate for their inferiority.
To understand why the "web apps have won" claim is dubious. There are definitely a lot of awesome web applications out there. Many of them were created back in the mid/late 90’s, The "features" of these applications were the key to applications, not the user interface. Now these days, most of these web applications offer APIs/web services/RESTful interfaces/whatever you want to call them. In many cases it is possible to build desktop applications that tap into the same features as these web applications. However, this was certainly not the case 10-15 years ago.
If a vendor could make installing and updating applications as seamless as web application models, I believe they’d have a goldmine on their hands.
Ease of deployment is what makes web applications rock. It’s not their functionality, or rounded buttons, or big text boxes, or gradients.
You don’t need to write a web application like the often praised 37 Signals’ applications (such as Basecamp) to have a well received application. It’s not because it’s a web application. It’s because they put in the features and functionality that customers need. If they’d written the same in a desktop application, and it was as simple to deploy and use, I’d argue they’d be just as successful.
This is as about as raw of a time zone selection field as I’ve ever come across in software. If you have any children, or people with weak stomachs, ask them to turn away for a moment.
It’s from StumbleUpon user Preferences.
Read it here.
Thus our test: We ask ourselves, “Would I be willing to teach my Grandma how to use this over the phone?”. If the answer is “Definitely”, we know we’re doing well; if the answer is “Maybe”, we know we can do better; and if the answer is “No”, then it’s often time to rethink the whole thing.
Definitely a smart way to consider the usability of many features.
I found the technique intriguing, but troubling in implementation. The problem I had in particular the way it completely obscured the content underneath each field (there was help for every field). I would have liked if it had only covered up the fields below the active field with a mostly opaque help box. But, as it was it would cover a field I just entered.
Then, there was the auto tabbing. Stop that. I accidentally tabbed through the month field, and then couldn’t tab BACK into the month field because of broken logic in the “day” field.
