Hawaii is, as far as I can tell, pretty much overrun by tourists, and thus you often had to look at somewhat hard to find people who are genuine. I guess the experience that stands out the most was a sailboat ride we took. The skipper, who had clearly done this trip hundreds or thousands of times, had his script memorized: he had a snappy comeback for every question, which he half-heartedly delivered. Were the jokes funny? Yes. But there just wasn't any sort of personal connection, mostly because it didn't feel like he was real. Now, I'm not so naïve to think that being authentic in this situation is easy, but I do believe that it is possible and ultimately vital for successful user experiences.
I contrast this with another tour we took, this time at Surfing Goat Dairy. Two German ex-pats run this very nice little goat farm in the middle of Maui, and they offer tours and tastings. I'm sure they've been through plenty of tours in the years they've been open (but probably less than the 3-a-days the boat skipper did), but it didn't feel like it. It felt like we were talking with actual humans, and knowledgeable ones who took pride in their work. And the tasty cheese helped, too.
It is so important, no matter the situation, to be authentic with those you work with (both inside and outside your organization). People can smell spin and obfuscation a mile away. Be straight with people, and they'll appreciate it.
With some types of projects, the best approach to take is to focus on continuous improvement. We stayed for a night at a restaurant and inn called Mama's Fish House. In the room, they provided a copy of Maui Magazine, which, coincidently, featured an article about the establishment's owners (I'd link to it, but Maui Magazine doesn't have it's archives online). The owners have employed a carpenter/designer for nearly the entire 30+ lifespan of the restaurant, and in that time this craftsman has slowly built out the building into a very impressive space. He mentioned, I believe, that they'd re-done every wall in the place at least twice. Basically, they started small (with a little hut), and built slowly built it out over the years.
Excepting the type of project where you either need to make a big splash quickly, or launch at a very large scale, the continuous improvement tactic is the one to take. This is the sort of approach we take on things like websites. Good websites are never done, and always "under construction." Sure, there might be periods were you do fairly major re-models, but mostly you want to instill the idea that you can always make small tweaks and changes to make it better. This approach also gives you much more flexibility to change as conditions change around you. You can address problems as they crop up rather than trying to initially plan for many contingences.
I think the difficulty of pointing a group of people in the same direction can be reduced to a simple mathematical formula:
Difficulty = n2, were n is the number of people in the group.
Needless to say, this really only applies to situations where people have the free will to choose the direction they want to take. But, this little formula should be kept in the back of every project manager's head, and factored into schedules and other project activities.
Don't invest in airlines. I won't bother recounting the 30+ hour Seattle-to-Maui travel nightmare, nor will I name specific airline names, but I can't help but notice that all is not well in this industry. Admittedly, this isn't exactly earth-shaking news, as the financial difficulties of airlines (not counting low-cost carriers like Southwest and JetBlue) is well know. Peter Merholz recently ranted about airlines and Victor Lombardi has some good observations on JetBlue, so I won't cover any ground they hit in their respective rants.
My observations fall to the airline's computer system. I'd love to get a look at the reservation and booking systems, because from my perspective as the guy across the counter, something is deeply wrong. It seems to take an inordinate amount of typing to handle even the most basic task (checking, seat assignment, and so forth). And making flight changes takes a wild amount of time. Because of the aforementioned travel nightmare, we were able to make some changes to our return flights (extra day stay, direct return flight). It took the agent a really, really long time to make the change. The kicker is that the agent didn't even manage to do the process correctly, even after 15 minutes of tapping away on his terminal. Nearly every time we needed to interact with someone, the first person who tried to help couldn't. Sometimes you'd see two or three agents pointing to the screen and giving advice and hints to the one typing. I'm pretty sure that no computer system should be this hard.
I'd really like to see an article about the computer systems the airlines use, just to learn more about it. I'm betting that this is a system that has evolved from 1960s-era Sabre system. If you've seen any write-ups on the usability or history of these systems, let me know.
]]>Joe Gregorio's Sparkline generator cgi and webservice. This implementation, done in python, joins a number of other sparkline generators. Cool.
Chris Campbell's Preview Your Links with Unobtrusive JavaScript. This looks like an unobtrustive client-side way to plop little icons next to links. Probably not right for all situations, but nice anyway.
]]>Well, I have about 300 more unread items to go, so I'll probably hit more good stuff.
]]>I'm working on a little python script that will grab search results from one of our vendors to include in a federated search system. I've had pretty good results with most of the vendors we work with, and all in all, my little program is pretty slick.
But, I'm stuck with one of them. You see, in order for their authentication system to work when I'm doing the search, I need to first get a cookie with a session variable from their server. So, it needs to look like this: hit homepage, get cookie, send second request, get search results. Pretty easy, huh?
Turns out, no, it isn't that easy. The root of the issue is that my script is including the "Connection: close" HTTP header. And when the server (IIS) sees this, it flushes the session variable it set. So, on the inital request, it gives me a session variable then immediately flushes it. Not so useful.
So, I need to not send the "Connection: close" header, so that IIS will keep the session alive. Fair enough. Let's look at what I'm using to grab the scripts. Plain old urllib and urllib2 won't cut it, as they don't have cookie support (well, urllib2 got it as of python 2.4, but our box is running 2.2, and I'm pretty sure that wouldn't matter anyway). So, I'm using ClientCookie (which eventually merged into the standard library as cookielib). ClientCookie is pretty darn slick, very easy to use. But, you guessed it, no persistence. It sets the same old "Connection: close" header as urllib2 does. So, I then turned to urlgrabber's keepalive module. This works like a charm...easy persistent connections. But, uh, no cookie support. Both modules let you set headers (to change the User-Agent and such), but my attempts to change the "Connection" header go nowhere.
I have two different problems, with two solutions. Just they won't work together. I've spent a few hours trying to combine them without luck. The next thing I can think of is to basically try to re-write the functionality of these two modules together as one, but that sounds really, really ugly for this occassional programmer.
Anyone out there a python guru with a good answer to this?? Write me!!
]]>I wonder, then, what she would think about me reading a book called "Better Off: Flipping the Switch on Technology." Probably best not to mention it, eh?
The author, Eric Brende, and his wife move to an Amish-like community and literally turn off the electrical switch. While I find this move to be fairly extreme, I do sympathize with their desire for less technology. I have a feeling that many of us would be better off if society was more judicious in its collective use of technology. The automobile, in particular, seems be coming quite close to a net negative for society. I watched a documentary recently (My Architect) on Louis I. Kahn. At one point, they discussed a vision he had for downtown Philadelphia where garages would be built around the downtown core, people would park, and walk to their destinations. No cars would be allowed in the central area. Sounds quite nice. Too bad they didn't go for it.
It becomes quite difficult, I think, to determine just how much technology is enough. Undoubtedly, technology is good (see: modern medicine, the expansion of information availability on the internet, etc). But also, it takes a toll. Finding a balance is hard for individuals, and harder, I'd guess, for society.
I don't have any answers just yet. But I think that striving for simplicity is a good thing. I'm not ready to become a subsistence farmer, but I'll keep working on simplifying stuff…
]]>For me, the issue comes down to ease-of-access. We keep hearing from our users that people prefer Google to our hand-picked, high-quality resources. Google is a one-click operation (seeing as it's built into browser toolbars and such), and fast to boot. Our resources currently live three or four clicks off of the homepage, and behind authentication schemes (they're subscription databases). And, each one of our databases has a very different interface. Some are easy and clear; others are more complicated. But perhaps the most difficult part is the user needs to know which one of the databases to try. With some exceptions, users could find relevant information in more than one of the databases, and because of the general nature of the resources, it can be hard to give good guidance to the users upfront. So, the user is left to click into each one with the hopes of finding info. No wonder people go off to Google!
So, we're going to put a federated search engine in place. The idea is that users would be able to use a Google-like interface, but get our high-quality resources back as results. I'm not viewing this solution as a comprehensive search solution. Rather, after returning a few results (say, 5 or 10), I'm going to dump the user back into the native database interface. In other words, those users who would like to use the more powerful tools provided in each system can do so. The simple results we return should also point the user in the right direction. They wouldn't need to try each and every database, only the ones that look like they might have quality results.
This is all well and good, but I think there is a bigger issue at stake in the information literacy realm. It seems like some of the librarians in article are focused on teaching patrons how to use the library information systems (OPACs, databases, whatever). The "click here, click there" type of training is fine and good (although I'd rather see interfaces that are so intuitive they don't require training). But, the focus in information literacy really needs to be on evaluating information. I don't care if the results come from Google or a subscription database, the patron needs to know how to evaluate the information and decide if it is trustworthy, useful, and relevant. This is much harder than "click here, click there", but ultimately much more useful.
]]>I did learn one thing about testing prototypes: when you fake content, it needs to either be very realistic or very obviously fake. Representing an image with a crossed-out box in a sketch works well. But, we were using high-fidelity prototypes (Photoshop comps printed out) and made the mistake of throwing in a random image into a spot that should have had a realistic image with text and a call to action. This threw a number of users off. So, make it realistic or not, just don't land in the middle.
Mike Lambert wrote in to mention the EyeTools service. This looks pretty cool, if a bit pricey. Basically, they'll run an eye-tracking usability test for you, and then send nifty charts to show where people are looking.
]]>The challenges are pretty obvious. First, how do you decide where to put the dotted line? Second, how do you avoid killing something too early, or celebrating too early. And last, how do you know when to kill a dud? The odds are with those smart enough to launch something new tomorrow.
These questions, to me, are the most interesting part of the post. The challenges might be obvious, but they're the hardest part to figure out.
It feels like I've been hitting these questions a lot lately at work. Not necessarily with launching a product or a service, but rather with features on our website. As you might have guessed from my series of recent posts on website stats, I've been looking at more ways to measure usage of different aspects of the site. Like most folks, we have lots of features, and limited resources. So, logic dictates that we should focus on the highest value features and dump the low-performance, low-value ones.
But, when to pull the plug? (Or, where is the dotted line?) And why does a feature get used or not? Low usage could point to the fact the feature was, in total, a dud. Or, it could be poor placement. Or unclear copy. Or a usability problem. It is easy to say that the something was just a dud, but pulling the plug could be a hasty decision. I'm inclined to spent at least some time focusing on our execution of a feature before I pull the plug. In a recent case, we spent time redesigning a feature and altering it's layout in an attempt to bump up usage. Turned out that a before/after analysis showed that the changes didn't really make that much of a difference. So, I think we're going to yank the feature. But, I think it was worth the time to experiment with the execution before giving up on the concept.
]]>[Long-winded intro about how we're testing the site, not the user...]
"Pretend you're doing research for a term paper on the Civil War. Where would you start?"
[User points to a link.]
"Great. Thanks for coming in today. Here's a water bottle!"
Anyway, does anyone know of any good resources on conducting usability tests with just a single page? Most of the usabilty resources I've seen assume a more long-term interaction. Shoot me an email at weblog@karlnelson.net if you have any good resources or ideas...
]]>I'm using the prototype.js system that is included with Ruby on Rails. The javascript library doesn't depend on Rails, and in this case I'm using it with a combination of PHP and Python scripts. Basically, the script makes a call to the server and then places the HTML it gets in response inside a div. The javascript that makes this all happen is called using onload(), but I've also toyed with just plopping it in the code, with little difference in functionality.
So, everything works like a charm, and the user is eventually presented with results from multiple sites. Then, Mr. or Ms. User clicks on one of the results, and leaves the site. So far, so good. But, trouble arises when the user clicks the back button and ends up back on the search page. Firefox re-fires the onload(), and the results appear quickly (I'm caching the results on the server side). IE6 doesn't re-fire the onload(), leaving me without results. This isn't good, seeing as a healthy (but declining) portion of our users are using IE.
After a little sleuthing, I came across this page. Taking advantage of the fact that IE's history/cache store pages with distinct URLs (I believe), these guys show a method using the Dojo toolkit to modify the URL by appending a "#" with a string of numbers to the URL. Voila! This should do the trick, but I haven't tried it yet.
I do have a couple of little concerns. One, it does muddy up the URL a bit. I can live with this, though. But, of more concern is the fact that it would create two entries in the history/cache for the same page. One would be blank, the other would have the results in it. Users would then have to step back through the blank page. And having watched many a user rely solely on the back button during usability tests, I'm not wild about this.
So, I see a few potential solutions:
The BBC is offering downloads of all of Beethoven's symphonies. Unfortunately, you need to pay attention to when they broadcast 'em, as the MP3s are only up for a few days after each broadcast. Still, cheaper than iTunes.
Here's a nice looking version control system comparison.
Peter Merholz on the The Dark Side of Design Thinking: "Look at any interactive design annual, anything judged by a panel of designers, and you will see a stupefying weakness for styling. It doesn't matter that after using any of the winners for 2 minutes, you're pretty much done (if you could figure out how to use it in the first place)."
Here's a couple of tools that developers can use, with Greasemonkey, when developing AJAX apps. Nice.
Tom Hoffman on free concept mapping software.
]]>I'm not sure I'll use the exact technique he describes, as my short-term prototyping needs aren't for entire websites, but rather for a single page (redesign situation). But, the article got me thinking about some variations on the technqiue. What if we scanned some page sketches (paper prototypes), then linked up the links and put 'em in front of users. Sounds like a nice way to try out a couple of design variations in a more real-world situation than just placing a piece of paper in front of the user. Could be useful, in that it would keep the low-fi nature of the paper prototype, yet incorporate hi-fi features like working links and forms.
I'll let you know if we try it...
]]>