Design and Development

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.

I ran into this little gem today: Golden Rules for Making Money by P. T. Barnum (1880). It just proves nothing changes when it comes to the fundamentals of making money. However, these days, there’s an extra word, instead of “Making Money”, it’s now “Making Money Online”. Just ask David Heinemeier Hansson, he was even compelled to give a talk on the subject.

Well let’s see what the new-age twists are on these Golden Rules. What changes to P.T. Barnum’s rules when we apply web 2.0 logic to it? Half-seriously, I call it Golden Rules for Making Money 2.0 (web entrepreneur edition).

1. Don’t mistake your vocation -> Hackers should code, designers should draw stuff in Photoshop, and Businessmen should sell and give VC pitches.
2. Select the right location -> Move to the valley. Or at least be in India or China.
3. Avoid Debt -> Splurge on someone else’s dime. Get VC money.
4. Persevere -> “Startups rarely die in mid keystroke. So keep typing!”
5. Whatever you do, do it with all your might -> Stick with Ruby.
6. Depend on your own personal exertions -> Take as few partners as possible. More sweat equity.
7. Use the best tools -> Stick with Rails.
8. Don’t get above your business -> Release early, iterate often.
9. Learn something useful -> Learn Scala or Erlang on the side.
10. Let hope predominate but be not too visionary -> Do something small …
11. Do not scatter your powers -> … and do it well.
12. Be systematic -> Switch to 4 day work weeks.
13. Read the newspapers -> Read Blogs.
14. Beware of “outside operations” -> Don’t blow your exit money on another venture. See rule 3.
15. Don’t endorse without security -> VCs: invest in people with previous exits.
16. Advertise your business -> Use Google Adwords.
17. Be polite and kind to your customers -> Offer email and phone support.
18. Be charitable -> Open source parts of your code.
19. Don’t blab -> Get IP. Enforce it.
20. Preserve your integrity -> Don’t comment spam or SEO spam to get traffic.

See? It’s basically the same thing nearly 130 years later.

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.

The mantra of the web 2.0 app is to release early, iterate often, and repeat. A big part of the “iterate often” though, can be confused for rolling on your own intuition. Even a great dog-food eating developer won’t be able to guess exactly what his or her customers want. After all, every individual is different.

This past week, the buzz in the developer world was/is Jeff Atwood and Joel Spolsky’s stackoverflow.com. One particular off-topic item that immediately caught my eye was the floating “Feedback” tab on the left side of the screen. I thought this was brilliant. It was an personal invitation for users of the site to express their opinions and cast their vote on suggestions for improvement. 

After clicking on this Feedback tab, I realized that this was a service provided by UserVoice. The folks at UserVoice have come up with a simple, easy-to-install widget that every web service out there can take of advantage of to quickly gather valuable user feedback. Brilliant.

Being a big fan of gathering feedback for product direction, I decided to look into it for Ronin. By the time I hit publish on this blog entry, you’ll be able to find the Feedback tab in your Ronin account. Use freely.

I’ve been a part of quite a few startups with varying degrees of involvement. I’ve been a part of them, studied them, worked for them, observed my friends involved in them, heck, even started them. I’ve watched them grow, watched them plateau, watched them die. If I had to distill my entire experience with start-ups into one rule of thumb, it is that start-up life is a roller coaster. A manic-depressive roller coaster.

No seriously. You are not ready.

Paul Graham writes:

One minute you’re going to take over the world, and the next you’re doomed. The problem with feeling you’re doomed is not just that it makes you unhappy, but that it makes you stop working

This cliche metaphor about roller-coasters is not news for anyone who’s read anything about the scene - it pretty much goes in one ear and out the other for the entrepreneur. However, I find it only really hits people hard when they get a taste of the roller-coaster of emotions first-hand.

I’ll be the first to admit that I had very little understanding of just what this roller-coaster feels like. When I was 17, I had my first experience at “entrepreneurship” building a small Windows application that was simple music production tool. In retrospect, it didn’t stand a chance, but I was young.

At the time, it was project of love. I didn’t necessarily want it to become a business - I just wanted people to like it. But, I think somewhere along the way, ambition snuck-in and turned it into more than just fun. I would devote time every day to working on my code. I would scour the internet seeking best-practice advice from peers twice my age. I would dream about features to be added in between classes. I would gather feedback from close friends - all in a very self-assuring feedback loop. Being young, every line of code, every keystroke, was fueled with “what ifs” - tell-tale signs of foolhardy ambition.

What-ifs are always escalating. What if my friends really love my app? What if it gets the attention of a small group of people? What if garners the adoration of hundreds of users? Thousands? Tens of thousands? What if people like it so much, I’d be able to pay for college just on software sales? Maybe even make a living off of it? Maybe it’ll make it big and I’ll strike it rich? Ah, the possibilities. The upwards roller-coaster was in full effect.

The way down is a lot less fun. It sucks. You begin doubting things. You begin to doubt your creativity, your reasoning, your abilities. You start to wonder if all that hard work you put in was worthless. The proverbial cloud is draped all over you for a long time and you begin to do more second-guessing than hacking. 

… And then something good happens. Either some new development arises or you’ve got a great new idea. Either way, you’re back on the roller-coaster.

Looking back on that experience (and the many between then and now), the greatest thing that came out of it was my growth as a person. I learned to appreciate the art of programming - setting me up for a future in computer science and software engineering. I learned to appreciate balancing personal life, with project life, with school life, and what eventually became career life. I learned that the rewards for writing software can be at a personal level - almost spiritual. I learned that the roller-coaster ride is tough. These learnings are constant; they’re everlasting. Good lessons are roller-coaster free.

The reality is, your wildest imaginations about the possibilities for your projects never come true. This is especially true in the current Silicon-Valley start-up climate. Everyone thinks that with a few lines of code, they’re going to be the next Big Thing. Dream on. If you’re thinking you’ve got some secret sauce that will take you to the top in one shot, you are just waiting for that roller-coast drop to bite you in the ass.

Instead, get real. Get realistic. The best way to avoid the fall is to never let your head get in the clouds. Start projects on small ideas with the realization that the most you can ask of it is that you’ll enjoy working on it, that you’ll learn a lot about your craft and your own abilities, and that you have a very good shot creating something great for like-minded individuals. The greatest success will eventually come from a series of small steps. But that takes the realization that sometimes, the greatest success is not financial, but personal as well.

In an oft-quoted blog entry, Chris Wanstrath of GitHub writes:

I didn’t just walk out of high school, pick up a Ruby book, meet Tom and PJ, then launch the site GitHub.  Before GitHub came, in chronological order, Spyc, Ozimodo, my ozmm.org tumblelog, ftpd.rb, Choice, Err the Blog, acts_as_textiled, Cheat!, acts_as_cached, Mofo, Subtlety, cache_fu, Sexy Migrations, Gibberish, nginx_config_generator, fixture scenarios builder, Sake, Ambition, and Facebox.  And that’s just the stuff I released.

In About Us, I described that “we want to do something small, something important, and something really well”. That describes Ronin as a culmination of the ideas I’ve described. Ronin is not a roller-coaster ride. Ronin is a labor of love - not a shot at a billion dollar business. I only ask that it provide me with more learnings, more experiences, and good people to work with. I hope that idea resonates with both the people who enjoy Ronin as a product and the people who read this blog entry with ideas for projects of their own.

Ronin was built with the idea that small firms and independent contractors should have an easy to use and super-affordable invoicing and client management app in one simple service.

Before we started Ronin, we took a look at existing products out there (and there are plenty) for our own freelance use. After reviewing the options, we decided that people deserve an alternative that doesn’t cost more than the monthly cable bill. Even better, for small businesses with a small number of clients, Ronin should be free. We also wanted something that fits our work flow.

To make all of this feasible, we applied the philosophy from Getting Real into the product that we built - everything you need, nothing you don’t. We built in all the features we feel that we needed in our experience doing freelance work, but we’re always open to more ideas and welcome suggestions to improve our application to what suits our users.

We also believe that companies don’t have to aim to be the next Big Thing. Instead we want to do something small, something important, and something really well. By not trying to be everything for everyone, we can be something useful for you. We hope you enjoy our product.