SMS vs. Pen and Paper

October 19, 2008

I realized something recently that using SMS for capturing quick notes might actually work better than pen and paper. To me, pen and paper is the most effective interface ever created. It is easy to use, intuitive, and the results of user actions are completely predictable. All these points are key to a good user experience. The notion that SMS could compete with the almighty pen was an interesting revelation that was worth noting.

I came to this realization while visiting my sister in New York. I was impressed with her latest life improvement campaign. Her focus and progress have been amazing, if typical of her. You see, my sister is the oldest in the family and the classic over-achiever. She was a stats major at Berkeley and became a senior partner in the actuarial practice (read mathematician on steroids) at KPMG. Therefore, I was not surprised by her driving progress, but what I found interesting was the key to her success. Her “coach” presented her campaign as a mathematical problem.

Can you say math geek?

My sister tracks her progress every day in a journal including the aforementioned mathematical process which she hand calculates. Can you see where a Web site would start to help? You leave your journal at home and need to record an entry. You do the same calculation every day which could lead to a mistake. You are tracking progress over time and that is something computers are made for. No brainer. Fire up Ruby on Rails and let’s create a startup.

But then, I noticed the true challenge in this scenario. Her journal uses the most intuitive user interface on the planet, pen and paper. So simple to use. Free from power supplies and foreign oil.

Damn you pen and paper! Mocking me as you sit open faced on the kitchen table. Damn you!

How many times have you read in my posts that I love simple and intuitive technology. GPS systems. Door knobs. And now, pen and paper. I was about to tell my sis that she was better off with the system she had when her husband pointed out something very interesting. My sister texts all the time. She has her Blackberry out at my nephew’s t-ball games. She reads email during meetings. She has her device open more than anything else.

Ah ha, the crackberry is mightier than the pen!

We quickly surmised that if my sister could capture her journal entries via SMS, she would have a more effective way to track her progress. Then, she would get the other benefits Web sites offer like historic tracking, search, automatic calculation, email reminders, and many other features we brainstormed that day in the kitchen in front of the demoralized pad no less.

Give that man a ribbon!

I am still mulling over developing the site. But truthfully, SMS to me creates a better user experience and provides a more effective tool for tracking then pen and paper. Writing a message is as simple as taking a note. Carrying a Blackberry now happens as frequently as keeping a pad in your bag. Capturing data via the Internet enables the many benefits of using computers to store data and manage processes.

Hurdle overcome, now what’s next? Oh yeah, if I could just capture some of her drive, I might have built the thing already ;)


Users Really Don’t Want To Think, So Don’t Make Them

October 9, 2008

I am reading Don’t Make Me Think by Steve Krug. His book discusses an interesting philosophy for creating simple and effective interfaces for users. The basic premise is making users think too much is a bad thing. Makes sense to me. I recently had my own encounter with being made to think which helped me appreciate the salient points of the book. And from there, I had a better understanding for how to make my own projects more intuitive. This is something you should think about too!

In reading the book, I was struck by how much of a simpleton the author thinks the average user must be. If the user can’t reach a conclusion quickly, the book presents, he is more likely to move on than continue looking. Users won’t read a paragraph of content. Count yourself lucky if they read to the end of the first sentence.

I am a big fan of creating interfaces that don’t require the user to hunt or guess what will happen. But should I really design a site the does not force the user to think? Isn’t it insulting to users to assume their attention span is that short? That users are that impatient? Will I truly draw active users to my site if I target the lowest common denominator so to speak?

Boy was I surprised to find out I was in this very category of user. Here is my sad tale.

I live in Napa where I belong to a number of wine clubs. I agree to buy a predefined shipment of wine every other month in exchange for discounts and other benefits. I got the following email from one such club a few months back:

Your July Wine Club shipment is set to ship or is available for pick up on July 14th. For those of you scheduled to pick up your wine, please note that we will also send an email and post card to let you know that it is available at the winery.

I read the email and drove to the winery the next weekend, on July 6th, to pick up my wine. What do you think happened when I got there? They told me that my wine was not ready for pickup. How can that be, I asked, I got the email saying it was time. We brought up the above email. Any ideas where the mistake was made?

You see, once I read “is available for pickup”, I didn’t read any more. I assumed the rest of the email was filled with marketing fluff or up sell or something else unworthy of my valuable time. I didn’t THINK to read anymore.

OMG, I am one of those users who doesn’t think!

The real issue here is the email. The tense is all wrong. If they simply had changed the words “is available” to the words “will be available“, then I would have kept reading to see when. I get hundreds of emails a week that I have to process while doing real work. Once I know what the email is about, a conclusion I am forced to draw rather quickly, I take whatever action is needed and move on. Plus, sending me an email in advance is useless as I am not likely to create an Outlook reminder for something like this. Would you?

I spoke to people at the winery about the issue after realizing that I would not get my shipment. They indicated I was not the only one who had done this. They did not give me my shipment early while I was there, which to me is just plain bad customer service. You see, it was my fault not theirs, right? I misread the email.

What I can tell you is that Steve Krug, the author if this book, is right on the money. We are all potentially users who do not think. You should keep that in mind as you develop your software. I’d recommend you get the book and then see how your work measures up. You just may be surprised.

UPDATE: After publishing this post, I received the follow up email from the wine club that my shipment was ready. This email was received on July 9. Here’s the email:

Your June club order has been processed and will be ready for pick up on June 30th at the winery.

Once again the tense is wrong. How can they say my pickup will be ready when the date referenced is in the past? Plus, if it was ready on June 30th, how come they didn’t give me my wine when I was there on July 6th? Truthfully, this is the downside of making users think. If your force them to really think about it, maybe they will conclude something other than you expected. I think I will email them and tell them to just email me when I should come over. Think they will listen to me?


Development Patterns for Technology ™

October 2, 2008

People in technology use patterns for everything from coding strategies to development strategies to interface design. We follow patterns because patterns a pattern represents a safe plan to a result that generally someone else has done before and validated. But patterns can also lead us into a false sense of security by turning innovators into followers and turning our products into another version of what has been done before. I thought I would offer my own thoughts on the benefits and pitfalls for following development patterns for technology ™.

I was reading an interesting
TechCrunch post about public relations titled PR Secrets for Startups by Brian Solis. This caught my eye because, as many of you know, Open Mountain targets startups as our primary customer. What was interesting in this post was the comment on PR “patterns”. PR firms had, over time, become less about relations to the public and more about following a certain pattern of information dissemination.

Something we should share begets a press release to the Roladex and PR wire. Why do anything different?

His point was that PR had fallen into the above pattern of action and that Web 2.0 may have finally shocked the PR industry out of this rut. Truth is, pattern behavior is all around us, which in turn leads to automated decision making and that is bad news.

Take open source as an example. A few years back, Linux finally established that open source software works as good if not better than commercial software. Suddenly, CFO’s were slashing IT budgets and demanding that their teams go open source full throttle because it was free. Does anyone still think open source means free? No. Once the CFO’s got over this pattern, we settled into the process we have today for evaluating open source right along side commercial software.

As another example, during the height of the boom, many investors were pushing Java running on BEA servers on top of an Oracle database because that was a pattern they knew worked. Of course now we know that the pattern of JBoss with MySQL is equally viable and less expensive for startups.

Patterns at the end of the day are neither good nor bad. The best companies and thinkers see the pattern as another data point. Following established development patterns for technology ™ has some nice benefits, but in the end this is just another decision along with what language to use, when to launch, how to host your solutions, etc.

Here are five benefits to consider when selecting or following a pattern:

  1. Communities form around patterns. People doing similar things are likely to share their experiences, and the resulting knowledge base is definitely beneficial to the community.
  2. Patterns create stability through consistency. Solutions are more stable if the underpinnings are based on technologies and methodologies that are tried and proven.
  3. Once you decide to use a pattern, the set of new decisions you need to make shrinks more rapidly than without a pattern. Teams can move faster by focusing on decisions outside the pattern.
  4. It’s less risky to follow than lead when it comes to everything but your core competency. You want to be leading edge with your core competency and the soul of your business. Patterns allow you to use the experience of others to solve everything else.
  5. Patterns are easier to communicate to non-experts. Once something becomes a pattern, it is often synthesized down to a key set of principals and benefits that are easy to share with the world.

But if you follow a pattern, here are some things to watch for:

  • Be wary of patterns that are not driven by experts. Having an investor tell you to use Java is not the same thing as reading it on TheServerSide or hearing it from James Gosling.
  • New patterns do not have the same benefits as established patterns. A great example of this is the scalability of Ruby on Rails, which is a hot issue right now. Some industry experts have expressed a concern over the scalability of the RoR pattern based on the experience of a few companies. I have no doubt the scalability issues will be solved as they were with Java and enterprise beans. Established patterns are less likely have these types of fundamental issues.
  • Patterns can lower your decision making capability. At the end of the day, a pattern is a tool not a solution. People following patterns can forget that and start to make their decisions based on what others have already done. If you follow that trend for your core competency, then you might as well move on to something new because you are already doing something that has already been done.

For us at Open Mountain, we often suggest patterns for development, right after we make sure we understand what your business is about. Patterns have nice benefits that we like to use to take the risk out of development.

(I posted this originally on May 25, 2008 and decided to re-post)