One of the things I love with this blog is that I can go back, read my older posts and see how my writing has evolved over time. When I wrote my first post on September of 2006 after working on a fix for DasBlog that would let me run it on a cheap hosting account (with medium trust settings on IIS), I wrote for an audience. Within a couple of months I understood that I was not going to have an audience. It's funny how everyone realizes that after he starts blogging. That's when most of them quit. Others who absolutely love writing, even if they have to write for a very small audience, continue.

Then somewhere, after a couple of months, people started coming to this website in small trickles. That was around the same time where I had gotten used to the idea that I was going to blog for three people, You, My mom (who still reads everything I write) and me myself. Even though my writing was morphing into casual writing, I was sprinkling my posts with an overdose of "Dear Reader" all over my posts. Something for which I was heavily criticized.

The look and feel of the blog and the font was also a reflection of my writing style. The font's of the blog were carefully designed to look beautiful and professional. Verdana is supposed to be one of the most readable fonts out there. It's not esthetically beautiful however. So I decided to go ahead with a 9.5 to 10pt Tahoma (which is nothing but a slightly compressed, skinny and better looking version of Verdana, though not as readable). The idea was that if my blog looks beautiful, you might stick around and read stuff.

The entire blog ran on a DIV based design, because Graphic designers around the world told me that if you cannot do a DIV based design YOU SUCK. Yeah, Right. So I landed up with a DIV based design with strange CSS positioning which made the blog look slightly different on Internet Explorer and Firefox. That is a whole different post there, but the point I am trying to make here is that everything about this blog, was planned to be 'technically correct'.

But what is 'technically correct' Isn't always the most pragmatic thing to do. Of course the blog has to look beautiful. Of course it has to have a single consistent font across the website and of course the design has to be DIV based, but then when a few more people start showing up and someone leaves a comment telling you that he wants to print your stuff on a printer and your DIV based design is chopping stuff off in his printer, 'technically correct' is no longer the right thing to do.

This weekend a couple additional funny things happened which nudged me to go out there and make some changes to the design of this blog. This weekend, I had some time so I started writing. The topic that I picked however, was how most managers love the idea of pushing their team to make them work harder and what they can learn from parenting. Because this topic happens to be near and dear to my heart, it turned out to be one of the longest posts that I have ever written till date on this blog.

When I had prettied it up, proof read it and published it, I started reading it. That's when I realized how everything that was so carefully designed to be 'technically correct', was so utterly wrong. I was starting to feel sorry for anyone who was reading this blog in-spite the 9.5pt Tahoma which was just making it impossible to read anything more than barely midsized post.

I decided to go hunting for fonts. And after a lot of reading, hunting, trying out stuff (and soul searching) I've landed with Georgia as the default font for the post text. Here's why:

1. Georgia is sexy! I love the look of it.
2. Georgia is fun to read. I actually ended up reading the entire blog post on the slap and push technique to management on both internet explorer and Firefox and no it did not cause me a headache.
3. Georgia is preinstalled in both Windows and Mac machines. Which is where most of my traffic is based out of. If you are running Linux and do not have Georgia preinstalled, I highly recommend you get your version of Georgia from here.

Besides Georgia as a font does not break or look hideous when I blow it up to a size of 12pt to make my posts easy on the eyes of the readers who are actually going to read it. In fact it looks just as beautiful at a 12pt size which is what you are reading at right now. Oh and yes, did I tell you the italics on Georgia look beautiful and get the point across. Not like the italics of Tahoma which... suck.

Just in case you were wondering about how the end result is different, here is the before and after images on a paragraph on the older blog post for you to compare side by side. It's a scaled down, low resolution image but even with these images you should be able to make out the difference between overall readability.

The old font:

The new font:

I don't know about you, but I would pick the new design any day.

With the text of the posts changed to Gerogia, it was time to think about the left navigation. I picked Verdana there, primarily because I wanted you to focus on the content text than on the left navigation. If you need to look for a link however, Verdana, being one of the most readable fonts out there helps you spot stuff easily.

The idea was to tune the blog for the small audience that is logging in everyday and reading stuff and not for the casual lurker who lands on the site through Google and decides if he is going to stick around depending on how the site looks.

With the font and the font size settled, I set out in search of a good "line-height" that I should be using to be easy on the serious readers eyes. Looks like most BlogSpot out of the box themes are pretty generous about the line height. I settled somewhere in the sweet spot between 170% and 190%. What this means is that you are probably seeing enough vertical space between two lines so that you do not have to strain them or move your face closer to the monitor to read stuff even in really high resolutions.

I have been reading some of posts after these design changes and I feel that some one these changes are actually nicer to my eyes. Oh and while I was at it, I moved back from a DIV based design to a table based design. It's much easier to control and It seems to be giving me a consistent look across browsers. Besides a table based design makes it really easy for me to spread out my design in percentages and utilize maximum real estate on the page. I know its not the best approach to designing a website but it is way better than having to maintain different CSS files for each browser. After all, the technically correct answer is not always the right answer.

Put simply, I've broken every single thing on this blog that was supposed to make it look good and what we have here is a blog that is much nicer to your eyes. Given the choice between looks and readability, I would pick readability any day. If there is a way to have them both, I would love to. If you have a few tips or suggestions on how the design can be improved, drop me an email or use the comments section below.

Oh... and... sorry for hurting your eyes all these years and thanks for continuing to read. #Grins.

Wikipedia defines Lorem ipsum in a website design proposal as - generally incomprehensible placeholder text allows viewers to focus on the visual elements, rather than the content.

Lipsum - the online Lorem Ipsum generator is bullish about the Lorem Ipsum history and future:

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.

It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.

It was popularized in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

To be honest; Lipsum has a genuine reason to be bullish about Lorem Ipsum.

Graphic designers around the world have loved Lorem Ipsum for more then one generation.

Even today; I see countless graphic designers designing their site-layout using Lorem Ipsum; sending the designs out for review and then replacing them with real content as the project moves ahead.

Most graphic designers love Lorem Ipsum because it keeps them from having to work with those nasty business guys who are way too lazy to think about or give them genuine content upfront. Lorem Ipsum also shields the designers from those pesky programmers who make them fix their nasty HTMLs every time the designers try to work hand-in-hand with them.

The business folks love it because it allows them to walk up to a creative designer and say - 'I want a marketing website' - without having to worry about giving them any content or specifics before they start designing the website.

The programmers love it; because they can now develop their system without having to worry about synchronizing their development with the pretty-looking-screens.

Throw in a few stock photos; make pretty boxes; fill them up with Lorem Ipsum; and you are good to go. Life; for a designer; was never so beautiful before Lorem Ipsum showed up.

Put simply; at the end of the day; programmers love building ugly systems; graphic designers love building pretty boxes and business users love telling both programmers and graphic designers what they should do without feeling the need to take any real responsibility of the content or the message upfront. Lorem ipsum is a universal glue that makes this entire ecosystem function and makes all this possible. No wonder; we all love Lorem Ipsum.

Jason Fried at 37Signals however; has the courage to walk a different path and say no to Lorem Ipsum. He advices developers and designers to consider Lorem Ipsum their enemy; not their friend. He explains:

Lorem ipsum dolor has long been known as the designer’s best friend. We think it should be your enemy. Using lorem ipsum dolor reduces text-based content to a visual design element (a “shape” of text) instead of valuable information someone is going to have to enter and/or read.

We recommend that when you build out interfaces you use real and relevant words not “lorem ipsum” representative text. If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source. If it’s a name, type a real name. If it’s a city, type a real city. If it’s a password, and it’s repeated twice, type it twice.

The goal here is to get as close to the real customer experience as possible. Don’t abstract yourself from the real experience. Every layer removed pushes you further and further away from the actual customer experience.

Ben Hunt in his book; Save the Pixel; explains the same thing from the perspective of a veteran experienced web designer. He explains:

Design the content, not the box it comes in.

Use your pixels on things that communicate meaning. It used to be very common for web designers to make just templates – attractive or jazzy  containers which would have “content” added at a later time.

This is a fundamentally wrong approach, because it doesn't fulfill the designer's mission - facilitating communication. If you find yourself decorating the package, rather than crafting real, meaningful content, stop & ask: “Are these pixels best used here?”

You want the visitor to focus on the navigation & content as that's where the signposts are that point to the goals.

When you are designing the layout of a website; it is easy for you to get consumed by just the layout and not even think about the content or what the design is trying to communicate in the first place. Ben describes this concept rather articulately in his book - Save The Pixel. In his book he explains:

Design isn't Art. It's not about creating beautiful or thought-provoking things for the sake of it. Design is a discipline – creating communication with a purpose.

So the next time you head out to a Lorem Ipsum generator; try spending some more time on your content or your system and try to figure out the message that your application or website is trying to convey using your design. If you don't have a strong message your pretty boxes will not mean a thing.

Now; go think of a concrete message and decent amount of content or the system before you even open Photoshop.

This dear reader; is your chance to designing something meaningful.

Don't build pretty boxes with Lorem ipsum. Let your design be a part of your communication; what you want to say and what it is that you stand for.

I wish you good luck.

The phenomenon of clicking, since the mouse was invented and demoed for the first time was supposed to make computers easy. Today when I watch computer users surfing the web it is not uncommon to come across users who are 'thinking' with their hand on the mouse. Thinking about what to click next.

This post is that 'click'.

The whole idea of a hyperlink has philosophy elements attached to it. The statement, that on the web, you're just one click away from anything is a rather philosophical concept that the early internet veterans were very excited about. Visit any modern day portals and you'll find this idea bastardized to its limit.

MSN for instance, while I was investigating for this post, was literally over twenty-two-inches long, containing over two hundred hyperlinks (counted through Anchor elements in HTML), each of which appeared to be desperately trying to help you so that you are just a click away from everything MSN had to offer you that day. 

If you want to get an idea of the real scale of the size of the whole MSN front page you can take a look at full blown portal home page screenshot in real size.

Yahoo faces similar problems and so do tons of other portals out there. 

Remember the good old days of CD-ROMS where 'interactive' CD's were in and happening?  If there was one underlying idea in all successful CD-ROMs, it was this: they were 'interactive'.

You application is supposed to 'interact' with the user. It is not supposed to be a helicopter with complicated levers and switches the user is supposed to pull, turn on or turn off. What the interactive CD-ROMs in those days taught us about usability, is something most modern programmers drooling over technology, and most user interface drooling over pretty looking pictures and user interface elements seem miss out completely now-a-days.

Steve Krug in his book Don't Make Me Think suggests that working with a great web application should be an experience that is as interactive as playing 'Animal, Vegetable, Mineral'; the famous 'Twenty Questions' variant. My personal rationale behind this is fairly straight forward and simple. If you think about all the time that you spend online and the emotions that you experience in that time, chances are that most of your web experience is primarily composed of two types of emotions; or should we say two types of moments.

Put simply these moments can be classified as:

1. The Question-Mark moments - when you are thinking about what to click next; usually because you are looking for something and aren't sure where to find it.
2. The Exciting Exclamation Mark moments - when you are happy or excited; usually because you found what you were looking for.

The basic premise under which 'Twenty Questions' works is one of on making the journey of finding the answer as interesting as the answer itself. The trick is to make your question-mark moments really short, mindless and effortless. Every question mark moment should be followed by quick confirmations. Every confirmation of being right and being on the right track that you get; should be like a pat on a back; resulting in more excitement moments for you and encouraging you to stay hooked on to the application.

As the philosophers often say - if your journey isn't rewarding; reaching your destination faster just doesn't matter. Twenty Questions takes this premise and turns the journey to the answer into a fun-filled game. Steve in his book, 'Don't Make Me Think' suggests that web designers and web developers should do just that with web applications. Put simply Steve suggests that your web applications experience should be like playing 'Animal, Vegetable, Mineral'.

Deep. Don't you think?

Awesome; now let's do some more soul searching, get philosophical and talk about life and happiness.

On a serious note, besides just appreciating the philosophical aspect of things we're discussing here, let's talk a bit of about how you take a concept which is as abstract as this and turn it into something practical that you can use to make your applications better. 

That is what the folks at Google seems to have done when designing the iGoogle portal. What iGoogle does on its home page, for instance, is an amazing example of a portal playing the 'Twenty Questions' host for me. iGoogle doesn't know what I would like to see; so instead of confusing me with switches, levers or a gazillion hyperlinks like MSN, Yahoo and others, it offers me a courteous, polite question  on what I would like to see based on my interests.

If you were reading and were to take a look at the full blown screen-shot of the image above and compare with the full blown versions of MSN, Yahoo or other portals, chances are high that you will notice what iGoogle is fundamentally doing here.

It's interacting with you by asking you simple a mindless question; from the moment you land of the site.

On a side note, the message of the question itself - 'start by selecting some of our most popular content' - is confusing but the overall intent is pure and polite. The next time you visit iGoogle, it remembers your selection using a cookie and doesn't bother you with the same question again. What's really important here is that iGoogle doesn't worry about how many clicks might have to go in to tell it your interests. In fact, it expects you to start clicking right away; by keeping the clicks mindless.

Put simply, iGoogle is playing the host for 'Twenty Questions' and the game begins with a simple mindless question whose answer you already know based on your interests, the very moment you land on their home page. iGoogle doesn't work hard at reducing your number of clicks. On the other hand it works hard at making your clicks interactive, mindless and enjoyable.

When compared to the driving, while the MSN Home-Page and the Yahoo Home-Page are much like maps of their online city, landing on iGoogle Home Page is like landing on a freeway will really big billboards where it's really easy to find your way around, come back if you are lost and start drive again. You don't even need a map. Steve Krug talks about this analogy in his book Don't Make Me Think. He explains:

If You've ever spent time in Los Angeles, you understand that it's not a song lyric - L.A. really is a great big freeway. And because people in L.A. take driving seriously, they have the best street signs I've ever seen. In L.A., Street Signs are big. When you're stopped at an intersection, you can read the sign for the next cross street. They're in the right place - hanging over the street you're driving on, so all you have to do is glance up. Now, I'll admin I'm a sucker for this kind of treatment because I come from Boston, where you consider yourself lucky if you can manage to read the street sign while there's still time to make the turn. The result? When I'm driving in L.A., I devote less energy and attention to dealing with where I am and more to traffic, conversation, and listening to 'All Things Considered'. I love driving in L.A.

While most user interface folks spend sweat and blood in trying to offer you easiest way to get to where you want to go, sometimes, a long enjoyable journey is much more rewarding than just getting from point a to point b. Ever took that slightly longer drive through the freeway just to avoid the city traffic in the shorter route? Thought so.

Just like most modern day drivers aren't deeply worried about saving a little bit of gas, over a generally pleasurable experience and getting there faster; most modern day web users aren't worried about clicking a couple of times more, provided your application is interactive, the clicks don't require thinking and your page loads are blazing fast. In Don't Make Me Think, Steve Krug calls this 'Krug's second law of usability'. He explains:

It doesn't matter how many times I have to click, as long as each click is a mindless, unambiguous choice - Krug's second law of usability. On the face of it, "number of clicks to get anywhere" seems like a useful criteria. But over time I've come to think that what really counts is not the number of clicks it takes me to get to what I want (although there are limits), but rather how hard each click is - the amount of thought required and the amount of uncertainty about whether I'm making the right choice.     In general, I think it's safe to say that users don't mind a lot of clicks as long as each click is painless and they have continued confidence that they're on the right track. I think the rule of  thumb might be something like "three mindless, unambiguous clicks equal one click that requires thought" Of course, there are exceptions. If I'm going to have to drill down through the same parts of a site repeatedly, for instance, or if the pages are going to take a long time to load, then the value of fewer clicks increase.

While in some cases less is more; when it comes to clicks, lesser number of clicks are not always better. The next time you spend a lot of time worrying about reducing the number of clicks you might actually be spending your time in making the application less interactive and cluttering your screens with elements which requires your users to use their brains instead of their fingers.

May I suggest, dear reader, that we spend our time in making our applications blazing fast by reducing the page load time and focusing on adding interactivity without worrying too much about the number of clicks. When you're cruising through high speed freeway, no sensible driver cares about the trickles of fuel he might have saved had he taken the shorter busy road with congestions. After all, speed still matters.

Is browsing through your application as rewarding as playing 'Twenty Questions'?

Is Your application blazing fast when it comes to page loads and responsiveness?

No matter how hard you try, they'll never be just one click away from everything.

Let's get our priorities straight. Remember, when it comes to user interface, less is more; even today speed matters much more than number of post-backs and when it comes to clicks, three mindless, unambiguous clicks are better than one requiring thought.

If you genuinely worry about your users, worrying about their brains having to work hard is much more important than worrying about their fingers having to work hard. In fact, if you can pull it off well, like iGoogle does, they might even enjoy and appreciate a couple of extra clicks here and there.

The idea of reducing the number of clicks in applications and websites is highly overrated. Unless you hear otherwise from  your users; start with the assumption that nobody is counting the number of clicks. Stop hurting their brains and start working on giving them an overall better experience; even if it means adding a couple of extra clicks.

When you're a kickass programmer who spends more time with the compiler than with other human beings you tend to run into problems. You start to think of your code as a way for you to interact with your machine; instead of also considering it a way for you to interact with your end-users and other programmers who maintain your code. Long story short, you become slightly inconsiderate about your end users and you start thinking more-and-more like a machine.

You swing like a pendulum, sometimes expecting your users to understand stack-trace of your exceptions, which you display as error message, and sometimes considering your users to be complete idiots who understand nothing about software; so you lean towards not even telling them what went wrong and lean towards completely lame and generic error messages.

At Multiplitaxion Inc, I happened to witness an application where I saw a team lean towards the later. Someone in the team had found the ultimate way to encourage reuse in code and centralize exception handling. The result: Every crash that the application went through showed one generic error message. 'Error Encountered. Our support staff is working on fixing this'; or at-least, something to that effect.

After we played around with the application for a couple of days we knew exactly what to expect when 'anything' went wrong with the application. After a few weeks it turned into a joke; every time the our-support-team-is-working-on-fixing-this error appeared on the screen, there were remarks which were on the lines of, "awesome! now we know the support staff has some work to do and is finally working". I officially declared this as the forty-two of all error messages ever invented.

As hilarious as some of the jokes regarding the support-staff-is-working-on-fixing-this error were, there was something fundamentally wrong about the error. The ingenious idea of a 'generic error message' seemed to work under the premise that the user is an idiot who doesn't even have to be told what went wrong. To say the least, the error demeaned the ability and intelligence of the end user and whispered gently to the end user telling him - 'you're an idiot'.

The other extreme is telling the user everything that goes wrong in the application and expecting him to understand your code and stack traces. This approach turns out to be equally rude and demeaning. About Faces 2.0 by Alan Cooper and Robert Reimann illustrate the beautiful point about most applications being 'rude' by displaying irrelevant errors to the user and blaming the user for the error. They explain their point by using this error as an example:

Alan and Robert explain how this error and software applications in general are not just loud; but also rude to the end-user. Their initial reactions as they encounter this error are not just humorous but very close to how an end user's mind subconsciously thinks when it sees the above error-dialog for the first time:

Thanks for sharing. Why didn't the program notify the library? What did it want to notify the library about? Why is it telling us? Why do we care? And what are we Ok'ing, anyway? It is not OK that the program failed!   Software is often rude to the user. It blames the user for making mistakes that are not the user's fault, or should not be. Error message boxes like the one in [the picture] pop up like weeds announcing that the user has failed yet again. These messages also demand that user acknowledge his failure by agreeing: OK. Software frequently interrogates the user, peppering him with a string of terse questions that he is neither inclined or prepared to answer: "Where did you hide that file?" Patronizing questions like "Are you sure?" and "Did you really want to delete that file or did you have some other reason for pressing the Delete key?" are equally irritating and demeaning.

If there is one underlying theme in either providing completely irrelevant code related details to the end user or not even telling him what's wrong, it is the programmers inability to think like the end user. As programmers we go from expecting the users of our applications to be just as technically savvy as we are to being a complete idiots.

Most programmers may not admit to looking down on users who are not very technically savvy but the fact of life is that we tend to do just that when we write code. The LiveArt example, which made it's way all the way to the CNN website is a classic proof of this:

Of course, there are degrees of rottenness. "Some bad error messages," Ezzell says, "are just placeholders that slip through. We've all been there." Ezzell acknowledges he once wrote a message that addressed the user as "Dumbkopf" and was mortified when the dialog made its way into production. Thus, he sympathized with Orem, Utah-based Viewpoint DataLabs, which managed to include the following in its LiveArt install: Setup is unable to locate a suitable version of DirectX on your machine. You will need to install DirectX before you can use LiveArt98, dumbass! Sympathy notwithstanding, Ezzell awarded the entry third prize. Red-faced developers at Viewpoint noted that the message had simply slipped through the quality-assurance cracks and that they'd fixed the problem "about 4 seconds after we realized it was still there."

Yes, of-course the 'dumbass' part in the installer of LiveArt was an innocent joke by the programmers; but none the less it is an indication of the fact that most of us programmers tend to find the fact that computer users aren't as technically savvy as us, somewhat funny.

As a matter of fact, the truth is actually a little darker than that. Actually, we don't want our users to be as 'smart' or 'intelligent' as we are. We expect them be just 'like us'. We expect them to be just as connected to the compiler as we are, just as absent minded as we are and sometimes even just as 'stupid' as we are. If you don't really buy my point, the same CNN article, brings to you a few hand-picked error messages from the history of computing from environments ranging from Microsoft Windows to Unix:

1. Error: Keyboard not found. Press F1 to continue.
2. Windows has found an unknown device and is installing a driver for it.
3. Error 0000: No errors found, restarting computer.
4. The procedure failed with the following error: The command completed successfully.
5. Cannot delete tmp150_3.tmp: There is not enough free disk space. Delete one or more files to free disk space, and then try again.

These are classic error messages which may or may not have slipped through the cracks of QA or maybe it is a classic case the technical teams, not even realizing there was anything wrong with any of these messages. Of course, they were neither hoping nor expecting that the end users will feel a little, lost, when they encounter these messages.

Ben Ezzell has an entire site dedicated to the stupidity of the error messages; but Ben is not just critical. His criticism, like any good criticism, happens to be fairly constructive; it goes all the way to writing Developing Windows Error Messages; which provides excellent advice to developers. In his book, Ben advices that developers should work hard at trying to see that at the bare minimum, each of their error messages they write at-least help answer the following three questions that users typically have when an error occurs:

1. What is the problem?
2. Why is it a problem?
3. What can I do to solve the problem?

The task of displaying relevant and appropriate error messages to the user is an art picked with time and experience. As much as using accurate, easy-to-understand-and-act-on  Error messages might sound trivial to us as programmers; the act coding your error message has deeper impact on how people perceive your application and the love they give back to your application.

Of-course you can continue to classify making your error messages meaningful, sensible and genuinely helpful as a 'trivial' task which can be fixed 'later'; after you are done with your functionality; but there's one tiny little problem with that approach; after you're done, the 'later' never comes. Besides, not asking unnecessary questions; and eliminating un-necessary warnings is a way of life which requires considerable discipline throughout the development cycle.  Don't take your error messages and the politeness of your lightly. Consider spending some time thinking about these items as you code.

Go the extra mile and every time you write an error message question yourself - do you really need to inform the user about this error or can you fix it yourself? is your error message full of errors? Is it outright rude? Assuming that the user understands your stack trace is expecting too much from him. Assuming that he is stupid and hiding sufficient details from him  is stupidity on your part.

Making your error messages sound like it's the users fault or making it sound as it was some external factor which caused the error to occur and then providing no clue about how to fix things is even worse.

After all, if your application doesn't work, we all know who is responsible for it.

On a serious note, don't write rude applications, May I suggest that we as programmers, consider introducing some 'politeness' in the applications we build.

Building applications that are not rude and avoiding errors in your errors is an art. The level of politeness you introduce in your application will usually decide the love it gets from it's users. Now go search all the error messages in that codebase you're working with and start reviewing them meticulously; can you find errors and warning which can be avoided or eliminated? Are your error messages full of errors? Are your error messages outright rude or demeaning to the users? Consider putting in some effort and thought towards making them meaningful, polite and genuinely helpful.

Ben Hunt has written an Excellent book on Web Designing; but when it comes to his own blog / web-site, Ben is guilty of breaking rule number three of Thirteen Blog Clichés . Jeff Atwood describes:

Go ahead click the link to the online version of Ben's book which is a freely available on his web-site. There are ads of other books that Ben has written on the page but when you try to find the author's name for the book that you are reading - zip! nothing!

I landed on this page through a Google Search Query and while reading the Web 2.0 design guide I had a hard time finding out that Ben was actually the author of this excellent book which imparts words of wisdom to web developers and web designers around the world on how to build effective web designs.

It was only when I navigated back to the primary domain (web-design-for-scratch) that I found out that Ben owned the entire site and that the book belonged to him.  Ben Hunt, in spite of being an amazing web designer, a great writer and a web guru, is guilty of making me think and that, according to Steve Krug, is an offence. Take that, Ben! :)

Jokes apart, for me Ben's book is as good as Don't-Make-Me-Think when it comes to building web-sites; and what' makes this book even better is that it's available online for free.

You there. You, yes you. If you're a web designer or a web developer building web applications you need to stop whatever it is that you're doing and read this book. Now! No, I don't care if you are busy; I don't care if have a lot of work to do; I don't care how many other usability and web design books you've read; go tell your boss you won't be doing anything for the next one day and read this book word by word.

Seriously,  Read the book; chances are, you'll probably take home more than one idea on web design that you always believed in but couldn't quite pin down.

The book highlights a lot of concepts on Web Designing but to me the concept that stands out the most can be summed up in one word:

Simplicity.

Just like simplicity in coding, building features, design and development, simplicity in web design also has it's own ability to stand out and distinguish itself from the crowd; in an elegant subtle way. When choosing between attractive-and-complex vs. simple-and-elegant I would prefer simplicity blended with elegance any day. After all, Simplicity Rocks!

"That's a great design! You've really proved that you're great at Photoshop and other designing tools. Now dump it and start fresh." - I often see myself giving this advice to web developers and graphic specialists around the world. Specially the ones who tend to use a lot of jazzy bells and whistles, beautiful smiling faces and rich color combinations in their web applications.

Don't get me wrong. I have nothing against a lot of jazzy bells and whistles, rich graphics and beautiful smiling faces on a web-sites. If your application, web-site or the point you're trying to convey to the world / your customers / your visitors demands that, by all means, go ahead and use all of these. If not, I don't see the point of having an elegant design that's much more attractive than the point you are trying to get across.

In Ben's word:

Here are some web-sites that I've often cited as examples:

None of them are rich when you consider them from a graphics perspective. Ever wondered why? Is it because these organizations cannot afford a couple of kick-ass web designers who know how to get a lot of jazzy images and bevels done?

Ben's book uses words from Antoine de Saint-Exupéry, the classic author who wrote soul stirring books like The Little Prince, to illustrate the point:

I think these words sum up exactly what I mean by "You've really proved that you're great at Photoshop and other designing tools. Now dump it and start fresh." much more articulately than I could have ever said it.

Early on in my career, on my way to office each day, I would pass a bill-board sign of a cellular service provider. The billboard hoarding had a very wise slogan - 'you don't always have to be loud to be heard' - as strange as it may seem the board had a lot of impact on my life.

With web site design, I think the most effective sites are the ones where the designers are not trying to 'prove' anything to anyone or becoming loud to be  heard. The most effective web-sites today, are sites where the web designers are making bigger points and conveying bigger and better ideas with lesser pixels - using a calm, subtle, non-intimidating and helping tone.

Dear readers, fellow Web Developers and Designers, for today I leave you with one thought to harp on and one assignment to execute.

Thought: Software is composed of technology, underlying platforms and above all end users and how they perceive and experience the application. If your User Interface doesn't gel with the world and ecosystem around it, it's useless.

If your user interface doesn't get to the heart of the problem you're trying to solve with your application or convey the point you're trying to make with your web-site, by showing up blazing fast and then guiding the user with a simple non-intimidating and simplistic tone, particularly without overwhelming or distracting them, you may have come up with a really beautiful design and proved that you're an expert when it comes to Photoshop, Illustrator and tons of other design tools but in the end it doesn't matter!

If your excess pixels end up taking too much time to load or end up innocently confusing your users by pulling their attraction on just the bells and whistles instead of the core functionality, you have missed the whole point and failed completely!

Yes, you have a beautiful User Interface, but is that really the point? Is that the only thing defining your success as a web developer or web designer?

As for the assignment, go read the really invaluable and free advice on making your Web User Interfaces better directly from the expert's mouth. Quick! :)