Software Development from Ryan

It’s not easy to be swayed to try something new, especially from advertising, and definitely if you have to pay for it. Old marketing doesn’t really work well even though it still lingering around. I find the only way I try something new is if its recommended by someone I know and this doesn’t happen very often.

Lately there have been a few blips on my radar for Chipotles. It was recommended both as a company worth investing in and having burritos worth tasting. So recently, being in the area, wife, baby and I decided to try it and it was an educational experience. Not only is their food pretty good but the whole customer experience, while simple, is well polished.

I’ve been looking a little closer at customer experience over the past couple months. It’s essentially the consumer version of software’s user experience. In both cases a product is not the focus of design. Instead, the focus is the experience surrounding the product. I suppose these thoughts stem from having read Do you matter recently (the one takeaway point I got from this is that a solid culture of design is necessary on a team that builds good customer experience). Making this link between the two types of design broadens the horizon of inspiration for designing software experiences. And of course, of particular inspiration is Chipotles. Here’s a few design ideas taken from Chipotles customer experience:

1. Limit Selection. I hate ordering food when the menu is long. It’s a lot of work figuring out what the best thing is to order. With long menus its a research project. Why do these restaurants make me do all this work? In contrast, if you go to Chipotles you can get Burritos or Tacos either with Chicken, Steak, or Pork, all for the same price.
2. Don’t Limit the Extras. They aren’t part of the product but contribute to the experience. These are generally the first things that get cut when trying to reduce costs but they’re usually the cheapest and contribute the most to the experience. For example, Chipotles lets you choose how many napkins you need, lets you help yourself to sliced lemons and full bottles of tobasco sauce. That my not seem like much but the experience is miles better than hot sauce packets and napkin dispensers. Google follows this technique with GMail’s ever increasing limit. You may not ever come close to that limit but its nice to know its high.
3. Care. This is more than a customer service smile. It’s caring about the details. When ordering there was a notice that the meat they used was free of chemicals and vegetable fed. When we sat down we received a bib for our baby (although she was not eating burritos!). When we used our napkins to clean up what became a messy burrito we saw, on the back of the napkin, instructions on how to unwrap and eat your burrito without making a mess.

I’m curious to see what other companies are paying attention to details like this in the software world. If you bump to any, send me an email!

Often I’m presented with a new web application that has a fantastic new interface and I just don’t get it. For example, here’s the interface for chime.tv:

This is an neat application built on you tube that has a joost like feel. I can understand that this looks cool but there’s always been a usability issue that I could never pinpoint with flash interfaces like this. If you look at the YouTube interface now you may find it more inviting and familiar:

Flash use in this case is minimized to the media player. The rest of the interface is HTML based. The blue links are familiar along with the rectangular vertical scrolling layout. This is how I use my browser, clicking links and scrolling. I even have a wheel on my mouse for it.

Let’s look at another example thats not as obvious: comparing Yahoo maps which uses a Flash interface to Google maps which uses a HTML interface. Here’s Yahoo:

Here’s Google:

I would say that at face value Yahoo looks better (even though Yahoo is showing me Buffalo instead of Toronto!). But with Google’s those little blue links can do wonders. I know exactly what the interface is implying by presenting those links. If I click them they will take me somewhere. The list on the left in the Yahoo interface is also clickable but it is less predictable what will happen.

I’ve struggled with this type of uncertainty about Flash interfaces for a long time. No matter how good they look they just don’t feel right. I wrote an instant messenger app several years ago initially with a skinned interface. It looked pretty cool but I eventually reverted back to a standard interface with controls provided by the operating system. Recently I’ve given this some thought and have come to a conclusion. Constructed interfaces are better for usability that drawn interfaces, (no matter how good your graphic designer is).

Whats the difference? A drawn interface is one that is created in a program like Flash. Flash is a really great app but I believe it is better for animations and multimedia than application interfaces. Basically, with drawn interfaces you need to draw your controls. A constructed interface is one where you use preexisting controls to build your interface.

Yes, the preexisting controls can get boring but its something you have to live with. We need standards like this so that we don’t have to think about performing simple tasks.

There’s also the argument that with drawn interfaces or skins you can replicate any operating system control. This essentially is true but nearly impossible to pull off properly without an enormous amount of work. Take for example the Google Maps and Yahoo Maps example. Yahoo comes pretty close to making controls that resemble operating system controls. They take an operating system agnostic approach where there controls are a compromise between operating systems. Take a look at the scrollbar for example. It looks similar to a Mac scrollback but its slightly different. The scroll arrows are at the top and bottom like on Windows. Another thing to note is the text is all anti aliased. This looks find when you’re on an OS/browser that automatically does this. But if you’re on IE6 the having anti aliased links looks different. Different can be good sometimes but its bad when it causes the user to think for even a split second.

It will be interesting to see which direction this heads. I’m definitely on the constructed interface side of things using GWT which uses the native browser controls. Rich client applications are making it big in the browser and there is a lot of new technology coming out that aims to tackle this including Silverlight, JavaFX, and AIR. It’s good to know that the iphone is on the constructed side, and Apple knows usability right?

Originally they had a touch of Ajax with their “digg” button where a click would submit your digg asynchronously to their server and update the digg count without a page refresh. This feature had been around for a long time and proved to be elegant and easily usable. Of course the lack of a page refresh also saves quite a bit of server bandwidth, but this performance optimization was shadowed by the features usability. Now, Digg.com has just added a little bit more Ajax icing to their traditional web app cake.

Basically what they have done is replaced the threaded comments with comments that are dynamically loaded when the user expands the list. All of the technical details are discussed by the implementor Joe Stump:

Probably the coolest, technically speaking, portion of the new comments is the manner in which most of the page is created. No longer do we create static HTML in PHP and send you a huge HTML page. Instead we give you the basics and, via AJAX/JSON, we make requests to the API and dynamically create the DOM using the FlyDOM jQuery plugin. The FlyDOM JSON templates are a stroke of genius if you’re looking at loading JSON dynamically into the DOM. The advantage of this is that initial page loads are much snappier and you can load the threads you wish to read on demand.

In simpler terms, Joe Ajaxified the comment system using the jQuery library. If you look past a lot of the technical coolness that Joe is talking about you’ll find that the greatest improvement here is performance based. Initial page loads are dramatically reduced by incrementally loading the page. If you look past any Ajax hype this performance improvement is half of the Ajax promise. The other half is usability. And although usability shined with the initial bit of Ajax on Digg.com’s digg button, digg members have declared this new comment system unusable.

In all fairness Digg.com is working actively on fixing the usability issues. It is clear however that usability in this instance came second, which is a mistake.

I work a lot with GWT building full Ajax applications. This is a bit different than Digg. In my case Ajax is the cake. The things that the GWT team does makes me happy. Seeing this Ajax issue at Digg reinforces that the GWT team is moving the project forward in the best direction. To understand this we can simply compare two quotes, one coming from JQuery and the other coming from GWT:

You start with 10 lines of jQuery that would have been 20 lines of tedious DOM JavaScript. By the time you are done it’s down to two or three lines and it couldn’t get any shorter unless it read your mind

Dave Methvin, JQuery front page

This sounds great to me. As a software developer I know the best code is no code. Or less is more. Digg.com made a good technical decision to use JQuery. But this is only half of the story and the half that developers usually tackle the best. Where is the other half?

We want great results, where “great” is defined by how much it benefits end users. Sometimes there are conflicts between what is easy for us developers and what benefits end users the most. When the two are in conflict, end user experience almost always wins.

GWT Team

I don’t think GWT would be the best solution for the Digg comment system since Digg just needed icing for their traditional web application. However, this is really the proper additude to have when developing applications that you want people to use.

Coincidently I’ve just finished writing a GWT example application that acts as an Ajax database administrator for a social news website like Digg.com. It’s a full Ajax application and the fifth example application in my book on GWT Applications. It illustrates how to dynamically load and save all data using JSON or XML on REST or Actions , or using GWT RPC…. basically a lot of server interaction techniques. Its tested on PHP scripts, Ruby on Rails, and a Java Servlet. Althought most of the technically interesting things are not visible, here is a somewhat underwelming screenshot of the applicaiton:

How long can you go without clicking on a website interface is the question asked by this user interface experiment posted today on Ajaxian. The website experiments with building a clickless interface and it pulls it off fairly well. It doesn’t take long to figure out how to navigate menus pages with only movements of your mouse. Thier idea comes from the fear of a mouse with ever an increasing number of buttons. They have clickless experiments and and games to show that mousless interfaces are functional and even suggest a humorous product that would help ween you away from clicking a mouse:

The site is fun although its less of an academic experiment and more of an art exibit trying to make a point. It looks like click statistics are measure possibly to come to some type of conclusion but the experiment is presented almost like a game: see how long you can go without clicking. Of course, when there is a button that your told not to push we tend to have an urge out of curiousity and defiance to push it to see what happens.

My mouse has four buttons and a scroll wheel that clicks like a button. I’ve actually have grown accustomed to using all of them but think that any more would be excessive.

Interfaces should always be simplified, but I doubt the definitive action of a click can be fully replaced by mouse movements. However, after playing with this site I can see how interfaces could be simplified by using less mouse clicking.

I read Buzz Marketing, The Tipping Point and the inferior Pyro Marketing earlier this year. My first experiment with these buzz building ideas in mind, the T.Q. Test, worked well. Unfortunately when people were done with the test the didn’t come back. It lacked stickiness.

Experiment #2, gpokr.com, really improves on a web apps stickiness. Its nothing new. You can play holdem poker for free everywhere on the net. There are actually several very small details that make it different and much more sticky, (although you can’t play for money so obviously its not right for gamblers).

My favorite detail that improves the user experience of the site the most for the amount of code involved is a simple little ranking next to the chip count at the table. After every hand this ranking is updated. I love seeing my progress on a hand to hand basis and have an interest to come back and check it out again. It has a pull to it. I could dream up dramatic development intensive features thinking bigger is better, and I think I usually do, but these little features are so much more valueable. One they are easy to implement and two they do not bloat the app giving it the ability to remain simple.