Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Alan Cooper @ Agile2008 slides

Posted by Tue, 12 Aug 2008 23:19:00 GMT

Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.

If anybody knows if there is video of this talk, please let me know. :-)

Here are a few skitches from the slideshow.

The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience
The Wisdom of Experience

Review: FogBugz, part 1

Posted by Tue, 01 Jan 2008 21:43:00 GMT

Today, I thought that I’d give FogBugz a quick trial. A few of our Rails consulting clients use it and I’m hearing that others are as well.

Along the way, I’m bringing one of my favorite tools so that I can share some things thoughts (visually) along the way.

Signing up for a free trial

My first impression of FogBugz was, “nice homepage design… but what is that screenshot of?”

I’m not a designer, but the interface in the screenshot isn’t jumping out to me as something that you’d expect to see in a modern web application. While I appreciate the default browser colors for links (this is really important)... I think they could have found a better way to distinguish which bug links you’ve previously viewed. It’s very likely that you’ll most bugs many times, so having the color be different might not make sense in the same way it would when reading content on a web site. Again, I’m not a designer and I’d be curious to hear from a designer on this. Just something that I initially thought.

Okay, this sign up form seems really easy to start with. I’m used to free trials being really simple to get going. So, I enter in my sub-domain selection and provide my email address on the following page so that they can confirm that I’m legit.

(several minutes later…)

Okay, this process required me to jump from my browser to my email to my browser back to my email and then back again to my browser. It’s really frustrating for an application to force me to go back and forth between my browser and email client. I think the initial email is something I can cope with, but I found it a bit silly to have to wait for another email to receive a link to login to my new account, especially considering I already knew the URL as that was the first thing that I provided. The application could have provided the link (or redirected me) to the following form, which I had a few things to comment on.

At first glance, this might not seem like much… but I’m becoming more and more disappointed by the choice of language that we’re using in applications. First of all, this is the first time that I’ve seen this page. I’m not changing my password… what you’re really asking me to do is, “Create (or set) a password.” There are other verbs that you could use here, but change really isn’t appropriate. Also, choose doesn’t work here either.


  chose; choos·ing.
  –verb (used with object)
  1.    to select from a number of possibilities; pick by preference:  

What am I choosing from? Again, you’re asking me to create a new password.. not change one and definitely not choose one, unless you’re implying that I should choose one from a collection of ones that I already use.

One might argue that we can make an assumption about what they mean, but it’s simple problems like this that can seriously confuse people that use the software we design and develop. As people interact with minor problems like this, their perception of the software as being helpful and friendly… can quickly deteriorate.

Okay, so that was my first several minutes of getting into my new FogBugz account.

Coming soon… Robby will share his thoughts on managing bugs with FogBugz.

That Checkbox Needs a Label

Posted by Sun, 02 Dec 2007 06:43:00 GMT

As a user of many web applications, I often find myself noticing little things that slow me down. One such thing is the use of checkboxes in web forms. It’s not the problem of checkboxes itself, it’s the face that checkboxes require the user to really focus their attention to a fairly small box on the page and perform a click inside. If you’re filling out a form really quickly, it’s almost guaranteed that you’ll take advantage of you your tab key to get through each field quickly. Sometimes there are select boxes, which require the user to make selections with their mouse. Checkboxes drive me crazy because it requires more time to position the cursor and move on.

So, when I see a form like this, I don’t see it being very quick to interact with.

While I’m not in love with the date selection interface here, my bigger pain has been the checkbox in the form. Why? Because they forgot to use the <label for=""> HTML tag.

What’s the problem? Well, I don’t have the convenience of clicking on the label text, which would toggle the corresponding checkbox.

I know, many of you know all about this… but I run into this problem everywhere. This is an accessibility issue for people and really just increases the chances for a frustrating user experience. When you use the label tag properly… it will provide a larger amount of the screen for people to click, which reduces the chance of not clicking in the right spot. The label tag was designed with this in mind so that people could click close enough to trigger the desired action.

Here is an example of where it becomes really useful.

So, the lesson? Please remember to use the label for tag. :-)


<input type="checkbox" id="remember_me" name="remember_me" value="true" />
<label for="remember_me">Remember info?</label>  

This is an easy thing to forget when building web applications. We’ve forgot and I’m sure you have too. I just wanted to point it out though because I see this happen so much… even in new sites.

Perhaps you run into similar problems with web applications that can be fixed with just a little more HTML. Care to share your experiences?

For more information, read Labeling form elements from the Dive Into Accessibility site.

Hug Your Designer Day

Posted by Tue, 22 May 2007 22:18:00 GMT

Amy Hoy, of slash7 fame, gave a talk titled, Rubber, Meet Road: Getting Designers Running with Rails, which provided a good overview of some of the problems that designers and developers face when working together. This was one of my favorite talks, because she essentially explained several of the problems that our team has faced in the past and in many ways, still encounter from time to time. A few things that I was surprised to hear, was that several companies leave their developers to implement HTML/CSS in the Rails applications, rather than let their designers into the area. Some teams, provide a directory in public/ for their designers to write their HTML/CSS. Amy said that she preferred to work in the standard view directories (as a designer), which is exactly how our team works.

In fact, I agreed with Amy on several points.

  • Developers say, “We can’t do that” too often, when really… we mean, “We won’t/don’t want to) do that”
  • Template languages create extra barriers to training designers. Stick with RHTML… designers won’t be afraid of ERb syntax if you sit down with them and explain some of it. Move the ugly stuff to helpers… like you should be anyways!
  • Teach your designers how to use subversion… let them break it first and then help them… they’ll love you for it
  • When meeting clients with a designer and a developer… don’t let the developer speak too much about implementation when it hasn’t been designed yet. Interaction Design should dictate architecture not vice-versa.

“Stop, Collaborate, and Listen”—Vanilla Ice

I’d like to personally thank Amy for being a diplomatic designer and telling the hundreds of developers that showed up for her talk to remember that designers and developers… think differently… and that’s a good thing for the application and ultimately… the user experience.

Having said that, I’d like to request that tomorrow, May 23rd, be… Hug Your Designer Day.

Matz on Considering Interface

Posted by Mon, 25 Sep 2006 15:11:00 GMT

...back in Portland after being in London and New York City for the past two weeks. It’s nice to be home. :-)

I came across this interview with Matz earlier today. It was published almost three years ago (pre-Rails)... I’m quite intrigued by what he is advocating here…

Bill Venners: You also mentioned in your ten top tips: “Be nice to others. Consider interface first: man-to-man, man-to-machine, and machine-to-machine. And again remember the human factor is important.” What do you mean by, “consider interface first?”

Yukihiro Matsumoto: Interface is everything that we see as a user. If my computer is doing very complex things inside, but that complexity doesn’t show up on the surface, I don’t care. I don’t care if the computer works hard on the inside or not. I just want the right result presented in a good manner. So that means the interface is everything, for a plain computer user at least, when they are using a computer. That’s why we need to focus on interface.

Some software people—like weather forecasters, the number crunchers—feel that the inside matters most, but they are a very limited field of computer science. Most programmers need to focus on the surface, the interface, because that’s the most important thing.

Bill Venners: You also mentioned machine-to-machine interfaces, so are you just talking about interfaces for users or also for machines?

Yukihiro Matsumoto: It’s not just user interfaces. When machines are talking to each other via a protocol, they don’t care how the other is implemented on the inside. The important thing is the proper output getting passed correctly via the proper protocol. That’s what matters.

If you have a good interface on your system, and a budget of money and time, you can work on your system. If your system has bugs or is too slow, you can improve it. But if your system has a bad interface, you basically have nothing. It won’t matter if it is a work of the highest craftsmanship on the inside. If your system has a bad interface, no one will use it. So the interface or surface of the system, whether to users or other machines, is very important.

One of things that we’re really advocating with Dialogue-Driven Development is artifact generation. Wireframes and lightweight prototypes are great for generating constructive dialogue between clients, users, and our team. We should make sure that we understand why and how users will use an interface before we worry about the code that will drive it. Too often we fall into a pattern of thinking where we’re convinced that we can build an agnostic application that has various interfaces to a central repository of business logic and data. While we strive for this during development, it really should be focused on after some initial interaction design has been planned. Of course, this is my opinion.

So, I must ask you. When you’re working with on a new project, do you focus on interface or code implementation first?