Sandor, are you posting a book about web development? What are you having in mind? Are you changing from C++ to something else?
No. Not at all. While it’s true that I’ve built some sites, such as Daily C++ Interview, I simply think that all developers should be familiar with some basic concepts of usability. I thought that I’ll get some concepts that can easily be interpreted in other areas as well. Plus I liked the title. Let’s see if it was worth the time!
Although I read the third revision of the book, it’s already old as it is from the end of 2013. Almost 7 years old, 49 dog-years and in web development, it’s rather something like 343.
Yet when I was reading it didn’t feel old. Especially if you consider that first it was released in 2000. Some changes were necessary mostly because of the mobile revolution. But again, keep in mind, that I’m just a C++ developer reading about web-development.
I’m sure there are more in the book, but I found the following eternal truths that almost make the book philosophical.
How we use the web is how we use pretty everything
The author found three facts of life about how we use the web. Let’s go through them one by one.
We don’t read pages, we scan them
Is it any different in other areas of life? How do we read and sign contracts? After all, that’s how so many people and in debts right? They don’t read through the contract to understand it well, they don’t figure out how things work, they just make a choice that seems satisfying at the moment.
We don’t make optimal choices. We satisfice.
Or how do we write software? Do we make optimal choices? Or do we just commit something that is good enough? But what is good enough after all? Are there optimal choices after all?
We don’t figure out how things work. We muddle through.
How many of us read through the manuals of software or a physical product? We don’t if we don’t have to. We muddle through. And if we do have to read the manual though, so often it means there is a usability issue with the product.
It seems that the above statements are valid anywhere, we just have to replace the “read pages” part at our convenience. Yet, it’s so important to mention these points, when we talk about usability.
How we make webpages is like how we should make other things
Though web pages are relatively a new phenomenon, in their knowhow they have common areas with other areas, such as writing a book, building a good park, or organizing our life.
You need a clear structure and what is clickable should be obvious
Our life needs a clear structure if we want to succeed. At least, that’s what all the life-improvement books are about. Highly effective people here, well regulated 4 hour work week there, after all except for some exceptions a well-lived life is built on the power of habit. Or whatever clicks with you.
Omit the needles words
This is again not specific to webpages. At Toastmasters one of the first things we were taught is to cut the filler words. Don’t say something for the sake of speaking.
Think about Kurt Vonnegut who shared how to write good short stories. One of his points was that every sentence must do one of two things — reveal character or advance the action.
There is no reason to do differently on a webpage. Every word should either reveal the intent of your webpage or help the user move forward with his goal/
You should always know where you are at a webpage
The first idea that came to my mind was about maps. When I see a map in a big park or a city, the first thing I’m looking for is the big red dot indicating where I am. If that is missing or it’s too small, not obvious, I shake my head. Unnecessary difficulties were dumped on me, just because someone was too cheap to customize some maps. Well, it’s still better than showing the wrong place, but come on…
On a webpage too, we should always immediately understand where we are.
Test early and save money
This is a very important message to all the devs and our management out there. You can be a true believer of TDD or you can despise it. The fact stays a fact. The earlier you test, the earlier you’ll find bugs. You won’t find all of them, but quite a lot. Each bug found earlier saves a few hairs and lots of money on maintenance.
It’s not different when you design the user interface of a website or an application. Or in fact, maybe it is. When you deliver business code, logic is logic. What is buggy, is buggy. But when you design a UI, there are feelings, there are religious debates on who likes what and who hates what.
Involve testers, watch them using your UI. It’s the antidote of religious debates. You’ll simply see what works and what does not.
The best time to plant a tree is 20 years ago. The second best is today. The best time to start testing is…
Conclusion
I started to book with great hopes and they were fulfilled. Don’t Make Me Think actually made me think and that’s a good thing. This book is almost philosophical. I think it has lots of value for backend developers, just like for anyone understanding what he writes about.
