Friday, July 19, 2013

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?

5 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Chris,
    When we place discrete (blue) pills on the Rows shelf, I agree it can look like we just made columns of data, but this perception gets in the way of understanding Tableau, and surly makes for a frustrating experience with Tableau.

    What happens when we place discrete pills on the Rows shelf is a hierarchy of Row headers is generated, a structure, a kind of scaffold. The marks are what we interact with, and they placed within this scaffold structure.

    This is a shift in perspective, one that does not match our expectations, it can feel different, inconsistent, and confusing, but if you are willing to consider another approach of working with data, Tableau can produce the results that you want without the frustration that you currently experience.

    I would love to talk with you, or anyone else who is frustrated with Tableau, more about this.

    ReplyDelete
  3. Hi Joe,

    What did the dimension member say to the measure?
    "I'm data, dammit."

    I think, at least in the case of the distinction between scaffolding (and I quite like that term, thanks) and "real" data I understand Tableau's orientation. And I disagree strongly with it because it's arbitrary and limiting and has real unfortunate consequences.

    Elevating the quantified values that are "mark"ed to a position of special treatment maybe made some sense when Tableau was brand new, but it has follow-on effects that negatively affect the broader goals of legitimate analysis.

    We do interact with the scaffolding fields - Tableau obliging shows us a tooltip and offers up the options of Keep Only, Exclude, etc. But we can't turn off this functionality, nor can we customize the tooltip, like we can with the "real" data's tooltips.

    I appreciate what Tableau does well and how it does it, but I don't want its virtues in that realm to be burdens otherwise. I see no technical reason why Tableau can't keep its goodness while correcting its problem areas. For examples: try as I might I see no reason why one shouldn't have the ability to configure the scaffolding tooltips; or why action filters and quick filters can't be rationally redesigned to provide complementary functional effects across dashboards.

    ReplyDelete
  4. Chris,

    I hear that you frustrated with Tableau because it does not work the way you expect it to. I have frustration with Tableau in other areas, but in the areas that you describe here, I do not experience frustration, and that is why I comment here, I would like to help you be less frustrated, I would like to help enable you to produce the legitimate analysis that you want without the frustration.

    I find that with greater awareness of how Tableau works with data, Tableau becomes an aid instead a burden when I work with the flow of VizQL instead of trying to force Tableau to work the way I expect.

    I agree that Tableau is missing the feature to configure the tool-tips of headers, it seems like an easy fix from the outside, but I suspect there are factors that we are not aware of preventing or delaying the additional of this capability.

    I also agree that filtering in Tableau is limited in some circumstances, but there are also many routes available. On the whole, Tableau is not endlessly customizable like a programing environment, therefore I primarily use Tableau as a prototyping tool.

    What is an example use case legitimate analysis that you find frustrating, or at least not expected effort, to create in Tableau?

    ReplyDelete
  5. Tableau as a prototype tool.

    A valid use of it, and one I'm increasingly embracing given it's inability to provide the meta functionality required for creating the polished, behaviorally rich analytics that are possible with a modicum of programming effort with other tools and technologies.

    But it's also in direct conflict with Tableau's corporate mission, which to all appearances is to maximize its market value by appealing to corporate interests as a viable end-to-end data analytical platform. In this framing Tableau Server is the market value maximizer since enterprise corporate budgets are almost bottomless, the margins on enterprise software are much, much higher than on personal tools, however useful in part because of the differences in support requirements, and one doesn't get the favorable Gartner and Forrester notices that generate market interest and valuation by selling personal productivity software.

    As to examples of where I find Tableau lacking, I refer to previous posts for starters. I also have quite a queue of topics in various stages of gestation that I haven't had the time to devote to getting into something resembling a coherent form. My hope is that I can get these finished and published pretty regularly in the next couple of months.

    A few things are worth mentioning here, though. The inability to create true box and whisker plots, bullet graphs, and sparklines is particularly vexing, the best one can do is simulate them in Tableau by leveraging features not really suitable for the purpose, and that's a common theme throughout the product that if not corrected speaks ill of Tableau's future. Not being able to present multiple visual types in a single scaffold (thanks again) so that I can show a sparkline, bar, and numbers for different measures in the same dimensional context is a real shame - using multiple worksheets in a dashboard to crudely simulate this is cheesy. Not providing a label when a dimension provides the text for a viz is eternally vexing and nonsensical. Requiring the use of parameters, calculated fields, and filters to implement straightforward functionality is a serious shortcoming.

    ReplyDelete