Archive for December, 2005

Users Lie

December 31st, 2005 3 comments

I consider myself a client side guy. I arrived there rather by accident – I was one of the least experienced (in terms of years worked) members of a team that was slated to build the company’s first Java based web application. When it came time to break the overall group into small teams, the three greenest (myself included) staffers were assigned to the client tier. I guess that sent a subtle message – the stuff the user would actually see wasn’t all that important so put the junior team members there. Ironically enough, the three of us also had the majority of the OO experience on the team (can you say procedural Java?)…but that’s a matter for another blog.

Oddly, we did spend a fair amount of effort on the user interface and we spent a remarkable amount of time doing usability testing. We had a fantastic UI architect that worked really hard to come up with a look and feel that was consistent between IE and Netscape (ah, the glory days of the late 90′s and serious browser incompatibilities – I love the smell of browser checks in the morning!) For reasons that still escape me, we actual brought in a rather pricey IBM usability expert to help us test the app and it was at this stage of my career where I discovered the joy of paper based prototypes (otherwise known as low-fidelity or low-fis).

The nice man from IBM taught a few of us how to moderate testing sessions. He told us to remind users that *they* weren’t being tested, that failures were actually our mistakes in the design. He taught us how to let users struggle, that telling them what to do meant, again, that we’d failed. We were coached on encouraging users into thinking aloud about their experience and tell us how they expected the app to work. But the most important thing he taught was that users lie. OK, he didn’t say it quite that way but it’s like Mom always said: “actions speak louder than words.” What a user says rarely matches what a user actually does. It’s why asking a user what they do day to day just doesn’t work – you need to actually observe them in their natural habitat (it’s kind of like being an anthropologist though truthfully it’s more like ethnography).

I’m not advocating that we completely ignore customer and I don’t mean to imply that they deliberately mislead us (well some do) but yes, listening to users is harmful. According to Nielsen, the First Rule of Usability? Don’t Listen to Users. Those of us that spend an inordinate amount of time dealing with ephemeral stuff like code are pretty good at working with abstractions (though we don’t hold a candle to those theoretical physicist types…) however, the average user has a hard time imagining what might be. Not to quote Kathy twice in one paragraph, but there is some quantum mechanics at work here. Again, actions and words don’t always match up – many of us respond to a kind of social calculus and consciously or not, we seek approval by giving people the answers that we think they want.

Of course what users want will be impacted by what we give them. It’s one of the main reasons heavyweight methodologies just don’t work – the feedback loop is too long and it gets short circuited by a desire to resist change. I used to think that my customers were just neurotic – we’d go build what they asked for, show it to them, then they’d say “it’s all wrong – change it.” It was considered rude to point out that we’d built exactly what they asked for…

I realize now that this is completely natural, my users were just reacting to what we were building. This is the fundamental strength of having frequent releases, customers get something to work with earlier and they can make adjustments to what they are asking for. Fundamentally, this is more efficient: if you’ve only spent a week or two developing a feature and discovered that it’s not useful, so what, you’ve only lost a couple of weeks. If you wait 18 months to discover that, well, you’ve just wasted a ton of money.

So, (mostly) don’t listen to what your users say. Watch what they do – get in front of real live users and watch them work. Asking what they do isn’t sufficient, a lot of times you’ll either get an incomplete answer (do you remember what you did yesterday morning?) or you’ll get the party line answer (well, this is what we are supposed to do). Don’t settle for the manager or the VP, even if they were the best at doing “foo” five years ago, things have probably changed (plus they probably wrote the proverbial book on doing the job and they misguidedly belief this is how things are actually done). So get out there and do some good old fashioned observation. If you’re lucky you might just build something people will actually use.

Categories: Software, Usability Tags:

Only in Minnesota…

December 31st, 2005 No comments

From the “Only in Minnesota” file, the iPod is apparently a must have ice fishing tool. Now I admit, I’ve never ice fished – I enjoy catch and release in the summer…when it’s warm…but the idea of sitting out in 10 degree weather dropping a line into a hole… Sorry, I just don’t have the patience for it though as evidence by the hundreds of fish houses I see on area lakes lots of folks clearly do. Of course I’ve heard of people who have fish houses that are more comfortable than their actual homes – most (if not all) are heated and it’s not uncommon to have microwaves, pizza ovens, TVs…even satellite dishes. I suppose if I was fishing from a couch while watching the game maybe I could be talked into it!

Anyway, I just had to post a link to The Unofficial Apple Weblog‘s recent post about ice fishing podcasts, yes, apparently the DNR has a podcast on ice fishing! There truly is a podcast for anyone.

Categories: Off Topic Tags:

API Design

December 28th, 2005 No comments

Winter must just affect people in a certain way – for some reason, I can’t seem to open up my blog reader without running into two or three articles on API design. Now, I’ll admit, I’ve seen some pretty poor APIs in my day (I still cringe when I think of the classes I’ve dealt with that had a singleton method) but it’s quite interesting that there has been so much chatter on this topic of late. I’m sure some of it is cross contamination – chances are the people I’m reading are also reading each other (in a nutshell, that’s what the collaborative filtering concept is all about – the notion that similar people like similar things). Or maybe short (cold) days just force people to sit in front of their computers more (my notebook is quite warm).

Anyway, I just thought it would be of value to my reader to point out some of the recent news on API design. Near as I can tell, Martin Fowler kicked this all off with a piece titled Humane Interface in early December. Ironically, I was helping a coworker with a validation service just after I read this and it did influence my advice. I’m somewhat torn on Fowler’s assertions here – on the one hand a small interface can be easier to learn however, a more explicit (though larger) interface can actually be easier to use. Like so many things, your users will let you know though I think it’s key to remember there is a big difference between writing a framework like API that will be used by lots and lots of developers (that are outside of your purview) and good design for APIs that are used within an application. And this distinction explains some of my disagreements with Eamonn McManusJava API Design Guidelines piece.

In general, I like Eamonn’s article. He hits it right on the head when he says design to evolve and his quotes of Bloch’s Effective Java are spot on. I was also pleased to see that he touched on ease of use and easy to learn – too many APIs are clearly not designed for regular old developers. Sure, they might make sense to Stanford PhD candidates but to those of use without Ivy League (and yes, I know that Stanford isn’t an Ivy League school…) educations, they are a bit obtuse (see we can use big words too – though I will admit I really like OS X’s built in dictionary – to the point where I get irritated that my work machine is XP). Still, I couldn’t help but think that Eamonn approaches this topic from the standpoint of framework designer (in this case someone that works on the Java specs). For instance, I’m not so sure I agree completely with his assertion concerning backward compatibility. Sure, you can’t just remove a public method in a superclass (twice…in a week) without checking with the rest of the team but if we never remove anything, why even have the concept of deprecation?

Good old Mr. Fowler wasn’t quite done on the topic of APIs. First, you should check out all the responses that Martin’s Humane Interface entry caused (scroll down). Of course the opposite school of thought is Minimal Interface! Honestly, I think I’m leaning towards larger interfaces but maybe it’s just because the days are getting longer. Ask me again next fall. More recently, Martin added another entry: Fluent Interface. I’m really intrigued by this approach though it seems like a Fluent Interface really only makes sense in context – in other words, the methods by themselves aren’t so obvious. I’m not sure where this falls on the ease of use/easy to learn scale but I do wonder if newbies would have a hard time getting up to speed on a application that made wide use of Fluent Interfaces. Of course maybe they only make sense in concentrated doses.

But he’s not done yet! Oh no, he’s practically the Energizer Bunny of API articles. Just last week, Martin posted an entry on Duck Interfaces. In general, I find dynamic languages can be easier to work with especially when I think of all the casting I’ve done in Java over the years. Seriously I put the objects in the collection, I know what type they are…again it’s the difference between writing a framework vs. writing an application. If I’m writing a framework that you are going to use, by rule I have to distrust you and write more defensively. Of course if I control the code I can be less wary. I’m also reminded of a comment Dave Thomas made concerning dynamically typed languages: when was the last time you got a class cast on a deployed app? Why didn’t you catch it in testing?

I’m sure there are oodles of other articles out there but this small subset caught my attention – enough so that I actually took the time to sit down and write this up. Of course I could also just be procrastinating on my latest project…

Categories: Development, Rants Tags:

What if

December 21st, 2005 No comments

The two most dangerous words in software engineering are what if – as in “what if the customer wants to…” and “what if some obscure thing happens when…” I’m not talking about all uses of what if – it’s critical if you’re Thomas Edison and you’re dreaming up the next great breakthrough, but if you’re building software, what if will bury you. A what if does not imply a requirement – and spending too much time on theoretical needs prevents you from meeting real ones.

The next time you are in a meeting and someone says “what if…” stifle the scream welling up within you and politely remind your team of the YAGNI principle. Ask for the specific requirement. Inevitably, when you’re reviewing your design, someone will point out that you need to account for their favorite obscure situation. This revelation will spur someone else to mention another arcane circumstance. Some developers will consider your design a failure if it can’t easily handle these exceptional cases. Don’t succumb. Build a class that makes the common case simple and easy – tattoo the 80/20 rule to your forearm (or their forehead). Remember – making the atypical possible does not equate to making it effortless.

I’ve seen too many projects that get caught up in the cup holders and the chrome forgetting that they don’t have steering or brakes. Plan to refactor – you will anyway. It may be boring, but doing ordinary things extraordinarily well can lead to pretty phenomenal results. 37signals hits it on the head – Simple means launching something (yes Phil, I can relate!). To quote:

Moral: If you find yourself talking more than walking, shut up, cut the vision in half, and launch it. You can always fill in the gaps later. In fact, you’ll know more about what gaps need to be filled after you’ve launched “half a feature” than if you tried to fill them in before launching anything.

I couldn’t have said it better myself.

Categories: Rants, Software Tags:

Meetings are Like Goldfish

December 15th, 2005 2 comments

I grew up on a farm. Well, not a real “working farm,” we didn’t make our living off the land, but we had a decent sized plot and at one point we ran quite a few head of cattle. No, we didn’t milk them (what are you crazy – those things need milking twice a day…every day) they were beef cows (which is to say we had a freezer full of hamburger and steak). Along with the bovines (Texas Longhorns mostly – this one reminds me of one of our old cows, Harriet – and yes, the girl cows have horns too…) we had horses, cats, dogs and a goat. Oh yeah, and we had goldfish too.

Now, unless you’ve been around the 1,000 gallon tanks that are used to hydrate large animals, you might be really surprised to hear that we had goldfish on the farm. Like us, large animals often like to drink with their meals. Unlike us, they lack opposable thumbs and mirrors so they don’t always realize when they’ve ahh, still got some feed in their snouts. Without fail, bits of corn and hay are deposited in the water tanks which, if you’ve ever been to a dorm room inhabited by college age males, you know what happens next. Algae and other nasty stuff develops and that just doesn’t make for good drinking!

Unlike your dog’s little dish, you can’t just dump out a 1,000 gallon tank everyday – you have to live with a little crud (OK not so much us as the beasts but it isn’t fun to look at). So what’s a rancher to do? Well, you toss a few goldfish in the tank and let them have at it! Goldfish are great because they’re cheap – and you go through a few on the farm. Some just flat out die (it’s not like the water is pH balanced) others have a pretty good idea what Jonah went through. Needless to say, you just don’t get too attached to goldfish…

So one day, my mother brings home a dozen goldfish – apparently they were on sale somewhere – and we proceed to dump them into our various tanks. As expected, about half died almost instantly perhaps from the shock of moving from the fish equivalent of a studio apartment to a 50,000 square foot mansion. Or maybe they were just afraid of cows. But the other half survived. Strike that, they thrived. Not only did they make it through the winter (the tanks were heated to prevent freezing), they had babies. And they changed color – they weren’t gold, they were a brownish camouflage, in fact you could barely see them. They also grew…a lot. While they probably wouldn’t have tempted a pro bass angler, these weren’t your little sister’s fish. Needless to say, we were quite impressed with our little fish farm!

Lets see, I had a point…really. Oh yeah, meetings are like goldfish – they grow to the size of their container. I’ve attended A LOT of meetings lately (my teammates were planning to steal my computer…there was a pool to see how long it would take me to notice) and I’ve discovered that if you schedule a meeting for 1 hour – it will take 1 hour…or longer. Ever so rarely, you’ll get done with what you set out to accomplish in less time than you budgeted and people will actually break but more often than not they just stick around. I think it’s a similar mentality to many a golfer these days – I paid my green fee and I’m going to take my time darn-it. Or maybe so many people live in meetings all day that they can’t imagine being anywhere else. Of course these sickos have bladders of steel.

I’ve also discovered that meetings will quickly fill the open slots on your calendar. Like I said, the last couple of weeks I’ve been getting my mail delivered to conference rooms. Without fail, I’ll check my schedule in the morning, content that I’ll have a couple of hours to answer email only to find by the end of my first or second meeting the cracks in my day are filled. It’s kind of like Field of Dreams – if there is an opening, chances are someone will take it.

I’m not (completely) railing against meetings – sometimes they really are necessary. But the next time you schedule a meeting, ask yourself: do we really need to meet on this or will email suffice? When you do schedule a meeting, make sure you only invite those people that absolutely need to be there. I know, maybe you work at one of those places where your boss (or user) insists that he (or she) be in any meeting where any decision is made but don’t take that to mean you need to invite half your team. And if you think you’ll only need 30 minutes then only schedule the meeting for 30 minutes! Give people an hour and they’ll use it, force them to economize. Of course you may want to book the room for an hour… One last thing – if you schedule a meeting for Friday afternoon, bring treats. You owe us.

Categories: Off Topic, Rants Tags:

Geek Music

December 8th, 2005 4 comments

Now maybe I’m not hip anymore and maybe we geeks just aren’t very “cool” but darn it, we can sing! I’ve been meaning to mention Roumen‘s NetBeans song for some time now. First of all, the lyrics are fantastic but you really need to listen to him sing it! If you don’t think NetBeans is worth checking out yet, the song should convince you ;)

When I first stumbled on the NetBeans Song, I certainly didn’t realize that this was a trend! Today I was catching up on some of my podcasts when I gave Michael Mahemoff’s Basics of Ajax podcast a listen. Ajax Patterns is a great resource (I’m very interested in the book!) and I also enjoy Software As She’s Developed. What really stood out in this particular podcast though was the very end where he included OK-Cancel‘s first-rate HCI Rap “We Got It.” Now, you really have to be a geek to fully appreciate it but trust me, you have to give this a listen! I’m a closet HCI guy and I was really jamming along, but, apparently I still can’t dance… Are there other examples of geek music out there?

Categories: Off Topic, Software, Usability Tags:

The Ajax Spoof

December 7th, 2005 7 comments

By now, I suspect you may have noticed this piece: Why Ajax Sucks (Most of the Time) which, at first glance, looks an awful lot like an Alertbox from noted usability expert Jakob Nielsen’s site. I for one am a fan of Alertbox and have read a couple of his books (and of course I think the other N in NN/g is one of the best minds around – check out his site: and go read Design of Everyday Things. Seriously, go ahead, I’ll wait.) so I was really interested to see what Nielsen would have to say about Ajax. Of course, it didn’t take long to realize this was just a some folks having a little fun! BTW – Nielsen has posted a note on his site disavowing any connection…

The first notice I got of this was from my old college advisor – he wanted my input! I’m not sure if he knew it was a hoax (and was just testing me) or if he wanted my honest feedback. Ajaxian got into the mix too: Alertbox Spoof: “Why Ajax Sucks (Most of the Time)“. This clever piece arose from Confusability – and they’re having quite a bit of fun with it! Check out their link to the spoof, and their follow up Hurricane Ajax – The Aftermath.

While we can all have a good laugh about this little spoof, it does raise an important issue: what are the usability impacts of Ajax? Frankly, I think Ajax is one of the first technologies I’ve encountered where I can truly say – it significantly improves the user experience (if used properly). On my application we think Ajax can make a real difference – enhancements our customers will notice. But it has to be done with care. Like any good tool, Ajax can both help and hurt depending on how it’s applied. Done right, you’ll exceed users’ expectations. Do it poorly and all you’ll do is increase their frustration. How do you know what you’re doing? It’s really simple – just test it with real users. If you screwed up you’ll find out pretty fast.

Categories: Ajax, Usability Tags:

Where is the Print Button?

December 7th, 2005 3 comments

Virtually everything I read these days comes from the web – beyond just a few parts of the Sunday paper, I get all my news from online sources. I also read a ton of blogs and whatnot and while I don’t mind reading short pieces on a screen at a certain point I just want a physical copy.

Most news sites get this and accordingly have a print button somewhere on the screen. Lately I’ve been using aggregators like Google News so the articles I’m reading are coming from a variety of sources and inevitably I end up searching for a print button! With all the design guidelines out there and the general commonalities on the web, why is there so much variety when it comes to print options? Sometimes it’s a link, other times a button. I’ve seen the link/button at the bottom of a story, the top, the left, the right…I mean come on, can’t we all just agree on an approach here? I know that the actual formating of the page for printing can be tricky but can’t we at least come to a consensus for *where* to find the darn thing?

I can understand (somewhat) that different sites act differently, but what about good old CNN? If you go to a normal news story – say this one about Katrina relief, you’ll find PRINT THIS at the bottom of the story. However, if you venture over to CNNMoney – say this article about AMT relief, you see PRINT at the top of the story. Sigh. They don’t look the same, heck they aren’t even named the same… Honestly, do news sites actually think people only use one source?

Here are just a few different print options:

Maybe I missed it, but have any of the usability guys provided some thoughts on this? Is it just me, am I just getting cranky? And don’t get me started on pages that don’t even have a Print button…oh wait, my site doesn’t!

Categories: Usability Tags:

More Thoughts on SaaS

December 5th, 2005 2 comments

Last week, I wrote a piece on The downside of software as service. As so often is the case these days, today I ran into a few interesting comments along the same line. Last week, Financial Times posted an article by Richard Waters called The future ends at the firewall. Waters explores the growing divide between the applications people use at home versus what they can use at work. Part of this is a bandwidth issue but more importantly, most IT shops lock the desktop down pretty tight these days. As a former corporate IT person, I totally understand the logic behind this – the net is full of nasty little bugs and many an end user just doesn’t get that they shouldn’t open up that attachment from their friend.

But it doesn’t just stop with the ability to install software. Many companies have their firewalls zipped up blocking all sorts of sites. Some of this makes sense – I mean, if you’re surfing girlsgonewild at work, you are asking to get fired. Still, the filters I’ve encountered are crude at best (I once had an email from Sun blocked…near as I can tell, the filter didn’t like the acronym for Java User Group…) and why other sites were blocked just didn’t make sense to me. At my previous employer, all web based email was blocked – boy, I didn’t realize what a pain that was until I moved. While I don’t check my mail constantly, it’s sure handy to bop in there from time to time.

All that said, I get why most corporate shops are locked down and I’m not sure I blame them. Still, I have to wonder what happens when our customers get used to working with some of these apps at home and start to demand them at the office. Are we really doing them a service? What happens when they get frustrated and find a way around us? It seems to me that we are much better off trying to get ahead of this trend and managing it as opposed to trying to kill it (ask the RIAA how their approach is working with illegal music downloads…it’s pretty hard to buck the market). We need to facilitate innovation! I use Basecamp and Backpack a lot and I think they would help many an organization yet I suspect some firewalls block them. Is it any wonder more and more corporations are outsourcing IT? How many companies look at their IT shop as a slow moving impediment that spends more time saying no than helping drive results? Why not find the lowest bidder – the service couldn’t be any worse. We may not like QD (quick and dirty) but sometimes that is exactly what is called for.

There is yet another angle on SaaS that caught my attention – do we trust the organizations that have our information? It’s one thing to have a few links on but what happens when Google has access not only to all your email but all your searches, documents and spreadsheets? Personally, I have a lot of faith in Google but what happens when their stock price drops and angry shareholders start demanding they take advantage of the vast wealth of personal information they have? What company wouldn’t pay handsomely for access to data on all the searches done on Google? Of course a lot of people think Google is evil!

Alex Bosworth has a post along these lines: Trust, Morality, and Software Services. While it’s one thing for a company to sell our personal information, what happens when governments get involved? Apparently Yahoo turned over a reporters personal data:

The Chinese government, one of the most corrupt and repressive regimes in the world, decided that this reporter was a traitor and asked Yahoo to hand over the reporter’s identity. In an unbelievable breach of ethics, Yahoo responded to China’s request by handing over personal details about the reporter without any resistance.

Recently Google searches were used against a murder suspect – now prosecutors say they got the information from the man’s computer but the just as easily could have asked Google directly. We may trust Google but what happens when a subpoena arrives? Anything in your search history that you might not want to share? I can’t wait for this to be used in a race for some political office “my opponent is of weak moral character – he routinely searched for…”

I think most of us don’t mind sharing data – as long as we know exactly what we sharing and with whom. I don’t mind that Amazon knows what books I’ve purchased and I’m pretty intrigued by what they recommend to me based on this data. However, I wouldn’t be pleased if I found out they were routinely selling that information to third parties. I’ve had an ING account for quite a while now (how can you beat an FDIC insured account yielding 3.75%?) and I was really amazed when I got their privacy statement – they’ve adopted opt-in. As far as I am concerned opt-in should be the default…not the other way around. Maybe a lot of people don’t care as much as I do but anytime I run into a site that says “we will not sell you information…ever…unless you let us” well, I get a lot more loyal to that site then one that says “we value you’re privacy, which is why you can opt out if you call 1-800-we-sellu between noon and 1 on the third Tuesday of the month and ask for form 7452.”

Privacy will be one of the major issues of the next 10-20 years and I think people are coming around to the value of their personal information (how many of you have shredders now?) Still, I think it will take a few Senators having their identity stolen to see substantial change.

Categories: Off Topic, Rants, Software Tags:

Ryan & Me

December 4th, 2005 No comments

On the off chance that you want to see what Ryan and I look like, Roumen posted a couple of pictures of us. We’re modeling the stylish shirts the kind folks at NetBeans sent us (thanks again!) This pictures were taken by my lovely wife (who is also extremely patient – she did sit around and listen to us talk for a couple of hours) just after our talk at TC JUG. As we’ve mentioned before, we wrote all the examples in Foundations of Ajax using NetBeans. Seriously – if you haven’t tried NetBeans in a while, you really should, I’m a convert, enough so that I added a banner to my site. And no, I don’t earn fees from anything you see on the sidebar – they are all organizations I feel strongly about supporting.

Speaking of talks – just a quite reminder that I’ll be talking at Code Freeze 2006 in January – if you’re in the Twin Cities area I hope to see you there. Also, Ryan and I will be speaking at OTUG in April. There is also a pretty good chance I’ll be talking at St. John’s in the spring sometime.

Categories: Ajax, Off Topic Tags: