Musing: Conversational Guides

For Aeolus, we’ve been talking a lot lately about how to improve the user interface and make things generally more intuitive.

One thing I noticed the other day was more of a general difference between desktop apps and many web apps — the presence of explanatory text on each page, often with a sort of conversational tone. In a desktop app, you might be presented with a form with various controls that you’re expected to understand. In a web app, you might get asked, “Hey bro, now that you’ve X’ed the Y, it’s time to choose your Z!”

We probably don’t want to address anyone as “bro,” but I’ve been thinking a bit about the concept of what this might look like in Conductor. We have a variety of forms users are asked to fill out to complete certain actions, and it’s not always immediately obvious. And for someone new to Conductor, our teminology isn’t always intuitive, either. (And for intermediate users, it’s still easy to get a little bit confused from time to time.)

Here’s an example of what I’m thinking. When you go to create a deployable, here’s what you see (click for full-size):


That’s great for power users, but what if you’re not one? Wouldn’t it be nice if there was a little bit of a description? (And if you are a power user, be honest: you’re not going to read the instructions anyway, so they won’t do you any harm.) What about something like this:


The text there is really just a quick example, so please don’t worry too much about the exact tone or what we should do for styling of the text. For now I just threw a %p tag at the top of the page and took a quick stab at telling the user what they’re meant to do here. We should probably do better than I did, and actually explain what a “Deployable XML file” is, and how they could create one.

What do you think about this? Are there best practices for this sort of thing?

The Browsers of Technical Users

I’ve been experimenting with gaug.es for analytics on a few of my sites. On my other blog, most of the traffic comes from searches for various technical topics, implying that the audience is likely a bit more tech-savvy then the general Internet populace.

Do you notice any browsers absent from this chart?

Trivia: “Other” is a 50/50 tie between Internet Explorer and Opera.

Also: gaug.es is very cool. Possibly cool enough that I will start paying when the 7-day free trial expires.

Hosting a Downtime Page with Apache

I had to help set up a downtime page for a site experiencing an extended outage. We wanted a “We’re working on it!” type page to let people know what it would be back up soon. But the problem is that if you serve this as a static HTML page, it would (a) only work on the site’s root page, and (b) be served with an HTTP 200 status code, potentially getting crawled by search engines and ending up in peoples’ caches. Both of those are bad.

What I really wanted was to set an HTTP status code that indicated that there was an error condition, so that browsers would hopefully not cache the page, and so that search engines would know not to index the page contents. HTTP 503 works perfectly for this — “Service Unavailable.”

I ended up setting up a new Apache virtual host on my existing server (not the one that’s down, of course), creating a quick page named downtime.html (the only content), and throwing together the .htaccess (assembled piecemeal from some reference sites, admittedly):

RewriteCond %{ENV:REDIRECT_STATUS} !=503
RewriteRule !^/downtime.html$ /downtime.html [L,R=503]
ErrorDocument 503 /downtime.html

The result is that all pages on the site now get the downtime page in response, served with the appropriate HTTP status code. Ta-da! This isn’t anything terribly involved, of course, but figuring out how to set a 503 via mod_rewrite was quite confounding.