engfer(s)

At the time of writing this article, I couldn’t find a more perfect example than the landing page of the open source software distribution web site, Sourceforge.net. Now, I’m not really sure what web usability and design standards (if they even used any) their designers/developers were using when they made this page, but I am going to pick apart and explain some of the problems that I see as poor selections and decisions for the landing page.

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!