Archive for the 'Technology' Category

From here to there, part 1

On the whole, Google Maps is a great service. The interface is clean, ads are unobtrusive, performance is generally very good, and its ability to parse abbreviations and incomplete names is top-notch. But after a spate of less than ideal driving directions from Google, I decided to step back and look at some of the other popular online mapping services to see if any competitors offered higher quality directions or a better experience.

I’ll touch on a number of services in upcoming posts, but first, some background on my recent experiences with Google Maps that spurred this comparison.

Go-go Gadget Map

Sometimes Google’s driving directions appear to favor minuscule improvements in distance or speed over more sensible directions, e.g. a number of small turns on side streets saving 0.1 mile or less, rather than reducing the number of turns or continuing on a single arterial road. Perhaps Google assumes that your smartphone or sat-nav gadget is holding your hand the whole way and thus it doesn’t much matter if the directions make more sense to robots than to humans. [1]

That choice, however, leads to some odd directions. For example, when heading southbound on the Berlin Turnpike (US-5/CT-15), just south of the CT-9 overpass there is a turnout to the right which loops around to cross the Turnpike perpendicularly to allow for an easier left turn across traffic. However, when heading southbound without needing a left turn, Google Maps still suggested taking this turnout and then merging back on the Turnpike in the original direction of travel. [2] This diversion may have saved a few feet at best (though even that seems doubtful) at the expense of adding two entirely needless steps to the directions.

Google Maps - southbound on Berlin Turnpike, Connecticut

Or in Oregon City, Oregon, when traveling southwest from Washington Street onto Center Street. The Google directions suggest a slight diversion onto 8th St (a minor sidestreet) rather than continuing on Washington St until 7th Street (a sizable throughway). Google’s own color-coding shows Washington, 7th, and Center streets in yellow and 8th Street in white, indicating that 8th St is a comparatively minor road, but still suggests the 8th St route due to the route being 1 metre shorter. [3]

Google Maps - Oregon City, Oregon

A potentially more dangerous tendency of Google Maps is to consider distance and time traveled more heavily than road type and remoteness. When driving from Rapid City, South Dakota, to Jackson, Wyoming, Google suggests taking WY-50 over WY-59, WY-259 over continuing on WY-387, and WY-134 to WY-133 over continuing on US-26. In all of these cases, Google’s directions favor roads which are considered by AAA to be “local” over “through” roads. [4] Opting for alternatives to Google’s suggested roads does increase travel time and distance (by a measly 19 minutes and 24 km on a 9+ hour drive), but in remote stretches such as these, a slight increase in travel time is well worth it if the road is poorly maintained, there are no gas stations on the lesser-trod road, or the local roads are sparsely signed.

Google Maps - Eastern Wyoming

Red = Google suggested local roads, blue = through roads

So, it looks like Google’s directions could use a few improvements. [5] So let’s see what else is out there …

(Continued in part 2)

  1. Indeed, while drafting this post a BBC News item about Google and robot cars popped up in my news reader.
  2. This particularly odd suggestion appears to have been corrected in the interim since my original query a few months back.
  3. Yes, a difference of less than 40 inches.
  4. I’m not from eastern Wyoming, but AAA’s “local” and “through” labels seemed appropriate to my own eyes as I drove through the area.
  5. Google’s unique features and capabilities will be covered in a follow-up post after all of the other services have been picked apart.

CHIFOO part deux

Two observations on my second CHIFOO meeting:

  1. I’m batting 1000 for striking up random conversations at the preceding CHIFOOd event and then finding out later that the person was the night’s speaker. This is despite having previously read about the nights’ topics and seeing photos of said speakers. Thankfully, both speakers were very approachable and seemed to regard contrary points of view as springboards for discussion rather than dismissing me as being argumentative (which would not entirely be a stretch of the imagination).
  2. As the night’s main presentation began I noticed that in a room full of usability geeks the preferred method of note-taking was pen & paper.

Apt to get lost in listings

After spending hours upon hours sifting through many and varied apartment rental listings, it became very apparent to me that having a better way to compare rental listings would be a great benefit to consumers. Similar to the Schumer box summary for credit card terms, a standardized table of terms, costs, and details of a property rental could go a long way towards cleaning up the always-painful process of apartment hunting.

Many apartment listings (like those on most apartment hunters’ go-to resource, Craigslist) do allow for basic filtering based on monthly rent, number of bedrooms, and so on. However, without reading each individual listing it’s often impossible to make truly accurate comparisons. For example, one apartment may bill water usage separately while another may include water and heat in the price of rent. If both apartments are listed at $1500 per month, it’s not clear that the first apartment could cost another $50 per month (or $600 per year!) for water usage.

Different markets bundle costs in different ways — for example, I don’t know a single Boston renter who pays a separate water bill, but in Portland it seems to be the norm — so it makes sense to spell out all of the standard living expenses associated with the property. It may not be possible to provide exact dollar amounts for each cost; one tenant may use more or less heat than the next, for instance. But simply noting that a separate expense exists is more information than many listings currently provide, and more ambitious landlords could provide utility usage details (three year averages of past usage, for example). Detailing the cost of parking separately from the base rental price would also be hugely beneficial, regardless of whether the prospective tenant owns a car.[1]

Including a floor plan could also save both landlords and renters a lot of wasted time. There are many apartments that may meet a renter’s criteria in terms of total floor area (e.g. 1000 square feet), but a particular room may not meet the renter’s needs (e.g. 10 feet wide to fit a particular piece of furniture with a comfortable margin). It doesn’t serve the landlord or the would-be renter to visit the property and take the time and effort to measure it themselves. It may take time to draw up floor plans for each unit that a landlord owns, but it’s a one-time expense and all prospective tenants will gain from it. (And come on, I bet everyone knows a few out-of-work graphic designers who would be more than willing to fire up Illustrator and draft floor plans at reasonable rates.)

On the technical end, it would behoove all involved to draft a standard way to represent this information digitally. Off the cuff I’d say that an XML schema could do the trick, with floor plans included in the file as SVG. Once a standard format is created, it would be easy to use any XML-capable application (desktop, mobile, or web) to compare, sort, and display listings.

Landlords could still be free to write up any rental listing they saw fit, but the standardized summary would need to be provided as an addendum (or at the very least, on demand). I suspect that if enough consumers favored listings which included the summary, most landlords would be inclined to just go ahead and always include it to save themselves the time of dealing with individual requests.[2]

I created a quick and simple first draft [3] of what such a summary could look like — see the PDF below, which has some example values filled in.

Property rental summary example (PDF, 62 KB)

  1. More on this in a forthcoming review of Donald Shoup’s The High Cost of Free Parking.
  2. Supposedly this is how the free market works, but more often than not information disclosure has to be mandated.
  3. The floor plan in particular is rough. More detail would be necessary to be useful; specifically, measurements for each room are key.

Back to the Future

Browsing the web has changed plenty since the debut of the dub-dub-dub in the early 1990s, but the basic design of the graphical web browser is still remarkably similar to the first entries in the field. From NCSA Mosaic 1.0 (1993) to Internet Explorer 6 (2001) to Google Chrome 14 (2011), a degree of consistency has been firmly established and users now have solid expectations about the core functions of the browser.

So when a website decides to roll its own navigation controls and warns, “Don’t use your browser’s Back button,” it places an enormous cognitive burden on the user. By explicitly warning users not to follow their instincts, the website developer is implicitly acknowledging the likelihood that users will rely on those instincts.

The recent push by browser developers to reduce browser chrome to all but the bare necessities means that the Back button is one of the few UI elements outside the web content itself. All browsers place the Back button in the prominent upper left corner; some browsers go as far as making the Back button larger than the Forward button, thus making the Back button the largest and most visible widget in the browser. Telling users to simply forget about that very large and very useful button is not a recipe for success.

“But my website is special! It’s OK.” No, it’s not. Jakob Nielsen’s Law of the Web User Experience states that “users spend most of their time on other websites.” And if you design a website that will fail under normal expected usage, you can bet that they will spend all of their time on other websites.

Gettin’ Higgy wit It

Human interface guidelines go far beyond the idea of a simple visual style sheet — “Buttons should have X units of padding” or “Window title bars should be dark gray” — and provide a comprehensive framework for developing consistent and enjoyable user interfaces. As my interest grew in the overall user experience, I dove into the HIGs for the major desktop environments: Mac OS X, Windows, GNOME[1], and KDE. The level of thoroughness and strictness of each HIG roughly mirrored my layman’s opinion of each environment, though there were some surprises.

Mac OS X

Far and away the most useful HIG in my opinion. Sure, Apple has been known to deviate from their own HIG (sometimes in baffling, trivial, or confusing ways), but the baseline from which they work is much clearer in both explicit specifics and its implied intentions.

Of particular interest to me were the menu guidelines, for both the menu bar and contextual menus. I was working on improving both menu types in a major product for the company I was working for at the time, and Apple’s HIG provided clear guidelines on how to standardize the common elements and rationale for managing custom elements. One thing which sets Apple’s HIG out from the pack is that it doesn’t shy away from explicitly telling you not to do something (contrast with the Windows HIG, below).

OS X Lion’s bothersome tendency towards skeuomorphic nonsense notwithstanding, Apple is unsurprisingly the leader when it comes to defining the user experience of their platform.


The Windows HIG is expansive, but it suffers from the platform’s long history of allowing a myriad of ways to accomplish any given task. The ability to say no is an important quality of any editor, and the strength of the Windows HIG is sometimes diluted by allowing similar widgets which operate in subtly different ways. If developers don’t have a clear directive of which widgets to use for a given situation, it stands to reason that most users won’t grok the differences in behavior when one developer chooses A and another chooses B.

I’ll be interested to see what the Windows 8 HIG looks like, as the Metro UI will require a tighter rein to maintain a consistent experience.


Having only using Linux in general and GNOME in particular sporadically at best, GNOME’s HIG turned out to be a good deal more thorough than I expected. Concise guidelines for most standard uses were provided, and importantly, explanatory text was included to help define the rationale. This supporting text helps to inform decisions when a situation is encountered that is not explicitly covered by the HIG.

As one might expect the GNOME HIG is not as comprehensive as the Mac OS X HIG (or as restrictive, some might say), but it does show that a collaborative project can execute a clear vision.


I have had the least hands-on experience with KDE. Working primarily from a vantage point of the stereotype that KDE appeals to the most devoted hackers and tweakers, I found the KDE HIG to mostly reinforce that view. In contrast with the GNOME HIG, which gave me a real sense of the GNOME design approach, the KDE HIG was an incomplete collection of loose guidelines. That’s not to say anything directly about the KDE environment itself, but the HIG didn’t paint a very clear picture. One might infer that a lack of clearly defined guidelines would manifest itself in the end user’s experience, but I’d have to demur on that point out of personal inexperience with KDE.


Evaluating these HIGs individually and collectively was an enlightening exercise. Not only did it sharpen the focus of each platform, but seeing where there was (and wasn’t) common ground between the HIGs provided a universal de facto desktop standard of sorts.

HIGs are also available for each of the major mobile platforms — iOS, Android, and Windows Phone 7[2]. The design choices outlined in each provide a look into both current and future mobile development, and as OS X Lion and Windows 8 are demonstrating, possibly the future of the desktop as well.

  1. This was prior to GNOME 3.0. I’m looking forward to exploring both GNOME 3.0 and Unity when I get the time, and I plan on posting after my first hands-on experiences with them.
  2. webOS also has a HIG, which could be an interesting read, but perhaps of muted practical relevance.


After receiving a tip to check Calagator (calendar + aggregator) for tech-related events in the Portland area, I decided to attend the October meeting of CHIFOO (pronounced “ky – FOO”), the Computer-Human Interaction Forum of Oregon.

First on the agenda was the “CHIFOOd” meet-up at a pub[1] for some food, drinks, and discussion, which proved to be a good introduction for a newcomer like myself. The speaker for the night’s event (who I arbitrarily sat down next to before realizing who he was) proved to be as approachable and talkative as anyone else there. And perhaps fitting for a meeting of people who explore the human side of computer interaction, it was there that I first heard that Steve Jobs had died that day.

After polishing off some sliders and pints[2], it was time to amble over a few blocks to the main event. Thomas Tullis presented a program titled, “Why It’s Time to Move Beyond the Usability Lab,” which discussed a number of engaging examples of how and why to explore options beyond the traditional methods. In addition to keeping the floor open for quick questions during his presentation, several times during the program all in attendance were able to participate in live polls via text messaging. (I did acquiesce and buy a cheap-o burner mobile phone before embarking on our cross-country drive. I had the phone on me that night and abstained from voting in the first poll, but eventually gave in for the second and subsequent polls. Damn you, snakes!)

All in all, a very interesting program and a group whose meetings I’m sure I’ll be attending more of in the future.

  1. In spite of (because of?) Calagator’s technology focus, “beer” is one of the most prominent entries in the site’s cloud tag.
  2. This pub in particular offers the choice of US or Imperial pints. I was tempted to ask for metric, but ultimately restrained myself.

Self-checkout lanes are checking out

It turns out that my avoidance of self-checkout lanes at supermarkets wasn’t just a demonstration of my personal tendency to be a stubborn old curmudgeon: major chains like Albertson’s and Big Y are phasing them out in favor of standard service lanes (,

Of the many things I have principled objections to, using automated tools isn’t one of them — my use of ATMs vs human bank tellers is easily 20:1 in favor of robots, for example[1]. But tools have to fit the job, work well, and most importantly, offer a noticeable benefit to the end user. Self-checkout lanes at supermarkets, in my experience, offered fewer advantages than they did drawbacks. Though there was a chance of enabling a speedier exit from the store, it was more likely that I would encounter a computer barking at me that there was or wasn’t some expected item in the bagging area, an item or coupon that couldn’t be scanned, or some other unspecified failure which required a manager’s attention.

These problems highlight how important it is to consider the overall user experience. Automation may be alluring to a business looking to shave costs, but when its effect on customer satisfaction is considered, the total cost of ownership may be much higher than expected. (Not to mention some of the other concerns mentioned in the linked articles, such as intentional and unintentional theft.) Sometimes a new technology just isn’t better than its predecessor.

  1. ATMs are often finicky and have a slew of minor usability issues of their own, but nonetheless generally earn a passing grade. I’ll be signing up for a new bank soon, so mayhap a future post will chronicle my first attempt to bumble through an ATM system I’ve never used before.