There’s more and more buzz around estimates and #noestimates in software development. People like to write bold statements and go extreme about things in blogs. Usually, personal dialogues are much more balanced. Some hate estimates and believe it’s a useless activity. Some defend it with arguments of arguable truth.
I want to dig into intrinsic estimates complications, what people mean by “estimate” and what future directions we may attack → Read the article.
A couple of years ago I bought BMW 530 E39. Not that I’d been into BMWs all that much, but I just stumbled upon a good deal to replace my old car, and I went for it.
This car was excellent. I liked almost everything about it except:
The rain sensor. Even when set on the “High” speed it functioned very slowly, which rendered it mostly useless in the field conditions.
The front and rear windshield defogger/defroster controls. Too far to reach.
The weird audio set controls. I had quite some trouble getting used to them.
Setting the in-cabin temperature with up and down arrows.
Then I bought the next-generation BMW E60.
Now, what do you think?
The rain sensor works perfectly.
They made the defogger/defroster controls bigger and put them to the center.
The audio set started to make sense.
They have knobs for the in-cabin temperature, and it’s just a pleasure to use them.
The smart BMW guys resolved all the issues I’ve been uncomfortable about. But — of course — they added a couple of new issues instead:
In the E39, cruise control was located right on the steering wheel, and it worked just OK. In the newer E60 model they did it as a lame lever on the lower left side of the steering wheel, with absolutely non-intuitive movements to switch on/off and adjust cruising speed.
Door locks and hazard warning flasher switch were moved from beneath the driver’s right hand to the central console. For several months I’d start in the wrong direction to open the doors, until I got used to the new setup.
While the change #2 looks quite logical as it comes along with the new iDrive system, they have no mercy from me for the cruise control.
On the whole, the next-generation BMW remained the same, but better. I think that’s a very important principle for the evolution of any interface:
Same But Better
We’re getting at the good old issue of UI novelties here. What’s better, slowly and meticulously improve the current system? Or introduce new elements in radical spurts, leaving no stone unturned in the old system?
Users are quite inconsistent creatures. For one thing, they like to download updates hoping they’d finally get the features and improvements they’ve been waiting for. On the other hand, they hate getting used to new features.
Any interface develops in cycles. Someone comes up with a new interface, users start bringing in their feedback — that’s the stage of step-by-step improvements. One has to rework some parts of the functionality and mix in new features gradually, without having people learn from scratch.
Then, a critical mass of new knowledge is acquired over time, and if this knowledge is used wisely, it becomes clear how to improve the system along with the UI. That’s the time for revolutionary changes, and that’s how all interfaces develop (if they don’t die before their time):
Most people like short things: short tasks, short emails, learn-how-to-program-java-in-24-hours books, lose-weight-in-a-month video guides. Modern society is cursed by impatience and time pressure. Information flows hit us from all sides and we just can’t resist. We spend more and more time on shorter and shorter things.
Software development demands focus. You can’t create anything significant hopping from one thing to another. That is obvious. Less obvious is that product development demands patience.
Service development is different. In most cases you have a project with a visible end. It may be a year long, or even several years long. But still project will be completed someday… Or abandoned. Most service products are sprints. Clients pay you money and they want to have something as soon as possible. They radiate the impatience. They set deadlines. They resist to invest much into good engineering practices like automated tests. Yes, you negotiate all that and sometime with a success, but still it’s quite hard to sell a great development process to the customer. So you rush, cut corners, drop some good practices to save time and argue about change requests. Agile approach helps to solve some of these problems, but you still feel the constant pressure. And rush anyway.
This strategy doesn’t work for product development. It takes a decade or more to create a truly remarkable product. Constant rework, constant improvements, constant polishing and learning. You fail, learn something new, improve things and move forward. It just can’t be done without patience.
Suddenly you understand that great thing takes time and it changes your attitude. You learn how to run with a steady pace, maintain energy level and endure the race. In a sprint you have no room for any mistake. Even a little mistake will cost you huge. In a marathon you have time to fix problems and still win.
If you are in a product development business, I can give you several advices:
Learn how to learn. This road takes many years, you need knowledge to solve problems and invent things.
Learn how to wait. It is so fucking hard to me. Sometime I feel enormous pressure to speed everything up and run at a full speed. But I realize that it will drain all our energy and development team will be exhausted and washed out. We’ll start to lose people. Morale will go down. That’s not a viable strategy.
Embrace re-work. Most likely you will have to re-write some parts of the system 3-7 times in the next several years. You should be ready to do that. Re-work is good. It makes things better.
Ship early. You may think that now I’m a 100% perfectionist who will kill for the 1px design mismatch in a latest release. That is far from true. I like to ship things as early as possible to some closed group of customers at least. For example, we are working on v.3 of our product during the last 15 months. It is still not public. However, we had first users 9 months ago. Currently around 600 people from 100 companies are using v.3, we have constant feedback and make improvements based on it.
Remember, that most people can run a 100 m distance, few people can run a marathon.
Why it is bad to have a single point of failure in a product and what to do about it.
Every day we solve problems. Some people solve many problems, some few. Most likely in your project there is a person, who solves most of the problems. Sometimes it’s a Business Analyst, sometimes it’s a Designer, most often it’s a Product Owner. He knows the market, the domain, the customers, the competitors, the features. He knows how things should work and pushes his solutions hard. Usually the team can’t resist and just accepts this situation. Is it good? Can we find better ways? Well, we’ll have to have quite a lengthy journey to find out.
Setting the Stage
Imagine, you have a new feature in the backlog. At this point we have several potential scenarios with a different level of harm:
Leave everything up to the developer.
Discuss this user story just before the implementation, come up with a solution and do no specs. Make all the decisions on the fly.
Discuss this user story just before the implementation, come up with a solution and do the specs.
Assign user story to a Product Owner, let him come up with a solution and have him do the specs.
Have UX phase, brainstorm a solution and create the specs just on time, before the development starts.
You can see that some of the scenarios are good, some are bad, and a few of them are just horrible.
To create a perfect solution, we should answer the three simple questions: When? Who? How? Well, the most important question is Why? We’ll assume it’s already been answered.
When?
Each story has its own life-cycle. It is born, it lives and then dies. There are three important moments in the life of a feature:
Someone has a good idea, and a feature is created in the backlog.
Development starts.
User story is released to production.
When is it a good time to have the complete solution? Obviously, not right after the story is created, as things change, and it may happen that this user story is no longer required. It may just be deleted from the backlog in the future. Somewhere in the middle when we have more data? Maybe, but still not perfect. The perfect match is when we have the solution right before the development is about to start.
In this case the solution is fresh and shiny. Everyone in charge does remember why things should work exactly the way described in the specs. It is certain that the user story will actually be implemented, so the solution and the time spent on it will not be thrown away.
If a feature looks very simple, the UX phase can start about one week before the implementation. If a feature is complex, several months may be a good timeframe.
Who?
Many teams rely on the Product Owner, Business Analyst, etc. and expect solutions and specs from them. A team doesn’t care about the solution, but does care about completeness of the specification. Sometimes this works, in most cases — not.
Some teams rely on communication and do not create specs at all. They brainstorm a solution on the fly and then jump to coding. Sometimes this works, in most cases… well, you got it.
Some clever teams rely on the group of people that consists of developers, testers, designers and product owners who brainstorm the solution, find the best one, iterate and delegate writing specs to the product owner. And these teams rock.
Why the first two cases are bad?
The Hero
Yes, Product Owner is responsible for the product. Yes, he knows a lot. Yes, he can solve problems. And, yes, you expect too much of him. It is quite unusual to expect the best solution from a single person. It is always better to have a small group of people with various skills, various background, various focuses to find a great solution.
Product Owner can brainstorm everything alone and write all the specifications. He can haul the product alone. As a result, he would be a single point of failure… while there are many other buses in the streets.
The communication would be one-way, without much collaboration, and in such environment Product Owner would tend to ignore the opinions of other team members, since they do not participate in problem solving. If you don’t participate, why the freaking hell should I care about your opinion?
Knowledge sharing would be zero. Product Owner is a domain expert, he knows a lot. But the team gets zilch from his experience. There are no discussions, no collaboration, no two-way communication flows.
I used to be such a person. It was not good for the company.
Product Owner’s Rule #1: Don’t do everything alone
The Rush
Got a real problem? Get together, brainstorm it quickly, get shit done and kick it out of the door. Sounds good? Hell, no. The good thing is that you don’t waste time and rush straight ahead. The bad thing is that the solution would be great rarely, good sometimes, and in most cases just average.
In the rush mode you tend to cut corners, take the first acceptable solution and go for it. There are situations when it is good. In any emergency case this is a viable strategy, but in the long run it will not work. Rush mode is very dangerous. You may be even proud of it and call it “agile”, but it is not.
— OK, the quick add feature. Who’s got any ideas?
— Well, let’s just put up the Add Task link . You click it and see the input field with the Name label and Save button. You add one task and see the input field again, so you can add many tasks quickly.
— Great! Let’s do that right away.
Maybe this is somewhat stretched, but in reality I saw very similar situations (and did very similar things myself!).
Product Owner’s Rule #2: No rush
The Team
I bet you expect a viable solution now. Here is the algorithm:
Brainstorm every feature in a small group of 4-7 people. Invite developers, invite testers, invite designers, invite product specialists. Invite everyone who has diverse skills and can contribute to a discussion.
Think. Talk. Draw sketches. Learn some techniques like Design Studio. Do use them. Draw sketches.
Build trust. Support honesty. Ban sarcasm. People should trust one another, or you will have a bunch of gamblers instead of a team. Don’t be afraid to criticize bad ideas. The people who can’t stand some reasonable criticism should leave.
Repeat. Several times for each feature. Mix people. Invite new people.
Eventually, several teams will emerge, the teams that can solve problems without you.
Find people that can lead features and be responsible for the solutions. Let them lead UX sessions and play the Feature Owner role.
Create beautiful specifications (this is where I really suck).
It took me 7 years to come up with this solution. It works.
Product Owner’s Rule #3: Spread the knowledge, use diversity, delegate
How?
The “how” question is very broad. How to form teams? How to find solutions? How to evaluate them? How to document solutions? I’m going to just scratch the surface here.
Creative processes are hard to structure and hard to estimate. In general you don’t know when you’ll have a great solution. It may take several days or several years.
Each Feature Team has its own UX phase. Some people like to think alone, have decent preparations and then share ideas. Some people like to brainstorm things ad-hoc. Some like to sketch a lot. Some like to create paper prototypes. In general, it does not matter which practices and tools people use. The must have rules are:
Diversity. Team should consist of diverse people.
Iterations. First solution is not always the best. Neither second, nor third.
Feedback. Team should share potential solutions with other people and with customers if possible (and listen to their feedback).
There are many practices and tools you can try. I’ll just list some of them here:
DesignStudio. In a nutshell, you have a group of people. These people can split into teams or work alone. They have limited time to sketch the solution and then present the solution to everyone. Solutions are criticized. Then you iterate based on the feedback and sketch again. We’ve been using this approach with good results. Yes, it is time consuming. However, time is not important when you want to spread the knowledge. So use Design Studio in the early stages of people involvement into the solution phase.
Sketches. The ultimate tool to brainstorm, explain, evaluate and present ideas. The main advice I can give is: hide your “OMG I can’t draw!” fear and sketch a lot. You will get better eventually. Sketch + speech is so powerful, so fast, so cool. You can iterate really quickly, try a dozen approaches and skip bad solutions.
Critique. Do it. Express your opinion openly and politely. Don’t hesitate to upset someone. You solve problems here. Bad solutions should be thrown away. If you’re afraid to say something critical about your boss’ solution — it’s a bad sign. Fuck the common brainstorming rule about ideas and critique separation. This is only needed if you don’t trust each other. Trust gives you freedom of speech. Use it appropriately.
Diversity. It really works. There are many proofs and observations on how diverse teams outperform experts and solid “think-alike” teams. Try it.
Paper prototypes. Not as fast as sketches, but still good. With paper prototypes you can evaluate flows and find bottlenecks. It’s easy to grab them and ask some teammates to try something. You can even shoot a video and share it with people.
Dynamic Prototypes. HTML+Javascript works best for such prototypes in most cases IMHO. However, there are many other tools that do provide decent solutions. We’ve had a somewhat mixed experience with live prototypes. In some cases they did work, and we got valuable feedback; in most cases we spent too much time on them and feedback was not so useful. Prototypes work great to prove some limited ideas about a solution, but they don’t work as full-blown usability tests.
Usability Tests. We do them on a real application now. About 10 tests give a ton of feedback.
Product Owner’s Rule #4: Learn and try new things
The output of the UX phase is quite simple: feature specification. How to create beautiful specifications? We’ll talk about that in the next article with an intriguing title “Visual Specifications”.
Now here’s a good topic for discussion. Many years ago we were hiring software developers as such. For the most part, they were good at their job, but not all of them. Me, personally, and all my teammates back from these times – we were writing in any language. Something needs to be done in .NET? There we go. Any HTML work? No problem (well, the HTML work was mostly for me). Shoot something in javascript? Done. I’m not talking about the quality of these solutions, not yet.
Then, we became set apart from each other: here’s the JS team, and they give zero consideration to the server-side tasks. These guys are .NET guys, and God forbid if they lay their hands on the client-side (with rare exceptions). This distinction projects into hiring as well: here’s a .NET, a .JS and an iOS position. It manifested itself in particular as we got down to tp3, putting the clear boundaries between various areas of responsibility. The UI is done in .JS and .JS only, everything communicates with REST API, the core team negotiates the query/response format with the .JS team, and off we go. This is a nice way to start a new project. Each team is busy with their part: they design architecture and do the refactoring as they aspire to perfection within their boundaries.
However, there comes a time when the teams are almost done with the architecture, but there’s a flurry of horizontal application-specific issues. It somehow turns out that there’re tons of the UI related tasks, and few server-side tasks. That’s when specialization delivers the heaviest blow. The teams are not aligned, there’re twice as less developers in the UI team as compared to the .NET team. As a result, a half of the core team developers hang around nagging for new tasks, and one has to assign them to not so important jobs. On the contrary, the UI team is permanently slammed.
My opinion is simple: there’s no ultimate specialization. Sure thing, someone prefers one technology over another, and works with it most of the time. But a classy developer is able to adapt to a new ecosystem quickly and write in any programming language efficiently enough. The 80/20 rule of thumb might well be in effect here. You’re focused on your core competencies, at the same time reaching out to the new areas.
From the company’s standpoint, it’s very cool when someone can create a feature in its entirety. There’re less delays, the feature passes all the developments stages faster, there’re less discussions and handovers. One can truly stay focused on the tasks that are important at this very moment, and not shop for some work of a lower priority.
From the developer’s standpoint, it’s not as simple as that. I’ve never had any problems or issues doing something by myself. For some reasons, it is a big problem for some people. Yes, at the beginning you’re not likely to come up with perfect solutions. Yes, there will be some naive mistakes. But, in my opinion, a great software developer can deliver sensible solutions even in a fairly unknown environment.
Next, it’s about personal involvement. Many people hold .JS for HELL. However, if the framework is done, as well as HTML, it doesn’t look that bad. Some interesting things can be accomplished with .JS as well.
Why I liked to do a feature all by myself? It’s about the great feeling that I did it on my own, that’s why. This feeling means a lot to me. How about you?
To sum up, we will now resume hiring classy software developers, the ones that can create the entire feature from start to end, despite the technologies, and have nothing against that.
Office space is something many companies don’t get.
Sure, you should have a wide table, a comfortable chair and a fast workstation. But that is not the goal of the modern office. You can have this all at home. The real goal of the office is to enforce communication. Creative work doesn’t happen at your desk, as you should already know.
A good office setup enforces communication. It has many places where people can sit and chat. It has many whiteboards and cork-boards. It has comfortable meeting rooms, a kitchen, a shower, coffee machines, a bar and a sports room. You are here to meet people and to talk to them face-to-face.
Traditional office kills creativity.
Our new office is different. It is designed to help people meet and talk.
I’d like to talk about 3 aspects of knowledge: span, depth and connections between the disciplines. I’ve come up with a good metaphor to bring these aspects together, and it looks very to the point. Though, I don’t like metaphors that much, as they’re misleading quite often.
Basically, my metaphor stems from another metaphor according to which people can be broken down into two types. The first type is someone who likes to go over many things in their learning and research. The people of the second type pick just one or two disciplines and dig into them. The first type are foxes, the second type are hedgehogs.
To me, learning looks very much like a geological field research. Imagine that you’re facing a new mysterious continent. You know nothing about it. Of course, you can see mountains, forests, rivers but you have no idea of what’s in there. You don’t know what’s over the horizon, is there a sea, how cold this continent is on the north and what’s the temperature in the south.
The map
So, you start putting the map together. You send expeditions everywhere and you sketch the local maps. Then you drill surface holes to identify the soul texture and composition. Then you discover oil, gold, diamonds, and you start mining.
Learning follows exactly the same scenario. Let’s say you’re studying maths. In the beginning you know very little about it. Okay, you count to 10, and you see how three red balls are different from five blue balls. Step by step you’re discovering some new territories. You learn multiplication tables, and you’re amazed as you get to know the real numbers, or as you find out that it’s impossible to divide by zero. You briefly touch upon differential calculus, and for some unknown reason you learn how to take integrals. By the time you’re 16, you’ve got the map of the nearby territories on your hands, but most likely you have no idea of the set theory, topology and functional analysis. It’s very unlikely that you’ve acquired in-depth knowledge in any of the fields in mathematics. Just scooped and scratched the tidbits off of the surface.
High school doesn’t provide solid knowledge. You only sketch your map at school as you get ready to drill the surface holes.
Connections
Choosing your field can be easy … or difficult. One way or another, there you are at a university. Your teachers rightly assume that you know nothing. The truth is: most of the teachers don’t really care where you start your drilling. They deliver their lectures in a boring or in a fun way, and they rarely put any emphasis on the connections between disciplines. Take physicists: they grab differential calculus and use it to solve their problems. No one cares to trace mathematical analysis to physics and to check if it can be used there. Any given scientific field is an island on your map. For some reason, the common belief states that it’s your job to build bridges between the islands – or at least to set up a ferry service.
Your map abounds in the white patches of seas and oceans that can hardly be drilled, except for the shelf areas.
The islands of knowledge build up clusters as they become one integral whole for you, and instead of the bridge an archipelago emerges. That’s the time when you lay down the foundation for cross-field connections. As these connections take shape, the archipelago transforms into a solid land, good enough to host a highway. For example, you’ve got this distinct knowledge of what derivatives are, and how they can be applied to mechanics. Bang, there you go, now you definitely see a connection between the motion of bodies and differential calculus.
Why differential calculus is a standalone subject in the school curriculum? Why no one ever says how it can be applied to solving practical tasks?
The contemporary education, at least in this country, does help if you’re set to discover and develop the new islands… but not the new continents. Too little attention is paid to the connections, as well as to the paths and the logic of discoveries. That’s too bad.
Foxes and Hedgehogs
Back to knowledge span vs. knowledge depth. When you set out to some new field, it’s better to put together a map first, that is, to acquire a span of knowledge. That’s the only way to be able to dig deep into the subject later and identify the spots for drilling.
For example, you learn programming. It’d be stupid to dive straight into the theoretical depths of the artificial intellect or the lambda calculus. It’s equally stupid to rush into some programming language. At the entry level, you need to find out the basics: how programming evolved, what is it for, which branches are available, what are their specifics. Next, it’s about the paradigms, types of programming languages, the platforms, how the platforms relate to each other, what are their development trends. Again, it’s about sketching a map of the continent called “software development” and understanding where to get started with this map. If you’re interested in web development – welcome to the world of JavaScript, functional programming, scripting and markup languages. If you’re more into game development, go ahead and look into AI, strictly typified languages and algorithms. Of course, it doesn’t mean that you can skip all the rest, but that’s the way you identify the spots for deep drilling.
You must be a fox first, to be able to shape-shift into a hedgehog later. That’s the problem of today’s world: it’s much easier to end up being a fox forever, than to become a hedgehog. I feel it myself; it’s a lot harder to get deep down into your chosen field of knowledge. You always want to read just one more blog post, check Twitter, take a look at this interesting article or book. When all the world’s information is at your fingertips, it’s soo tempting to be a fox.
Deep drilling
The spot is selected, and the drill sharpened. So, how to drill now? Watch out for interesting soil layers and horizons. If you reach those layers, you’d never roll back. Beware the space in between the layers – that’s where the rocks might crumble. You dig deep into the subject, you read, you do something, and there’s a moment when things fall into place. Congrats! You’ve found the gold.
There’s one more good metaphor, I’ve picked it up in some book. In the beginning you find yourself in the dark room, and you’re using touch and feel to discover what’s in this room. Then there’s an instant, when the lights turn on, and you see very clearly what is where. The same is going on in your head. The light is suddenly on, and all the standalone concepts get precisely aligned. You will never forget that moment, and this clear alignment will always be there. The lights will be on at all times. The overhead lights might dim with time, but they won’t go out completely.
At times it’s very hard to make yourself keep on drilling. When you see that nothing changes, and you’ve been pecking this subject for several months with no evident progress, you just want to give up everything and get away to some sunny beach. What are you supposed to do in this case? The answer is the same – keepondoingit. If you give up once, give up twice – you’d lose your self-confidence, that’s it.You’d obsess over the thought that you’re good for nothing and get stuck at your current layer forever. You have to keep on drilling. You have to get to the first precious layer and experience the “aha!” moment. You have to turn on the lights to see what’s in the room.
What’s the difference between brilliant programmers and average programmers? It might well be about just one thing: with brilliant programmers, this faith is there all along. They just believe they can’t be anything else but brilliant programmers, whereas average programmers never conjure such things and give up on the drilling eventually. The power of faith and self-confidence can work wonders.
What if you don’t like the drilling location that you’ve previously selected? You have to get busy with something else then. If you take no delight in the studies, if you unconsciously register the count of pages in a new book the moment you open it – this subject or this discipline is not for you. Go over your map one more time and find another location. Maybe you’d get interested in UX, or automation, or marketing. With one or two trial drillings you will locate the spots worth putting your effort into.
Summary
So, how we learn? What should we do to make the learning process more efficient?
Turn on “the fox mode” and sketch your map. Identify some starting points for a more in-depth look into the subject.
Try to make sense of the connections between disciplines and order the studies logically. It’s quite easy on the high-level.
Turn on “the hedgehog mode” and dig deep. You’ll have to interrupt the focused digging though to jump to the related subjects, otherwise you won’t be able to reach the even deeper layers.
A great teacher would disclose his map to the students, guiding their way and showing implicit connections between the disciplines. Students will never lose their way if they have such a map.
Unfortunately, I haven’t come across a teacher who would have done that to his students. So I have to break through the jungle all by myself, working with my machete and carrying my torch, as I put new territories on the map. Hopefully, my children will have better luck.
I started to dig into visualization about a year ago. The topic is fascinating; visualization can be used in a wide variety of applications, including agile software development. I’ve read several books related to information visualization, and I’d like to share my reading experiences. Hope this list will be helpful to someone.
This is a remarkable book. It provides a very clean and beautiful theory of data visualization that you can apply to practice immediately. Yes, the book is quite old, but absolutely relevant and has a fresh feeling about it. Bertin and Cleveland are great thinkers, as they’ve come up with some breakthrough data visualization concepts.
The most efficient constructions are those in which any question, whatever its type or level, can be answered in a single instant of perception, in A SINGLE IMAGE.
This book was far from being at the top of my reading list. Maybe that is why I find it quite dull: very simplistic, useless information on data mining, etc. Maybe it can pass as someone’s first book on the subject, but I think that if you’ve previously read at least one book on information visualization, this one can be skipped without hesitation.
I have to admit. Data checking is definitely my least favorite part of graph-making. [...] But this is what good graph designers do.
The main thing that I’ve learned from this book is: you’d better visualize everything. Yes, everything you say. When you explain your idea, work to support it with some visuals. When you discuss a solution – sketch it. When you create a roadmap or a plan – draw it. Visuals are great helpers and communicators. Even one picture can spark a good discussion and bring new ideas.
Visual language … born of people’s need, worldwide, to deal with complex ideas that are difficult to express in text alone.
A really disappointing book. Examples are so awful that I can’t even look at them. The information continuously repeats itself. I haven’t learned anything new from the first part of the book and just skimmed the last chapters. Anyway, this book is severely outdated.
Dashboards almost always require fairly high-level information to support the viewer’s need for a quick overview.
The famous Tufte books. I can give just one advice: read them all. You should savor the aesthetics of their design, typography and great illustrations. These books are crafted with care. I love crafted things. The content is great as well. Tufte’s work is based on Bertin’s teachings, but it has some novelty and passion.
This book is all about how to visualize things. It has examples from various domains.
There’s a book that you simply must see. Riveting ideas on how to tell compelling stories of cause and effect using numbers and images.
This book gives a great start for any data-specific visualizations. Data-to-ink ratio and sparklines are novelties invented by Tufte. I think this book is the most useful one of all Tufte’s books.
Allowing artist-illustrators to control the design and content of statistical graphics is almost like allowing typographers to control the content, style, and editing of prose.
This book gives answers to how, why, and what we see. Visual perception, encoding channels, color, memory — these things may sound pretty advanced. This book can hardly be considered a straight help reference on data visualization, but it provides a very good basis for understanding various techniques, and understanding is priceless.
If we understand the world through just-in-time visual queries, the goal of information design must be to design displays so that visual queries are processed both rapidly and correctly for every important cognitive task the display is intended to support.
I purchased this book at the UXLX conference in Lisbon. I did not expect too much of it initially. But after several dozen pages it paid off every cent I’d spent and exceeded my expectations in every possible way. This book is for UX designers, yes, but I’d say every executive should read it. There’re so many gems inside.
Well, this book gives no specific frameworks. It’s just extremely inspiring. Read a complete review.
Without appropriate design, yesterday’s success is tomorrow’s failure, since today’s great applications are tomorrow’s legacy systems
Cleveland’s books are not an easy read. They are full of terms and even include some maths. Still they are a must-read for any serious data visualizer. Cleveland has described many useful principles. The book is very practical.
It is hard to imagine anyone reading this book and not getting some good ideas to put immediately into practice.
Quite many concepts in this book have already been described in “The Elements of Graphing Data”. This one is more advanced and has more maths inside. I recommend to start with “The Elements…” and then grab this book to learn about the quantiles, Q-Q plots, jittering, coplots and dot plots.
We need more than just the logarithm in our arsenal of transformation methods. Logs cannot be used for data with zeros unless the data are adjusted. And a transformation other than the logarithm is often the one that leads to a simple data structure; in many cases the logarithm can fail to cure scewness and monotone spread, but another transformation does so.
The book ends the same way it begins, with dry data.
by Wolfgang Aigner, Silvia Miksch, Heidrun Schumann and Christian Tominski 4/5
This could be the first book that aggregates all the body of knowledge on visualizing time series: good theory, historical excursus and many real examples. The authors have categorized time-oriented data visualization patterns, and this is a major – and very practical – achievement. The book has no examples, though (it’s quite small for that type of information).
As visualization researchers, we are intrigued by the question of how this important dimension can be represented visually in order to help people understand the temporal trends, correlations, and patterns that lie hidden in data.
Which books on visualization have you read? Can you share your experiences?
How do people perceive information? How designers can thrive on this process to help people understand data faster? Let’s try to look into this complex field and explore some basic principles.
The visual encoding is the way in which data is mapped into visual structures, upon which we build the images on a screen.
There are two types of visual encoding variables: planar and retinal. Humans are sensitive to the retinal variables. They easily differentiate between various colors, shapes, sizes and other properties. Retinal variables were introduced by Bertin about 40 years ago, and this concept has become quite popular recently. While there’s some critique about the effectiveness of retinal variables, most specialists find them useful.
