Feed on
Posts
Comments

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 only 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>

or

<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?

The other week I read a great article in the New York Time about the IRS and income taxes and how archaic our entire system for reporting our income is. You’re probably saying no kidding genius, tell me something else I don’t know. Well to put a fine point on the problem, I’ll cite this paragraph from the story:

Requiring taxpayers to file returns without being told what the government already knows makes as much sense “as if Visa sent customers a blank piece of paper, requiring that they assemble their receipts, list their purchases — and pay a fine if they forget one,” said Joseph Bankman, a professor at the Stanford Law School.

In other words, why in 2010 are we still burdened by the same ridiculous, error-prone system, that is decades old, that everyone (except accountants) hates? Most people either pay someone to prepare their taxes or they buy software and do it themselves. There are also those who use free software to prepare their taxes, but regardless of how you do it, it takes time, sometimes money, and is an endlessly annoying task.

In the digital age, filing income tax returns should be a snap. The important data from employers and financial institutions have already been sent to the government’s computers. Yet taxpayers are still required to perform the anachronistic chore of preparing a return from scratch. And, in many cases, they pay a software company for the privilege.

I highly encourage you to read this article and start thinking of how much better this annual root canal could be. I just got mine done and it made me sick.

Update: I may be disgruntled but I’m not as angry as this guy.

One question I frequently get about the Infinite Carousel jQuery plugin focuses on the way that I chose to create the thumbnail images. Probably the biggest criticism is that the thumbnail image is just a tiny part of the overall image and in some cases doesn’t help distinguish the images that make up the carousel. For example, if the upper left corner of all your images is say sky blue, then all the thumbnails may end up looking alike.

For those of you that haven’t looked at the code that generates the thumbnails, the plugin uses the individual carousel images as the background image (CSS background-image) for each respective thumbnail div. I did this primarily for speed. By reusing the carousel images as the background images for the thumbnails, there’s no added processing needed to create the backgrounds. The trade off here is pretty obvious; speed for recognition.

For many images this works out just fine, but for some it doesn’t. Therefore I have come up with two alternatives for better thumbnail images. I will present these options here, but I am not yet making this part of the plugin itself. Your feedback will determine if a future version of the infinite carousel will incorporate one of these new methods to generate thumbnails.

Method #1 – HTML

The other easy solution to creating thumbnail is to simply resize the carousel images to fit into a smaller area. The biggest issue with this resizing the individual images and using them as thumbnail images is that a) the quality degrades (pixelization) and b) the aspect ratio may not be the same as the original image. There’s nothing you can do about the quality when you take a large image and change the width and height attributes in a web page. Thems is just the facts of web life. An images resized by altering its dimensions will end up pixelated to some degree. Not the end of the world. The aspect ratio can also be overcome by properly calculating the correct width and height for thumbnails based on your full size images. For example, if your images are 800×600, setting a width and height for your thumbnails of 40 pixels would end up squashing the image. However if you set them to 40×30 then they would better represent the actual images.

Click here for an example of method #1.

Method #2 – PHP

Another solution is to generate properly resized thumbnails automatically using the proper aspect ratio using PHP,  so that the smaller image is the proper size and not pixelated. The trade off here is processor utilization. If you have a lot of traffic to your site then without some sort of caching mechanism, the constant thumbnail generation could end up being a real drain on your server. The aspect ratio isn’t as much of a problem with the PHP solution as the PHP script that generates the thumbnails can easily be coded to generate the them using the same aspect ratio as the full size images.

Click here for an example of method #2.

Method #3?

While I did say there were two alternatives for the thumbnail issue, there does exist a third option — manually creating the thumbnail images. You could generate your own scaled down versions of your carousel images and then point the plugin to a folder of thumbnails. This would require extra work in creating and managing more images, increase the number of requests to the server (unless we used sprites), and also require some sort of special naming convention so that the plugin could correlate images with their respective thumbnails. This would increase the quality of the images and keep server processing to a minimum, at the expense of giving you more work in creating and managing images. I’m not big on more work myself, but to each his own.

One issue with using either the HTML or PHP solution is that since we’re moving from using a background image to filling the div with an image, we can’t as easily place numbers on the thumbnails as we did previously. It can be done, but now it would require CSS to position the number over the image in the div.

Personally I’m leaning toward method #1 as the most viable solution. As long as your thumbnails aren’t tiny, scaling the full size images down should give fairly decent results and not cost anything extra in terms of server requests or processing. View the source code of the first example’s modified carousel code to see the two lines that were changed.

If you’d like to have the PHP script used in method #2, post a comment and if I get enough interest I’ll post the source.

Wow, what a week. For a web developer/designer/tech lover there has been a lot of new information in this first month of 2010 (at last we get to use the word “twenty” to describe the new decade — twenty-oh-four never rolled off the tongue). Not only did two of the best browsers get some nice updates, but Apple finally released their long-rumored tablet and Microsoft told users to stop using IE6. Oh, and then there’s PayPal.

Firefox and Chrome

First off, Mozilla and Google both released updates to their web browsers. Firefox 3.6 is out now, and in addition to some bug fixes it introduces eye candy known as “personas”, stale plugin protection, downloadable web font (WOFF)  support, support for new CSS attributes such as gradients, background sizing, and pointer events, and support for new DOM and HTML5 specifications including the drag & drop and file API, which allow for more interactive web pages.

Google released the fourth version of their Chrome browser which added the ability to add extensions and sync bookmarks across multiple computers.  They also have added more HTML 5 support including  LocalStorage, Database API, WebSockets, and more. I like Chrome, but I still haven’t switched to using it as my primary browser (still Firefox). I think it’s making good strides but for the time being I still use it  mostly for testing. I like it, don’t get me wrong, it’s just that Firefox and I are old friends and well, I don’t see a need to dump Firefox just yet.

The iTablet iSlate iPad

Just yesterday Apple released their long awaited tabled, the iPad. Almost instantly the jokes about the name iPad began to circulate around the Internet with no end in sight. I admit I also cringed at the name, and was hoping for something more inventive than iPad. While Apple’s iWhatever line is certainly good branding, it’s wearing thin on me and it’s inevitable that at some point they’ll need to come up with a better solution. Continue Reading »