Have I mentioned I’m on Twitter?

I seem to be posting there a lot more frequently than I am on the blog. Here are my latest thoughts:

Introducing TwiddleEast

This weekend as Israelis and Palestinians clashed again in Gaza, and it seemed like everyone had a reaction to the violence.

As I consumed the popular media, I began to think about the more pedestrian views out there. It is important to understand what the everyman thinks, even if one does not agree with him or her (and I certainly do not agree with many of the opinions out there). After all, it is only by understanding others’ points of view that we will ever get ourselves out of these international confrontations. Peace comes when people understand and interact with one another.

A great place to get at peoples’ opinions is the popular new communication tool: Twitter. Twitter allows users to post messages, opinions, and thoughts 140 characters at a time. Each post is a tiny glance at a person’s thought. If you’re not a member yet, you should give Twitter a try. It’s quite fun and addictive.

So, as I set out to glance at what people were saying about the situation in the Middle East via Twitter, I decided to build a tool that would help with this task. And so I did just that, with TwiddleEast.

Here's what TwiddleEast looks like
Here's what TwiddleEast looks like

TwiddleEast allows you to quickly glance at what people on Twitter are saying about a few of the Middle Eastern countries in the news today.

Check it out, and I’d love to hear if it is helpful to you. If there is anything I can do to make TwiddleEast better, don’t hesitate to let me know, and while you’re at it: follow me or TwiddleEast on Twitter.

On Winter and Payback

I spent nearly an hour this afternoon digging my car out from a pile of snow and slippery ice. I had done the same thing yesterday, though it was less ice and much more snow. Winter in a cold climate tests one’s will to commune. All those hours holed up indoors means that you’re not interacting with people, nature, or the world in general.

This afternoon I was convinced that it was time to get out. Time to persevere (against a zero-degree temperature) and try, at least a little, to get something done. So I packed my side bag and headed out to the gym. That’s when I met my hurdle: digging out the car.

I started the activity the way I normally do: by starting up the engine (because if it’s too cold for that to happen, then there’s no point in the rest) and blasting the defroster. I then brushed and scraped the car, and checked the tires to make sure they were in a good position to free themselves. Everything looked fine, and as I waited for my windshield to fully defrost I thought positively about how I would get out of my spot. I pictured the car rocking gently back and forth and then, almost comically, jumping out of its spot and onto the nice, soft, well-plowed street.

The ease of my vision was not to be in real life. I rocked my car plenty, but managed to get myself stuck and re-stuck three times. Yes, that’s right, I said three times. Each time I ran into my apartment building and grabbed the steel-headed shovel, ran back outside and cleared as much ice as I could away from the wheels. And each time I found myself stuck again, only to repeat the whole process.

Finally, in frustration, I decided to give up. This was enough of a workout for the day. Shoveling snow is not as easy as it may sound. You have to realize that that soft snowy powder that you may be picturing eventually turns into big, heavy boulders of ice and hard rocks. (This is why there are many heart attacks during winter…people forget how difficult it is to shovel snow.) As I surveyed where my car lay, I realized I was blocking an alleyway. So not only was I stuck and ready to give up, but I also had to do something to get myself unstuck.

Luckily, a nice man from the next apartment over had seen my struggle and came outside to offer a hand. After a bit of pushing he was unable to free me from the predicament. We talked about strategy for a few minutes, and then another man showed up. “Easy on the gas, real easy,” he said. Another couple of heaves and ten seconds later my car was free.

When I returned home a bit later after a drive to cool my insides down I found a nice parking spot that should be a bit easier to get out of. As I approached my apartment I spotted a car with its wheels spinning. With the driver accelerating, I pushed the car out of its spot. A few minutes later when I ran to my car to pick up the forgotten shovel, I spotted the man I had pushed out helping yet another stranger. As I passed he waved and said thanks, and I relayed my story of just an hour earlier. We laughed it off and shared a, “yup, it’s finally really winter again” moment.

This is what it’s like to live in Chicago. It’s a city that’s tough as it is soft. It’s a place where people push past and look out for each other. A place where we don’t interact much in the winter, but when it’s needed, people are glad to lend a hand.

This is where I live and despite the tough parts, I love when the gentle, helpful side of this city emerges. It’s like no other place I’ve lived.

Get out and vote

And all you people are the heroes I’ve known
We’re staring off the edge into the unknown
We are not there yet, but we cannot go home
So we cry and we sing
Yeah I remember everything

How for once in our lives
We saw what we wanted and took a bite.
We picked the fruit from the tree, and it was ripe.
And it was ripe, and it was ripe, and it was ripe.”

– Ben Lee, “Ripe”

If you’re American, get out there and vote today. It’s your civic duty. We’re all counting on you. Thanks.

Google Chrome’s Design Comic

So the big news on the internets today is Google’s new browser: Chrome. It’s only available for Windows as of today, and since I’m on a Mac I haven’t been able to play with it yet. But that’s ok, because Google hasn’t completely left me out of the loop. I have access to the comic interpretation of their engineering decisions.

Google Chrome Design Comic
Google Chrome Design Comic

Comics have been a topic of discussion in the Interaction Design Community for a while now. With Scott McCloud providing the art for Google’s message, they really couldn’t go wrong. McCloud has quite literally written the book(s) on creating effective comics. (Of course, you can create your own design comics too, thanks to projects like Martin Hardee’s Design Comics.)

One thing that I’d like to applaud Google for with this comic is their use of actual Googlers as the narrators of the story. Naming names like this gives credit to the actual thinkers behind the work. All too often in the business world today, we hide individuals behind a big corporate brand. In this example, these Googlers will feel real ownership and responsibility for their product, and they’ll be motivated to continue working on the project even if (and when) they leave Google. Of course, I’d also like to call out the fact that no User Experience team members were named in this document, even in the section titled “Search and the User Experience.” This is strange, and I hope there was a User Experience team dedicated to this project.

And another thing Google did well here was in not trying to over-engineer their explanations of highly technical processes. They simplified their message down to bare essentials, and I felt enlightened after reading this document. Most technical documentation talks down to people, assuming that all the basics are already understood. Google removed some barriers to entry by explaining their new technologies in a way that almost anyone with a little technical know-how can understand. This is something almost every other open source project out there fails at. Technical documentation is far more than simply documentation…it’s an implicit invitation to take part in the experience.

Browser Threads Vs. Processes
Browser Threads Vs. Processes

At the end of the day, I’m really impressed at the quality of this documentation. I actually read the entire thing, which is much more than I can say about the technical documentation for any other software I use. Who knew that I could find the difference between multiple threads and multiple processes interesting?

Well done, Google. Now I just have to find a Windows computer…ugh. I swore off those things months ago…

Ask “What if” Questions

What if we could travel 5 miles in less than 5 minutes?

What if we could watch movies in our own homes?

What if we could buy things for a whole day without using any paper money?

What if we could communicate with friends on the other side of the world without leaving the house?

I hope you noticed that, in fact, we can do all these things today. However, a mere 100 years ago, these questions would have been dismissed as pipe dreams by most people. But dreamers dream, designers design, technologists build, and before you know it, really difficult problems find solutions.

This is why I try to take the long view when thinking about design problems. Today’s technology is ephemeral, it will be gone before you know it. But when you find solutions to the big problems, those interactions can last for centuries. So the next time you start a project, instead of asking, “What would the UI look like to solve this problem?” (or even worse, “What will the architecture of the software look like?”) ask “What if we could ________?” And fill in the blank with a really challenging problem.

After all, if you’re like me, you didn’t get into technology to solve tiny little problems. You got into technology to make lives better & jobs easier. You got into technology because there are challenging problems to be solved. What if you solved them?

Comments on a User Interface Manifesto

Jono DiCarlo at Mozilla Labs documented his feelings about user interface design in a great post titled These Things I Believe. While I do not agree with him across the board, he does make some interesting points, and helps guide software developers toward the (great user experience) light. I’ll call out a few of his assertions here:

Software is for humans, not computers

This is the only absolute truth in the world of technology. Software architectures change, programming languages go through cycles of popularity, and code design patterns will be preferred by some over others. At the end of the day, though, the software we build is always being built to help some human be more productive, happy, or both, even if it literally has no user interface. Before building your next piece of software, I implore you to ask yourself how this software will make the world a better place, as Jono suggests.

People use computers to connect with other people

’nuff said. This is the only reason 99% of people use computers at all. (If you’re reading this, you’re probably not part of the 99%. That’s ok though, because you are not your user.)

There’s no such thing as free software

Open Source software is, by and large, really difficult to use. I would never leave my mom alone in a room with Linux, it’s just too cruel. Like Jono says, “Linux is only free if the value of my time is zero.”

The job of the UI Designer is to provide what the users need, not what they say they need

This paradoxical statement succinctly defines what it is that I do for 40+ hours every week. There are various methods that provide clues as to what users really need, other methods that design for those clues, and still other methods that test whether the users’ needs have been fulfilled. What I do at work all day is carry out those methods.

User interface design can be approached scientifically. But usually isn’t.

This is where Jono and I will disagree. He lays out a list of metrics that can bring about statistically significant results when it comes to usability testing software. My clients frequently argue to me that if we drive down the number of clicks in an application it will be easier to use. I don’t care about click counts. I’ve seen well liked software with high click counts, and hated software with low click counts. On top of this, while gathering metrics based on click counts, frequency of use, time on task, error rates, and error frequency may get you some information about your software (which is good), these methods never tell you how to fix the problems. Real world, in-situ usability testing will tell you these problems, and suggest solutions.

It is a sin to waste the user’s time, break the user’s train of thought, or lose the user’s work.

Yup, sin is the right word to use here. Have you sinned lately?

Thanks to Jono for creating this list. Maybe one day I’ll make one of my own. 🙂

Generate Design Ideas. Rinse. Repeat.

Adaptive Path‘s Kumi Akiyoshi blogged a quick piece about the visual design of Aurora. I really love the exploratory designs that were created before deciding on the one we saw in the videos. I don’t necessarily love all of the features within them, but it is so important to create multiple design options before settling on the one that will be developed.

Aurora Design Option

A visual design option for Adaptive Path’s Aurora, by Kumi Akiyoshi

Another Aurora Design Option

Another design option (see more)

These examples show different options for the visual design, but you can generate ideas for anything you design. I do this all the time when I’m designing exactly how a feature will work. Anyway, go check out Kumi’s post. There’s lots more to see.