AlanHogan.com

Anticipatory UI for a better UX

Sat, 04 Feb 2012 01:35:08 -0500

Mint.com’s header changes based on whether or not anyone has logged in from that computer before.¹

On your first visit to the website, no login form is shown (but there is a prominent button labeled “Log in.”)

On return visits, you’ll be greeted with a login form, saving you a step.

I love this solution. It’s optimal in a way most users will never notice. (Note nothing is even rearranged, so muscle memory is preserved, even if the relevant cookie is missing.) It reduces both clicks & clutter, in different situations — without taking away any functionality whatsoever.

In what other cases can we anticipate user actions and optimize accordingly?

Technically, they approximate this with cookies, any web developer would expect. ↩

Inspiring Vision in a UX Role

Sat, 04 Feb 2012 01:06:37 -0500

The most inspiring thing a person can do is to work hard on problems they care about that align with what the team cares about, share that work with others, gracefully take feedback, and continually produce.

— Emily Cunningham’s notes from Q&A after Scott Berkun’s talk

Hello, SF!

Sat, 10 Dec 2011 20:12:26 -0500

I’m pleased to announce that I have moved to San Francisco, California; from Phoenix, where I spent the last five and a half years.

I’ve been here before. Most recently, for Startup School (in association with Y Combinator and Bases) and related events — technically in Mountain View, Stanford, and Palo Alto. Before that, Sean and myself went to Pitch and Disrupt SF to network and show off Blogic, and I had the pleasure of attending a Designers and Geeks event at Square. And my very first SF visits were with the Simperium guys, whom I thank for that opportunity.

I drove here late last week in a “comically large” Budget truck that broke down 30 miles before Coachella, and have spent the last week crashing with friends, whom I thank for their generosity.

I have joined the iDoneThis team doing contracted front-end web development. It’s always great to get to work on a tool that I had actually used and enjoyed beforehand (as it was with Simplenote).

I’m loving the city so far, aside from the challenge of finding a good place to live — and even that is kind of fun, really. Maddening, but interesting. (Let me know if you have a room or studio to fill.)

I’m very excited to be in a city full of friends both old and new. I look forward to meeting more of the designer & developer community, as much as I’ll miss my Phoenician friends (and Pennsylvanian pals, for that matter).

Hope to see you around.

Facebook Has Gone Too Far.

Sat, 10 Dec 2011 20:07:34 -0500

I don’t really follow Facebook terribly closely, but recently, they enabled some sort of terrible, insidious API for “publishers.”

The end result is that I see an interesting article in my Facebook news feed. “Cool,” I think. “I would like to read that.”

Click.

And it opens this awful modal dialog.

(fallback)

Uh… well, no thanks, I would rather not have everything I read automatically and publicly logged on Facebook.

Click “Cancel.”

The dialog closes. And that’s it. No article opens.

Then I realize something. Facebook is actively breaking the fundamentals of the Web. The “link” I clicked in my news feed would seem to be a textbook example of a hyperlink: Blue, underlined words describing a page on another website that I should be able to click and read. Or right-click and open in a new window, or maybe long-tap on a phone and copy the URL of… but no. No, that “URL” isn’t foreign; it’s a link to a Facebook.com page requiring me to grant unacceptable permissions to an “app” before, you know, reading the other side of the original pseudo-link.

It’s shameful. Broken. Even evil.

Facebook ought to be ashamed.

Yahoo ought to be ashamed, too. And they should know that I never ended up reading the article I saw in my timeline. Just as well. Yahoo is a bad web citizen; yahoo.com news stories from as little as two years ago (and maybe less!) now result in 404 file-not-found links. Those items are gone. It means swaths of blogs and sites have broken links, that sources and references are now unverifiable. It’s not just the news: Perhaps both more and less understandably, Yahoo removed whole neighborhoods of content when they took GeoCities completely offline, too. The Web isn’t supposed to be taken so cavalierly.

End result: I will be finding less content via Facebook, and reading less on Yahoo. It’s just as well.

RIP.

Thu, 06 Oct 2011 00:13:21 -0400

Steve put so much of himself into Apple, it’s really no wonder we tend to conflate the two.

But we should not forget that Steve was more than Apple. He was a man unsure of his future.

Unsure, but hungry for knowledge. Eager to think. Striving for greatness.

Steve, you’re gone. But I congratulate you for putting a ding in the universe.

Updates for my Lion Mail.app post

Thu, 28 Jul 2011 00:05:35 -0400

I have made updates to my Lion Mail.app vs. Sparrow article thanks to tips readers have sent me (thank you!).

For anyone subscribed to my RSS feed, here are the changes:

I added a footnote regarding Priority Inbox simulation.

Erik Hansen has helpfully written up a tutorial showing how to create an inbox view that only shows unread or flagged/starred items. I am not yet aware of any hacks that take advantage of Gmail’s automatic “Priority” filtering feature, but haven’t really looked into it.
I noted a Mail.app negative.

By default, sent and other (e.g. archived) messages are not always shown with received messages in the preview pane’s thread/conversation view. You can pull them in using the Show/Hide Related Messages button:

You can also change this default to automatically include all related messages, in Preferences.
I added a tip to make drafts sync to the actual Gmail drafts folder.
For each Gmail account you want to change this behavior for:
1. Navigate to the [Gmail]/Drafts folder
2. In the top menu bar: Mailbox › Use This Mailbox For › Drafts.

OS X Lion's Mail.app vs. Sparrow

Thu, 21 Jul 2011 16:16:10 -0400

A Review & Comparison with Sparrow

Just over a month ago, I reviewed Sparrow, a new Gmail- and Twitter-inspired mail app for OS X.

I had a number of complaints, but also a fair amount of praise, for it. Most of the positives were in comparison with Apple’s own email client, called Mail, or Mail.app for clarity.

But since then, Apple has released a major update to OS X — namely, version 10.7 Lion. And Mail.app¹ has been given quite a makeover.

So now the question is, what advantages does Sparrow retain over Mail.app? Are Sparrow’s negatives present in Mail.app as well, or do they afflict solely Sparrow?

Let’s go through them one-by-one.

Sparrow vs. Lion Mail.app

Former positive: Sparrow felt less cumbersome than Mail. It’s debatable if this is still true, given Mail’s new three-pane layout and unified inbox. It seems to me that Mail makes better use of Fitts’ Law, with more clickable targets; it is also more intuitive, but less visually “fun”.
Irrelevant: Both Sparrow and Mail.app allow me to jump between tasks/views more quickly than the Gmail web app.
Former advantage: Mail.app has gained a unified Inbox, like iOS (and Sparrow). All your accounts’ emails can be shown in one commingled inbox, and you can view any inbox independently at any time.
Sparrow negative: No undo for archiving. Mail.app gets it right.²
Sparrow negative: Incessant right-pane content reloads — not a complaint shared by Mail.app.
Sparrow negative: Hard to figure out how to view “all mail”. Much more intuitive in Mail.app.
Sparrow negative: Hides all quoted text, even if you have never seen it before (e.g. in a forwarded message) — Mail gets it right, like Gmail’s web app (and has a beautiful animation for expanding quoted text, in the less likely event you even want to show it).
Sparrow negative: No option to limit alerts to only “priority inbox” items. I haven’t tried this, but I am fairly sure this could be done in Mail, as a rule could be set up to play a sound only for messages in the Priority Inbox folder or tag, if exposed over IMAP. But it wouldn’t be totally straightforward, so this negative half-way applies to Mail, which at least has rules, unlike Sparrow.
Sparrow negative: Bad UX when sending mail fails. Mail.app actually has two options: Suggest other outgoing mail servers (can be useful if you are traveling), or silently keep trying to re-send. Both are better than demoting the outgoing item back to Drafts!
Sparrow negative: Can’t view full headers. Mail.app even has an optional toolbar button for this.
Sparrow negative: Terrible search. Mail.app’s is much better, even supporting some Gmail-style search strings such as from:bob picnic, which would only return messages from someone named “Bob” and containing the phrase “picnic.”
Shared negative: No super simple way to view only unread items in the inbox. In Sparrow, it’s a trip to Advanced Preferences. In Mail.app, you can create a “smart mailbox” showing only unread items in “Inbox” to create an analogous view.³

That said, Mail.app still has a few potential drawbacks of its own:

By default, Drafts sync back to the server in a label called [Imap]/Drafts instead of the Gmail drafts folder.⁴

However, the fix for this is fairly simple. For each Gmail account you want to change this behavior for:
1. Navigate to the [Gmail]/Drafts folder
2. In the top menu bar: Mailbox › Use This Mailbox For › Drafts.
You can also do this for the Sent Mail folder.
No real support for “Priority Inbox”. This is unsurprising considering that Mail, unlike Sparrow, is not supposed to be very Gmail-centric, or that Mail.app has a much longer development cycle than Sparrow.⁵
By default, no toolbar button or hotkey shortcut for archiving messages. Both of these shortcomings are easily remedied, though! Right-click the toolbar to customize it. System Preferences’ Keyboard pane (Keyboard Shortcuts tab, then “Application Shortcuts”) allows you to set a custom shortcut for archiving. (I set mine to ⌘-Y.)
By default, sent and other (e.g. archived) messages are not always shown with received messages in the preview pane’s thread/conversation view. You can pull them in using the Show/Hide Related Messages button:

You can also change this default to automatically include all related messages, in Preferences.

Awarding the Olive Leaf Crown

Lion only came out yesterday, but so far, I’m absolutely loving the new Mail.app. I’m going to keep using it exclusively (over Sparrow) unless I find some gargantuan annoyance that Sparrow solves. Given the number of negatives solely in Sparrow’s court, I do not expect this to happen any time soon.

Three cheers for the best Mail.app yet!

Along with a number of other apps included in OS X, such as Address Book and iCal. Siracusa on those apps’ changes ↩
I initially mis-reported this as a Mail failing, and was corrected by Antonio; my subsequent experiments confirmed this. I am not sure how I missed this at first. ↩
Thanks to Antonio Salazar Cardozo for mentioning this. ↩
Thanks to Antonio for this correction as well; I had initially reported that it seems drafts did not sync to the server at all. And a hearty thank-you to Scott Cook and Tim Lukian for pointing out the fix! Here’s a screenshot of the Drafts folder, expanded to show each properly set-up sub-account:
↩
That said, you could probably build some sort of approximation of Priority Inbox using Mail.app rules and/or smart mailboxes. For example, Erik Hansen has helpfully written up a tutorial showing how to create an inbox view that only shows unread or flagged/starred items. I am not yet aware of any hacks that take advantage of Gmail’s automatic “Priority” filtering feature, but haven’t really looked into it. ↩

A Brief Review of Sparrow Mail

Wed, 15 Jun 2011 16:28:45 -0400

I have been using Sparrow (@SparrowMailApp on Twitter) as my primary desktop mail client for a month now. I like it, but I have a lot of complaints, too. If you’re considering switching, I hope you find this quick review of use.

Update: OS X Lion is out, and I really like its updated Mail app.

The Good

Sparrow is a welcome new option to the OS X mail app landscape. It borrows some interface stylings from Tweetie, the seminal OS X Twitter client eventually purchased by Twitter, Inc.; the end result is that Sparrow feels less cumbersome than the current Mail.app that ships with OS X (as of this writing, that means 10.6 Snow Leopard). [Updated comparison here, now that 10.7 Lion is out.] Sparrow is mostly a one-window deal, and it holds hands with Gmail quite nicely, with native support for starring, labels, and even many of Gmail’s keyboard shortcuts.

Sparrow lets you move around a bit more quickly than Gmail, which still prevents you from going back to your inbox before your current draft finishes sending or saving (after all these years!). This is an expected benefit of any native email app, but Sparrow doesn’t disappoint here; this is a big part of why I use it instead of Gmail.

Another great thing about Sparrow is its unified inbox, showing mail from all your accounts in one view. (I don’t love how it is then tricky to see which account actually received the email as you are replying, but in some sense, this could be considered a success of this feature.) The convenience of having one inbox is what keeps Sean on Sparrow.¹

The Bad

Sparrow can be quite annoying at times, particularly in its current limitations.

You can’t undo actions like archiving. (Good luck figuring out which message you accidentally archived!)
Sparrow refreshes the whole right pane screen up to three times while sending a reply (very distracting, and puzzling as to why, technically, this is necessary).
It took me a month to figure out how to view “All Mail.” (Use the tag icon at the bottom of the window.)
Sparrow hides all quoted text by default, even text you have never seen before. Consider a forwarded email: You only see the forwarded text, and a tiny, non-underlined, easy-to-ignore “show all text” link at the bottom. Sometimes this occurs within a threaded conversation, all but guaranteeing you’re going to miss something that someone thought important enough to clue you in to. Gmail never makes this mistake!
There is no option to only sound the incoming-mail alert for “priority inbox” items.
If your Internet connection is spotty or overloaded and Sparrow’s initial attempt to send a message fails, it doesn’t go to an “outbox” to retry periodically; it just never sends (and reverts back to a draft for you to manually retry).
You can’t disable the unread count badge on the dock icon, which I consider stressful and unwanted.
You can’t view an email’s source or its full headers.
Sometimes the search feature just fails to find messages that are in your account (going to Gmail’s web interface and searching will find the email).² And message search doesn’t allow any of those great Gmail search operators.
You have to go into Advanced Preferences before being allowed to view a list of unread messages (or priority inbox).

Conclusion

My list of complaints is long. And yet, I find Sparrow the most convenient option I currently have for working with email. [Update: No longer the case.] I’m going to keep using it and keep hoping for meaningful, regular updates.

I’m not sure these guys’ priorities are straight: the last update added Facebook integration to pull avatars (and to spam your Facebook wall with an ad for Sparrow unless you actively opted out). To be fair, it also added the unified inbox, which was a welcome feature. I can’t be alone in preferring to see my list of gripes shrink than to see a few more friends’ faces in my email.

If you want a very Gmail and Tweetie-like native mail client, you can check Sparrow out in the Mac App Store, or download the free trial from the Sparrow website. It’s probably worth a spin.

In a sense, this keeps my desktop and iPhone email situation fairly close in terms of the the contents of my main email view. Thanks to Sean for mentioning this feature while reviewing a draft of this review. ↩
It also doesn’t seem to support Gmail’s search operators (like label:Work). Thanks to Sean, again, for reminding me of search’s weakness. ↩

URL as UI

Wed, 15 Jun 2011 13:35:00 -0400

URLs are part of your user interface.¹

Your web app’s user interface has three major components:

Your HTML (GUI) — the pages themselves and their behavior.
Your API — used by developers (internally and/or externally).
Your URLs.

Everyone knows URLs are important and shouldn’t change. But there is more to the concept of URL as UI than that.

The perfect URL

To help imagine what the perfect user interface expressed through URL design would look like, imagine that you can’t use your HTML UI for navigation. How would you get to the page you are looking for?

An ideal URL is guessable.

Synonyms should ideally redirect. If you have a support page at /support and a user types /help, is that really such a bad request? Don’t show them a 404 — send them to the page they’re looking for!

An ideal URL uses honest hierarchy.

If your URL’s path includes a slash — like example.com/widgets/674 — then truncating everything after any slash in the path² should result in a useful page, not an error.

In this case, example.com/widgets should probably list widgets and/or allow the user to create their own new widget, even if that means redirecting to /widgets/new.

If that’s not possible, either explain why on the page or consider removing your false façade of hierarchy. For example, the previously mentioned URL could be re-written as example.com/widget-674.

An ideal URL doesn’t include a filetype extension.

This applies only to actual pages, not media like CSS, JavaScript, images, or audio.

Forcing the user to type .html or .php is bad for at least three reasons:

It’s extra typing and length, which is inherently bad.
It requires the user to know what powers your site to use your URL as a user interface.³
It makes your URLs more likely to change if your site technology does.

An ideal URL doesn’t care if your URL includes a trailing slash.

Pick either /foo or /foo/ and redirect users to the canonical page.⁴

Obviously, omitting the trailing slash means shorter URLs, which is always good.

An ideal URL is similar to URLs on other websites.

Plenty of websites use the URLs /login and /logout, so a URL like /create or /session/destroy is a hell of a lot less guessable — inherently, yes, but also because it’s not expected.

Just like you put your site search widget in the top-right of your page and links to your TOS in the page footer because everyone else does, your URLs should be similar to others’ as well. One of my favorite Nielsen quotes: “Your visitors spend most of their time on other sites.” This should influence all the aspects of your app’s UI design, not just its GUI.

An ideal URL is the same on every device.

Jane goes to your website on her iPhone and tweets a link to one of your pages. John clicks her link on his desktop computer. Should he see a mobile version of the website? No.⁵

Gracefully handle 404s.

Since you would never simply delete a URL (right?), you have to anticipate that many, if not most, of your (human-triggered) 404s are failed attempts to navigate your site via that third user interface, your URL. What can you do to help you user out? Consider linking to your home page and/or site map — or showing a directory of major sections. (Apple is great at this.) You can also pre-populate a site search field with terms extracted from the errant URL, an approach I take here at alanhogan.com.

Inspiration

To see what excellent URLs look like in practice, consider these examples.

Synonym redirection.

Visit http://apple.com/finalcut and you’re automatically redirected to http://www.apple.com/finalcutstudio/.
Subdomain & path interchangeability.

Google wisely redirects http://google.com/docs to http://docs.google.com. It hasn’t always been like this, which is (to me) a fantastic sign because it means someone at Google cared enough about the concept of URL as user interface to eventually set up this redirection.
Cross-domain kindness.

For technical reasons, Simplenote’s web editor runs at https://simple-note.appspot.com but the canonical product site is at http://simplenoteapp.com.

This meant that the “Downloads” link at the bottom of the editor, for example, sends users to the other domain. This works fine in “UI #1,” the HTML GUI — but from a URL-as-UI perspective, it stinks because a user who appends “downloads” to the current URL in the web editor would be served a 404 page. Until recently. Now such requests automatically redirected across the editor domain to the product site. And why not? We know exactly what the user wants.
Context-aware 404s.

Apple has a wonderfully specific error page for 404s that occur in their Final Cut section: http://www.apple.com/finalcutstudio/x asks the user, “Looking for something on the Pro Apps site?” and lists products in the suite.
Improving unituitive URLs.

I keep using Google as an example, but URL design is something they both struggle with and seem to improve at, over time. Consider their translation service. It used to be the unintuitive http://google.com/translate_t (don’t ask what the _t meant). I don’t think http://google.com/translate even worked. Now, however the service lives at the much more memorable and guessable http://translate.google.com. Thankfully, they avoided breaking links by redirecting from the old URL, and they maintained guessability by making /translate redirect to the subdomain as well. Huzzah!

Room for Improvement

Let’s take a look at some less than perfect examples:

Not anticipating the company.com/major-functionality pattern.

http://google.com/spreadsheets results in a 404 File Not Found error.⁶

Is an obnoxious, cute, unhelpful page really the answer here, when a user is clearly requesting the spreadsheet functionality of Google Docs?

Google Docs’ spreadsheet functionality is apparently not considered a product itself but it’s not smart to make the URLs reflect this arbitrary and elusive definition. After all, the Big Competitor here — Excel — is not the same product as Microsoft Word, is it? Microsoft handles http://microsoft.com/excel with an appropriate Excel-specific redirection. As an underdog competitor here, Google should expect end users to have the Office family of discrete products (Word, Excel, …) as the basis for their mental model of Google Docs.
Not anticipating the company.com/product-nickname pattern.

http://www.apple.com/osx results in a generic 404.⁷

It ought to redirect to http://www.apple.com/macosx/.

(At least a link to that page is provided on the 404 page!)
Not getting mobile URLs right.

In a classic presentation, Rob Manson noted an Australian company whose main website is at http://quantas.com.au, but whose iPhone website was at http://quantas.com/mobile. Note the sudden disappearance of the “.au” from that domain.

While it’s bad enough to segregate URLs into mobile and non-mobile versions (in most cases), doing so in completely counter-intuitive fashion is a tragedy — especially if you aren’t doing automatic redirection!
Not registering domains & subdomains for your product, or disregarding common use-cases.

Adobe provides us an interesting case to consider. Imagine someone guessing at a URL from which they could download the latest version of the Flash player. (Hey, it’s important — apparently 50% of the Mac’s security problems — and a definite majority of browser crashes! — are due to Flash bugs.) How do they fare?
- http://adobe.flash.com is almost great: It redirects to a software download page with a link to download Flash Player, but it’s surrounded by tons of products that have nothing to do with Flash.
- Interestingly http://flash.com is aimed at developers and attempts to sell the visitor on the “Adobe Flash Platform”.
- http://adobeflash.com is a kind of third-party site. I wonder how Adobe let that happen. I’d guess they haven’t made too big a fuss because the site, though it feels kind of spammy, does offer free resources for Flash developers.
- http://adobe.com/flash redirects to Flash Professional, the Flash-creation product part of Creative Suite. No, this is not the same thing as the Flash Platform at flash.com.
I was initially impressed with http://adobe.flash.com actually being relevant to the #1 reason people would want to do something having to do with the words “Adobe” and “Flash”, but altogether I’m not impressed:
- Why are all four of the above URLs redirecting to completely different pages?
- Why aren’t any of the above four URLs going to a page whose primary purpose is to let people download Flash Player? (Expecting normal people to call it Flash Player instead of Flash is hopelessly naïve!)
- Why is there an assumption that it’s more common, responsible, and/or profitable for people to need to buy Flash than to download the latest player? After all — someone having a bit of difficulty updating Flash Player is more likely to abandon the process than a professional trying to purchase Flash Professional… and Player releases come out much more often than the newest version of Creative Suite does… and way more people have Flash Player than Flash Professional.
The harder it is to get a legit Flash player update, the more likely people are to be tricked into downloading a spyware/Trojan “codec” from that porn/warez/squatter site. One could then argue that Adobe’s URL failings here are unethical, or at least negligent!

Caveat

Users are trained to navigate primarily through the HTML GUI.

Still, power users, keyboard aficionados, and those with good memories (especially) sometimes navigate via URL.

For me, URL as UI feels important, but taking it as seriously as I try to may not be necessary in many cases. Yet as your site becomes more popular, the potential to turn more 404s into successful uses of our most neglected user interface grows. I encourage you to take advantage of that opportunity.

It’s not a new idea, but it’s not universally adopted or always perfectly executed. See the Room for Improvement section. ↩
Including the slash itself, or not. ↩
I have heard that exposing your site tech can make you slightly more vulnerable to hacking, as an attacker can use known vulnerabilities in your technology stack against you. Still, you’re just as likely to leak this info via your X-Powered-By HTTP header, error pages, markup, or one of a myriad of other ways. ↩
Or support both /foo and /foo/ without redirection — but for SEO purposes, you should then probably use rel-canonical to indicate the preferred URL. ↩
There is not really a consensus that the m.example.com domain pattern is inherently bad. But you must really nail the implementation, or there will be problems like the one I mention. ↩
As of June 15, 2011. Hopefully this will change at some point in the future. Here is a screen shot of Google’s worthless 404 at this URL. For a comparison, note that currently http://microsoft.com/spreadsheets yields a helpful 404 that includes search results — this first of which is a link to Excel (screen shot). Success! ↩
As of WWDC 2011, Apple changed the name of their desktop operating system from “Mac OS X” to “OS X” (ahead of the release of OS X 10.7 Lion). I expect their URL situation to update to match this situation, soon. ↩

Tab and Indenting in Textarea Elements

Mon, 04 Apr 2011 18:24:34 -0400

The classic problem of not being able to indent or outdent text in textarea elements on the Web has been solved by Ted Devito. That’s right, you can now use the Tab and Shift+Tab keys to indent any number of lines, in plain old textareas.

Developers: Use Tabby, a jQuery plugin.

Everybody: Tabby is a available as a bookmarklet. One click, and the free-form text entry controls on most any website should now bow to your tab-related desires.