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

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.

Saying Goodbye Was Never This Hard

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

There was a post the other day on Signal vs Noise about the pain of opting out of mailing lists titled, Redonkulous unsubscribe delays, which I was reminded of after the following experience.

Earlier today, I got an email notification from my old Friendster account, which ended up being spam. I hadn’t logged into the account in ages and looked around at my profile and others. No meaningful interaction between my friends in a few years. It’s felt like a ghost town. So, I thought… “should I just delete my account?” I was thinking about doing the same thing with my Facebook account as well, because I’m getting tired of being invited to applications a few times a day due to a friend leaving my name checked when they sign up for a game. (this is getting old…)

So, I decided to kill the Friendster account, which I’ve had since February 2003. Oh… the good ole days of social-networking sites.

Upon filling out a form I got the following error with the notification, “Please list the other social networking site you switched to.”

The tone of this error message is very rude and helped support my decision to leave the site.

While I appreciate that they’re looking for feedback, they shouldn’t demand it out of me. As a result, my response was…

Wait a minute. You’re demanding that I list the sites that I’m switching to… in 20 characters or less? Thanks for giving me the opportunity to LOLBUG you. Sigh. Who makes these interaction decisions there?

If they really wanted to get some useful feedback, perhaps they could have asked me nicer.

So, I decided to head over to Facebook and compare their process.

At first glance, this looks very much like the form that I was presented with on Friendster. Except that I can only select one reason why I am leaving and I can think of a few. However, when I made a selection… something surprised me.

Okay, so maybe I’ll leave my Facebook account around for the time being. Perhaps there is a Facebook application out there that will be get my attention.. but to date, this has yet to happen.

This post is dedicated to the memory of Robby Russell’s Friendster Profile. Feb. 2003 – Dec. 2007. R.I.P.

Skitch... my favorite desktop application of 2007?

Posted by Tue, 20 Nov 2007 19:04:00 GMT

It just occurred to me that my first Skitch was on July 7th, 2007. 7/7/7. I’ve been meaning to post an article about how Skitch has changed the way our team approaches reporting bugs and communicating ideas visually.

First of all, the Skitch web site advertises it (see video) as a fun tool for playing with photos and sharing stuff with friends/family. While this is true, I think their bigger market could be those of us who work in the web design and development community. It took a less than a week for Skitch to become a tool that I rely on the most during my day to day work and since it keeps surprising me that people aren’t using it and/or haven’t heard about it… I thought that I’d share how we’re using it at Planet Argon.

Introducing “LOLBUGZ”

Our team is currently using Lighthouse for managing bugs/tickets for internal and client projects. If there is one way to slow down bug fixing cycle.. .it’s the ticket submission process. It takes a lot of time and commitment to try and communicate some problems that you’ll find in a web application. This is why screenshots can be so useful to helping speed up the process. Skitch allows us to not only provide a screenshot really quickly, but it gives us the ability to focus our attention with shapes and text, which provides more context when viewing an image.

For example, here are a few real-world Skitches that I’ve used to report some problems.

What happened to this drop down?

This pagination needs some CSS-Love!

Oh no! Tags are getting grouped together…

Styling has gone crazy…

I mastered an unordered list! (hooray!!)

This list isn’t scaling anymore…

Side note: LOL BUGZ was a term coined by Rick Olson at Active Reload to describe the tickets that I post for Lighthouse. ;-)

Trying out 15 during the initial releases for the iPhone… bug report sent via twitter to Erik Kastner.

As you can see, using Skitch helps communicate some very specific things without needing to type a huge description. Of course, we do try our best to add more context with our tickets. For example, here is a real-world example of a ticket that I posted on Lighthouse. As you’ll see, there are a few skitches embedded in the tickets, which works much better than attaching screenshots to tickets.

One of the best features of Skitch is it’s work-flow. Within a few seconds, I can do the following tasks.

  • Take a screenshot of a specific region of my screen
  • Add some arrows and text
  • Click on Webpost, which will upload directly to myskitch.com
  • Click on Share to navigate to the new upload
  • Click on the embed textfield and it uses JS to copy the embed html into my paste buffer
  • Paste the html snippet directly into the ticket that I’m reporting
  • Submit my LOL BUG

Side note: it also allows you to upload to Flickr, a ftp account, etc.

Over the past four months, Skitch has become one of my favorite OS X tools. The interface is lightweight and the workflow is almost perfect (feature request: providing the embed code in my paste buffer without needing to go to myskitch would be A+++)

I’ve also used Jing, which works on Windows and OS X and does video. I’ve not found it to be as intuitive for working in this manner. In fact, the work-flow leaves a lot to be desired. However! It does do video and this has come in handy a few times for showing people some “live” interaction-type bugs that can’t be communicated as easily through text/images.

If you’re not using Skitch yet and are on OS X… I highly recommend that you try it out for a few weeks during a bug fixing sprint. We’ve gotten our clients and almost everybody on the team using it in this fashion. The productivity increases haven’t gone unnoticed.

That’s not to say that it’s not fun for point out things that aren’t related to your project bugs. ;-)

Happy Skitching!

UPDATE

Plasq liked the writeup and gave me 50 extra invites to pass out for Skitch. So, if you’re in need of one… ask me via email. Thanks Plasq team!

Zeldman on Web Design

Posted by Tue, 20 Nov 2007 18:01:00 GMT

In a new article on A List Apart, Jeffrey Zeldman writes:

“Some who don’t understand web design nevertheless have the job of creating websites or supervising web designers and developers. Others who don’t understand web design are nevertheless professionally charged with evaluating it on behalf of the rest of us. Those who understand the least make the most noise. They are the ones leading charges, slamming doors, and throwing money—at all the wrong people and things.”

He goes on to describe Web Design as, “as the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity.”

Read the rest of the article, Understanding Web Design on alistapart.com.

RubyURL: new design and code base

Posted by Wed, 08 Aug 2007 13:58:00 GMT

Yesterday evening, I deployed the new version of RubyURL. This was a collaborative effort between Chris Griffin and I, which we’re happy to finally push live.

There are a few things that we’re going to push out in near future, such as an API and a new RubyGem.

RubyURL » Keep it short (and sweet)

Chris volunteered to work on the new design and I did most of the programming in Ruby on Rails. When we worked on this, we really wanted to keep the process as simple as possible, despite some of the problems that the site has been having.

In the end, we have a Rails application that is only 85 lines of code and has a 1:2.3 code-to-spec ratio. I wanted to keep it under 100 lines of code. This means that there is some breathing room for further development.

We also tried out a beta account that I was given for RoundHaus for Subversion hosting. We had a really good experience using their service and were impressed by the plethora of useful features that came with the repository, such as continuous integration, rcov/code coverage stats, and twitter integration!.

If you find a bug, be sure to submit a ticket on the RubyURL bug tracker.

On a side note, we deployed this on a brand new Rails Boxcar, our new hosting solution that will be launched in the very near future. ;-)

Designers, Developers, and the x_ Factor

Posted by Wed, 01 Aug 2007 05:39:00 GMT

Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.

Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.

I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.

Scenario #1: The case of the changed div id, (victim: designer)

  • Designer adds a few HTML elements to the page, defines an id on a <div> tag and styles it with CSS.
  • A few days later, a developer needs to make some changes, tests it in their favorite browser and commits.
  • Later, the designer doesn’t understand why the styling is all messed up. “It was working fine.”
  • ...minutes, hours… go by where the designer tries to track down the issue. “Oh! Someone renamed the id in this <div> tag. Sigh.”
  • Developer apologies, but explains that he needed to do it because he needed to make it work with his new RJS code.

Scenario #2: The case of the changed div id, (victim: developer)

  • Developer is implementing this cool new Ajax feature into the web application
    • The code relies on there being one or many HTML elements in the DOM with specific id values defined.

Example: <div id="notification_message">

  • A few days later, a designer is making some changes to the layout and needs to restyle some of the view that this <div> tag is defined. Designer decides to change the id to a different value for any variety of reasons. (or perhaps they changed it to use a class instead of styling it by the id). Often times, we don’t know who set the id or class… and many times the developers aren’t savvy enough with HTML and designers end up cleaning things up a bit.
  • Later, code is checked in and designer didn’t notice that the Ajax was now breaking as they weren’t focusing on just the layout.
  • Day or two later, developer sees bug, “Feature X isn’t working, throwing JavaScript error…”
  • Developer is confused, “Hey, that was working! What happened?”
  • Developer tracks down the problem, discusses with designer, they figure out a solution. Problem solved.

I could outline a few other examples, but I really wanted to highlight these two types of situations, as our team has seen this happen on several occasions. Luckily, we’ve learned through these experiences and have taken some measures to try and avoid them in the future.

Moving forward (together)

Both of the examples above, were essentially the same problem, but resulted in problems for a different role in the design and development cycle. While, I’ve definitely been the victim of #2 several times myself, I know that I’ve also been the guilty of #1. So, what can we do as designers and developers to work with each other without causing these little problems from occurring? (remember: many little problems can add up to a lot of wasted time spent resolving them)

Several months ago, I had a meeting with Chris (User Interface Designer) and Graeme (Lead Architect/Developer) to discuss this very problem. At the time, we were implementing a lot of Ajax into an application and were occasionally running into Scenario #2. We discussed a few possible ways of communicating that, “yes, this div id should NOT be changed (without talking to a developer first)!”

Idea 1: Comment our “special” HTML elements

We discussed using ERb comments in our views to do something like the following.


  <% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
  <div id="notification_message">
    ...

We all agreed that, while effective, it was going to clutter up our RHTML code more than any of us desired.

Team Response: Meh.

Idea 2: Reserve id’s for developers

Another idea that came up, was to ask that designers only use classes and ids wold be used by the developers when they needed it.


  <div id="developer_terriroty" class="designer_territory">
    ...

Chris pointed out that this wasn’t an ideal solution as there is a distinct case for when to use ids versus classes.. and he is very strict about adhering to the HTML/CSS standards.

Team Response: Not hot about it…

Idea 3: Naming convention for Ajax-dependent elements

The third idea that was discussed, was specifying a naming convention for any elements that were needed by our Ajax code. We played around on the whiteboard with some ideas and settled on the idea that we’d prefix our id’s with something easy to remember for both designers and developers.

We agreed on… x_ (x underscore), which would make an element id look something like this:


  <div id="x_notification_message">
    ...

x == ajax... get it?

While this adds the strain of typing two more characters to much of our RJS code, we don’t run into Scenario #2 very often anymore.


  render :update do |page|
    page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
    page[:x_notification_message].visual_effect :highlight
  end

or in client-side JavaScript (where we also use this)...


  $('x_notification_message').do_something

I find that this helps our team keep a clear distinction between what can and shouldn’t be changed in the views by our designers. Sometimes they have a good reason to do so, but they know that if there is x_, then they should ask one of the developers on the team for assistance in renaming it without causing any problems in the application. It also allows our designers to add classes to these elements, or style the id that we’ve defined.

Team Response: Wow, was that all we needed to agree on? Hooray!

This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.

If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?

Until next time, remember to hug your designer. ...and if you’re still having developer design your applications, consider hiring a designer. ;-)

UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)

Older posts: 1 2 3 4