Whether we realize it or not, the displayed cursor image tells us about the area of the screen below our mouse cursor; it tells us whether or not we need to click, drag, move, resize, or even wait.  Now, I know that we all know this, but I believe that sometimes as developers (especially web developers) we forget that not all items in an application have the correct default cursor for the action that is assigned for that item.

The Web Standard

For years we lived without JavaScript in our browsers; it wasn’t used by developers, or it was turned off or disabled by the user because there were so many security flaws with the JavaScript engine; however, as those security flaws are fixed and JavaScript’s functionality increases, the age of no-script is quickly coming to a close.

One of the side-effects from living without JavaScript for so long is that users are now used to relying on the mouse pointer to signal whether or not something on the page is clickable or actionable.

In the web world, the default cursor (without any background movement) means that there is no current actionable item beneath the mouse at that time.  Once your mouse moves over something actionable, the cursor will either change (page links), or the background will change to so show a possible action (form buttons).

When the mouse hovers over something like a link or an image used for a form submission, the hand cursor would show to indicate that an action will be executed by clicking on that item (whether it be submitting a form or going to a new page).

Furthermore, there are many other cursors that have different meanings (both actionable and not) when hovering over different elements, both actionable and not.

Taken For Granted

With the advent of JavaScript, more items than just anchor tags and submit buttons became actionable. We can now execute actions based on hovering, clicking, moving, button pressing and other user input actions on any other type of visible elements: span‘s, div‘s, tables, etc.  Moreover, we can even execute actions on browser events that the user has no control over (XMLHttpRequest, onLoad, etc).

People now use JavaScript very freely and frequently on their pages to simulate actionable elements that at one time could only be implemented with anchor tags, img+anchor tag combos, and form buttons.

However, I think that sometimes we believe that the user will automatically or inherently know to click on the span or div (or any other random element that has no innate way of communicating required user input) to begin some action without giving them at least one or more of the most possible types of action signaling.

Although the course of action may seem very clear to us as developers, it may be unclear to the user without the proper signals and directors to drive the user to click on an actionable item.

As an example of how things might seem unclear, look at problem 4 in the following article about Sourceforge.net’s landing page:

• Case Study: Poor Web Usability and Design

Moral of the Story

If you are going to make some page element an actionable item (especially those with raised surfaces), at least make the cursor seem like it’s about to execute an action. If you can’t do that, then use the title attribute to show a tooltip about the action to be executed.

Counter Arguments

Now, there are the counter-arguments that I do agree with on a certain level:

• The hand cursor is reserved for the anchor tag, and the user knows that when they click the anchor they will be taken to a new page.
  • This is true; however, the latter supporting part of the argument fails because when a non-JavaScript actionable page element is clicked, it usually either removes, adds or modifies the page content. Before the advent of JavaScript, this could only be done with forms and anchor tags to make separate HTTP requests; however, with JavaScript we can do the same things without having to waste a request to the server**. Therefore, since the effect is the same, why shouldn’t their signals (mouse cursor) be the same?** Note: Look forward to a future article on the <noscript/> block. In proper usability, you shouldn’t put the blinders on to non-JavaScript enabled browsers and mobile phones.
• This is all bogus because desktop applications and operating systems, which the users are used to, don’t use the hand cursor for actionable.
  • This is a weak argument because of one the reasons that I listed above; inside of a web browser, people are used to anchors and buttons being the only way to execute actions. Since the hand cursor is used on hovering over anchors and buttons, it would be fair to say that most actionable items inside of a web browser should follow that same pattern.There are circumstances when not using the hand cursor might be okay; an example might be the +/- tree expansion and collapse (treeview).It’s contextual; you make the call on when you need to use the hand cursor, but err on the side of using it too much.

Final Tip

All it takes is adding the following CSS style to your element to make the cursor change:

• cursor: pointer

Sourceforge.net Landing Page

The first question we must ask is: why?

What possessed this elite software distribution organization to make this unappealing front page with poor usability? I digress.

Problem 1:

The large header at the top is really nice… for blogs or pure search engines; however, to waste 259 pixels on the landing page of an open source software distribution web site is a sin.

How many people do you think really search for software on Sourceforge?

If I think about it, the only way I get around when I’m on that site is to drill-down by category.

However, most often I follow a series of links to a hosted project web page on Sourceforge via Google or some other referring site/resource.

To be honest, I don’t know if I have ever searched for anything on Sourceforge.

I don’t think that they have enough people using search to warrant a landing page that has such a large section of page focused on search.

I believe that they could have accomplished the same goals without such a large area at the top (considering the top nav area on the rest of the site is only 102 pixels).

» SIDE NOTE: if you are going to center your page around a search box, at least focus() the mouse pointer on the search input!

Problem 2:

As described in problem one, we again hit on the abuse of negative space, but this time it’s the main navigation bar.

The three so-called “buttons” that they have placed there don’t really act like buttons! They have a huge selection area with a raised three dimension effect, and when you hover over any area of the “button”, the “button” image doesn’t change at all.

Moreover, as you can see in the third figure in the picture below, the actual actionable area covered by the anchor is tiny in comparison to the area it should cover.

If you do the math on the pixel areas covered, only 11.7% of the “button” area is actually clickable!

Moreover, the only thing that changes on the anchor on hover is the removal of the underline and the usual hand cursor appears; this is not very noticeable.

What should they have done? Just to name a few…

• Make the anchor a block level (“style: block”) element so the whole h2 is filled
• Do something on hover with the anchor element besides remove the underline; use bold, color, font-size, italics or something else to show it changes
• Increase the anchor font size or boldness to make it pop a bit more
• Change the background button image to a hover image when the mouse hovers over the area. (Make the button act like a button)
• Reduce the size of the button. Instead of having the same background span all three anchors without a visual break like a big friggin space bar, break it up into discrete visual chunks.
• Add a title=”…” attribute to the anchor to create a tooltip, which describes the action to be executed, on mouse hover.

Problem 3:

I believe I don’t need to even go over their crappy use of the slideIn() and slideOut() for the navigation content; it explains itself.

» Problem 4 (the main problem and article impetus) «

The main problem on the Sourceforge.net’s landing page that actually spawned the need for me to “bring this to light” was their quirky little button at the bottom of the page…

This button, when clicked, extends some additional information at the bottom of the screen…

1st Issue:

Why in the world did they make a button for displaying only 127 pixels worth of footer content?

The button and useless bar-thingy take up ~40 pixels itself; was it really necessary to save 75% on what would have been the initial browser paint?

I could understand a little more if an AJAX request was made because it would save 1KB or so uncompressed; however, the content is just hidden from display!

» SIDE NOTE: what the heck is that useless bar-thingy doing there? The space inside that bar made me feel like when I pressed the “button”, I was supposed to see the hidden content appear inside that 10 pixel high useless space; however, I was disappointed.

2nd Issue:

When you hover over the “button”, your mouse (nor does the button image for that matter) gives no indication that the area below the mouse will execute any action or event by clicking on that element

It really bothers me when you click an element in a web page, where the regular mouse pointer is being shown, and an event or action occurs to my surprise.

What did I expect to see? Something more along the lines of this…

As compared to the method currently used on Sourceforge’s landing page, the above alternative makes the action clearer by doing two simple things:

1. Apply “cursor: pointer” to the enclosing element to show the hand cursor on mouse hover.
2. Add a title=”…” attribute onto the enclosing element so that a tooltip describing the action to be executed appears when the mouse hovers.

The Reasons for their Haphazard Page Design & Development

Who knows?

What do I think?

• I think someone or some team at Sourceforge.net stumbled across the revamped jQuery UI home page a few months ago and decided to go buck wild with integrating as many jQuery UI components as possible.

I have seen this happen so many times; just because an object has the capability to do something, doesn’t mean that it is right to use it.

What Do You Think?

Please leave a comment below and rate it!