The End of Consistency

In Safari on the Mac, single-clicking in anywhere in the location field will direct keyboard focus to the text area and place the cursor at the character boundary closest to where you clicked. This is the same behavior as every other text box in Mac OS X.

In Google Chrome, clicking text in the location field will automatically select the entire URL. Presumably this is because Google engineers feel that people are more likely to want to replace the entire URL than to edit a portion of it.¹

However, there are several scenarios where you’d be better off with Safari’s behavior: (1) there’s a typo in the URL you’d like to change; (2) you want to move up a level out of dead-end navigation by deleting everything after the last slash; (3) you want to copy only a portion of the URL, either (a) just the host portion, or (b) just the file name portion; (4) you want to append text to the end of the URL; (5) you get the idea …

Chrome’s behavior is flawed for two fundamental reasons. First, it breaks consistency with the rest of the Macintosh interface. You may not think it’d be a big deal, but it’s upsetting—often on a subconscious level—when someone expects a widget to behave a certain way and it responds slightly differently. Second, Chrome’s custom URL field favors beginner users at the expense of all others. While an application that tells a new user, “hey, I made your life easier by assuming you meant to select the entire URL,” may be helpful to the novice, it’s hostile to experts—they already know how URLs and text fields work, and their actions are usually intentional.²

The infuriating thing about the inconsistency is the conflicting responses to bug reports filed by users who found the behavior undesirable: Google has said both that the standard interface behavior is correct and we will follow suit and that the current, non-standard behavior is better. This run-around response seems typical of Google, a company that has little experience providing technical support for end users.

Cupertino Kremlinology

In preparation to try my hand at Apple prognostication, the standard disclaimers apply: I have no inside information, I am engaging in idle speculation, and I am fully prepared to eat my words. Okay. Let’s get started.

I’m not interested in what unreleased hardware will look like, since it’s safe to say anything designed by Apple will be simple and breathtakingly beautiful (as usual), and will solve the associated design challenges with kick-you-in-the-pants obviousness.¹ The interesting question I keep coming back to is whether a tablet device will run the iPhone OS, and by extension, run iPhone apps.

First of all, since the rumored tablet would presumably have more in common with an iPhone than your mom’s MacBook—multitouch screen, accelerometer—it’s safe to say it would not be running Mac OS X. Apple has already created a mobile version of OS X—the iPhone OS. Furthermore, it’s clear that Apple has designed Cocoa Touch from the beginning to have enough headroom to grow into a device with a larger screen. (Which might explain why the SDK took so long.) Evidence of this includes the UIWindow class, which exists even though iPhone applications display only one window. I bet Cocoa Touch on the tablet will allow multi-windowed applications.

I would also wager that the device would be able to run existing iPhone apps without any trouble. I’m almost positive, however, that they won’t run full screen. App developers have spent too much time optimizing their UIs so widgets are relatively finger-sized. The interfaces simply won’t scale without usability problems.

Given that size is less of a constraint in a tablet device, I expect the hardware to be powerful enough to support multitasking. This, combined with the presumption that the tablet would run iPhone apps at their native size presents an interesting UI possibility. I envision a dashboard-like layer where a limited number iPhone apps run as widgets on the tablet.

Picture this: iPhone apps launch on a translucent layer where a pair of widgets run side-by-side on the screen. A simple swipe will switch between pages of running apps that don’t fit on the first screen—just like having multiple pages open in Mobile Safari. Capping the number of simultaneously running apps is as simple as limiting the number of pages in the widget layer.

Apple would be crazy to launch a device without the momentum of the App Store behind it, and the only way hit the ground running would be to let existing iPhone apps run on a tablet. In the end though, Apple has spent far more time thinking about these problems and refining the solutions than all of the armchair product-designers and rumormongers combined. I may be wildly off predicting the app switcher, but it’s a fairly safe bet that whatever we see next Wednesday will blow us away.

In the Cards

John Gruber responds to Justin Blanton’s To Pre or Not To Pre:

The entire user interface is built around the concept of cards rather than apps. So while the iPhone’s Mail app already stays running while in the background, what you cannot do on the iPhone but can on the Pre is have multiple email messages “open” at the same time.

There are a few things going on here. The SDK only displays a single 320 x 480 window per application. This is most likely some combination of a design decision (application switching happens through the depth axis) and an engineering decision (it’s easier to manage windows when an app gets only one of them). Developers, of course, are free to implement an interface like the ‘pages’ in Mobile Safari. (Ah-ha! The card metaphor has been on the iPhone since day one.)

So the decision not to implement pages in Mail has nothing to do with whether the iPhone OS supports cards or whether a developer is capable of displaying and switching between multiple open documents in any other way. My guess is that implementing pages in Mail was either considered too trivial or too confusing to implement.

The interesting thing is that views within an iPhone application belong to a window object. Currently, of course, an application can only display one of these, but I suspect it wouldn’t be too hard for the OS to allow multiple windows of an application to behave like cards.

Regarding iCal Usability

Marco, in a post about mediocre Apple software, complained that “Moving the ‘drawer’ event-editing interface into an annoying popup, [introduced] even more interface quirks and unnecessary clicks.”

The latest version of iCal made a few interface improvements, and the pop-up editor should be counted as one of them. Perhaps it’s time to do a usability tear-down. I won’t pretend to be unbiased, but I will try to back my points up with examples. For those of you following along at home, I’m comparing iCal version 2.0.5 to version 3.0.5 simply because those are the versions installed on my old laptop and new one.

The immediate differences are obvious, when side by side. Taking advantage of the new unified title bar and toolbar look in Leopard, the day/week/month segmented control and the search box have been moved to the window’s toolbar, where they’re more prominent. Also, the mini-month view has been redesigned, and the editing drawer has been replaced with a pop-up editor.

The redesign of the mini-month view was much needed. The new view is roomier and offers more information. It uses three-letter abbreviations for the weekdays instead of the cryptic initial letters. When the first and last weeks of the current month share days with the previous and next months, they are now shown, but in a much lighter gray. By grouping the previous and next arrows around the month label, their function is more intuitive. The confusing diamond button in the old month view has been replaced by a “Today” button in the toolbar. Overall, these improvements are subtle but worthwhile.

I found the editing drawer in version 2 problematic. I would frequently move the window to one side of my screen to transcribe info into new events, but the drawer would get hidden off the edge. So I’d usually just keep the damn thing closed. At least the drawer did the right thing (it would automatically open on the side of the window with enough room) when double-clicking calendar whitespace to add a new event. But double-clicking an existing event only selected the event name for editing. To edit the event, I had to either type Command – I or click the info button in the bottom right corner of the window.

In version 3, double-clicking an event will always bring up the info pop-up, and double-clicking whitespace in the calendar will create a new event and bring up the editing pop-up. I haven’t found the pop-up to be quirky at all. However, double-clicking the date portion of a square in month view will switch to view that day.

There is one major issue I still have with iCal. Its time zone support has sucked from day one, and I have never been able to get event times to stay consistent across time zones. It’s some sort of black magic or something, and I don’t have the time to figure it out. Overall, the under-the-hood issues with the software are more annoying than any interface quirks.