When consumers have a great user experience, they don’t notice. They don’t wonder how you designed the product so well. They just use it and move on, but that’s a good thing. They shouldn’t feel bad while using your product. Don’t make users feel bad because eventually they’ll choose a better user experience as a coping mechanism.

User experience: Because your users internalize your product’s failures.

Today, I checked the numbers in iTunes Connect for Dollar Clock. At first, I only looked at the total downloads, in the left graph, where the hash mark notes the header change. Clearly, the header change increased the downloads. Then I looked at the purchases and updates separately, in the right graph, and the pattern was less clear. During the week after the header change (the bar after the hash mark), more of the downloads were updates, not purchases.

During the same week I changed the header, Dollar Clock 2.0 was posted to the App Store, and many people downloaded the update that week. The total downloads indicates my header change had a significant effect, but the breakdown reveals confounding variables. Perhaps if I had more variables, I would find that the header change had absolutely no effect.

Or maybe I just wanted an excuse to use Tufte’s small multiples.

Tracking Changes

I’m using git and GitHub, but any scm would be fine. I’ll run through the steps here. (Keep in mind I use WordPress’s update system for version and plugin updates; I just want to track my own changes.)

1. Removed unused themes and plugins to reduce installation size to 25MB (du -h)
2. Created a private repo on GitHub
3. Setup git in blog’s root directory on DreamHost:

   git init
   # Didn't bother ignoring any files.
   git add .
   git commit -m "current state of blog"
   git remote add origin git@github.com:username/myblog.git
   git push origin master
   

4. Edited the CSS file using WordPress’s editor then listed the changes (git status) and diff’d the changed file using git (git diff style.css)
5. Decided my edits didn’t look good on the live blog and reverted them (git checkout style.css or git reset HEAD --hard)
6. Ran mysqldump then gzip on the blog db and added it to git also
7. Updated .htaccess to hide the new .git directory (DreamHost): RedirectMatch 403 /\..*$

Seeing the changed files in git is fantastic, and at this point, I wonder how I got by for so long without versioning my WordPress changes. But tracking changes isn’t enough.

Staging Changes

Now, I can easily revert horrible template changes, but anyone hitting the blog during that time will still see it. It reminds me of how the early Facebook team used to directly edit the HTML on the production site when they were adding features. Debugging changes on a live site is annoying and unnecessary. Instead, just use a subdomain. Here are my steps:

1. Created a subdomain on DreamHost for the staging area and assigned it a private IP/enabled SSL (I require SSL for administration)
2. Pulled the current repo in that new subdomain’s root directory on DreamHost:

   git init
   git remote add origin git@github.com:username/myblog.git
   git pull origin master
   

3. Pointed this instance of WordPress to the new subdomain by adding WP_HOME and WP_SITEURL in /wp-config.php according to WordPress’s “Changing The Site URL” page (I want to use the same database so I didn’t change those entries)
4. Waited a couple hours while the DNS changes propagated for the new subdomain
5. Logged into WordPress on the subdomain and changed a couple lines of CSS
6. Checked out the result on the subdomain and committed it to GitHub
7. Pushed the commit to GitHub and pulled it down in the live blog
8. Verified the change on the live blog

Staging changes is so much more comforting. Before, I wondered how many visitors hit my site mid-change (which sometimes took hours) and left annoyed. At least now I can think, “Actually, I designed it that way intentionally…”

Whenever I encounter a strange error message or a similar roadblock while programming, I google for answers. This approach leads to a wide array of websites, almost all blogs. (In fact, most of this site’s traffic comes from Google, presumably from the same approach.) As soon as I get to the site, I want to quickly assess the post’s relevance and my level of trust. If the site is interesting and useful, I’ll trust it more if I come across answers on it again…if I recognize it. When I designed this blog, I tried to add these same breadcrumbs that I look for when I google: relevance, recognition, and trust.

Relevance

When I click on a Google link, I want to figure out as quickly as possible if the page is relevant. So I look around for a date, an author, tags, and a comment count.

I expect the date to be embedded in the URL, but unfortunately, WordPress’s default permalink format is arcane: http://www.bdunagan.com/?p=123. The URL format is displayed to every single visitor, and yet, all this conveys is how many times I’ve posted before this. It’s a sad default when the very next option conveys both timestamp and title: http://www.bdunagan.com/2009/11/05/sample-post/. The visitor can quickly glance at the URL and instantly know the post’s age and topic. The default permalink format is really an indication of the blog creator’s laziness.

The URL is easy. One step further is the post’s meta information. I want to know the author (for a site like TUAW), tags, number of comments, and frankly, the date again (as I might be looking at the homepage where the date isn’t in the URL). All that information gives me a better idea of whether or not the post is relevant to my goals. Including that information next to the title makes sense. However, the default WordPress theme hides this information, shown above, at the bottom of the post instead of next to the title and above the fold. Worse yet, comments follow that section, so I can’t easily page-down to the bottom of the screen, as it might be tucked away in the middle.

Recognition

The default theme for WordPress is Michael Heilemann’s Kubrick. It’s a fine theme, but far too many authors stay with it, making it difficult for new visitors to trust the site and for repeat visitors to recognize the site. (Moreover, many spam blogs use this theme as well, making sites using it more difficult to trust.) Selecting an alternate theme is ridiculously easy; just go to the admin section, click Appearance, find a theme, and click “Activate”. WordPress is nicely architected such that nothing more is required. And with the large number of free, built-in themes, selecting a relatively unique one is no problem. Many insert the post’s meta information near the title, rather than at the post’s end. Creating an identifiable site helps visitors recognize you. Going with Kubrick is just lazy.

Trust

A new visitor to this site has no idea who I am. No trust at all. The only thing going for the site is the fact that it showed up in Google as possibly relevant to the visitor’s goal. In addition to the content, I put a quick description of myself at the bottom. I put links to Twitter, LinkedIn, and Flickr. Each represents a one-click path for the visitor to find out a bit about me. No guarantee it will be interesting, but it does establish I’m a real person who writes Mac software. I want to establish a modicum of trust with the visitor. It’ll help the next time the visitor comes to the site and recognizes it.

Matt Gemmell’s blog redesign is a great example of this trust in action. I visited his site yesterday but immediately thought I’d clicked on the wrong link; the theme was completely different. Instead of the graphic-rich white-on-black theme I was accustomed to, the site was text-rich black-on-white with lots of white space. I went over to Instintive Code to see if I’d mistakenly gone to Gemmell’s other blog. Nope, no work blog. So I went to the blog’s index page and saw the title “Accessible Blog Redesign”. Ah, a redesign. Still, there was a brief period when I didn’t trust the page I landed on; it wasn’t the one I built my trust on.

To drive home the importance of breadcrumbs for trust, visit Clay Shirky’s blog. Shirky is an impressive speaker and a great writer. When I read a tweet last spring about his sharp critique on the demise of newspapers, I immediately clicked through to the blog post. But I landed on a standard WordPress site with the default Kubrick theme. Weird, seemed like a guy as aware as Shirky would do something a bit more creative. I looked back through the blog’s history. Hmm, created a month ago with only three posts so far. More weird. The blog came from Shirky’s domain, but it had no links back to the homepage. And, Shirky’s homepage didn’t have any links to the blog. At this point, I’m very skeptical about the blog. I actually googled around to make sure other authoritative people linked to the blog articles, which they did. Now, nine months on, the blog still only has six posts and no links. I still find it weird. So many missing breadcrumbs.

Iterate

Ironically, in writing this blog post, I noticed that my single posts didn’t include the number of comments up at the top like the main index does. Fixed that. And I added a nice favicon from Glyphish. Iterate, iterate, iterate.

A year ago, when I first implemented it, I was averse to adding a secret preferences window, because I couldn’t think of a natural place for accessing it. Instead, I added a quick key-value pair to Info.plist. Users wouldn’t happen across it; most of them probably don’t know app bundles are folders. But the preference was there if needed. So, I shipped that. Multiple times. Recently, I decided this preference needed to be dynamic, for those times when a user wants to enable logging without restarting the application. I set up an NSTimer to read the key-value pair from Info.plist every minute. After finding out the dictionary was cached, I figured out how to manually read it. Problem solved.

And yet, I completely ignored all the signs that pointed to a bad user experience. The workflow for setting the preference was complicated to explain to other developers (who know app bundles are folders). Non-developers asked for the specific steps multiple times. And yes, the Info.plist dictionary is cached, implying it’s for general application information, not debug settings. Still, it took two thoughtful comments on my other post to snap me out of my developer haze and think about the feature from a user’s perspective.

The goal of the feature was to hide the user-configurable preference from immediate view, not to bury it completely. The Info.plist workflow didn’t work, so I started brainstorming. How about a secret preference window? Fine, but where would it go? Perhaps an NSMenuItem, but that’s not hidden. Then I realized an alternate NSMenuItem was the perfect fit: hold the option key and “Preferences…” switches to “Secret Preferences…”. A user won’t stumble across it, but the menu item is a key away. Moreover, an NSTimer isn’t necessary; Cocoa Bindings make a preference change instant. That’s what I implemented today.

Never be afraid to iterate your design. The product I work on went through many iterations before arriving at its current form. Apple agrees. When I’ve talked to their UI evangelists, John Geleynse and Eric Hope, both consistently cite design iteration as one of the most important processes for developing award-winning applications (along with product definition statements). Most apps start out looking mediocre; the best user experiences are the culmination of many iterations. Keep iterating.