From Chart White Space to (the need for) Architecture

Johan Sivertsen has been doing a stalwart job of organizing and consolidating ideas in the Tableau Community forum. His organization of the ideas in to functional groups is terrific stuff. It helps organize the space into realms of commonality, without being prescriptive or too rigid.

This post started out as a response to a specific idea on white space in charts that Johan had consolidated along with some related ideas.

I was struck by the degree to which Johan's work is aligned with my thinking about Tableau, how it's current state is a reflection of the path it's taken, and that the surface friction points I've been finding, and which this blog started out as a simple collector for, are only symptoms of deeper architectural issues.

In a sense I feel almost like I've been monitoring earthquakes long enough for them to be a lens through with the deeper structures are visible. In this view Tableau isn't a coherently designed elegantly implemented holistic entity that provides a consistent, smoothly linear path from the simplest to the richest functionality. It's much more like a Rube Goldberg wonderment that started out as a clean, tidy gem onto which was bolted, welded, riveted, and glued additional mechanisms that may have seemed to make sense in their own local context, but weren't part of a real design.

After lots and lots of frustration with Tableau's awkward parts, gaps, inconsistencies, lack of clarity, etc. I'm becoming more and more convinced that the particular friction points are manifestations of Tableau's genesis as very particularly functional software. And in the cobbling-on of additional functionality over time using existing bits and pieces without reconsidering the core design paradigm's applicability to the needs of doing new things.

It looks very much to me like Tableau was originally designed to render visualizations of quantitative values, commonly within a dimensional organizational context, with specific semantics surfaced in the configuration of the user interface elements. (seems almost too obvious, but I wasn't there and don't really know) Those things that fit within the initial design tend to work very well - they're clear, fairly obvious, e.g. double-click this, drag that there, configure the up-front properties of the quantified values: colors, size, etc.

Things that aren't part of the initial design space tend to be less clear, less intuitive-to the point of being inscrutable, awkward, or even just badly implemented. Formatting is perhaps the most obvious example - trying to format anything that's not a mark is much less obvious than it should be, up to the point that after seven years with Tableau it's still sometimes a hunting expedition to find just the right nook where I can format the table element I need to. And why visualizations, tables in particular, don't have easily configurable frames, much less a visible boxing model, is an enduring mystery. Table calculations are even more mysterious - if not for Joe Mako this area would be a very dark zone indeed.

Back to the chart white spacing idea - this is an example of something that wasn't in Tableau's initial design, which seems to be that there's a rigid cellular framing of the marks' space. Within this concept only the simplest, most rudimentary configurations are meaningful e.g. all rows have the same height, quant columns containing marks are all the same width, context columns (mostly dimensions) can be individually widened and narrowed, and only the width of the mark can be changed.

And why does Tableau make a distinction between first class data—the quantified measures rendered with marks, and second class data—the context-creating Rows- and Columns- Dimensions? This might make sense from some particular technical implementation perspective but it causes lots of cognitive and user-functional problems.

The higher-level considerations, which get reasonably and somewhat subtly complex pretty quickly are, being outside the initial design space, not addressed. Which isn't too surprising since there are some pretty significant architectural challenges involved, pervasive across the product, that require a serious re-think and Tableau has been concentrating on other areas.

Surveying the landscape of things the Tableau customer community have been asking for, and Johan's idea curating is really helpful here, suggests that a large fraction of them are manifestations of common causes. For example, there's a linkage between many of the requests for charting improvements and the basic concept of what a visualization space is – redefining the visualization space paradigm, aligning it with the more comprehensive cognitive space it needs to be, and them orienting its representation and manipulation, will address whole swaths of ideas, suggestions, and complaints.

Similarly, there are real problems with the current implementations of quick and action filters. Where they should be complements, varying manifestations of a deeper underlying mechanism, they are only superficially so. Rethinking what filtering is, what it is not, and how it should be manifested and then implementing filtering appropriately would smooth things out, almost certainly eliminating the current two forms. I have another post in the works on filtering, but I for now I ask this question: why did anyone ever think it made sense to necessarily tie inter-dashboard launch navigation to action filtering? Granted, it make it possible to use worksheets as inter-dashboard guided navigation channels, but it's harder to think up a clumsier way to do provide this functionality — on the other hand it does leverage several of Tableau's basic principles so it probably made sense to implement it that way to whomever programmed it.

The big questions for me are: Is Tableau is going to put in the foundation that will let them address the product's current shortcomings in a coherent, consistent way? Will they continue with seemingly ad-hoc programmed features that don't share a common design philosophy and continue to fracture the product into increasingly mismatched islands only nominally related to one another. Will Tableau address its shortcomings and adopt new functionalities adroitly and well, or will it leave the door open for the next disruptive technology that fills in the gaps?