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.

While the bulk of Imulus development takes place in a .NET environment we all still enjoy geeking out from time to time. As a previous Ruby on Rails app developer (mainly front end) I have a fascination in staying up on RoR as well as other open sources frameworks and languages. Obviously this includes a vast number of options now days (RoR, Cake, Django, etc). However, the bulk of them have one common thread, MySQL.

Unfortunately for quite some time getting MySQL to run on Mac OS X 10.5 was somewhat of a pain in the ass. In comparison to some database setups typing in a few terminal commands is no big deal, however, compared with installing MySQL on 10.4 Tiger the 10.5 install was a huge step back. Tiger had a simple PKG installer that once run offered a simple start/stop MySQL preference pain within OS X’s system preferences. However, with the release of Leopard this prefpane was no longer functional. Luckily the issue has been fixed!

The bug has been addressed and there is now a prefpane that can be downloaded and used with version 5 of MySQL. Further it also seems that new versions of MySQL have this fix implemented by default. Great work MySQL community, it’s always nice to see frustrating issues fixed! Especially those that will help new users get a chance to try the product without jumping through hoops.

Earlier today I was reading an A List Apart article titled Progressive Enhancements with CSS. The main idea behind it being that breaking out styles into a multitude of files is beneficial. For example, creating a typography.css for type styles, a layout.css for positioning styles, and a colors.css for colors and graphics. At face value this sounds great because abstraction, for the most part, works well on computers (utilizing folder hierarchy’s, categorizing types of media, tagging web articles, etc).

Fine and dandy. But there seems to be a real world problem.

There are three big reasons I see not to break out CSS into multiple files.

First, when you break out CSS into multiple files you are forced, no matter what to write a lot of duplicate code. For instance, if I want to have a certain container have a typeface, background, and color in a single main.css file I can do the following piece of code:

#element {
     position: relative;
     float: left;
     width: 20em;
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

However, if I break this out into: typography.css, layout.css, and colors.css files I have to do the following:

/* typography.css */

#element {
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

/* layout.css */

#element {
     position: relative;
     float: left;
     width: 20em;
}

/* color.css */

#element {
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
}

Okay, pretty easy to see that the amount of code being used favors having one central CSS file. Now, let’s talk about style management and the second argument I have for not using multiple CSS files.

A single CSS file for a website can grow to be quite a large file. Most I’ve written fall in the range of 1200 to 2000 lines. The problem with this is that making small changes can be a bit of a hassle. However, I would argue that the single best way around a complicated CSS file is to clearly comment code, use shorthand css, and make sure there is good style structure. I.E. Don’t go styling something in two different parts of the file and don’t write five lines of CSS when one will do.

But, in no way is the answer to break the CSS into multiple files. Why? Because the worst possible thing you can have to do is deal with the above problem three different times. Granted, if you only have to make a small color change than you only have to edit one file. But, if you use only one file to begin with then you only have to edit one file anyway.

Last, there’s a reason a site like digg loads in one 2500 line CSS file. The answer is that the less page requests the better. Doing multiple page requests to get different styles that are separated is inefficient. If a site gets a lot of traffic or a large traffic spike the less page requests the better. Granted, this may not be common but when it happens there’s nothing more important than trying to keep the site up.

Want more assurance?

Neither Dan Chederholm simplebits.com, Veerle Pieters veerle.duoh.com, or Jeff Zeldman zeldman.com use broken out CSS for type and color.

It has to say something when the big wigs in the bizz don’t follow the advice of A List Apart eh?

Exceptions?

As always, there are a few exceptions to this. For instance, if the website is like MTV.com and has a constantly changing color scheme then it could be useful to break out individual styles into a separate CSS file. One that overwrites the default styles of the base design and can be updated without disrupting the primary styling of the site. Also, microsites that have completely different layouts from their parent sites almost always deserve a new CSS file.

Conclusion

Basically there’s no need to break out your styles into a multitude of files. While the idea of abstraction might sound good the benefits just don’t add up. All you really end up with is a waste of time and resources.

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.

Incase is apparently not just about making sexy and functional cases for devices but they also have great design sense when it comes to their online checkout process. The instant you add an item to your cart the process begins with lightboxed cart contents. This focuses the user specifically on the checkout process, rather then distracting them with items like navigation, banners or other sorts of graphics.

Add to Cart

The Checkout screen makes full use of the display area rather then asking the user to enter each piece of customer data on a separate page. They don’t beat you down to create an account but they make it easy in case you’d like to come back again. Shipping and tax is updated on the fly and you are given the chance to review the total cost before you submit your order.

Checkout is SO NICE!

There are other items about the Incase Web site which I like, but I think it’s important to give them respect for thinking about the user and not following the typical flow of most product driven ecommerce site.