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.

Back in August I had the pleasure off hearing Jason Fried of 37Signals discuss 37Signal’s philosophies and methods. The presentation essentially followed the same script & theme which you can see here.

For those unfamiliar with 37Signals’ software and design principals here are a few examples to give you a flavor of their thinking:

• Less is more.
• Meetings are useless.
• Working remotely and collaborating is better then being in an office and interrupting each other.
• Chunk large projects into smaller bits which can be completed quickly.
• Focus on speed rather then perfection.
• Don’t do specification, wireframing or usability studies. They are a waste of time.
• Personas are bullshit.
• Invest in what doesn’t change like speed and customer service.
• Roadmaps and planning are useless.
• Morale feeds off progress.

Now, I’m a big fan of 37Signals and what they have done; however it’s a mistake for interactive agencies, web designers and developers to wholeheartedly adopt 37Signals’ ways of working without establishing a strong reputation first. It is key to point out that 37Signals is a product development company, not an agency focused on developing marketing sites or building custom client applications. 37Signals builds for 37Signals!

I asked Jason, “Why don’t you do consulting work or client work any longer?” His response was “it isn’t profitable compared to product development.” I’m sure he is 100% correct. The 12 person team at 37Signals is raking in millions of dollars in revenue each year. By contrast client work is time consuming, labor intensive and involves lots of education between both sides of the project. We are a company of 9 people and we haven’t even crossed the million dollar revenue mark yet.

Jason’s presentation did address several audience questions about client work. Which can be summed up as follows:

• Select your client’s carefully. Not every client is a good match.
• Train your clients on how you work, rather then how they expect you to work.
• RFPs and scope-of-work project estimations should be avoided at all cost because the written description can be interpreted differently depending on the reader.

37Signals originally started as a web design company and then they morphed into a product development company because the product work was far more profitable. Therefore I have to be critical of how their recommendations apply to us interactive agencies. Their advice doesn’t come from success in the client services area!

The ONLY way a client is going to be willing to accept those 3 points is if they know your agency’s record, and they RESPECT your abilities above all other agencies. Let’s use an example. If Widget Corp is looking for an agency to redesign their aging ecommerce site, and two other equal agencies are willing to bend to the desires of Widget Corp’s RFP, then good luck getting that project.

There is something to be said about standing your ground and holding true to your principles however at the end of the day if you don’t have revenue, then you don’t have a business. I’m not interested in being a martyr for the cause.

I’ve always admired the work of IDEO. They are a company which solves problems for their clients in a very fluid and evolving manner. They have put themselves in a position of respect, they do amazing work and I’m pretty sure they are VERY profitable. Any web company doing client related work would be well served to study the success of IDEO while blending in the philosophies of 37Signal’s product development methodologies.

At Imulus we plan on doing things differently. We’ll be proof that a interactive agency can develop great products while doing extraordinary client work. We don’t believe the two are mutually exclusive. Our position is the our brand of doing great client work and great product development will put us in a position of respect. This position will allow us to negotiate using the 3 points above.

This is our position and what makes Imulus unique in the realm of interactive agencies.

Months ago I posted an article explaining my opinion on Apple as a company that I passionately love and resepct, but also one that at times hurts its base by making overbearing decisions that punish users and developers.

However, as I’ve said before, to Apple’s credit they do listen when there’s an uproar. And point in case is the decision by Apple to drop the iPhone developer NDA. Now, here at Imulus we haven’t done first hand iPhone application development. But as technology advocates, developers of online software, and supporters of Apple products, we like seeing Apple make the right decision. There is no question that removing the NDA will make applications instantly better. In a nutshell it will allow developers to: exchange code samples, publish tutorials and techniques, as well as publicly talk about bugs and problems. Now instead of forcing developers to reinvent the wheel with basic iPhone functionality they can work on implementing standards for complex functions.

Apple also made the decision to restrict iPhone app reviews to actual purchasers of the app. Up to this point tons of people have been critiquing applications without ever using them. Leading to reviews that sounded like: “the app looks okay but it’s too expensive so I’m giving it a low score.” This is ridiculous. And Apple has made the right decision in allowing only users of the app to actually critique it. Another win for developers and users.

So cheers Apple, thanks for your support in making the platform better, even if it did take longer than it should have. The outcome will be worth it. Now, if only you’d give away the iPod touch 2.0 software for free to previous owners.

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.

We run across a lot of discussion whether the stage of wireframing a website is important or not. Should you avoid the process of wireframing and just dive into design? What is the purpose of wireframes and why many designers and developers implement this stage as part of their planning tool?

Wireframes are an essential tool of communication that provide a rough guide to website structure. Their purpose is to give guidence to general layout, navigational elements, and content structure to designers, developers and clients. The stage of wireframing is achieved after the process of sitemaps has been approved. At this time, you should have in your hands a site structure in a hierarchical style. Here at Imulus, we take time at a wireframe stage in order to run the design and developing stage smoothly. Only an educated client will understand this process if explained. Sure, all clients would like to see their website redesigned in 24 hours…that would require a lot of java. We take time to explain to our clients why this stage is important to us and to them as well. They will understand.

Our designers will work through the wireframe stage to completion and then will sit down with our developers to discuss the many possibilities. This opens different perspectives which are always handy to get everything on track. For example, when it comes to talking about some special functionality feature for the site, it is a good thing that developers know this ahead of time and see what’s expected. They can see what problems they can run into and how to solve them ahead of time. It is too late if this got avoided when the design is already in development. As for the designers, it is easier to have a wireframe in hand. You get the idea where things are supposed to be, and start to visualize the design. Try to have some fun with wireframes. OK, sure, they can get boring sometimes especially when it comes to some revisions but that’s all because you’re anxious to start the designing and developing. Also, you don’t have to adhere strictly to what the wireframe is showing. We have run across many times where the wireframe was showing one thing, but in the design stage we have changed it. It’s all right to change the wireframe in the design stage as long as the purpose and direction is not lost. My advice is to spend whatever time necessary to complete the wireframing stage; it will make your job easier in the design stage, and will save headaches to developers, as well as to clients.

A book recommendation to follow on a wireframing stage: Web Redesign 2.0 | Workflow That Works by Kelly Goto & Emily Cotler