Catch My Fame

Why I Use jQuery Over YUI

Mar 31st, 2010 by admin | 1 Comment »

With all the jQuery posts I’ve made, and all the jQuery plugin work I’ve done, it may surprise you to learn that when I started moving from coding in pure JavaScript to using a library/framework, that I started using YUI first.

A few years back, when interest in the new JavaScript libraries really started to heat up, I took a look at what was out there. The main contenders at the time were YUI, jQuery, Mootools, and Dojo. After checking them all out, testing the examples they each provided, and reading the documentation, I decided to try YUI, figuring that since it was created and used by the folks at Yahoo! that it would not only be around for a while, but that it would be high quality. And I was right. Sort of. While the quality was high, there was also a learning curve to be tackled, and it was then that I hit my first wall with YUI’s documentation.

Let me take a minute to go off on a short tangent here. I love PHP. One thing I particularly love about PHP is how simple their website is, and how easy it is to learn about any part of the language. Pick a PHP function and you can find a page on php.net devoted to just that function which clearly explains everything about it. They start off explaining the function and what it does, the arguments you can pass to it, what you will get back from it, and any special notes. Then they show some real world examples and finish with user contributed notes. In my opinion this is perfect. It’s just the right amount of information to get anyone started, and it serves as an excellent reference. Not too much and not too little. Just right. Goldilocks knew her shit.

OK, back to YUI. I got into YUI sometime around their version 2.2.2 release in 2007. This was their first big release. Back then, YUI had basic documentation, not unlike PHP’s structure showing examples and explaining how-to-use the various features. My first problem arose when I needed help beyond what the YUI team had published. There weren’t many YUI tutorial or fan sites, so I turned to the YUI forum, which used to be a basic Yahoo! Group. This is where I got stuck, and in the end is what probably lead me to stray. The YUI group was pretty quiet, but the worst part was that I never received any real help. I’d post questions and they’d be completely ignored, which left me to turn back to my own resources and spend hours trying to figure out what was wrong. I’d pour over the YUI documentation, looking to see why I couldn’t do what I thought that I should be able to do, only to throw my hand up in frustration and walk away. Later I discovered errors in the YUI documentation but I couldn’t figure out where to make corrections or who to tell so that they could fix the problems so that others wouldn’t fall into the same hole that I did. I finally discovered that YUI was running a bug tracker on Sourceforge so I reported my bugs there and most of them were eventually, albeit silently, fixed. So after all this moving around from the YUI site for examples, the Yahoo! group for discussion, and Sourceforge for bugs, I was tired and discouraged. I felt like I was spinning my tires and getting very little in return.

About this time, jQuery had released a new version (1.2.6 in 2008 I think) so I decided to check them out and see what was going on in that camp. I was pleasantly surprised with what I found. Not only did it seem like the jQuery project was growing bigger and bigger, but jQuery turned out to be easy to learn and use. Documentation was structured along on the same lines as PHP, however discussion about jQuery relied on Google groups. Uh-oh. At first I thought that this was going to be a repeat of my YUI experience so after trying some examples I decided to post a few questions to the group to see what kind of a response, if any, I’d get. To my surprise I received answers right away and they were useful, clear, and friendly. But the real shock was the small learning curve that came with jQuery. I was able to get up and running much faster with jQuery than I was with YUI. jQuery seemed more intuitive than YUI. Plus, jQuery was big on plugins, something that YUI barely mentioned. Plugins allowed you to not only easily use code that someone else had written, but you could build upon it and tweak it to do whatever you wanted. I was hooked.

To me, the simplicity and brevity of jQuery, along with its ability to create powerful and useful code with a small footprint, and plugins is what really makes it like the Swiss Army knife of JavaScript. YUI just wasn’t there yet and if it was, the YUI team wasn’t able to get that message across and share it with everyone. I don’t know about you, but once I find a product I like I tend to stick with it. While YUI, Mootools, and Dojo (et al) are all popular, competent JavaScript libraries/frameworks, nine times out of ten I’ll go out of my way to find a jQuery solution to a problem before I try to start learning another tool.

Around the same time that I was getting heavy into jQuery, Yahoo! released version 3 of YUI. So being a former YUI user I decided to see what the new version was all about, wondering if they had taken a huge leap forward. Maybe Yahoo! had addressed all my concerns with the fragmentation of documentation, errors, and support with this new release. In my opinion, while the technology of YUI 3 may have improved, unfortunately most other issues seemed to have stayed the same if not gotten worse. I tried to go through the examples and documentation of this new version only to find the learning curve even steeper than before. It seemed that anything YUI 3 could do, jQuery could do and with less pain. Many of YUI 3′s features were in beta form as well, including things like widgets and plugins. Maybe I didn’t give YUI 3 a fair shake since I had been turned off to it in the past and was also so satisfied with jQuery. Maybe I’m just not smart enough for the high level explanations that the YUI team likes to provide (although I have my BS in computer science, a MBA in business, and a pretty decent IQ so I’m hoping that’s not it). I’ve never enjoyed complex things that can be made simple. I love simplicity. And to me, jQuery is the epitome of simplicity. On the plus side for YUI 3, they seem to have a whole new discussion forum although I can’t attest to whether its any better than the last one (although I can say it’s far more tan/mocha colored than the old one).

That said, I suppose the rivalry that goes on between all the JavaScript libraries/frameworks is a good thing and that the friendly competition that it generates can only help spur on better development tools for everyone. In the end, each developer should use whichever tool he or she is most comfortable with and for me, right now that’s jQuery.

Posted in JavaScript | 1 Comment »

Labels – An Easy Way to Make Forms Better for Everyone

Mar 11th, 2010 by admin | 7 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 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.

Posted in Usability | 7 Comments »

Narrow Minded

Mar 1st, 2010 by admin | No Comments »

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?

Posted in CSS, JavaScript, PHP, Usability | No Comments »

The Stupidity of Income Taxes and the IRS

Feb 18th, 2010 by admin | No Comments »

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.

Posted in Rants | No Comments »

Thumbnails in the Infinite Carousel

Feb 3rd, 2010 by admin | 8 Comments »

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.

Posted in JavaScript | 8 Comments »