Design and Development

There was an interesting article I came across titled “12 Killer Ways to Make Extra Income On the Web“. The article is interesting because there was only really 1 killer way that is even worth mentioning, and that is “Freelancing”. All of the other recommendations are either a waste of time or require much more effort than simply getting paid to produce good work. The age old “do-work-for-money” will never go out of style. If you’re good at what you do, of course you should be getting paid well to do it.

However, like all marketable things, your personal time is something that you should price with careful consideration. Unfortunately, there is one business model that is cropping up across the web that is counter to this. These sites (typically targeted towards logo or web design) allow you to submit entries for a chance to win a small cash amount ranging from several hundred bucks to maybe a thousand dollars for a winning entry.

Without being religious about NOSPEC, my advice is to steer clear of these “contests” unless you are simply trying to get your feet wet with design (or whatever industry you’re jumping into). There are various reasons that people throw around, but in my opinion, if you don’t value your time and effort, why should the client? If you really undervalue your work that much, maybe it’s because you consider yourself an amateur and not a professional. Also, on the flip side, clients that flock to these sites typically have no appreciation for the good work that professional designers can produce. As a friend of mine once aptly described it, it is like these folks couldn’t tell the difference between interior design and interior decoration.

Show respect to your own profession, lest you sarcastically post a blog entry entitled “Why I hate freelancers.” Whether it is web design or software development the good clients out there are looking for real professionals, not amateurs.

In his book “The Design of Everyday Things” Don Norman talks about mental models as a way to describe how a system is perceived from a designer’s perspective vs. a user’s perspective. The trick in having an application that feels natural for users is to have those two perspectives be as aligned as possible.

A few weekends ago, when I was conducting usability testing for Ronin, I noticed that the subjects were often clicking the upper-left logo to go home. This is a common paradigm on the web, and it’s often very acceptable to have the upper-left logo act as a “reset”, but I was disappointed in the inefficiency of navigation. For example, for a particular user to navigate to a certain invoice, he would click home, click on the client’s name in the “Recent Clients” section and then navigate into invoices from there. He would also frequently click from one client to another using “home” as a bridge while scanning for open projects. While this didn’t seem like much work (and he pointed to me that he didn’t mind it at all), I felt that the mental model he has established for the application didn’t quite match the mental model I had in mind as the designer of the application.

One problem I identified was that he used home as an entry point because it was the only thing common to all pages - the fact that they were tied to the home page somehow. The lack of consistently available top-level navigation made it impossible for users to develop a deeper, more accessible mode of traversing through the app.

Enter tabs.

Tabs help to establish a clear mental model.

What you’ll notice if you study most applications is that there is always a highly visible interface component that helps users establish a mental model of how to interact with the application. Media players typically have play/pause/stop commands, browsers have back/forward/address-bar, and web applications typically have tabs, or some high-level navigation element.

After adding the tabs in, I found that it helps reassure users of exactly what Ronin is designed to do. It helps scope the application so there is less learning time when a user first jumps into the application. It clearly maps out the high level concepts of “Clients”, “Projects”, and “Invoices” and gives users a consistent anchor to use apart from “home”. You’ll find that these tabs have been implemented into Ronin.

We as humans continually evaluate and reason about the things we perceive. Unfortunately, being subject to so many new ideas and applications means we can only commit a large part of our learnings to standard interface elements and practices. It’s up to the application designer to keep in mind that helping nudge this process along is often means obeying age-old rules of thumb. In this case, it’s “always have visible, clear, top-level navigation.”

I love Otherinbox. I think it’s a great tool to manage the email overload we’re subject to in this web-world of ours. But, getting my friends and family to check it out is impossible.

Why? Because they hit otherinbox.com upon my recommendation and they’ll look at and it and say “WTF am I looking at?” (exaggeration mine). So then it’s up to me to explain to them what it is, how it’s set up, why they need it. I realize after doing this a few times that it’s not up to me to explain other people’s products. That’s what a freaking homepage is supposed to do.

My advice: if you’re building a product homepage, you better have a 1-liner that makes people “get it”, because the one thing we’re short on in this information overloaded world is attention. (This is the same advice for sales pitches, VC pitches, whatever.) Your homepage is an elevator pitch. Heck, I’ve been elevators that move a lot slower than people skimming through product homepages.

The very opposite of that is a blog-driven product homepage. Blogs are for articles, news items, random-thoughts, not for product explanations. Maybe it’s just me, but when I see a homepage like that, I wonder why people are too lazy to make a good homepage.

I’ll give Otherinbox the benefit of the doubt and pretend that because they’re in private beta, they want to turn people away… (yeah, right).

Also, if someone from Otherinbox happens to run across this blog entry - change your favicon, please. It’s still running the Typepad default.

Effective development of any project (whether web or otherwise) requires effectively “scaling” the code-base. The experienced shops like Amazon break their code into services - modular components that are easy to understand and maintain by a small group of developers. I don’t need to hark on the benefits of modularity, but one can never overstate the importance of having a “shallow” code-base. The best software architects know this, and the big shops apply these techniques effectively.

However, from my observations, CSS always tends to get left out of good code-base architecting. That’s probably because designers who work with CSS only do it as a means to and ends - getting a pretty and usable design, while developers who work with CSS couldn’t run away from it fast enough. It’s stuck in some void where people approach it with a 10-foot pole.

Oddly enough, it’s CSS that is often in most need of solid architecting. After all, the “language” (if you can call it that) sucks, was poorly designed, doesn’t work consistently in most browsers, isn’t DRY, and makes people want to take a sip of the old table driven kool-aid once in a while.

Here’s how I approach the problem:

1. Break your CSS files down. Give your CSS files short, easy to understand names. “basic.css” is not a good name. What’s basic about it, exactly? “main.css” is a poor name. Is it the main CSS file or CSS for the page called main? I like to use “common.css” for CSS patterns (more on that later), “style.css” for styling only (more on that later) and “x.css” for pages called x.
2. Use an asset manager. This goes with number 1. Breaking your CSS down into small chunks means more round-trips if you <link> each stylesheet. Go with an assest manager to bundle all those files for you. For example, try bundle-fu for Rails.
3. Separate styling and layout. Styling is what your <em>s <strong>s <h1>s look like. Layout is probably specific to the page. Get detailed. “styling.css” can be for basic HTML elements, “styling-modules.css” can be for styling specific to reusable modules, etc. Developers call it separation of concerns. CSS designers call it sanity.
4. Don’t put IE specific hacks into their own file. (Only do this if you don’t care about validation.) This flies in the face of convention wisdom. Well, the next time you’re wonder why something looks different in IE after pouring through your CSS, only to realize 30 minutes later that something’s inconsistent in “ie6.css”, don’t forget what I told you here. IE specific CSS files are un-DRY. Instead, put the hacks as close to the non-hacked CSS as possible and document it.
5. Use common patterns. People spent countless hours on things like clearfix and the holy-grail so you don’t have to. Put these common patterns into their own file (I like common.css and common-layout.css) and don’t mess with that file.
6. Use a reset. This is an extension of #5. Resets means your CSS works tabula rasa. No more wrestling with inconsistent browser defaults. Try these reset rules. Make sure you document any exclusions for bandwidth saving reasons.
7. Use white-space effectively in CSS files. This one doesn’t work for me, but I’ve seen people swear by it. Use indentation to mimic the DOM hierarchy when you’re doing complex selectors.
8. Document CSS like you would document code. And realize that sometimes the best documentation comes from having well thought out CSS in the first place, just like how good code documents itself. If you’re working in an environment where many people are touching the same CSS files, having everyone understand the organization (see #1) is the only documentation you’ll need.

I’m sure there’re are more best-practice approaches to “scaling” CSS so that more than one person can work on it without going bananas, but these work well for me. Heck Ronin only uses a subset of these rules, and it’s already saving me my sanity. Google around and maybe you’ll find more to add to this list.