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

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.

Happy Birthday Allison

Posted by Thu, 29 Mar 2007 01:53:00 GMT

This morning was delightful. I woke up to find that 37signals had referenced our website on Signal vs Noise this morning. In particular, they referenced the Rails hosting order form on the PLANET ARGON site. What’s interesting is that Allison created this design over a year and a half ago.. and we’re actually in the process of a complete site redesign, which Chris and Allison are planning to blog about in depth. :-)

There are some discussions within the comments on the blog post about the design decisions that were made, some of which we’ve already begun to address in our redesign process brainstorming (based on google analytic conversion data).

On top of that, today is our Experience Director, Allison Beckwith’s, birthday.

Thanks for the linkage, 37signals!

...and… Happy Birthday Allison!