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.

I think that truly listening and paying attention to people’s ideas is something we all could do better.

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).}

The thing is that a lot of my video podcasts (diggnation, TED Talks, Wine Library TV) are great to listen to with just audio. And in fact I find the extra battery life saved can be a welcome benefit. Well, about two weeks ago I figured out how to listen to audio from video’s on the iPhone with the phone locked. Here’s how:

1. Start your video from the iPhone iPod app
2. Lock the phone. At this point your video and audio will stop
3. Double tap your home button to bring up iPod controls in locked mode
4. Select play and the audio from your video will start playing while the phone is locked

I’m not sure if this tip is published but it’s been super useful for me. Hope it helps you all out too.

Update: Just realized these steps also work if you want to listen to audio only with the phone unlocked. Simply do the above and then unlock your phone, wala!

Here at Imulus we think if you believe strongly in something you should voice your thoughts. Voting is one of the best ways to put your ideas into action. We encourage everyone to register, educate themselves on the issues, and then participate come this November 4th.

If you’re not in one of the states listed above you can find a full list of voting deadlines at Rock the Vote’s website.

Updated 10/16/08
For all the Colorado visitors to our blog. Here is a link to the Colorado Blue Book which describes the various voting amendments and the views both pro and con for them.

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.

/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 started noticing this right after I got my iPhone 3g about a month ago. Here’s the deal. Apple is downsampling images that are imported through iTunes onto your iPhone. I.E. they go from looking great on screen to looking grainy and slightly textured.

If you want to see for yourself save out a photo from your favorite photo manager and import it via iTunes onto the iPhone. It should now be located in your photos directory within the iPhone Photos App. Take a look at it closely in comparison with the original, you will see the result on the right (rollover for comparison shots).

Here’s my question, why is iTunes doing this to our photos? It seems like the iPhone has a good enough processor that it shouldn’t have trouble showing photo details. After all, this is the platform that plays video and 3d games. And even worse, it doesn’t seem to have this issue if you look at photos via Safari. In fact, I found that my image uploaded online and then saved via Safari to the camera roll looked a lot better than the imported version from iTunes!

What’s the deal Apple? I don’t want my photos and wallpapers to look like they came from 1996.

1. Don’t work on hard problems. Break them down and keep things simple.
2. Avoid distractions (open office environments, meetings, e-mail, etc.) get a site or product out of your head and into production ASAP.
3. Deliverables are bullshit, clients don’t care, the end product is what matters.

First off, I want to say I have great respect for 37signals and their impact on the industry. Having the chance to talk with Jason about issues such as: stopping IE6 support, disregarding Photoshop in the design process, and scaling with growth, was an absolute treat. Clearly the team at 37signals is one of the most innovative and talented in the industry.

However, I think 37signals dominance in the web products field has distorted their ability to critique the client-based approach. And while I don’t have knowledge to speculate specifically on day to day client interaction, I do have a few things to offer from a developer perspective.

Team chemistry is important.

First, people working from home all the time can be harmful to the group chemistry. Jason and team do a huge amount of work via telecommuting. Relying on campfire, screen sharing, and video chat interactions for the bulk of their communication. They feel this helps minimize distractions and keep people productive.

I’m not sold this is the way to go. I think it’s hard to truly feel connected and dedicated to your team if you don’t spend real time with them. When’s the last time you became really good friends with someone without spending some serious face-to-face time with them? For me it’s never happened, not once. And as great as chatting online is, it’s not the same as being in the same room and hashing things out. You miss the subtle face gestures, the inside jokes, the bantering, and the all around comradery that happens in the workplace. Part of the reason Imulus does great work is because we have dedication to one another. Even on days when I’m completely out of wack mentally I still find myself focused on helping the team. Why? Because I’m relied on to help create the great stuff we build. And I trust those I work with to do the same. As ridiculous as our office gets sometimes in the end we get shit done and we do it for each other and ourselves.

Deliverables have a purpose, it just needs to be refined sometimes.

Second, I don’t buy that all deliverables are bullshit. Just as some companies like to skip Photoshop (37signals) and go straight to coding, and others (Apple) like to make mockups pixel perfect it’s impossible to say that one solution is better than the other. Yet, we can agree that certain processes work better for certain people as well as certain projects.

Let’s talk about the way we work. Imulus’ basic approach is to offer the client a timeline, design brief, wire frame, and mockup of the final interface. Now, it’s important to realize that we haven’t always done it this way. In fact, for some time before I came to Imulus the wireframe process was basically nixed. What was the result? Instead of 5 hours spent reworking things in the wire frame process, 25 hours was spent reworking things in the development process. Look, we aren’t naïve, we recognize that clients change their mind and get new ideas all the time. However, we’ve found that most of this re-thinking takes place in the wire frame stage. And therefore we save hours of coding changes by altering the approach up front. In essence, if you’re building a car and the frame is faulty, why wait until the upholstery’s getting put on the seats to fix it?

Still, we know it’s a strong possibility that some of our deliverables are blown out of proportion. And as most firms do we will continue to collaborate and narrow down our inefficiencies. However, we have found that some deliverables are an extremely important step, and just because some projects or companies don’t require them doesn’t mean they aren’t important.

In conclusion

Clearly 37signals has clout and track record to support the way they work. And regardless of how that alters the Imulus process we love hearing about it. It’s phenomenal that they have so much passion behind what they do. I hope over time we can refine our own process to the point they have. Until then it’s great hearing a second opinion about things.

Here are my first impressions after a few days of use:

First off, the price point on all iPhone cases is ridiculous. They should all be $15 or under. That said, if I have to spend over $25 I mind as well get the best looking and feeling case I can. The Flick comes in at $35, a bit steep but in the ballpark of many other hard iPhone cases. I have the white and contrary to what I read on some reviews the white matches the phone’s white pretty darn well. It’s not a complete color match but it definitely looks better than almost any case I’ve seen. Primarily because it’s super thin. The thickness has a trade off however because it isn’t a largely protective case. It’s probably enough that it might save your phone if you drop it once but I would still aid on the side of caution. One concern is the bottom edge of phone (by the dock connector) because the case offers no covering for the metal rim on that section. However, for me it seems worth the trade off for such a minimal body shell and natural iPhone feel.

If you want a minimalist case this is a good buy for sure. It fits snug, looks great (minus no apple logo showing) and seems durable for basic wear and tear. I.E. a night at the bars, a skid across the picnic table, or the occasional water contact. Over time I assume the white will look cleaner than the black in regard to prints and scratches. Still, dirt might be another story. The case does scratch fairly easily but can only really be noticed from an inch or two away. The rubberish clip hinge on the bottom for docking is secure and feels good. However, if you plan on docking it nightly I could see it wearing out and not fitting as well over the course of a year.

To summarize: I recommend the Contour Flick highly but want to emphasize that this is really a case for people that want some protection in that awful “oh… crap… I just dropped my baby on the concrete floor” type of moment. This case is not for the “I leave my phone wherever I want to whenever I feel like it” type of owner. And definitely not for construction workers, waiters/waitresses, or stunt men. If you have additional questions please feel free to ask them in the comments. Also, if you’ve had particularly good or bad case experiences we’d love to hear about them.