I am reading the jQuery Cookbook at the moment. I will blog some interesting examples that I am come across and pad them out
- if even only slightly - in the hope that they make more sense to the untrained eye.
Let's begin!
Consider a form as such:
Who is going to win the Heineken cup next year?
Click on any one of the teams, notice that the radio box is selected. Then start typing in the "Other" text box. Isn't it a bit odd that the team you previously selected is still selected even though you clearly started typing in the "Other" textbox? Does the user seriously have to explictly select the "other" radio button even though an "other" indication has already been given?
Now, try this. Clear out the "other" text box and select another team. Then select the "other" radio button. Notice that the "other" textbox does not have focus even though you are hardly going to click the "other" check box and not want to type anything into the corresponding text field. Good GUI should assume the user will want to behave rationally. When the "Other" radio box is selected, it makes sense that its adjacent text box should get focus. Remember good usability means the user can achieve what they want with less clicking. And remember, good usability means that things are intuitive and GUIs do not display contradictions. So with all that in mind, we can include the discussed usability guidelines and come up with something like this:
Who is going to win the Heineken cup next year?
So how did we do that? Well let's take a look at code:
Discussion:
:text is a JQuery psuedo class Selector which selects all elements of type text. As per JQuery recommendations, pseudo class Selectors should be preceded with another selector or tag element otherwise the universal selector is implied. In this case we do input:text and only one text box will be selected. That's ok.
The .each(function(){ means iterate overall inputs of type text and execute the specified function. Don't forget ".each" can operate on sets of elements of any size including just 1 which is the case in this example.
$(this) corresponds to the object which is being operated on by each. In this case it is each input text box. If you don't believe me add:
console.log("this is: " + $(this)[0].id);
and you will see something like:
this is: Source5Txt in the console.
The inputText button and radio button are stored in the local context.
This is for efficiency.
A website will always contain some links. Links fall into one of two categories:
Internal links - links to other parts of your website.
External links - links to other websites external to your website.
There are times when it might make sense to warn the user you are leaving your site. For example, you may have a SAAS style architecture with external links.
It is good usability to differentiate links that keep the user on the site and links which will take the user away from the site especially if the latter could invalidate a transaction or session. Even if nothing could become invalidated it must just to differentiate in cases when the site the user will be trvalleing to next is very similar (which might lead the user to think it is the same site), or it might just be nice to say bye.
Well one way you could do this is to use some JQuery to select to all external links and add some JavaScript to execute to warn the user of the results of their action.
The ^ after href means means all elements that begin exactly with http:. This is an example of how JQuery builds on CSS selectors.
:not([href*='"+location.hostname+"'])
means match elements that do not match the window.location.host property.
Don't forget jquery provides many powerful selection filter expressions using the (:) syntax, Other examples are
:first, :odd and :even.
... location.hostname
is the dom way of figuring out the hostname of your site.
attr("target","_blank")
is a browser standard to open a new window.
.click
is the JQuery method whichs binds custom event handler to the the JavaScript "click" event.
You have a menu bar with the standars buttons, including the proverbial "previous / back" and "next / forward" buttons which look like...
You have been asked to improve the usability of them. In addition, your application is not coming up well in performance analysis tools. One reason for this is that many pages are downloading numerous components resulting in too many HTTP requests. It's time to consider mechanisms to reduce the number of HTTP request required to display your pages.
The solution
Well consider the usability first. The images for the buttons don't look that bad. It's obvious what they mean and what they will do, so there's not much point adding tooltips. But we could make things look sleeker with some "hovering". What's hovering? Hovering is a technique which dynamically changes a component when a mouse "hovers" over it. Technically, tooltips are a form of hovering but there are other types: components can change colour or light up. Let's apply some hovering magic to our prev / next buttons. Hover your mouse over the buttons below, do it a few times and watch them glow.
So how did we do all that? Well, the first thing we do is make alternative images of our original images. This can be done using any decent editing tool: gimp, paint shop pro, take your pick - for this example, I just used Picaso. The second thing to do is to amalgamate the four separate images using a tool such as CSS Sprite generator
into one single image.
Why one single image? Well that's for the performance part. HTTP requests can be expensive. We don't want to have to 4 separate HTTP requests for 4 images. So instead, we have one image which contains everything we need. This downloads all four components in one go. We then use some CSS tricks to:
Pull the 2 images out of the one big sprite
Switch the images to their hover versions when the mouse hovers over them
So how do we all that... time to look at some CSS.
The second half of the cake is the HTML, note the id's
Explanation
The CSS shows a styled navigation list. A list with id="navlist" will
reap the styled benefits.
An element with id="prev" will disect up the collection of images aka the "sprite sheet" and take out the part of the image it wants i.e. the left arrow
An element with id="next" take out the right arrow
"prev" and "next" have hover images which are also taken from the sprite sheet and will be displayed when the mouse hovers over them.
So there we go. Better usability and better performace. A good day's work. So any other questions? Well an obvious one would be why not just use an image map? It will also reduce HTTP requests. That's true. But, it's not as flexible as using CSS sprites. When image maps are used, the images have to be continguous. Using the CSS sprites technique, you can split them up whatever way you want. A whole bunch of images can be put onto the one sprite and then can be used together, seperate and in whatever order you want. In fact this is how most companies used CSS sprites. They create a sprite sheet which contains various images for all parts of the web application. Inline images are another approach. This approach will download the image in the same HTTP request as the page and thus also reduce HTTP requests but it willalso increase the size of the HTML page. Browser support for CSS sprites approach is also better.
So, is anyone else using CSS sprites - hell yeah!
Recognise anything here...
References
Really interesting page about the evolution of google super sprite
Previously, this blog posted an overview of HTML 5. Let's have a closer look at one of the more useful HTML5 features: placeholder text. Placeholder text is a short hint intended to help the user understand what their data entry should be. It is not default text.
Previously to achieve this involved some javascript; now it's extremly simple. Simple add the placeholder attribute to the input element.
Placeholder text has some real benefits. It means you are conveying more information to the user but not taking up anymore valuable real estate space on the page. Now, it is fair to say that there are some very popular GUIs that don't use placeholder text. For example, the login screen for gmail does not.
gmail login
This begs the question when from a usability perspective when does it make sense to use it and when is it best avoided? Let's think about the gmail case a bit more and that helps answer the question.
By default, the gmail Username textbox gets focus when you arrive at www.gmail.com. This makes sense. The Username textbox is the smart staring point for this page. It's the logical place for the user to start their interaction. Now, when a textbox has focus any placeholder text it has always gets wiped. Otherwise, the user would be seeing a mixture of what they are typing and what the placeholder text was. That would just be horrible! So, since the username textbox has default focus for gmail.com it makes sense that when you arrive, the username textbox is blank. How about the case when the user types nothing in the username textbox and shifts the focus to something else? Would the arrival of placeholder text add meaning or confuse the user? I'd argue it would confuse them. Aside from the sudden flicker being an irration, the user could think they did something to cause the text to be put there. It will confuse rather than elucidate! As for the password field, well they generally don't have placeholder text - for obvious reasons. So gmail is being smart here. There is no placeholder text but for logical reasons.
So placeholder text is great but there's the question of when it should be and shouldn't be used should not be avoided.
Now, let's dig a bit further into the usability. The W3C spec states that the: "placeholder attribute should not be used as an alternative to a label". I'd also suggest that the placeholder text should not repeat the label. What's the point in saying the same thing twice? There's no point in duplication, but there is nearly always a case for elucidation. A good example is the firefox searchbar. This is the text bar found in the top right corner of the Firefox window that can be used to search popular search engines without the user having to access them directly. A number of different search engines can be selected. In all cases, there is icon for the engine which acts as a label for the search engine. There is also placeholder text in the search textbox ajacent to the icon label. This elucidates what the label icon is identifying. For example, for Wikipedia we see, the Wikipedia icon and then the placeholder text: Wikipedia (en)
Wikipedia selected
What's really clever is here is the use the very efficient use of real estate. The icon is very small and in case it is not clear it means Wikipedia, the placeholder text elucidates the matter. We see the same if Google is selected.
Google selected
So yes placeholder text is a great feature. It's easy to use but using it at the right time and smartly requires thought. It all comes down to the simple question: is the addition of placeholder text going to elucidates matters for the user or not?
So any browser caveats? Well not all browsers support the placeholder attribute. For example IE 9 does not. But thankfully, if the placeholder attribute is not understood, it is ignored. There are no nasty exceptions or error messages. Just have a look at this webpage in IE 9. As always, if you want to support fallback use the Modenizer library. There are several examples available using Javascript /JQuery if you want to have placeholder text in browsers that don't support this simple way of doing it using HTML 5.
References:
1. HTML5 spec: http://dev.w3.org/html5/spec/Overview.html
2. HTML5 placeholder spec: http://dev.w3.org/html5/spec/Overview.html#the-placeholder-attribute
3. Site to test your HTML5 browser support: http://html5test.com/
4. Site to test your browser support for input type attribute support: http://miketaylr.com/code/input-type-attr.html
