Alex Metcalf

BBC website promoting their advertising:

Well, I guess they’re reaching the millions who can use Flash and don’t block it.

You know. Those millions.

I feel bathed in the inclusivity of their approach.

Following from my last post about the iTunes store, I appear to be on a roll here. Here’s how you can give the iTunes store’s search results a makeover.

Here’s the current store search results page (click to embiggen) for ‘TomTom’, where inexplicably the app search results aren’t at the top – even when you search from an app store page:

And my mockup (click to embiggen):

Again, purposely an evolution rather than a revolution. There are some really creative ways you could take these search results even further, given the huge amount of store content you have to sift through.

An iTunes thread on Ars Technica inspired me to give the iTunes store a user experience spring clean – specifically, browsing TV shows.

Here’s the US store’s current presentation of Curb Your Enthusiasm, Season 1 (click to embiggen):

It’s crowded. Information is duplicated, such as the main season picture, the show title and season number, and many little details like “Genre: Comedy” (we’re, uh, in the Comedy section).

The episode list feels like a wall of text, unbalanced in density between name and descriptions, and doesn’t encourage you to browse and engage. And I’ve really tried hard to think of a reason why anyone would want to sort the episodes by time – the need for a column format is questionable, not helped by the column widths not being resizable.

Finally, it has some carry-through annoyances from the rest of the store, such as the incomplete breadcrumb trail – of course, that reflects a bigger structural issue.

So here’s my version, purposely an evolution rather than revolution (click to embiggen):

Notable changes:

• Episodes are visually larger with more implicit structure, and include full descriptions, a video frame, subtler presentation of metadata (time, episode number, etc.), and a clearer visual cue to try the preview.
• The breadcrumb trail is more complete – although Apple needs to make some additional landing pages in the site structure to fix the real issue. (An overview page for all ‘Curb Your Enthusiasm’ seasons is one example.)
• Lots of unnecessary wordage is removed. Customer reviews take half the space. Other seasons don’t mention ‘Curb Your Enthusiasm’ over and over. And I think most people understand the description without a big fat ‘Description’ heading (although there are good accessibility reasons for a heading).

I may work up a ‘revolutionary’ example. My mockup is mostly window dressing, apart from the experimentation with episode display.

The biggest problem with iTunes is this: it uses a relatively inflexible display approach for all its content – movies, podcasts, music, (soon) books, and so forth – and it’s really starting to creak and groan under the strain. Such diverse content types need tailored presentation to be fully engaging and successful.

(As an aside, remind me next time not to Photoshop up an example that uses a mottled blue background. That caused me seven levels of pain.)

So I wrote “yo ho ho and a bottle of rum”, and Inkwell’s (OS X) handwriting recognition translated it as “Go hobo and a bottle of rum”. An interesting social comment, but not quite what I was after.

I’m on a one-man mission to make a better browser window. Too much vertical space is wasted with bookmarks, fat tabs, and empty title bars. I want to browse!

I’ve updated my original Safari mockup to now have a shorter status bar at the bottom, expanding only to show relevant information (in this case, a tick mark to show the page is loaded).

Come on developers, use the vertical space better!

Bookmarking in the latest beta of Google Chrome is confusing. Here’s why, and how to fix it.

Here’s what happens when you click the ‘Star’ button in Google Chrome. You get the following ‘dialog’ (or panel or whatever):

As you can see, the bookmark is already created, and we’re given the chance to edit the bookmark’s name and the folder it goes in.

The problem here is that the completed step of creating a bookmark with default information (“step 1″), and the incomplete step of editing that bookmark (“step 2″), are being merged together, and a single dialog is being used to cover both. It feels like a nod to how bookmarking has always been done, without understanding the effect of the changes to the task flow.

Dialogs are designed to give the user control over one clearly defined step. “You’d like to save something… okay, give me the details in this dialog, and then click ‘Save’ to complete the saving process.” The buttons across the bottom of a dialog almost always perform some action based on the fields and options in that dialog.

Safari takes a similar approach to bookmarking. “You’d like to bookmark this page, because you’ve chosen ‘Add Bookmark…’. Okay, confirm the bookmark name, then click ‘Add’ to complete the bookmarking process.” It effectively reverses and combines the steps of Chrome: rather than editing the bookmark after creating it, you make sure the details you use to create it are correct. Whatever the merit of this approach to the task (i.e. asking you to confirm the bookmark creation), it’s incredibly intuitive in how it’s executed.

Chrome still gives you a single dialog box, but uses it to give options affecting one completed step and one incomplete step: mistake one. The buttons on the bottom of the dialog affect different stages, with one button (Remove) having nothing to do with the fields and options in the dialog. (As an aside, there is also no button to cancel unwanted edits made in Stage 2.)

The purest solution to mistake one is to use a UI element or approach that could separate the following:

1. I have automatically created a bookmark based on your click of the star, but you can delete it if you want.

2. You can optionally choose to edit the details of that bookmark I’ve created.

Chrome also uses some inaccurate button names: mistake two. ‘Remove’ is actually an undo for Step 1. ‘Close’ is actually a save/apply/whatever for Step 2. ‘Edit…’ is… just plain weird.

Firefox’s approach is a half way fix. It uses slightly better buttons and wording to avoid being as confusing as Chrome, so it avoids most of mistake two. However, parts of mistake one are there too: it proudly says “Page Bookmarked”, with options in that dialog to then edit the details. “Cancel”, however, should really cancel any changes to the edits (the focus of the dialog), not delete the bookmark. They kinda get away with it.

And the ideal? It depends on how people bookmark, which I can’t judge other than my own habits. I don’t think confirming the creation of a bookmark is a huge deal. It’s not like we’re doing it excessively on the critical path of using our computers.

I’m sure an elegant solution can be found: it’s just not Chrome’s current one.

Some (techy) audiences have been clamouring for the iPad to support multitasking: more than one app running at the same time.

Despite the naysayers, it’s hard to argue with the ability to listen to your favourite internet radio (Pandora) when using iWork, or continuously chatting with your friend (Beejive) whilst web browsing.

Here’s how Apple could implement it.

A ready-made, mostly-permanent ‘dock’ for indicating and accessing background apps is already available: the status bar.

Background apps would need to have:

• Resolution support for less than the whole iPad screen (to visually separate them from the foreground app, as in the mockup below);
• An in-app button with Apple-dictated OS-wide terminology (background / minimize / whatever), to background it.

When the user is in a background-supported app and clicks the in-app button (say ‘minimize’), the app could minimize itself into an icon in the status bar, returning the user to the springboard. The app continues to run, but can be recalled at any point by touching its icon in the status bar or in the springboard.

As in the screenshot below, the focus on the recalled app could be enhanced by dimming the foreground app. Some form of front panel would be ideal.

(Used Beejive as an example app)

I have used red/yellow buttons for closing/re-minimising the app; however this is an OS X Desktop concept, used by me only to show ’something’ is feasible here. iPhone OS-style named buttons could equally be used (with agreed terminology).

So with this approach to background apps:

• A user maintains full control over which apps are backgrounded;
• A user can clearly see at all times which apps are backgrounded, and access them / close them easily if necessary;
• Multiple apps can be supported;
• No dramatically different app/task manager concept is needed.

I don’t think Apple will be doing free-for-all multitasking any time soon. However, it won’t be because it’s hard to implement.