Category Archives: Usability

Adjustable Columns with jQuery

View the demo here

I’m currently working on a project that uses jQuery throughout the user interface to improve the user’s experience. In one section of the application there are three divs laid out next to each other horizontally as if they were three columns. The leftmost div contains a series of items to select from via check boxes. When you pick one (or more) items, the middle div is populated by a jQuery Ajax query and displays a list where the content is based on what was selected in the first (leftmost) group. Finally, you can click on an item in the middle div which will then bring up detailed information in the rightmost div.

Normally this wouldn’t be a problem, but in this case the issue is that the width of the columns needed to be dynamic. If we had made the column widths fixed, then whenever the data in any of the columns was wider than the containing div, a horizontal scrollbar would’ve popped up. While this wasn’t a showstopper, it’s wasn’t visually appealing. You might be thinking that using a table would be a good solution except for the fact that resizing table cells isn’t much easier than resizing multiple divs, plus we’re not displaying true tabular data. Another possible answer could lie in using frames, except for the fact that frames disappear in HTML5 and I haven’t used frames in over 10 years. Continue reading Adjustable Columns with jQuery’s Weird Redesign

If you’re a regular visitor to you may or may not have noticed the recent changes to their website. At first it appears as if there were only minor cosmetic changes to the header of the page but upon closer inspection you’ll notice something else – a ridiculous choice of content placement.

The first time you visit the page you see what appears to be a normal home page

Notice that the vertical scroll isn’t at the top of the page? It’s almost imperceptible and in fact, I didn’t notice it for a week. Why does this happen? Scroll up the page and you’ll see that now has a large chunk of content sitting up above what appears to be the normal top of the page. It wasn’t until I saw a link where some of the old navigation used to be that said “Where’s my navigation? We’ve moved it to the top” that I noticed this big change.

So I have to ask why would you redesign a page and place a large chunk of important content up above where the visitor will see when a page loads so that they have to scroll up to see it? This just seems completely counter intuitive to web navigation. Visit a news site and then scroll up to read the headlines? That’s like opening the New York Times and then finding that the top stores section was folded down behind the front page. explains this change by saying “We’ve moved the news menu to the top of story pages and made it easier to see what’s happening across the site. When you first get to a story, you’ll see sections and shows displayed across the top of the page. Below is the name of the section you’re in and a search box. Scroll up to see top headlines, slideshows, video and hot topics. Roll over a section name to see more from that section and click on a section name to go there.” Scroll. Roll. Click. Are they serious? Is it just me?

Labels – An Easy Way to Make Forms Better for Everyone

I’m sure you’ve filled out a form on a website and at some point gotten a message about not completing a required field, only to find that one of the boxes you thought you clicked on never received your click. Sure you probably clicked close to the button or box when you filled out the form, but when it comes to clicking, close doesn’t count. So then you went back over the whole form and made sure that the checkbox or radio button was properly clicked. The thing is, if the person who designed the form was aware of the mysterious <label> tag, then odds are you never would have had to go back and correct the mistake in the first place.

The <label> Tag

The label tag makes completing forms easier. The main point of the label tag is to provide a usability improvement for mouse users. According to the W3C: “Some form controls automatically have labels associated with them (press buttons) while most do not (text fields, checkboxes and radio buttons, and menus).  The LABEL element is used to specify labels for controls that do not have implicit labels”.

So what does the label tag do for us? Basically it allows you to extend the clickable area for most form elements. For example, instead of having to click on a radio button, you can click the button or some text that’s been enclosed in a label tag. While a typical radio button might appear like:

<input name=“option1” type=“radio” /> Click here to select option 1

The same button with a label could look like either:

<label><input name=“option1” type=“radio” /> Click here to select option 1</label>


<input name=“option1” type=“radio” id=“option1” /> <label for=”option1”>Click here to select option 1</label>

Notice the differences between these two examples. In the first example, the input element and associated text have been wrapped within a label tag (implicitly associated). This is the easiest way to use the label tag; however in some cases the text you want to associate with a form element may not be adjacent to it. This is where the second example comes in handy. Here, the associated text is wrapped by the label tag, and the label tag has a “for” attribute which specifies the id of the element to associate the label’s contents with (explicitly associated). In this case, we use the id attribute of the input element “option1” in our label’s for attribute. The end result is identical from the user’s perspective.  Labels also allow you to target the text of form elements so that you can style them without any extra div or spans tags. Pretty handy.

Check out this example that shows two simple forms; one without labels and one with.

If you click on the various elements on the form on the left, you’ll see the only way to make choices is to click exactly on the control, whereas on the form on the right, not only can you click on any of the form controls, but you can click on the text associated with the control. And in the table example, you can even click the space around the control (the blank areas in the table cell) which allows you to easily select the radio buttons.

Also note that labels help users that have screen readers when they access forms. Screen readers will read out the label text and then the form elements associated with it. Without label tags, most forms are just read as list of items with the text coming together (e.g. first name, last name, email address) followed by a list of form fields (e.g. input box first name, input box last name, input box email, etc). With label tags added, screen readers read the label correctly along with the input field it’s associated with.

While the label tag is nothing new, some developers forget how beneficial they are while others don’t know they exist. So the next time you’re designing a form, remember that people don’t like to have to hit tiny targets with their mouse when they can just as easily click in the vicinity to accomplish the same goal.

Narrow Minded

Recently I was checking out some code written many years ago by another developer, and as I was hacking it up to be re-used, I started wondering why he had decided to split up his lines of code so that they were very narrow. Comments, for example, that were a few sentences long ended up spanning nearly a dozen lines when they could easily exist on just a couple of lines. It was then that I noticed that he had been wrapping his text at 80 columns – in other words, each line contained no more than 80 characters. It’s been a long time since I forced myself to wrap code at 80 columns, either because what I had written was concise to begin with, or because no one else would be looking at the code and it just didn’t matter, and I had almost forgotten why people did this in the first place.

I’ve seen code wrapped at 80 columns plenty of times before, but something about picking apart this code at that moment made me suddenly ask why. What was so special about this 80 column “standard” and why was it seen throughout the programming world? When I first started out coding this was just assumed to be the way to do things but I had never fully heard an explanation as for why this was done.

As it turns out the answer lies in old technology and tradition. In the early days of coding,  text based terminal displays were only 80 characters wide, so any lines longer than 80 characters needed to be wrapped. There just wasn’t any choice in the matter. Remember that GUIs and mice didn’t exist back then and scrolling was typically done only vertically. Some people believe that the even older computing method of using punch cards, which also typically had 80 columns, is the reason for this style of coding, however while it may have influenced the design of those old terminals, I don’t believe that punch cards directly gave way to practice of coding text at 80 columns.

Now since virtually no one uses an old terminal to write code, and today’s monitors are larger and have larger display resolution than older machines, why do we still see this? The answer? Tradition. Well that and readability. While most modern code editors will let you type a single line for as long as you want, reading that line becomes a huge pain in the ass. You’re forced to scroll horizontally to the right to read the code or comment, and then scroll back to the left to get back to the rest of the code. While an 80 column limit might seem constrictive or limiting, it actually makes code easier to read, and can help you write better code by making you find ways to shrink your code down to fit in one line. Another advantage to limiting the characters per line is code comparison. By staying with the 80 column rule you can usually fit two files side by side and examine them line by line quite easily.

Oh and while 80 columns is sort of a standard, 72 and 76 column layout are also quite common, but slightly more restrictive. Personally I am lazier than I like to admit and I often don’t pay a load of attention to how many columns each line of my code takes up. But that’s being both a bit lazy and selfish. By making your code readable, it helps you and anyone else looking at it…and you just know you’re going to need another set of eyes looking at your code at some point to help ferret out a bug down the line. And while I’m no advocate for 80 columns, if you stick with a layout that makes your code easy to read why not pick something like 100, 120, or 132 columns now that most people have larger monitors? Being lazy I also don’t think that any of this should be a rule but more of a suggestion or guideline. Bottom line, once you get your code to work the way you want it to, why not make it look good and improve the readability at the same time?