Today I posted this question to LinkedIN and I was floored by both the speed and the detail of the responses. Informally surveying the responses I’d say most are in favor of the HOME button call out in the main navigation.

Here’s a highlight of some of the responses.

• Sometimes clicking on the logo takes you home and sometimes it does not.
• I click on “home” links quite frequently, especially in bread crumbs.
• I personally don’t even look for a home button, though I do like breadcrumb navigation links.
• I got 4 blank stares from the very educated 30 to 50 year old normal web users in the room. “Clicking a site’s logo takes you to the homepage?” one of them asked me. Which was justification enough for me to keep the nav button.
• Maybe 20% of users are aware of the logo-as-home-link standard.
• On rare occasions I’ll use if it’s there.
• I don’t think everyone is aware that the logo goes to the site home and in any case one of the most frustrating things about many sites is that you have to *think* to navigate.

What to do?
Andy Bosselman said it best “look to the leaders”, so I did. I looked at usability leaders and well-known sites and the results were mixed.

Using It

AdaptivePath

Nielsen Norman Group

37Signals Basecamp

Adobe

There’s No Place for Home

Microsoft

Apple

Amazon

The Verdict
Clearly, there isn’t a standard that is widely accepted on the top-tier sites. In our case, for the last few years we really have restrained from using the HOME button unless the client specifically has requested it. Based on the responses and discussions within the office we’ve arrived at a decision. We’ll include the HOME option in the navigation as long as the navigation isn’t overcrowded. It just appears that the logo-clicking standard has a long way to go before it is widely accepted.

On a daily basis I spend anywhere from five minutes to three hours cursing and wishing ill will upon Microsoft Internet Explorer 6. Sometimes I do this silently under my breath and sometimes, to the dismay of my coworkers, I do it quite vocally. The reason? Internet Explorer 6 is an: insecure, slow, outdated, and non-standards compliant browser.

Let me illustrate this a bit further. If browsers were cars — IE6 would be an El Camino truck that’s been sitting outside in the rain for 20 years. Underpowered, ugly, basically useless in every scenario, and ready to explode and kill you at any moment.

Development of a website that supports IE6 adds about 15 to 20% of additional time to a project. And further, IE6 doesn’t support the everyday commonplace technologies of all other modern browsers. Meaning websites simply don’t function or look as good as they do in today’s browsers.

So here’s the question.

If today’s modern browsers (Firefox, Safari, Chrome, Opera, IE7) are easy to get, run faster and safer than IE6, and are free. Why are some company IT departments still forcing users to browse on IE6? In general it seems to boil down to three big reasons.

1. The company has internal software that was built specifically to run on Internet Explorer.
2. The company manages a ton of machines and the workload/headache of upgrading them all to a newer version is too much.
3. The company and users feel comfortable on IE6 because they “know it”.

Here’s the problem. When we as an industry don’t embrace new enhancements in development it’s the client’s viewers and the client’s brand that suffers. We’re still building phenomenal web sites. But the straight truth of the matter is they’re not as good as they should be. The web has soooo much potential but it’s not being utilized. Why? Because we’re still supporting a legacy browser* that was released in 2001.

As I’ve said before. In order for things to get better sometimes you just have to make the jump. Other companies are already doing this. Apple, 37Signals, and Comedy Central just to name a few. Notice anything about those first two? They dramatically care about their user’s experience. So much so that they’re willing to sacrifice incompatibility for some users to benefit the rest of them**. Cheers to that, I hope we see it more.

^{* As long as companies ask us to support IE6 we will. We’re not afraid to share our thoughts on the browser landscape but we also recognize the need to compromise.
** I understand that some users don’t have control over what browser they use. For these poor souls I cry (really, I’m tearing up as write this).}

Google just recently posted an article talking about their opinion on dynamic vs. static URLs. In short, Google is saying that dynamically created URLs from a content management system, i.e. URLs that contain information talking to a database such as:

/media_review.php?user_id=25&article_id=315

should be left as is instead of rewriting them to look cleaner (static):

/media-review/bruce/dnc-ratm-concert/

Here’s a direct quote from their blog post on the topic:

Does that mean I should avoid rewriting dynamic URLs at all?
That’s our recommendation, unless your rewrites are limited to removing unnecessary parameters, or you are very diligent in removing all parameters that could cause problems. If you transform your dynamic URL to make it look static you should be aware that we might not be able to interpret the information correctly in all cases… …if you’re using URL rewriting (rather than making a copy of the content) to produce static-looking URLs from a dynamic site, you could be doing harm rather than good.

The problem is that Google seems to be making a recommendation on what is best for their search engine crawling and not what is best for the user or web usability in general. There is no debate, URL rewriting makes websites easier to use. It makes people understand what they will be looking at when they visit a link, and in general provides clearer information than dynamic URLs. For instance, here on our blog you can see all of my posts by going to http://blog.imulus.com/bruce the url is clear and easy to understand. If you want to see all my posts for a certain category you can do this http://blog.imulus.com/bruce/css. This functionality makes logical sense. Websites with extremely complicated URL calls can utilize rewriting to help their viewers better understand where they are on the site. And in regard to marketing materials — the time I see a company willing to use a url with ?id=237 at the end for a marketing or advertising campaign will be my first.

The fact is this, URL rewriting is an extremely useful tool (ironically Google’s blog post about dynamic rewrites uses rewriting for the URL). And while certain rewrite schemes may hide data that Google would like to parse, that doesn’t mean people shouldn’t use rewriting. The idea that a usable standard should be changed just to make Google’s web crawling better is ludicrous. Google throughout their history of search has continuously accommodated for changing website methods. By stating that URL rewrites are improper Google is taking a strike at one of the best standards to come out of Web 2.0. They’re suggesting a machine’s readability is more important than a human’s. And guess what: they’re dead wrong.

I’m a big fan of 37Signals and what they stand for so I know my feature request has a 99.9999% chance of never getting implemented but I’ve got to make these requests for BaseCamp.

REQUEST #1
Apply to All
When creating 10 or more Milestones, please give me the ability to apply my dropdown selection to the other 9 Milestones. For instance, if I’m selecting USER A for who is responsible, why do I have to select that multiple times?

REQUEST #2
JavaScript Calendar
Why is it when I add 1 Milestone I’m given a nice visual calendar to select a date but when I’m adding multiple Milestones I’m given a date drop down for both year, month and date. It seems as though this design choice is making me work too much.

REQUEST #3
Hasn’t Logged in Recently
This use to work really well but it changed a few months back. Now I can’t tell the difference from a user who hasn’t logged in verses a user who has never logged in. Perhaps a simple variation call “has never logged in” might help here.

Otherwise this is a great product, I continue to recommend it to my clients and associates but these few changes sure would be real nice additions. At least in my book.

This weekend I played around with my Mint account and part of the setup included me tying in my 401k program which is managed by Paychex. Mint just couldn’t connect to Paychex so I decided to visit the site to find out what’s the deal.

I was greeted by this atrocity.

I partly want to commend the designers for trying something new, but this isn’t the site to try that on. The audience here isn’t likely to be tech savvy or frequent visitors; two criteria I would look for when trying out a new interface direction.

Users are familiar with entering a username and password but an image is pushing it. 6 hours after selecting my image I came back to the site to write this post and I forgot my image already. Who has a favorite image? My question to Paychex; why not just use a CAPTCHA here? They are becoming widely used and more and more people are becoming familiar with them.

Here’s a suggestion. Use reCAPTCHA if you don’t want to create this yourselves, but please get rid of this image option for “added security.” While you are at it, make the whole UI of the benefits section more usable.