Tableau Veers from the Path
I’ve seen it happen many times, but it never ceases to sadden me. An organization starts off with a clear vision and an impervious commitment to excellence, but as it grows, the vision blurs and excellence gets diluted through a series of compromises. Software companies are often founded by a few people with a great idea, and their beginnings are magical. They shine as beacons, lighting the way, but as they grow, what was once clear becomes clouded, what was once firm becomes flaccid, and what was once promising becomes just one more example of business as usual. The prominent business intelligence (BI) software companies of today have become too big to easily change course in necessary ways and too focused on quick wins to ever make the sacrifices that would be needed to do so. Once upon a time, however, these companies were vibrant, filled with the exuberance and promise of youth. As they grew, however, it became harder and harder to maintain their original vision. It’s easy for a few people to share an inspiring vision, but it is difficult for that vision to remain pure when the organization grows to 50, 100, 1,000, or more people. The demands of payroll and release schedules make it easier and easier to justify compromises and to chase near-sighted wins. Add to these challenges the demands of taking a company public and the alchemy seldom produces gold.
What does this have to do with Tableau? I believe that this wonderful company, which I have uniquely appreciated and respected, is losing the clear vision of its youth. Even though Tableau distinguished itself by a courageous commitment to best practices, which I believe is why it has done so well, it now seems to be competing with the big guys by joining in their folly. Tableau seems to have forsaken the road less travelled of “elegance through simplicity” for the well-trodden super-highway of “more and sexier is better.”
Tableau has a special place in my heart. Not long after starting Perceptual Edge, I discovered Tableau in its original release and wrote the first independent review of Tableau 1. I was thrilled, for in Tableau I found a BI software company that shared my vision of visual data exploration and analysis done well. Since then I’ve used Tableau, along with Spotfire, Panopticon, and SAS JMP, to illustrate good data visualization functionality in my courses and lectures. Until recently, I assumed that Tableau, of all these vendors, would be the one mostly likely to continue its tenacious commitment to best practices. However, what I’ve seen in Tableau 8, due to be released soon, has broken my heart. Tableau is now introducing visualizations that are analytically impoverished. Tableau’s vision has become blurred.
I recently received an email promoting the merits of Tableau 8. It included a link to more information, and when I clicked on it, this is what I read:
“Crave More Bling?” I couldn’t believe my eyes. Could I have clicked on a link to SAP Business Objects by mistake? This is not the Tableau that I know and respect. As it turns out, someone in the Tableau’s Marketing Department thought twice about the term “bling” and removed it before my screams reached Seattle, but in truth, whoever called this bling was just being honest; some of the items in this list of new visualizations are nothing but fluff.
I won’t write a full review of Tableau 8 here. Despite the problems that I’m focusing on, this version of the software includes many worthwhile and well-designed features. For the time being, it will remain one of the best visual data exploration and analysis tools on the market, but I’m concerned that its current direction does not bode well for Tableau’s future. To express my concern, I’ll focus primarily on three new visualizations that are being added in Tableau 8 and why, in two cases, they should have never been added and, in one case, how its design fails in a fundamental way.
Word Clouds
Back in 2008 my friend Marti Hearst, who teaches information visualization and search technologies at U.C. Berkeley, wrote a guest article for my newsletter about word clouds. In the article, Marti described some of the fundamental flaws of word clouds, which she referred to in the article as tag clouds, because these visualizations were always based on HTML tags at the time.
I was confused about tag clouds in part because they are clearly problematic from a perceptual cognition point of view. For one thing, there is no visual flow to the layout. Graphic designers, as well as painters of landscapes, know that a good visual design guides the eye through the work, providing an intuitive starting point and visual cues that gently suggest a visual path.
By contrast, with tag clouds, the eye zigs and zags across the view, coming to rest on a large tag, flitting away again in an erratic direction until it finds another large tag, with perhaps a quick glance at a medium-sized tag along the way. Small tags are little more than annoying speed bumps along the path.
In most visualizations, physical proximity is an important visual cue to indicate meaningful relationships. But in a tag cloud, tags that are semantically similar do not necessarily occur near one another, because the tags are organized in alphabetical order. Furthermore, if the paragraph is resized, then the locations of tags re-arrange. If tag A was above B initially, after resizing, they might end up on the same line but far apart.
Tag clouds also make it difficult to see which topics appear in a set of tags. For example, in the image below, it’s hard to see which operating systems are talked about versus which ones are omitted. Intuitively, to me, it seemed that an ordinary word list would be better for getting the gist of a set of tags because it would be more readable.
Since Marti wrote this article, what was once reserved for HTML tags has become a popular way to display words from many contexts, such as books and speeches. Here’s a word cloud that Tableau is currently featuring on its website to showcase this new addition to Tableau 8:
What this tells me is that the candidates said the following words quite a bit: “people,” “going,” “governor,” “president,” “government,” “we’ve,” “make,” “more,” along with a few others that are legible. These individual words without context are not very enlightening. “More” what? “Going” where?
Filters have been added to this word cloud for selecting words spoken by Obama, Romney, or both candidates and for removing words that were spoken outside a specified number of instances. Combining a word cloud with filters gives it an appearance of analytical usefulness, but the appearance is deceiving. A word cloud is as useful for data analysis and presentation as a cheap umbrella is for staying dry in a hurricane. Assuming that an analysis of these words in isolation from their context is useful, a horizontal bar graph would have displayed them far better. Bars would provide what the word cloud cannot, a relative representation of the values in a way that our brains can perceive. Words differ in length, so in a word cloud a long word that was spoken 100 times would appear much more salient than a short word that appeared the same number of times. You might wonder, “What if there are too many words for a horizontal bar graph?” In that case, another one of Tableau’s new visualizations—a treemap—could handle the job more effectively. More about treemaps later.
Word clouds are fun, but they lack analytical merit. When did Tableau, which was originally developed for visual analysis, become a tool for creating impoverished infographics? Did they add this feature to satisfy one of their prominent UK customers, the Guardian? Whatever the reason, with the addition of word clouds, how many of Tableau’s customers will waste their time trying to analyze data using this ineffective form of display?
Packed Bubbles
Bubbles have their place in the lexicon of visual language, but only when encoding values using the sizes of circles is the best choice available because the most effective means—2-D position (e.g., data points along a line in a line graph) and length (e.g., bars in a bar graph)—cannot be used. This is the case when we display quantitative values on a map, because 2-D position is already being used to represent geographical location and bars cannot be aligned for easy comparison because they cannot share a common baseline when they’re geographically positioned. Bubbles are also useful when, in a scatter plot, which uses horizontal position to represent one variable and vertical position to represent another, we also want to make rough comparisons among the values of a third variable in the form of a bubble plot. Using bubbles by themselves, however, is never the best way to display values, but this is what you’ll soon be able to do with Tableau 8. Here’s a simple example that displays sales per country:
How are sales in South Africa? Yes, it’s there in the list; it just isn’t labeled. We can solve this omission by forcing all of the labels to appear, as follows:
Now, can you find South Africa? Given enough time, you can spot it at the top. What is the value of sales in South Africa? Nothing about the bubble reveals this, but we can hover over the bubble to access its value. We could do this for all the bubbles if we don’t mind taking forever to see what a bar graph would reveal to an approximate degree automatically.
How much greater are sales in the United States than Argentina? Come on, give it a try. Finding it difficult? Try it now using the bar graph below.
We can now see that sales in the U.S. were approximately nine times greater than sales in Argentina.
What if there are too many values to display in a bar graph without having to scroll? Let’s look at larger set of data—sales to 3,356 customers—first using bubbles.
Cool! Assuming they’re all there, that’s a lot of bubbles. What do these bubbles tell us? Some customers buy a lot and some buy little and a bunch buy amounts in between. Anything else? No, that’s pretty much it. And why is only the one bubble that represents Jim Hunt labeled? As we’ll see in a moment, it isn’t the largest.
I can put 3,356 horizontal bars on the screen at once, but they will appear as thin, indistinguishable lines. Also, there won’t be any room for the customer names, but those names don’t appear in the bubble display either, so that’s not a problem. Let’s see how it looks.
This isn’t ideal by any means, but it provides a more informative overview than the bubbles. For example, we can easily see that approximately 10% of the customers made purchases totaling more than $35,000, approximately 70% of them made purchases totaling less than $5,000, and approximately half of them made purchases totaling more than $2,500. We could continue citing similar observations. If we wanted to see and compare individual customers, a sorted, scrolling version of a normal bar graph like the one below would often work when comparing similar values, and we could filter the data to compare specific customers that don’t simultaneously appear on the screen.
When I first learned that packed bubbles would be included in Tableau 8, I immediately sent an email to Chris Stolte, the Chief Development Officer, Pat Hanrahan, the CTO, and Jock Mackinlay, the Director of Visual Analytics. These guys are all respected leaders in the field of information visualization and friends of mine. “Why are you doing this?” I asked with an only slightly veiled sense of disgust.
Chris provided the answers, which I’m sure all make sense to him, but don’t make sense to me. Our perspectives are different. Chris lives and breathes Tableau almost every minute of his life. To the same degree, I live and breathe data visualization, independent of particular products. I believe that a feature should only be added to software that meets the following requirement: it is the best way to do something that really matters. I have the sense that Chris uses a different yardstick. He believes that packed bubbles add value, which he explained as follows:
There were two driving reasons for us building Bubble Charts into the product:
- Incremental construction of views. The first was that we want to create an application where you can incrementally build up visualizations of your data and easily change from one view to another. This is the journey we have been on since the day we wrote the first line of code for Tableau. The vision is that you should be able to easily explore the space of possible visualization of your data to find just the right view to answer your question and to tell the stories in your data. As you place your data on the canvas, you should always be creating useful visual presentations of your data and getting immediate and useful feedback. We have done this well but there have always been places in the flow where users create views that feel broken or that don’t present the user’s data in a natural way. To really help people feel comfortable, I passionately feel that we need to invest in making sure every step is a reasonable view of their data to create a feeling of “safe exploration”. Supporting this flow is what drove us to invest a lot in “best practice defaults”. It is also what led to introducing Bubble Charts (and other charts) in v8.
- Visualization of networks, relationships, and paths. We want to extend Tableau to include visual presentations of data that support answering questions about networks, relationships, and paths. This includes node-link diagrams, adjacency matrices, Sankey diagrams, etc. This introduces the need for additional encodings and visualizations—and flows.
Here’s how I responded to Chris:
- Incremental construction of views. A visualization that represents data in a way that doesn’t support a better understanding should not be in the flow. Packed bubbles fall into this category. The user should always be directed to different views that are useful and optimally informative. Sticking an ineffective visualization between two effective visualizations, which does nothing but serve as a transition between them, adds no value. It will waste time. More concerning is the fact that people will not use packed bubbles as a mere transition but as a visualization that has value in and of itself. Even if you could demonstrate a case when packed bubbles were actually useful, which I did not find, the value that they add would still need to be significantly better than the harm that they will cause if you support them.
- Visualization of networks, relationships, and paths. This is not a justification for packed bubbles. What you must do architecturally to support network displays, etc. is not a valid argument for exposing people to the steps that you took to get there. In the past, you have exposed people to unnecessary requirements that got in their way merely because of architectural constraints. For example, forcing people to use two quantitative scales to combine two types of marks in a single chart (e.g., bars and lines) was unnecessary and harmful to the interface and the user experience.
When I visited Tableau’s website to find an example of packed bubbles, this is what I found:
A small set of bubbles has been combined with a map and two bar graphs. Do the bubbles provide an effective way to display the causes of fires? Hardly. Obviously, a bar graph would handle the task effectively, but these bubbles cannot. Tableau is not only enabling people to display data in this ineffective way, but by showcasing this example they are encouraging the practice. Damn it, when did Tableau decide to nudge people in useless and potentially harmful directions?
The Marketing Department is even featuring bubbles as the new face of Tableau, as you can see below:
Maybe this is what it took to impress Gartner enough to elevate Tableau to the leaders’ section of the BI Magic Quadrant. What will it take for Gartner to grant them a more prominent position than Microsoft—spinning 3-D pie charts that sing? Once a software company starts down the path of adding silly features to a product, it becomes nearly impossible to remove them. Just ask the folks responsible for the charting features of Excel.
Treemaps
Many months ago, when I first learned that Tableau would be adding treemaps, I welcomed the news, but cautioned them to implement them well and to only nudge people to use them when appropriate. Ben Shneiderman created treemaps to display large numbers of values that exceed the number that could be displayed more simply and effectively using a bar graph. Here’s an example that appears in my book Now You See It that was developed using Panopticon:
What we see here is the stock market. Each small rectangle is an individual stock. The larger rectangles group stocks into sectors of the market (financial, healthcare, etc.). Imagine that the size of each rectangle represents the price of the stock today and the color represents its change in price since yesterday (blues for gains and reds for losses). If it could be done, I’d rather view this information in a bar graph, but if I need an overview that includes all of these stocks, there are far too many values to put in front of my eyes at once using bars. A treemap is called a space-filling display, because it takes full advantage of the available space. A treemap displays parts of a whole and does so in a way that handles hierarchies. In this example, stocks are displayed as a three-level hierarchy: the entire market (level 1), individual sectors of the market (level 2), and individual stocks (level 3). Rectangles within rectangles are used to separate the groups.
A treemap belongs among Tableau’s visualizations, but I expected the implementation to be more thorough and reserved for large sets of values. If we look for examples on Tableau’s website, here’s one that we find:
This is a relatively small set of values. Could they be better displayed using a different graph? You bet. A simple bar graph would do the job. Good data visualization software should never encourage us to display small sets of data as a treemap—never! Here’s another example that’s featured on Tableau’s website:
Imagine how much better this would work using two horizontal bar graphs, side-by-side, with the items in each sorted in the same order.
Besides the fact that we’re being encouraged to use treemaps when they aren’t appropriate, Tableau’s treemap itself suffers from a fundamental flaw: it cannot effectively display values in groups. I’ll illustrate. Imagine that we want to compare sales and profits per customer, so we begin with the following treemap.
The rectangles sizes represent sales and their colors represent profits (green for profits and red for losses, which you can see assuming you’re not color blind). This is a decent start, except for the fact that the labeling seems entirely arbitrary. Let’s continue by breaking customers into continents to show a hierarchy (customers by region), which treemaps were designed to support. When I double-clicked the Continent field, this is what I saw:
Hold on…what just happened? When I added continents, rather than organizing the customers into their respective regions within a single treemap, the visualization automatically switched to separate treemaps of a sort displayed within bars, but little that is useful can be done with this view. The individual rectangles for customers are too small and anonymous without labels to be of much use. Unlike packed bubbles, however, I can imagine occasions when these treemap bars could be enlightening, but I’m concerned that they’ll mostly get used when other forms of display would work better.
When I questioned the folks at Tableau about this, I was told that groups could be formed within a single treemap by dropping a categorical field of data on either the Details or Labels attributes in what Tableau calls the Mark’s card, but I did this and the treemap remained unchanged. After further correspondence, I learned that in addition to dropping the categorical field onto the Mark’s card, you must make sure that it appears in the list prior to other fields that are lower in the hierarchy. By placing Continent on the list before Customer Name, the treemap was rearranged as follows:
This is a step in the right direction, even though something is definitely amiss with the labeling, but it isn’t the view that I expected and wanted. As you can see, the continents are not clearly delineated. To delineate groups clearly, we must relinquish the quantitative value represented by variations in colors (in this case profit) so that discrete colors can be used to represent the categorical groups (in this case continent), resulting in this view:
When I asked Jock about this lack of standard treemap functionality, he replied:
We focused in Tableau 8 on the mapping of data fields to graphic properties rather than the formatting techniques for showing nesting found is some treemap implementations such as border width, spacing, “cushioned” rendering, etc.
I’ve seen many implementations of treemaps, but this is the first one I’ve seen that doesn’t allow values to be easily and clearly grouped.
I’m concerned that Tableau is becoming more and more like other software vendors that prioritize product release schedules over quality. This isn’t the only sign of this that I’ve seen. When brushing and linking (coordinated highlighting) was introduced, it couldn’t support proportional brushing, which in my opinion is essential. It still cannot. When extensive formatting capabilities were introduced, the initial interface was designed as a complicated panel with pages and pages of options, much like an old-fashioned dialog box. I can never remember where the option that I need. They realized that the interface sucked before it was released, but there wasn’t enough time to fix it, and it remains to this day. When they introduced a way to combine different types of marks (bars, lines, data points, etc.) in a single chart, it required a second quantitative scale and axis, even though it is rarely needed. Why? Because this was the easiest way to deliver the functionality based on the underlying architecture of the software. Convenience of development team trumped our needs as users. This approach involves unnecessary steps and a confusing interface, but it has not been fixed.
For years I’ve been encouraging my friends at Tableau to add a box plot to its library of visualizations—a form of display that is fundamental to a data analyst’s needs—but it has never risen high enough in the list, while word clouds and packed bubbles, two useless forms of display, have now been added. Obviously, the guys at Tableau have a different perspective and set of priorities than I do. I believe that mine correlates more closely with the needs of data analysts.
The Story of Show Me
In an early version of Tableau, a great little feature called Show Me was introduced. Show Me remains always available with a list of chart types to assist us in selecting appropriate forms of display. Based on the data we’ve selected, Show Me recommends charts that might be useful.
I have always loved Show Me, but my love for it has waned as it’s gradually grown over-complicated and lost site of its purpose. Rather than suggesting charts that are useful, somewhere along the line Show Me began instead to suggest chart types that are possible. In the beginning, Show Me was simple and elegant, but this is no longer the case. How Show Me has changed represents in microcosm the larger problems that I’ve observed in Tableau as a whole. It is difficult to add features to a product without over-complicating the interface. Good interface design isn’t easy, but it’s necessary.
Below on the right is how Show Me will look in Tableau 8:
It includes 23 types of charts from which to choose. In order, starting at the upper left, the list includes the following:
- Text table
- Symbol map
- Filled map
- Heat map
- Highlight table
- Treemap
- Horizontal bar
- Stacked bar
- Side-by-side bars
- Lines (continuous)
- Lines (discrete)
- Dual lines
- Area chart (continuous)
- Area chart (discrete)
- Pie chart
- Scatter plot
- Circle view
- Side-by-side circles
- Dual combination
- Bullet graph
- Gantt
- Packed bubbles
- Histogram
Show Me has grown to include far too many choices, which undermines its ability to guide us. It has become bloated, awkward, and confusing. I believe that the following shorter list of chart types would serve its purpose more effectively:
- Text table
- Bar: When selected, either a vertical or horizontal bar could be automatically selected based on factors such as the length of labels and the number of values. Regular bars could be easily transformed into stacked bar by dropping a categorical field of data onto the color attribute, so there’s no reason to include stacked bars as a separate choice in Show Me.
- Line: Only one type of line graph needs to appear in Show Me: the type that displays a series of values continuously, without breaks in the line. On rare occasions when what Show Me calls a discrete line—one that has breaks in it—is useful, this could be made available as a simple formatting option. What Show Me calls dual lines is merely a line graph with two quantitative scales. This also could be handled as a simple formatting option, not just for line graphs, but for bar graphs and area charts as well.
- Area chart: Similar to a line graph above, only one kind of area chart is needed in Show Me: the one that displays values continuously, without breaks.
- Dot plot: This is the conventional name for what Show Me currently calls a circle view and side-by-side circles.
- Scatter plot: (Dropping a quantitative field of data on the size attribute turns a scatter plot into a bubble plot.)
- Histogram (In appearance, this is a bar graph, but it possesses special functionality that is needed to display frequency distributions, and as such it deserves to be on the list.
- Box plot: A visual analysis product without a box plot is missing something essential.
- Geographical map: Symbols would serve as the default mark, but color fills would be readily available as an option.
- Heat map: This is a heat map arranged as a matrix of columns and rows. What is currently named a heat map in Show Me is misnamed, for it uses symbols that primarily vary by size, not color. This functionality is already readily available whenever symbols such as circles or squares are being used, which is the default when a dot plot is selected, by dropping a categorical variable on the size attribute.
- Treemap
- Gantt chart
This list reduces our choices from 23 to 12. Not bad. Each item on the list actually qualifies as a different type of chart; none are mere variations of another chart on the list with different formatting. Navigating these choices would be so much simpler.
Notice that I left out the pie chart. When the guys at Tableau first added the pie chart to the product, they explained to me that they were doing so only because pie charts are sometimes useful on geographical maps to divide bubbles into parts of a whole. For this sole purpose, there is no reason to include the pie chart in Show Me. Bubbles on maps can easily be subdivided like pies into parts by dropping a categorical field of data onto the color attribute. By including the pie chart in Show Me, people are encouraged to use it when other forms of display, usually a bar graph, would work more effectively.
Also notice that there is no chart type in my list that serves as a combination of marks (e.g., bars and lines). It shouldn’t be necessary to list separate chart types for every possible combination of marks. A good interface would allow us to select a series of values in a graph and change its mark to any type that’s appropriate.
And finally, notice that I’ve removed from the list my own invention, the bullet graph. I did this because a bullet graph can be treated as a variation of a bar graph or a dot plot, which could be easily invoked as a formatting option.
In Show Me, too many charting options are suggested as viable views, often when they’re ineffective. Here’s Show Me again:
The following chart types are highlighted in Show Me because they supposedly provide useful ways to view the two fields of data that I’ve selected: Market and Sales:
- Text table
- Heat map
- Highlight table
- Treemap
- Horizontal bar
- Stacked bar
- Pie chart
- Circle views
- Packed bubbles
Let’s see which views are actually useful based on the data that I’ve selected. We’ve already seen the text table, which is definitely useful.
Here’s what Show Me is calling a heat map:
This isn’t actually a heat map, as I mentioned before, because colors are not being used to encode the values; sizes are. Rarely would we choose to display these four sales values using the sizes of squares.
Here’s a highlight table:
This is slightly more useful as a way to add a visual representation (color) to a text table, but other forms of display will usually work better.
Here’s a treemap:
It would never make sense to display a small set of values such as this as a treemap.
Here’s a horizontal bar graph:
Unless we need precise values, as provided in the text table, this is clearly the most effective way to display these values. Fortunately, this is the chart that’s featured as the best choice by Show Me.
Here’s a stacked bar graph:
Try to compare the stacked market values. To compare them easily and accurately, we would definitely want a regular bar graph. The only time this stacked bar would suffice is when we primarily want to know total sales with only a rough sense of how its divided into markets.
Here’s a pie chart:
Try comparing the slices or determining individual values. This is never going to serve as a useful view of these values.
Here’s a circle view:
Only the bar graph does a better job than this circle view (a.k.a., strip plot). Using the positions of the circles to encode their values works well for our brains.
What’s left? Oh yeah, the new packed bubbles chart. Here it is:
Thank God Tableau decided to add this chart to its Show Me recommendations. Just imagine the enlightening views this will provide! (Yes, I’m being sarcastic.)
Why Is This Happening?
What’s causing Tableau to compromise the integrity of its product? Given the circumstances, here’s a list of the possibilities that I would usually consider:
- Has their mission to go public led them to add ineffective but eye-popping sparkle to the product to entice investors?
- Has their marketing plan led them to curry favor with analysts who don’t understand analytics in general or data visualization in particular, such as Gartner and Forrester, by adding features that might appeal to them?
- Have they been tempted by the possibility of big deals with prominent companies to add senseless features to win those deals?
- Is the development organization, which has now become huge, inclined to add features merely because they are easy to implement based on the underlying architecture or to design them in hobbled ways because the best design cannot be implemented without changing the architecture?
- Have they lost touch with their roots in academic research and no longer remember how the human brain works?
- Have they gradually become like most other software organizations, limited to an engineering perspective and driven by sales, as opposed to one that is balanced by a commitment to design and inspired by opportunities to provide the best possible product?
- Have they become slaves to product release schedules even when that means that new features will be implemented poorly?
- Have they become so immersed in the product and out of touch with those who rely on it that they’ve forgotten what really matters?
These are the questions that I would ask about any vendor in these circumstances, but they aren’t questions that I want to consider when trying to understand Tableau. Although no organization is immune to losses in effectiveness as it grows, I’ve always believed that if any software company could stand firm in its vision and commitments, Tableau was that company. The truth is, I really don’t know what’s driving their decisions to compromise the integrity of the product and its usefulness to the world. Even for the folks at Tableau, I suspect that most of the reasons behind their choices are unconscious. I suspect that most of the poor design choices stem from the fact that when people become immersed in a product, their perspective becomes myopic and skewed and they can no longer see the product through the eyes of its users or the guiding lens of best practices.
What criteria should be used to guide product development? A product should never be designed merely to do what’s easy…to do what’s fun for the developer…to do what can be done in the allotted time…to do what will produce the highest revenues…or even to do what people are asking for most. There’s nothing wrong with design that is easy, fun, profitable, or any of the other benefits in this list, but these should not serve as the primary drivers of product design and development.
Here’s a simple guideline for good design: “Design the product to do what’s most useful in the best way possible.”
What’s “most useful?” The fact that customers are asking for something in particular does not in and of itself make it useful. People sometimes want things that are far from useful or they want things to be designed in ways that don’t actually work. Anything that helps us solve real-world problems is useful. Problems are not created equal, however. Solving some problems is more important than solving others. The value of a solution should be tied to its potential for making the world a better place. It not that word clouds and packed bubbles are far down the list of problem-solving features for a visual data analysis product; they aren’t on the list at all.
Great products are never those that try to please everyone and do everything. Rather, they begin with a clear, focused, and coherent vision, and they persistently do what’s necessary to express that vision as effectively as possible without detour or compromise. Based on what I’m seeing, I fear that Tableau is trying to make its product do everything one can imagine doing with data. This can’t be done. It shouldn’t be done. Making the attempt will result in a product that is complicated beyond usability. It is reasonable for Tableau to make it easy for analysts to share the results of their work with others in polished ways by providing basic data presentation functionality, but it doesn’t make sense for the existing product to become a comprehensive platform for the development of infographics. Such a tool would require functionality similar in complexity to Adobe Illustrator, very little of which would ever be needed by a data analyst. If Tableau wants to compete with products such as D3, which provides a flexible programming environment for the development of interactive, web-based infographics, it would make sense to develop a separate tool that integrates nicely with the existing product. Sometimes good design involves setting practical limits and sticking to them.
I believe that Tableau is increasingly veering from the path. It pains me to say so. It’s all right for a company’s vision to evolve, and I’m sure that Tableau’s has in meaningful ways, but what I’ve described doesn’t qualify as progress. If you’re one of Tableau’s customers and you share my opinion, I urge you to make your concerns known. Please join me in reminding the good folks at Tableau that they are better than some of the design choices that they’re currently making.
Take care,
50 Comments on “Tableau Veers from the Path”
Steven,
I couldn’t agree more with your perspective on Tableau 8. I think the downward trend toward focusing on eye candy began with the introduction of the pie chart. Too much emphasis is given on what the users are requesting on the forums, which is resulting in Tableau losing its soul. The product does not “feel” the same as it used to. These changes break my heart too.
I went to their kickoff event yesterday and the first thing I saw was this horrible map with pie charts all over the place.
https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-prn1/75074_498050736897346_1125259384_n.jpg
The focus on fluff was evident throughout the event. I left with my head down, knowing that I have a lot of work ahead of myself teaching people what not to do in Tableau, rather than what to do.
I have clearly voiced my concerns to all of their senior management. There are other very, very core issues that are not being addressed that would make the product so much better. Three in particular are a Mac client, support for Linux and the incredibly painful experience of rendering visualizations in a browser. I believe these three core issues in particular are going to drive customers away more than the new eye candy will add.
To me, Tableau 8 feels like it’s been clumsily put together, with several simple existing features not working as well as they used to. There are new features like the multi-select drop down which on the surface appear like awesome improvements, yet they perform incredibly poorly. And they will release this particular feature in a clunky, useless state rather than holding it for later delivery and making it right. I’ve already told the folks at Tableau that I’m going to recommend that no one use this feature.
Unfortunately the list of poorly implemented features is much too long. I share you disappointment. Tableau has had an incredible impact on my life and to see it teetering on the edge of SAP-land hurts.
See you in Austin!
Andy
http://www.facebook.com/VizWiz
Stephen,
I very much agree with your assessment, and while I believe there is still time for a turn-around (and equally so that there will be one), some things do baffle me.
Tableau is billed, above all else, as an analysis tool. Why not focus on deeper analyses, like integration with a statistical library? Why not beef up table calculations? Rendering is, as Andy points out, very painful. Why on earth is text being rendered as an image? Tableau conferences are a sea of Macs, and yet, no Mac client. IT departments do not like me because I insist that they must support a Windows server. Why must Tableau Server run on Windows? It’s a headache to maintain and a headache to lock down. Everything else in the data center runs a linux variant, and is maintained expertly. There’s no experts in many modern IT departments for Windows servers. What about tools for extract management.
The most disturbing thing to me is that the bubbles and clouds are being released into the wild along with web authoring. As I voiced to my rep yesterday, when he asked if I was excited about it, I said I was concerned. Most of my job is not building visualizations but advocating for the sensical use of data, and most importantly, to not read tea leaves. Data collection is an expensive endeavour. I am concerned that the combination of authoring tools that support this kind of eye candy will greatly diminish the value of data. Ultimately, this means that Tableau would make my job harder, instead of easier.
Sincerely,
Annie Elliott
http://www.linkedin.com/in/anniebelliott/
As a beta user, I’ve been impressed with the floating / freeform dashboard design experience. I am a little confused why, in the marketing blurb image that Stephen has shown above, Tableau is distinguishing between freeform dashboard design and floating content on maps…unless I’m naive, the floating content on maps is just an example in practice of freeform design. Anyway…
I cannot disagree with any of the points made above. I would also add that I have felt that the folks at Tableau (at least those who show up on the forums) feel the same way. I may be wrong, but there does seem to be a sense of despondency about the “Kraken”.
I hope that Tableau ‘rights’ itself, whatever that means. I personally hope for more in the way of useful statistics; I hope for improvement to the user experience and I hope for improved speed and browser rendering. I am a big fan – but with now 2 years of experience using Tableau and having become more aware of ‘good’ visualization practices, I am no longer easily dazzled by the bling. But then…I’m not a prospective new customer…
Completely agree Steven.
I found my initial v8 beta experience rather jarring as well. I was excited to see the treemaps, but then disappointed to see how limited the implementation was. My post asking questions on the beta forum was met with crickets. I wasn’t phased by the word clouds as I know some people like those. The packed bubbles blew my mind though. I started looking around for the tweaks to switch the choice of layout algorithms or other things you find in a tool like Gephi. None were to be found. Packed bubbles seems to just be a way for not so informed people to not so inform others using chart junk. Fairly disappointing set of next steps from my point of view.
Dan
http://afinanceguy.com
Steven right on target. I hope they are listening at Tableau.
Andy: right too. I was telling my students today that there was a time when no pie charts were available from Tableau.
And talking about good practices: I’m still waiting for the simple and beautiful boxplot (in one click i mean)
I have used Tableau software for years, and helped thousands of people get the results they need from the software, many times one-to-one. I talk with other Tableau expert users and we attempt to decode all the logic the software uses.
With Tableau version 8 I will continue to do this.
I too hold Tableau to high expectations. When I see things like word clouds and bubble charts in this software that I have invested so much into, something that I am passionate about, I am disappointed too.
It gives me pause, prompting me to consider why I choose Tableau as the software I use every day. My reason for using Tableau is VizQL. If there ever comes a day when Tableau turns their back on VizQL, then their software will hold no value.
I see Tableau v8 as a compromise, they added bling to make people who asked for bling happy, but kept their core. They added fluff that on the outside may look like they have lost their way, but I see it as appeasement. The customers who want these poor practices are paying the bills, enabling the empowerment VizQL provides, and a greater reach for the software, to pass a gatekeeper’s feature checklist.
I have not been happy with Tableau’s marketing for some time, they say many things that I do not agree with, and highlight examples as being wonderful when I think they are horrible examples.
I am more then willing to ignore marketing that I do not agree with, and not use features that I think are a disservice to a user, as long as the core, the VizQL, is there.
There are some really great things the Tableau developers added that make my life using their software better, things such as the speed of table calculations, sheet specific filters, and the killer feature of v8 for me is Data Blending.
These are not surface things, these are how Tableau works under the covers, behind the scenes, and that is where I see strength added to Tableau with version 8.
Unfortunately, version 8 does not yet help with their confusing data densification logic, and some cases compounds the confusion, so hard stuff is still hard.
The behind the scenes work that Tableau software does is not perfect, but I know of no other software that enable the Cycle of Visual Analysis the way Tableau does. Tableau makes my life with data a joy.
From what I can tell, Tableau v8 is a rewrite of their code in a new development environment one that will enable a future version of Desktop to work on Mac OS and Server to work on Linux They are not there today, but I can clearly see them working in that direction.
I can see Tableau cares, but I think version 8 is a compromise.
I am thankful you have collected your thoughts here, I am full agreement many of your points, and I look forward to Tableau’s response.
Steven, like the folks above I share many of your feelings. I will, however, come to the defence of packed bubbles. If you consider them not as ways of accurately showing data but as a way of guiding navigation they can be an effective use of space. As you might remember we do usability testing of our dashboard designs with users and used in the way I outline above they are testing well with their audience. You need to use calculations to change the scale (i.e. our perception of colour and 2d size isn’t linear) but they will be a useful addition for navigation purposes. Of course this is not how most people will use them.
My view on increasing the usefulness of bubbles would be to have a packing algorithm which took account of ‘closeness’. We’re using them to explore open text comments in surveys and feedback and it would be good to have words that are commonly associated together being positioned together. Of course this brings us back to network diagrams which is a core application for my data type but few / no BI tools have support for.
The word cloud implementation in Tableau 8 is particularly ugly. I take the view that if you’re not going to match the quality of something like Wordle you shouldn’t implement it. I can’t see myself using them but at least if you do it do it well. It’s a bit embarrassing.
My greatest anger with v8 is with the implementation of forecasts. I strongly believe that a prediction into the future needs to incorporate uncertainty and there is no way of doing this at present. I would have been most happy with an implementation of fan charts – http://en.wikipedia.org/wiki/Fan_chart_(time_series)
As well as a Mac version I’ve been hoping for some proper analytic tools for some time. Specifically I’d like an integration with R. This is not going to help the average user but I think most statistically-trained folks would find it meets all their needs. At the moment you can do a lot with pre-preparation of the data but it can start to fall down when you need to update results because of user interaction.
I too can’t understand the lack of inclusion of boxplots. In fact someone at Tableau should look at the geoms available in ggplot2 and put them in as standard http://docs.ggplot2.org/current/ In addition I would like the following in the list of charts available as standard: dendograms, parallel coordinates, scatterplot matrix (as a one-click), waterfall charts, sankey diagrams, slope graphs (with useful labels) contours on maps and even the humble venn diagram. Of course network diagrams with a variety of layout techniques (tree and non-tree) would be fantastic.
I would also like some basic drawing tools to create dashboard items like fig6-52 on p156 of Information Dashboard Design.
Like Joe I like Tableau a lot but I do find it hard work to get the result I need. I find myself increasingly using it for prototyping and then building the real thing in R or D3.
I will follow in a few days with a longer post on my blog. Stephen turned me on to Tableau in 2007–which saved my former employer millions of dollars– and lead to the creation of the Tableau BI Consulting team at InterWorks. I have been in love with Tableau ever since. And, the Tableau community is one of the best groups of people I’ve had the pleasure to work with and learn from. Many I consider to be close friends…Andy and Joe in particular.
I remain firmly and passionately committed to Tableau–because Tableau offers the best solution in the marketplace. My perception is that V8 is an aggressive update to the software. I don’t love bubble charts, I can live without text visualization. I like the tree maps even though the implementation of them isn’t perfect (I can work with the current implementation and steer clients in the right direction). I can make box plots now in Tableau. They aren’t straight forward–Show Me enabled– but can be built easily by using aggregation controls and reference lines with the proper settings (agree this should be a Show Me option). I almost never use Gantt Charts.
What I want is for Tableau to continue to relentlessly pursue speed on data at massive scale. Wouldn’t it be cool to zip through petabyte scale data sets on a $1,000 laptop? Parrellel rendering, continued improvement in flexibility and ease of use (I like the new marks card). It would also be nice to provide users with the ability to rearrange the Show Me button content and hide options that aren’t needed or desired.
The environmental things (more OS options for example) should come over time. Most of all I expectTableau to maintain the standard of excellence that has all made so many people passionate about data visualization. Stephen’s points are fair criticisms regarding the addition of chart types of limited value. But, I hesitate to say they are of no value. Many times clients ask us to create what we consider to be bad visualizations. We give them what they want AND them show them something better. That works much better that telling them what there asking for is bad. Showing them is much more convincing. If you can’t get in the door with the customer you can’t win there hearts and minds. I suspect these chart types were added because customers or arge prospects asked for them.
There are many improvements in V8. I’ve been using it since September and really love what has been done in Tableau Server. We built the performance analyzer at InterWorks over a year ago–as an add-on to Tableau–and were happy to see that Tableau has incorporated an improved tool called Performance Recorder as a menu option for desktop and server. That will help many new enterprise clients tune there dashboards to load and render faster.
I enjoyed reading the post Stephen. As usual, when you are critical you put in a lot of effort to explain why something isn’t good and provide instructive examples. Everyone benefits from the medicine even if it doesn’t taste good.
Hello, thanks for the post. One minor point: the name “tag cloud” does not refer to HTML tags (that would be ‘body’ and colleagues, right) but to social tags as collected through social bookmarking services like delicious. You make a good point about missing context; I agree they are better when the words, such as tags, haven’t been in a particular order in the first place.
Hi Steven,
I really started using Tableau with the beta release of Public. Back then, I wrote a review which resonates with what you said in your introduction – my sentiment then was that it formed a foolproof framework – a user could throw data at it and the resulting form would always make sense.
As I started using the tool more and more I was sometimes frustrated with its lack of flexibility, compared with my standard practice of coding visualizations from the ground up, but accepted that as the price for this most important feature, the guarantee that the form will be correct.
no gauges. no glossy gradients. and certainly no traffic lights.
Fast forward a few years. by interacting with the community, I have seen my share of horrible tableau visualizations. Repulsively horrible. Exorcist-grade stuff.
I couldn’t get how people will make the conscious effort to deviate from defaults, for instance, and drive their vis right into the ground. the most common error was to throw all the data at a view and/or dashboard and not prioritize. The “because I can” syndrome.
conversely, in a recent project, an esteemed colleague of mine used tableau 8 packed circles in a presentation to a client. We had been doing text analytics and the context was to highlight important terms among a vast corpus. We wanted the others to be visible but down-toned, while the most important ones would be visible at a glance. their exact score mattered not so much than the impression that 5 to 10 terms, and not the ones that were expected, stood out.
Obviously, the packed circles were by themselves on a view, there was a low 3-digit number of bubbles, and the view was prepared so that we could make our point. In our a separate, print-friendly report we reported exact scores and used ordered bar charts.
Though, for presentation purposes the packed circles have been useful, and it’s been comfortable to use it from tableau, while we could have whipped it up outside of Tableau easily.
my point:
with the new tools, people will use new features “because they can”. and because when they show it to their unsuspecting bosses and colleagues, they will pass for gurus. that’s how organizations go. and yes, those new features allow people to go overboard more easily, and a large proportion of users will be drawn to that. I regret that, I think we all do, and I’m betting some folks at Tableau do to and weep.
But the truth is, that existed before.
The good part about Tableau is that it’s not dirt cheap. and learning it by oneself takes time which is costly too. if an organization is going to use it at any scale, it is just absurd not to pay for formal training. and it is through training that people will make better visualizations. proper training, not about what you can do, but about what you should do and why.
Really interesting piece marred only by a strange inaccuracy:
“Did they add this feature to satisfy one of their prominent UK customers, the Guardian? ”
We are not customers of Tableau – we’re more likely to use Datawrapper to produce bar charts, ironically. On the occasions where we do use Tableau, we use the public version.
Simon Rogers, editor, Guardian Datablog
Stephen,
Tableau 8 adds new data visualisations that are not useful for analysts. The treemap would be useful, however the way it is implemented (and advertised on their website) doesn’t capture a key feature of treemaps, namely their ability to show data hierarchical in structure. I deal with such data. I would have expected with treemaps implemented in Tableau to have a corresponding easy way to ‘import’ a taxomony for the data. I couldn’t find it, or maybe I’m missing it?
The way treemaps are advertised by the company make them similar to gigantic, impossibile to read pie charts.
Cristina
Joe,
I agree with your points that the majority of the features added are to introduce some additional features to the tool to placate a number of users who demand these features before even considering taking Tableau on in a corporate environment.
I would have previously looked for features like tree maps, bubble charts as they are what senior stakeholders are demanding. It takes time to educate stakeholders in why you wouldn’t use certain visualisations in certain situations and you almost have to show them why (just like this article by Stephen).
Does it have to be built in to Tableau to do this – not necessarily. But does it get Tableau’s foot in the door so users can then take advantage of the all the great features Joe highlighted and ignore the ‘fluff’ once the disadvantages are recognised – absolutely.
Stephen, another great post. I do agree Tableau has incorrectly prioritized some of their development efforts however I’m not as upset about the addition of useless chart types as you. I am however, disappointed and concerned that the performance improvements and statistical functions have not worked out as initially promised. These are the biggest problems I have with the current version of Tableau, besides the obvious no mac desktop or linux server versions.
re: performance
Tableau really needs to make this priority numero uno. The fact that I can make a single view incredibly slow with very little data means that I’m going to have to spend a ton of time upfront aggregating which severely detracts from this concept of visual exploration of my data and pushes me back towards data modeling techniques which can take months before realizing any value from my work. Data sizes are only getting larger, and we (as analysts) need tools to help explore them easily and quickly.
re: statistics
I believe my thoughts here align with yours about adding another interface to leverage the core Tableau functionality without compromising the UI’s simplicity. Many stats guys these days know and love the stats package R. This tool requires the user learn a full-fledged programming language and is widely used by all the largest tech companies in the world, those with actual “big data”. Why can Tableau not provide a better programming interface to integrate with tools such as R? Imagine for stats guys they can still use R for all their magic and then when it comes to rendering a view, they call a Tableau library of functions to generate the images.
If I had it my way, and I know this isn’t Burger King, these would be my top 2 priorities. All that said, I am excited about several of the new features including web authoring, free-form design (including pixel level adjustments) and the new data extract API.
Keep up the good work!
@bensullins
Simon,
The Guardian provides Tableau with high-profile, public exposure. In so doing, you provide a powerful promotional platform for the software, which gives you influence. I cited the Guardian as an example of an organization that might tempt Tableau to add eye-catching but ineffective forms of visualization to the product because I’ve seen some of the worst examples of this in your publication, especially those created by David McCandless, who is particularly fond of bubbles.
Thanks for replying Stephen. As I said, I really like the piece and agree with 98% of it.
And, yes, we do showcase visualisations by lots of people, including – very occasionally – David McCandless. It’s what our Show and Tell section is for . And yes, sometimes they have bubbles and sometimes they don’t. I want the blog to show lots of visualisations by lots of people – some of which I love, some of which I don’t but are interesting and will spark a debate.
But if you did a survey of data visualisation types we use in posts that we put together here, you would find simple bar charts well in the lead.
And we are not customers of Tableau.
Best wishes,
Simon
Andrew Marritt,
Regarding the use of packed bubbles for navigation purposes (i.e., as a way to filter data based on selecting one or more bubbles), the folks at Tableau mentioned this as a justification for the addition of this chart. I don’t agree. Any occasion when packed bubbles could be used for filtering the data, a bar graph could be used more effectively. With a bar graph, you can find the item that you want to use as a filter faster and you can actually read and compare the values that the bars represent accurately. Packed bubbles serve this and all purposes that the folks at Tableau have used to justify them less effectively than other forms of display.
At the end of your comments you mentioned something that I think we should discuss: the fact that you and some others must depart currently from Tableau and build systems using other products, such as R and D3. This is important because I believe that the kinds of systems that require tools like R and D3 should not be built with Tableau and that the folks at Tableau should not try to match the functionality of these tools. R is a full-fledged statistical programming tool. Statisticians can use it to build analytical systems that require sophisticated statistical functionality. As a programming tool, if you’re expert in its use, you can build just about anything that you need with enough time and patience. D3 is a programming tool for building web-based visualization systems. D3 is used extensively by graphical journalists, such as those who work for the New York Times, to build interactive infographics to support news stories. Once again, as a programming tool, if you’re expert in its use, you can make visualizations that look and do almost anything that you can imagine. Both of these are programming tools, not rapid visual data exploration and analysis tools. If the team at Tableau tries to make the product match the capabilities of these programming tools, it will become unusable for visual data exploration and analysis. You, Joe, and others like you who build custom analytical systems, will at times need a different tool for this. The folks at Tableau could perhaps build such a tool, but trying to make the existing product support all of your needs will destroy its usefulness for the vast majority of people who use it. I think it’s important to recognize that different purposes sometimes require different tools and that making attempts to make a single tool support all purposes will result in a tool that does a great deal, but does nothing well.
Simon,
The Guardian is in a position to promote effective data visualization by only showcasing infographics that are well designed. As an editor, do you not see this as an opportunity to lead the way?
If you use Tableau’s software, which is the case, then by my definition you are a Tableau customer. The fact that you use it for free doesn’t change this fact. I am also a Tableau customer in that I use the software, even though I’ve never paid for it. Whether you are a customer or not really doesn’t matter, does it? What matters is that the Guardian uses Tableau’s software, showcases its functionality, and as such exercises influence. Who knows to what degree the Guardian’s occasional use of bubbles, improperly designed treemaps, and other ineffective forms of display contributed to Tableau’s motivation for introducing some of the flashy stuff? What I invite you to recognize, however, is that by showcasing ineffective visualizations at times, you influence people in ways that potentially undermine their uses of data.
Stephen,
I absolutely agree about showcasing things that are well-designed, which we do. But I also want to democratise the process and encourage more people to feel that data is something for them, rather than an abstract property belonging to a few – as well as show new ways of visualising data when we can. Show & Tell is about separating off, to some extent, these visualisations and asking our readers what they think too. It is not a place for long strips of marketing ‘infographics’ – that visual disease of the web – but for a variety of ways of seeing the world.
And, if you have read the comments, you will see that our community are a discerning bunch who will vigorously debate the merits of infographics and the data itself. I am happy to provide a platform for as many interesting visualisations as possible. Some of them you will like and some you won’t but I think that’s OK. Comment sections of newspapers have allowed various views to permeate their pages for decades: it’s about allowing as many opinions as possible.
I hardly think you can then use us a reason for Tableau moving into word clouds.
Re: the whole ‘customer’ thing: the Oxford Dictionary defines ‘customer’ as “a person who buys goods or services from a shop or business”. We do not do buy services from Tableau, therefore we aren’t customers. We are sometimes users of the software, when it fits, yes. But not customers.
We demand precision in data visualisations; we should do the same with language too.
Best wishes,
Simon
Simon,
I use the term “customer” more loosely than you do. As you know, if you looked up the term in the Oxford English Dictionary, which I just now did as well, my use of the term fits within the OED’s various definitions of the term. Regardless, my point was that you have influence, which is true.
I too work to democratize the use of data. In fact, this is my life’s work. How we differ, however, is that I think we should democratize data only in useful ways. Showcasing ineffective forms of display undermines this effort. There is enough confusion on the Web today regarding data visualization. The Guardian could join me in trying to promote best practices by vetting its graphical content more thoughtfully.
As a journalist, would you ever showcase ineffective uses of the English language in the Guardian? I doubt that you would. Just like words, graphics are a form of communication. As such, syntax of a sort applies–rules for using graphics to communicate clearly and accurately. As a graphics’ editor for a large news publication, you have an opportunity to help people improve their graphical skills through example. This is a wonderful opportunity. You could extend your use of it in more helpful ways.
I second the note on R- there is a GUI called Deducer which is quite awesome, but R has its own things with Big Data Visualization.
A very nice and informative post that can be used for Tableau and the rest of the community’s benefit
Stephen,
Appreciate the long review of some of the new features in Tableau 8. I agree with your commentary that added features don’t always help further the cause, especially if it is “elegance through simplicity”. Having said that, I think you underestimate the kind of pressure and number of feature requests you get as a developer of a very popular software solution. In the comments alone, you can find many of the respondents complaining about a Mac version and some of the “missing” stuff. Does doing all of this add complexity…sure. Do customers understand the dependencies and constraints…usually No. So, it might be true that you don’t have someone with the dictatorial capacity of a Steve Jobs to say “No, I want only one button” within Tableau’s Design team. But when you are trying to improve upon a solution, you make difficult choices between fixing something, adding new functionality that you believe is useful and listening to your customers who are very vocal about what they want to see.
Having been on the receiving end of that pressure, I can say that it was easier to go the route of listening to your customer and add new features. Until, it turned out to be counter-productive and disillusioned the core set of users who loved the simplicity…which I hope isn’t the situation with Tableau 8 (I didn’t like some of their changes, but there were many I did like). One additional thing I’ll add is that we can look at things from a creative and theoretical standpoint to guide design, but you will never be able to anticipate or imagine some of the uses that users will put your product through. Some of these uses will inspire and humble you, while some of these uses will seem to be plain wrong and go against the grain of what you strongly believe in…but try convincing the Customer that!
For example, from a purist’s perspective I completely understand your criticism of Tag or Word clouds, but I think you haven’t looked at some very valid use cases where they shine and have more impact than a bar chart.
The example you provide is for a speech and the way I’ve seen it being used is to surface verbal tics or the tendency to over-use certain words. If you filter out the obvious prepositions, you can get a sense of the speaker’s vocabulary or the lack of it. For most speeches, if you tried representing all the words in a bar chart, you’d have something untenable. I think of word clouds as a tree map with words…I’m not measuring quantitatively the size of each of the squares or comparing each word to the next, I’m just focused on the words that pop out of a long speech.
The more frequent use is to synthesize feedback from multiple conversations. What you espouse about context..Amazon has started doing this (not with word clouds) by summarizing some of the feedback in phrases and saying that X% of the reviewers share a similar sentiment. This no doubt provides more context than just individual words, because it is a book that is being reviewed. But what if you were describing a person or a brand? You don’t need phrases if you have hundreds of blog entries or comments to your pictures in your flickr stream and if you are looking to see what feelings are evoked. The example that immediately came to mind is the very inspiring word cloud that I saw in Avinash Kaushik’s blog: http://www.kaushik.net/avinash/incredible-analytics-experience-5-years-occams-razor/
There’s probably someone out there who might be able to make a similar use case for bubble charts, but just wanted to add my perspective to a great discussion.
Thanks
Prakash aditham
Prakash,
I am quite familiar with the demands of software development. I’ve been a part of a BI software development team in the past. As a designer, I am also aware of the fact that software companies cannot produce good products by giving customers everything for which they ask. This approach results in bloated, unusable software, which is typical of the software that is available today. (Perhaps a version of Steve Jobs is needed at Tableau to keep the product focused on good design.) Customers that understand their jobs and do them well know what they need to do, but they rarely know how to design software to accomplish what they need to do. This is the responsibility of an expert design team. What really matters and really works should always determine what goes into a product, not customer demand. You are absolutely right when you say that it is easier to give the customers what they want. Easier, in this case, isn’t better.
You said, “You will never be able to anticipate or imagine some of the uses that users will put your product through.” This is absolutely the case, however, when you can imagine many ways in which a feature that you’re planning to add will be misused and thus do harm and few or no ways that are useful, you shouldn’t add the feature. Product development should not be approached as an test bed — “Let’s put this feature in the product and see what happens.” This kind of experimentation should be done in environments where they can’t do harm.
Regarding word clouds, they have no place in a data exploration and analysis tool. For analytical purposes, not entertainment purposes, a bar graph will always provide a more effective way to compare the number of instances that words and phrases have occurred. Word clouds are an example of what I call “data art” or “data entertainment.” Research has shown that they are analytically impoverished, and we know the reasons why they don’t work. The jury is out on this particular visualization, and the verdict was “guilty as charged.” Nevertheless, if you feel that you have a data set that would be better analytically served by a word cloud than a bar graph or any other form of display, I invite you to send it to me. If I can’t display the information is a way that is more analytically useful than a word cloud, I will publish your example and give you credit for proving me wrong.
Stephen,
Thank you for your response. Let me clarify that I wasn’t suggesting an experimental approach to Product Development. If you agree that you cannot anticipate all the use cases or how a particular feature is used, then logically speaking even “good” chart types can be misused. Does that preclude them from being included in the solution? What is the threshold to exclude it? 20% misuse, 50% misuse? Who determines the threshold and if you determine that 60% misuse is the threshold, are you going to force the remaining 40% who know how and when to use that chart type to use something else? I completely agree with your assertion that a middle ground is for “Show Me” that provides only the best choices.
As for word clouds, I respectfully disagree that they are only for “data entertainment” and I gave you two very specific examples of what they are well suited for. To reiterate, I’d use word clouds only when I want to visually represent a large set of words that would make bar charts unsuitable. I likened them to Heat Map for words, because in your justification for Tree Maps, you say “If it could be done, I’d rather view this information in a bar graph, but if I need an overview that includes all of these stocks, there are far too many values to put in front of my eyes at once using bars.” Quantitatively, there’s not much I can determine by just eyeballing relative size of the squares (unlike a bar chart), but still there’s value in seeing all the squares and the color means something to me.
A speech has probably hundreds of words and if you want to see all the words represented, bar charts wouldn’t work well without scrolling for pages. The second example about understanding brand sentiment is also relevant…the size of the word shows frequency, the color whether it is positive/negative or neutral. As Avinash says in the link I provided, “There were hundreds of responses (!) A simple way to visualize all that (textual) data, and identify trends, is to create a tag cloud “. Please tell me that it wasn’t the most elegant representation of the feedback he’s received – it was far better than anything I could think of at least. Conceptually, a treemap uses area and color to convey information, a word cloud uses size and color to convey information, so I don’t get why we should villify word clouds.
Thanks
Prakash
Prakash,
A feature that is often useful can be included in a product, despite the fact that it can be misused. What we should never do, however, is encourage people through defaults and guidance tools to use them in ineffective ways. Features should be incorporated in ways that discourage misuse. As I illustrated in my blog post, including visualizations in Show Me encourages people to use them. Packed bubbles should not be included in Show Me and word clouds have already been removed to discourage their misuse. A visualization that is occasionally useful–enough so that it makes sense to include it in the product, but not so often that it should be emphasized–can be added to the product, but it shouldn’t be included as a default or in a guidance tool such as Show Me. We don’t need to determine a fixed threshold for the percentage of times a feature might be useful. Packed bubbles, which are never useful, are far below the threshold.
Regarding word clouds, I don’t find your examples analytically useful. The data can be displayed for analytically purposes more effectively in other ways. If you don’t agree, please provide me with the data sets and I’ll demonstrate how. I’ve explained, based on research done by others, why word clouds are not effective. For one thing, the sizes of words do not even come close to representing the number of times those words occurred. The size of an object, such as a rectangle in a treemap, can accurately represent a value, despite the fact that we can only perceive them to an approximate degree, but the sizes of words, which vary in length, cannot. Also, examining words independent of context is very misleading. And finally, a good analyst wouldn’t want to see every word, so there is no reason to include hundreds of words in a single visualization.
Sorry used Heat Map and Tree Map interchangeably in the comment above, but I hope it doesn’t detract from the main argument that word clouds can be useful
Thanks
Prakash
Stephen,
The joy of observing users completing tasks is that they make you humble. Even the most experienced designer will be surprised on a pretty regular basis. Like storytelling with data, user interaction of data displays I feel is a research area still in it’s infancy.
As far as your comments on R and D3 there are frequently times when I end up using them because it can be quicker than doing the same thing in Tableau. Tableau is great for the simple drag-and-drop scenarios that they demonstrate if you bring data in the format it likes. But as many analysts will tell you often the majority of time is taken getting the data in the right shape. My workflow for dashboards is to hand-sketch what I want before going to the tool This means I focus on the objective of providing something to guide decisions not pick what is easy to do in the tool. As you take Tableau further, sometimes to do what would seem simple things, you quickly get into a land of complex table calculations, custom SQL and hoping that Joe or one of the other amazing folk on the forums can help.
As a few others have mentioned, Tableau handles the behind-the-scenes stuff very well. It’s brilliant for prototyping and just getting some ideas up in rough and exploring data sets. If you want to build a dashboard or even something to be exported to pdf it can often take longer than just writing a bit of code by the time you’ve done all the Tableau work-arounds. The code, being reproducible can often be easier to maintain, reuse on similar data sets and as I said quicker to write. The flipside is that Tableau & Tableau server can handle all the back-end stuff really well. We’re sitting between two sub-optimal solutions.
Stephen,
Thank You for the unbiased and informative article. Thanks also to the Tableau Gurus who shared their views above.
I agree with you on the limited usefulness of word clouds and Bubble charts. I do like the new Marks card in Tableau 8 beta, as well as connectors to Salesforce.com and Google analytics,to provide better visualisation on those platforms.
I agree, “bling” doesn’t really sell the software, the people who invest time and money into buying a piece of software are looking to find insights and answers to their questions, by analysing and visualising their data.Tableau’s greatest asset has been its simplicity,clean visualisation and ability to connect to many data sources out of the box, and ease of learning.Simplicity and Performance are the key attributes that could be a game changer!
It would have become more value for money as a DV tool, if it provided an interface/connector for R, which got overlooked. The corporate analysts are increasingly using R over the past couple of years.
SB
Stephen
Thanks for your reply and for taking the time to engage. I don’t agree with the point about customers, but there you go.
I promise I’ll stop soon. But…
Just a few definitions and differentiations. Firstly, I am not graphics editor at the Guardian newspaper and I have never been. That falls presently to the brilliant Paul Scruton and previously to Michael Robinson. Both of whom know an awful lot more about graphical design than I do and are often fierce adherents of the kind of simple, clear graphics which you champion. There is nothing in the piece you have written with which they would disagree and I think you would be hard-pressed to find anything in the Guardian Graphics department’s work which does not fulfill those rules.
My job? I edit the Guardian Datablog, which is the home of a lot of the Guardian’s data journalism online. Our output on the blog comprises news stories, opinion pieces and data analyses. Often these are accompanied by charts and data visualisations which also follow your rules. At the moment we use Datawrapper a lot as it is a great way to produce simple clear charts at speed, as we are often working to tight deadlines. Most of the result of our work is in written articles, not data visualisations.
In terms of graphcs, I would say that 80% of the output of the Datablog is either our own simple charts or more ambitious graphics produced by the Guardian Graphics department working directly with our reporting team.
A small part of the output of the site is a ‘blog within a blog’, the Show and Tell section. This is where we publish interesting things from around the web. Are they all perfect? Probably not. But are they interesting or do they tell interesting stories? Yes, I think so.
Of course, that is my opinion. Yours or any of our readers’ may be different, and this is where the point about written articles comes in. I would not expect every article written by every writer for the Guardian to be in the same style or approach. I would expect them to be able to follow an argument, be literate and at least be accurate, however. And as long as data visualisations that are pitched to me follow those rules, will engender debate and discussion, then great. They may not all be to my taste, but that is what it is: my taste and opinion. I’m not sure there is an objective school of knowledge that says this is ‘right’ and that is ‘wrong’ – particularly as tastes and fashion move all the time.
Having said all that, if you would like to write or visualise data for us to show on the Datablog, I would be honoured. There is a real hunger out there for a glimpse of the knowledge you possess. Let’s share that.
Hi Stephen
Software vendors are motivated by all sorts of things, but money is normally the primary one. Customers or potential customers have probably asked for these features and made it part of their buying decision – Tableau has simply obliged.
That aside, sometimes people use visualisations to hide numbers as you often point out. The benefit of having Tableau offer this is that someone would have the option of saying ‘please change that to a bar chart, etc so I can understand it better’. This is not possible if you have a PowerPoint slide – bad behaviour will be exposed and hopefully lessons learned.
Cheers
Adrian
Tableau has a forum to introduce product enhancements. My intuition tells me a lot of these new features have come from this forum, which means they are user suggested. I have only started working in Tableau over the past year, but what I have found is that there is a lack of what I feel should be fundamental functionality.
Simon,
As the editor of the Datablog, you have an opportunity to vet the content. I believe that it is in the Datablog that I’ve found the Guardian’s examples of ineffective data visualization that I referred to previously, such as McCandless’ work. I’ve used examples from you Datablog in lectures to illustrate how not to visualize data. These examples do not meet your journalistic requirement that the content “follow an argument, be literate and at least be accurate.” McCandless’ Billion Pound-O-Gram, which appeared in the Guardian, is an example of this.
There actually is “an objective school of knowledge that says this is ‘right’ and that is ‘wrong.’” It is based on many years of research into the way graphics are perceived and how they can assist or impede cognition. Many books, such as mine (also Tufte, Robbins, Ware, Cairo, Cleveland, etc.) explain the findings of this research in the form of data visualization best practices. Although style and fashion certainly exist in data visualization, this isn’t what I’m talking about. I’m referring to perception and cognition, and how graphics can be designed to work effectively for humans. Are you familiar with this body of research? If not, I invite you to become familiar with it and to let this body of knowledge help you vet the content of the Datablog in ways that will better showcase effective data visualization practices. In so doing, you will join in the effort to usher in a true Information age, rather than the dysfunctional data age in which we currently live.
Hi Stephen
For what it’s worth there is not much in what you just said that I would disagree with – in fact we are well aware of these principles of graphic design and I would say that both our own output and that of the Guardian graphics team adheres to those rules pretty firmly. And if you see something that either I or our graphics team produce which does not then please let me know.
But I will always want the Datablog’s show and tell section to be a place where graphics of all different types are published to engender debate and encourage new ways of visualisation. Obviously, the more people who visualise data in ways that are “effective” the better. But the nice thing about that section is that it is a place where everyone is free to submit something with a good chance it will be published.
Simon,
By allowing a visualization to be featured in the Guardian, you are granting it a degree of credibility. It appeared in the Guardian, after all, so it must be good, or so readers will reason. Readers will emulate these examples, even when they’re completely ineffective as journalism, especially if they’re eye-catching, unless someone moderates the show and tell section to either deny bad visualizations a forum or critique their effectiveness so that readers can learn from them. In cases when novel visualizations are posted, that are not obviously either good or bad, you can frame them as experiments and invite critique. I’m encouraging you to get more involved as a moderator, using this forum that you edit to nudge readers toward better data journalism. You’re opportunity is golden. Use it more proactively.
Scott,
To my knowledge, there is no idea in the Tableau forum requesting Word Clouds, Bubbles, or Treemaps. Therefore my guess is that these features are not suggested by Tableau forum users.
Johan
Stephen
I wish that you would spend a bit more time on the Datablog – and we could have this conversation afterwards. “Frame them as experiments and invite critique” is exactly what we do. You never know – you may be pleasantly surprised by what we produce.
If you’re looking for me to say that I won’t use David McCandless’ work ocassionally, however, then you will be disappointed. Whether or not you like his work, he has probably turned more people onto data visualisation than any other data journalist I can think of living today. Those people will then I believe investigate the field more and hopefully discover too your work and those of others in the field. And when we use his work we will, as we always do, ask our readers what they think too.
Simon,
I’m not telling you to deny McCandless a forum for his work. That isn’t my place. I’m merely pointing out that providing him and others who promote ineffective practices a forum for their work, you are supporting bad practices. In so doing, you are aiding a abetting a crime against data journalism. We’ll never progress in our use of data as long as people like McCandless are encouraging others to make the mistakes that we learned to avoid more than a generation ago. Must we continue to repeat the mistakes of the past?
McCandless does not understand data visualization because he never bothered to study the field. Instead, he began generating flashy infographics and, because publications like the Guardian endorsed his work by showcasing it, he gained notoriety in a field of practice without ever actually developing the essential skills that are needed to do it effectively. With this recognition and notoriety affirming his work, he hasn’t felt the need to step back and develop the skills that he’s lacking. Why would he. People like you are saying that his work as a data journalist is already good enough for major publications like the Guardian. You endorsed his work, not because it was good, but because it was popular. Is that what an editor should do? Perhaps for a publication like the Sun, but for the Guardian?
You can’t sit back and claim neutrality. You’re an editor. It’s your job, as I understand it, to promote good journalism. When publications like the Guardian begin to treat graphical journalism as conscientiously as they treat written journalism, then we’ll begin to see progress.
This part interested me:
“The fact that customers are asking for something in particular does not in and of itself make it useful. People sometimes want things that are far from useful or they want things to be designed in ways that don’t actually work.”
Just this week I had a discussion with a co-worker in which she was talking about dual-scale charts. I mentioned to her that dual-scale isn’t very useful, as there is rarely (if ever) an advantage (and oftentimes a disadvantage) to overlapping multiple metrics within the same space (especially so when some are bars, some are lines, and none are trends). I even offered the simple alternative of plotting two or more vertically-aligned charts. Her response: “my users prefer dual-scale charts”.
I wasn’t sure how to respond to that (Stephen – any ideas?). Furthermore, I’m not sure how best to deal with that type of user; I, too, have had users request that I do things a certain way that I know is wrong and not actually in their best interest, and while I try to explain to them how they’ve got it wrong, many times I don’t enjoy the luxury of any other choice than to do it their way. In such cases, what do I do?
One time I had a user request that I display an average inventory for multiple warehouses. I tried to explain to him that such a metric is misleading (one warehouse being overstocked and another being understocked would imply that “all is well” when all is clearly not well) and that displaying inventory vs. target for each warehouse (the way we were already doing it) was really the better way. He became belligerent. He thought I was arguing with him, questioning how he’s been doing things for years, and since he knows the business better than I do (which he does, even though I apparently understand numbers better), I should just do it anyway. The project’s decision-makers took his side.
Maybe this is why Tableau has turned to the dark side (the article seems to propose this, as do other comments here). Perhaps constant requests from important customers’ decision-makers (who are frequently told by almost every other vendor that fancy useless graphics are the future of BI) have convinced the less-graphicacy-savvy decision-makers at Tableau to include such features. Not that this is okay. But what can people at Tableau, who do not agree with these decisions but are in no real position to refuse them, do? Quit? Is there another BI/data-viz company out there that they could work for that actually cares about data-sensemaking before money-making? Are they hiring?
Stephen,
I’m in near 100% agreement with your comments about the analytical usefulness of the v8 implementations of treemaps, word clouds, and packed bubble charts. Like Jerome, I’ve been able to find a couple of cases where the packed bubbles were useful in creating an overview before drilling down to details in further worksheets. I certainly could have used something else, the bubbles added some novelty for me as I was searching for how they could be useful.
However, I think that’s only X% of the story of Tableau v8, where X% is small, and the rest of that context shows that Tableau has not lost their direction. The new Marks Card that reveals the sort order, the improved text labels, multiple discrete values on the Color Shelf, serious performance improvements, improved ease of use for blending in multiple ways, passing parameters to the query, all of these are evidence to me of Tableau taking the process of analysis seriously, and are evidence that Tableau has not lost their direction. Another piece of context that I think is important is that Tableau replaced a bunch of underlying code in v8 for the new pipeline and more. While we might debate (and even agree) that some of the new functionality from that effort (like the non-cartesian chart types such as treemaps) is not where we’d want it to be, Tableau also laid the groundwork for browser rendering, web authoring, and Mac and Linux versions, which are all important for Tableau to continue in the marketplace.
Earlier in the beta I had a long conversation with Jeff Pettiross at Tableau about using packed bubbles and treemaps in analysis and I think one big issue is that in Tableau we’re used to dragging and dropping pills for which have some prior knowledge of the cardinality, sort order, etc. onto the Rows & Columns shelves. With that knowledge have some ability to predict the X/Y layout. The algorithms for the layout of the non-cartesian chart types are pretty much black boxes and don’t let us have any ability to predict where things will end up, and that takes us out of our analytical flow. Our confusion is compounded by labels vanishing because of the small size of many bubbles & rectangles, and these chart types all depend on area that is harder to interpret than length. Personally, I think a potential solution to this issue for analysis involves using highlighting and transitions so we can track what mark goes where, though I’m definitely *not* clear on how much value that would add for the development effort required.
Over the last few months I’ve been involved in a tool analysis with several other BI vendors and their latest drag-and-drop Tableau clones. I’ll blog about that experience at some point, my major learning was that even with the new v8 charts, Tableau is still the best at evidence-based visualization. By “evidence-based” I mean baking recommended practices right into the application, for example I don’t have to turn off the default color gradients with reflections in Tableau because it doesn’t do them. Tableau doesn’t do everything I want it to do, and it continues to do a better job for me than anything else I’ve seen.
Jonathan
Jonathan,
Tableau is definitely still one of the best visual data exploration and analysis products on the market. No debate there whatsoever. Version 8 includes many worthwhile and well-design additions. This, of course, does nothing to assuage my concerns about the harmful effects or compromises in design of some of the features. These are departures from Tableau’s original vision to support best practices and commitment to design integrity. Without correction, decisions of this type will take Tableau in the same direction that has led other BI software companies to become unreliable.
Hi Stephen – maybe we will never agree (or even draw this conversation to a close) but let’s introduce some facts to the conversation as I fear you haven’t spent that much time with the section you are so critical of.
In 2012, the Datablog ran 725 pieces of content, which includes written articles, charts, videos and maps. We ran several awards, including one for statistical excellence in journalism from the Royal Statistical Society.
Of that number, we ran 67 pieces in our Show & Tell section – 9.24% of the total. These are pieces produced by people outside the Guardian in a separate section of the Datastore, as opposed to being part of the main part of the blog. This section is clearly labelled as being a place to showcase experimental and interesting visualisations and where we actively elicit comments from users as to what they think.
Last year we ran three pieces by David McCandless – which is 0.4% of all Datablog posts.
Oh and no word clouds.
This also means that 90.76% of our content is produced within the Guardian, often with simple charts and visualisations using tools like Datawrapper (which, by the way, was produced with advice from Tufte) or with graphics produced by the Guardian graphics team. These are hardly shabby and several have won prizes at Malofiej. In short, we adhere to pretty strict design rules and principles.
So we allow under 10% of our editorial space to be taken up with visualisations from outside the Guardian, often experimental; always interesting and worth discussing.
I appreciate what you say about ‘objective truth’ in data visualisation – although this is the only field I can think of where this view applies. In science, journalism and literature, there is a recognition of the subjectivity of those taking part. And clearly if we are to deny all alternative voices and methods then nothing new will ever develop.
We actively ask our readers what they can do with the data. To then turn around and say, actually we’re going to ignore all that work and not even allow a fraction of our site to showcase things which are interesting around the web would be odd, to say the least. Then it starts to sound less like “good” and “bad” and like something much less appealing: like a dogma.
Simon,
I appreciate your thoughtful and passionate defense of the work that you’re doing at the Guardian. We clearly disagree, however, about your responsibility as an editor and the effects of the poor data visualizations that you often showcase in the Show and Tell section of your Datablog. This is the logo that appears at the top of the Datablog’s main page:
Facts are indeed sacred, if by facts you’re referring to those that are true. We don’t treat things that are sacred in the way that facts are sometimes treated in your blog. In the introduction for Show and Tell, you say: “Welcome to Show and Tell, our new site highlighting the best of the world of infographics and data visualisations on the web.” Let’s take a look.
In my most recent visit to your site, this is the first visualization that I found featured there:
This is a linear arrangement of bubbles (circles) that are meant to represent the percentages on Catholics in various countries. Only the table that appears above the graphic, however, is useful. The graphic suggests that circles of various sizes as shown here is an effective way to graphically represent the values and the differences between them. As you know, this graphic is an ineffective quantitative display. Where have you pointed out or even suggested that this graphic isn’t effective or shown a more effective way to display these values?
Here’s the next visualization that I found:
The caption for this says: “Twitter users grouped into tribes, annotated with words typically used by each group.” Can you think of more effective graphical ways to tell this story? I can. This is eye-candy, pure and simple. When people see examples like this and believe what you’ve said, that these are examples of the best infographics and data visualizations on the web, they will emulate them. What a waste.
I know that I’m being hard on you. That’s because you’re an editor for an influential news publication. You can do better than this. It’s your job to do better than this. I’m not saying that you’re a bad guy. I’m saying that you’re missing a wonderful opportunity to make the world a better place by actually doing what you claim: to use your Show and Tell section of your Datablog to show a curated set of great infographics and data visualizations. If you do that, I’ll praise what you’re doing.
You cannot dismiss my perspective as “dogma.” I am not dogmatic. I know all about dogma. I was raised in a fundamentalist religion. I was told, “This is the way it is because we say so, and if you question what we say, you risk going to hell.” I clawed my way out of dogma and now believe in a scientific view of the world. We discover what’s true through research, based on evidence. Science has informed the use of graphics for presenting data. If we want to progress in our ability to find, understand, and present the stories that live in data, we should take advantage of these scientific findings, using them as the foundation on which to then build ever better methods. Many of the examples in your blog are encouraging people to ignore science and emulate practices that we know don’t work. My attempts to discourage this are not examples of dogma, they are the compassionate advice of a teacher who wants to help people do better.
Andrew Craft,
It’s often difficult when you’re a part of an organization to be heard. According to Jesus, “A prophet has no honor in his own country.” Sometimes I can go into an organization and say exactly the same thing that someone on the inside has been saying for years without success and people suddenly listen. Why? Because I’m from the outside and they’re paying me for advice, so to ignore me would create cognitive dissonance.
When people are accustomed ineffective forms of display, they need to be shown a better way before they can be convinced to change. They also need to be willing to open their eyes and see, which isn’t always the case. People who care about doing their jobs well, however, are willing to listen. Those folks can be shown better ways through examples and explanations. Regarding dual-scaled graphs in particular, people can learn to use them effectively, so there’s no reason to wean them of this approach if it works for them. What I mostly warn people about in regards to dual-scaled graphs is their use when presenting data to people who may be confused or misled by them, such as the general public.
I understand that in your role, you will not always be able to give people the most effective solutions when they insist otherwise. You do what you can do. You courteously push and prod. If you can do most of your work well, you may be able to tolerate the few occasions when suboptimal work is forced upon you. If the balance tips to far in the direction of work that is unacceptable because you know it does harm, if you can’t change this, then you have no choice but to tolerate it in the meantime while you search for other opportunities. One of the greatest joys in life is the opportunity to do good work. You owe it not only to yourself but also to your employer to do good work. When your employer doesn’t support that, your employer doesn’t deserve you.
Regarding your warehouse inventory example, I’ve been there many times during the course of my career. I often did work to support people who were supposedly experts in their jobs but sometimes did their work in ineffective ways that weren’t obvious to them but were obvious to me because I had particular skills or a perspective that they lacked. If the people that you’re working with respect the fact that you bring something to the table that they lack, then they’ll accept your help. If they see you as nothing more than an automaton that does what they tell you without question, then you’re out of luck if you can’t convince them otherwise. Do your best to show that, even though you can’t do their jobs, you bring an area of expertise that is different from theirs that could be helpful. Smart people are will be open to this if you demonstrate appropriate humility.
Regarding the appropriate response from Tableau when customers ask them to do things that don’t work, my answer is simple: “Always do what’s in the best interest of the customer, not what the customers wants.” Giving customers what they want may win the sale, but if it hurts the product, it won’t keep those customers happy for long and it certainly won’t win smart customers. The vendor is never without a choice. Making bad choices out of a sense of necessity or convenience is hard to stop once you begin down that path.
The folks that I know at Tableau are all good, smart, well-meaning, and talented. As I said in my blog post, however, when organizations grow, it because increasingly difficult to keep good intentions and smart decisions on track. As others have commented, people from many other BI software companies have joined the swelling ranks at Tableau and have brought with them the perspectives of those other companies. Some of those perspectives muddle the works. It is hard to keep a vision pure and vivid under these circumstances. When I last visited the folks at Tableau to take an early look at Tableau 8 during the alpha stage of development, I was asked to give a talk to the development organization because, as the organization was growing, many of the new folks were not aware of the basic principles of effective data visualization and it was getting harder to keep the ship on course. A common vision that is pure and vivid is necessary. I doubt that Tableau is making decisions that I consider bad strictly for revenues or because customers are asking for features that Tableau recognizes as bad. I believe that it’s more likely that they themselves are merely losing touch with what matters and what works as they become more and more immersed in the product and less able to step back and get the lay of the land.
Stephen
Thanks for taking the time to look at part of the blog. Obviously those are two examples of external graphics on the site. In the last week, however you will find a piece about John Snow’ cholera map, another on the composition of Popes featuring, yes, bar charts; another on the use of antibiotics (more bar charts); a piece on wellbeing (bar charts); a large piece on a decade of war in Iraq (mostly bar charts); a historical list of uk voting intentions (line chart and pie chart); another on Surian refugees (bar charts).
Having written that, I’m worried we are using too many bar charts but they are probably the most effective way of visualising that data.
But we also publish the raw data itself because we believe many of our readers, you included, may be in a position to do better things with the data; our role being as much to democratise data as visualise it.
As I said, external graphics are a tiny part of our output and are there to engender discussion. And next week we will publish one of David McCandless’ graphics which I’m sure you and other of our readers won’t like. However some will, and others will like part of it but may disagree on elements of it. But I think we are all mature enough to discuss those tastes online. That is what the blog is for – and I would love it if you became part of that process too.
Stephen, thanks for this explanation of the weaknesses of various newly popular methods of obscuring the quantitative relationships within data sets by making the presentation appeal to those who must be obeyed. If that is the reason the folks at Tableau give for adding these “features” to their product, then perhaps they could do all their customers a favor by consolidating them into a second group of tools called “Chartjunkers.”
After all, folks really should know what “value” a feature is providing them, right?
This comment is in response to the one by Andrew. Andrew, I’ve addressed some of your questions in articles I’ve written. Some suggestions for what to do when asked to draw a figure you disagree with are covered in my 2011 Amstat News article. Some comments on who is to blame – the vendor or the user – appear in my 2010 commentary on Steve’s article at Interaction-Design.org. Links to both of these are available at
http://www.nbr-graphs.com/resources/chapters-articles/
Simon,
As I’ve demonstrated in this blog and in books, articles, courses, and lectures for many years, I am very much a part of this discussion; I just don’t do it on your website. However, I’m not seeing you participate in a discussion on your own website in a way that promotes effective practices and works to improve data visualization. You seem to believe that your role is one of neutrality. An editor should be unbiased in regards to the the news, but not in regards to the way in which the news is communicated. Making sure that journalism is clear and accurate is the role of an editor.
As you know, I have not said that your site features only ineffective infographics and data visualizations, but that it also features those that are bad and makes no distinction. Doing so does harm. The fact that many of your readers will like the infographic that you’ve commissioned David McCandless to post on your site does not justify its inclusion, unless you believe that the role of journalism is to give people what they want rather than what is true and useful.
As with most companies, Tableau likely feels pressure to constantly come out with new features. Maybe we’re reaching the long tail of visualizations, so we now have word clouds and packed bubbles. Packed bubbles only seem to be useful (charitably speaking) if there are one or two entities that are much larger than the rest — the outliers. That being said, I don’t mind the inclusion of these charts types. It understandably annoys the purists (respectfully submitted, Steve) but if somehow fills some need that Tableau has identified that increases their revenue, great. I agree with Steve, though — it appears that Tableau development is just a bit disconnected from the main body of users and current data visualization theory.
As many have said, Tableau would gain more users, revenue, and ultimately continued respect by 1) having a Mac client 2) supporting *NIX deployment, and 3) working on rendering performance. I assume these items are much harder to address, or they would have been done years ago.
Readers — I believe that this discussion has now run its course, so I’m closing it down for comments. I’m getting on a plane for Singapore in a couple of hours and don’t want to find a series of comments covering ground that we’ve already covered needing responses when I reach my destination, exhausted and brain-dead.
Thanks for sharing your thoughts.
[…] to which his opinion reflects the perspective of Tableau. I recently learned that when my review of Tableau 8 was published, Tableau employees were forbidden from responding publicly. That makes this brief […]