I’ve used an iPad for over two months now. During that time I’ve used many apps across a broad range of categories, and designed and produced one. I’ve gained a fairly deep knowledge of the iPad (and iPhone) HIGs. As part of my day job, I typically have four to five conversations about products, features, and designs for the iPad, daily. In other words, I’m a power user who has in practice pushed my iPad to it’s limit, and in concept pushed ideas for interactions with my iPad to the extreme.

So, please take that into account when I say that while I agree that the iPad is a great device for “seeing” the web, it’s not a great device for deeply using it.

To clarify this statement, consider the following cases for web use:

1. Update status on Facebook
2. View photos on Facebook and Flicker
3. Read the NYTimes.com
4. Use Gmail to write a long email to mom
5. Comparison shop for a new washer/dryer
6. Research vacation rentals in Vienna

The first three cases - both incredibly common - require me to click a few buttons, and/or type in a few words. On my iPad, accomplishing these tasks via mobile Safari and the iPad keyboard is a breeze. Indeed, they are so easy, that when coupled with the iPad’s form factor, the experience of conducting them is better than on my laptop.

However, when I engage in the fourth task on my iPad, the experience of using the web begins to degrade. In this case, where I am typing a long email to mom, the iPad’s keyboard simply falls short. For me, typing more than a URL, or at most a string of 20 words, becomes unbearably arduous. For me, the lack of command keys destroys my typing workflow. I simply can’t live without the ability to very quickly copy, paste, and delete. And while this isn’t the fault of mobile safari, the experience of writing emails is a significant part of deep web usage that simply lacks on my iPad.

Finally, tasks five and six are just a complete waste of time on the iPad. For each of these cases, the ability to spawn, and then navigate across multiple new windows, is entirely necessary. On the iPad, such workflows are downright antagonizing. On the other hand, using Safari on my laptop, I’m able to open new URLs either in tabs, or in new windows, and easily navigate across them, again using command keys.

To link this all back to the title of this post - when Apple claims that the iPad is the best way to “see” the web, I don’t disagree with them. But when it comes to relatively common use cases that require typing, key commands, or the quick spawning and subsequent access of multiple browser windows - deeper web use cases - the iPad provides a poor user experience.

Sorry to post two NYTimes.com articles back to back, but they happen to both be relevant to design.

This article describes how GE’s lack of product usability coupled with poor product instructional design, and flavored with a dash of incompetence on the part of the hospital technicians, has led to numerous cases of over-irradiation. It’s sad. And in my opinion, the primary fault lies with GE.

Normally, the more radiation a CT scan uses, the better the image. But amid concerns that patients are getting more radiation than necessary, the medical community has embraced the idea of using only enough to obtain an image sufficient for diagnosis.

To do that, GE offers a feature on its CT scanner that can automatically adjust the dose according to a patient’s size and body part. It is, a GE manual says, “a technical innovation that significantly reduces radiation dose.”

At Cedars-Sinai and Glendale Adventist, technicians used the automatic feature — rather than a fixed, predetermined radiation level — for their brain perfusion scans.

But a surprise awaited them: when used with certain machine settings that govern image clarity, the automatic feature did not reduce the dose — it raised it.

When a company designs and builds a medical instrument/equipment whose function poses an inherent medical risk, that company is responsible for ensuring that the use of the instrument/equipment has been usability tested. In other words, the company should run end-users of the instrument/equipent thought usability studies, in the context of work, in order to ensure that the instrument/equipment is indeed usable, and to evidence areas where the instrument/equipment might cause it’s end-users to error.

I wouldn’t be surprised if GE had neglected to test their gear before unleashing into the hands of ill-trained technicians, who then nuked the brains of unsuspecting and frantic stroke victims.

This kind of thing roils me. It’s like the combination of a Don Norman debate, and a Norman Bate’s moment.

John Nack with the inside scoop on CS4 installers, and plans for CS5.

Google’s homepage today advertises the new G1 phone, in by doing so violates one of their core design principles.

Miguel Helft with the rest of the story.

Jen Jacobsen via Boxes and Arrows with some downright useful information on how to plan for, create, and bring online audio content in a useful and usable way.

I’m sure many of Jen’s points apply to video IA on the web, but it would still be nice to read a similar article focused solely on video. If you know of something like this, please drop it in the comments.

Aza over at Mozilla Labs out with a new video explaining Ubiquity, Mozilla’s latest foray into useful browser plug-ins.

Ubiquity’s goals:

Empower users to control the web browser with language-based instructions. (With search, users type what they want to find. With Ubiquity, they type what they want to do.)

Enable on-demand, user-generated mashups with existing open Web APIs. (In other words, allowing everyone (not just Web developers) to remix the Web so it fits their needs, no matter what page they are on, or what they are doing.)

Use Trust networks and social constructs to balance security with ease of extensibility.

Extend the browser functionality easily.

Here’s my take - Ubiquity is a great idea that is already available, to a certain degree, in existing applications such as Quicksilver, or even OSX Spotlight. Ubiquity does not need to be built into the browser. In fact, Ubiquity’s functionality would ideally find its way into a desktop app. As a desktop app, Ubiquity’s natural language search capabilities would index and retrieve information on my machine as well as all the information on the web. Furthermore, as a desktop app, the idea of interacting with functionality and information isn’t limited to applications that reside on the network.

All that being said, Ubiquity seems perhaps a better fit for an AIR app.

NYTimes.com with a new editorial on the current state of ballot design in America: BAD.

Ballot design has traditionally been left up to states and localities, which have had a spotty record. Local officials responsible for ballot design often lack the technical expertise to make the right decisions. State laws are often written in ways that permit, or even require, ballots to be poorly designed. New York has long had a misguided “full-face ballot” law that requires every race to be listed on a single screen or piece of paper. Experts say that leads to information overload, voter confusion and errors. There is also remarkably little usability testing before elections, which would allow officials to learn in advance when ballots have problems.

Congress should require that ballots used in federal elections meet minimum design standards. It should also mandate pre-election usability testing and make funds available for it. States and localities need to draw up better guidelines for how ballots are designed and clearer instructions to voters. They should also publicly report after each election how many votes are lost because of miscast ballots.

I doubt this would ever be an issue in Europe. I would assume that in most of Europe, at least some decision-making elected officials would have a base-line level of typographic instinct, borne into them from their surrounding cultural history of european modernism and the tradition of the grid, that would lead them towards making the right decision.

If any readers readers in Europe have example ballot designs or articles that support or refute my assumption, please post em!

Aza and Ryan both post their observations on the benefits and problems with modal overlays. For those of you unfamiliar with the term, modal overlays are those web 2.0 lightbox-style boxes that pop-up over your webpage while the rest of it darkens. In a sense, they are modal dialogs for the web.

Quicksilver, my friends say, is a great productivity tool. Once you’re used to it, all your computer’s applications and files are at your fingertips. Well, I’ve tried to use Quicksilver a number of times and to be quite honest, I’ve found the cost of learning the tool’s usage patterns to be higher than the reward. Perhaps it’s just me, but I can’t be bothered investigating plug-ins and multiple sets of key commands so that I can control my apps like a puppet-master. Too much control, so little time. So, no Quicksilver for me.

And so it was until last week that I had resigned myself to the fact that I would never be as efficient in my OS as my Quicksilvered buddies. That is until my friend Daniel mentioned in passing that he uses Spotlight to open applications and quickly access files. Aha! Some practical magic. The Spotlight trick was learned in literally 1 second, and the rest is history.

The key to Spotlight’s success is its simplicity. First, the cmd+space combination is easy to learn, to remember, and to execute. It’s ideally ergonomic. Second, spotlight’s interface is a simple input field and surrounding blue box. In contrast to Quicksilver’s cool but distracting spinning cube, Spotlight is blissfully straightforward. Finally, spotlight’s real-time search result categorization makes it easier to find, and open the right stuff faster. And that’s the true essence of Spotlight’s simplicity - it’s only about finding and opening/running stuff. And at this point in my computing experience, that’s all I really want to be able to do faster.

Recently, from Jakob Nielsen:

Should the OK button come before or after the Cancel button? … We get countless questions about small details in UI design that don’t matter much to the overall user experience. One classic is the order of buttons in dialog boxes: OK/Cancel, Cancel/OK.

He provides a straightforward analysis. What I like best about it is the part from the quote above, where he says that questions like the ones related to OK/Cancel don’t matter much to the overall user experience. It is so true.

In the past, I’ve worked in corporate design organizations where relatively small-scale issues like OK/Cancel seem to be on the top of everyone’s mind. IMO, this is a symptom of 1) design inexperience and/or 2) a design organization guided by analytics.

For example, an inexperienced designer, or one who does not think both broadly and deeply, falls back on their ability to nit-pick insignificant details like OK/Cancel. When a designer has nothing else to say or contribute, nothing works better (to them) than throwing out minor nits. Sometimes it even works, especially when non-designers (who have little to no design experience) are sitting in the room.

In the second case, which includes design-systems for banking, mission critical applications, or super-highly scaled applications like Gmail, OK/Cancel type design issues actually do matter, analytically speaking. Generally, the design quality of such systems depends on user-sucess metrics. Thus, optimization and tuning for these systems often focuses on the precise wording and order of a small number of items.