Showing posts with label blog. Show all posts
Showing posts with label blog. Show all posts

Saturday, June 28, 2008

Tale of Two Blogs

I know all kinds of folks out there have talked about this, but I wanna add my two cents and it's my blog so...

It is friggin' hard to have both a company blog and a personal blog and not just talk about useless drivel on the personal one.

The difficulty I'm having is that there are things I want to talk about on this blog that simply don't fit in with the overall goals of my company. These things are in the same idea-space as LiquidPlanner's project management stuff so it is hard to keep them separated.

If I have a good idea for a blog post and it fits in well with the mission of LiquidPlanner then I want to post it to the company blog. But when they don't fit in so well I don't really want to post them here because... well... someone might read it and confuse my ramblings here with our company position on many of these issues.

So I've decided I'm gonna be brave. I'm gonna post here a bunch of the things that don't really fit in with LiquidPlanner so well. So there'll be a bit of a change in tone over the next couple of weeks here. There will be things that didn't really fit in with the original idea of this blog as a digression on project management and organizational wackiness inside of a larger company.

And there will be a lot more posting.

Saturday, January 19, 2008

Mmm... Donuts

Amy Hoy has a great little blog called Slash7. I highly recommend it. She recently reposted an old article "The Ape and the Donut Eater" about interaction design and how good humans are at abstract learning about things like ordering donuts at a donut shop, or opening doors (there are a lot of different kinds of doors).

I started to write a short comment but to paraphrase Mark Twain, I didn't have time to write a short comment so I wrote a long one. One that I want to expand upon here...

The gist of her post is that there are all kinds of things that after we have learned to do them seems super simple. But if you're approaching them for the first time they seem confusing or complex. The techniques for dealing with these things are what get us through the day. Those learned techniques allow for a level of interaction with complex technology (like doors or computers , and if you don't believe me about doors just read her article).

This line of thought got me to thinking. For interaction design I wonder if things can't be split into two broad categories. I don't really know how to label them but let's try...

  1. Has cultural support desk
  2. Has no cultural support desk


Her donut shop example is a good one:

When you think about it, ordering doughnuts is a technique we all know, and if you didn't know, it might be kind of difficult to start. You have to know that doughnuts are generally sold in dozens and half-dozens (otherwise, you pay out the nose), and that when you say "I'd like a dozen doughnuts, please," the person working behind the counter will grab a box, some tissues, and then stand there, waiting for your instructions.

- Amy Hoy, Slash7

In North America there is a culture of how to order at a donut shop. You can watch other people placing their orders and at least attempt to infer what it is you're supposed to be doing. That's a case of there being a culture there to support the new "user".

Suppose that there was no culture of ordering at a donut shop. Then you couldn't even watch the actions of other customers because they don't know what to do either. There's no cultural support desk.

Software, particularly really new software has this problem in spades.

While designing the interface for LiquidPlanner (the product I'm currently working on) we ran into this problem. We needed to show uncertainty in the time it takes to complete a task. Like most problems we could break it down and most of the pieces had parallels that folks would just "get" (i.e. there is cultural support for them). But there wasn't anything out there doing this, so there isn't "some guy down the hall" who knows what the do-dads on the chart mean and can explain it to you when you get confused.

This is the point where I think real interaction designers shine. The good ones out there are worth their weight in proverbial gold because they make the user feel smart with designs that play to your preconceptions rather than fighting against them.

They are also good at dropping little nuggets of information along the way without getting all "RTFM" on you.

Speaking of which... have you noticed that when posting comments on blogs (or forums or...) that folks seldom tell you which markup language to use? Is HTML allowed? Which tags? RedCloth? LefthandedReversePolishPolyMarkDown?

I run into this all the time when commenting. A simple link to a reference and a preview would make me so much more likely to comment since I'd worry less about looking stupid (I still may sound stupid however). Blogger (the site this blog is hosted upon at the time of this writing) is a good example. They give a happy little "these tags are allowed" and a nifty preview button.

Anyway, time to get back to rehearsing my 6 minute DEMO demo. Did I mention that we're going to DEMO?