Friday, August 31, 2012

Discussing Table Formatting, Tableau Design,and Why Care?

This post carries on a discussion originating with this post: Tao of Tableau - Deciphering Tables #1 - Simple Features that got too long. (blogger only accepts HTML <= 4,096 characters). It started off continuing a thread that Joe Mako started with his insightful comment on that post and then it grew its own legs.

One of the things that I loved about Tableau right from the start is that it made analytical data access and visualization really easy and straightforward. And it got so many things so very right: drag-and-drop and double-click data organizing; using the right type of chart; highly effective color schemes; good data-ink ratio; and so on.

But Tableau, as good as it is, as much as a leap forward as it was, isn't perfect. There are some things that could, that should, be better. For example I've always thought that "Columns" and "Rows" aren't the best terms for the shelves, with "Across" better than "Columns", but there's no equally good simple alternative replacement for "Rows" ("Down" is close) as long as the shelf is itself horizontal, and re-orienting the shelf imposes its own UI space and usability problems. But I digress. A bit.

It almost feels like trivial and senseless grumpiness to point out what are in one sense minor blemishes on such a lovely complexion. But then again, they stand out because their surroundings are so clean and clear and good.

It's sort of like warts on a toad. Nobody cares about a particular wart on a toad because it's already full of them. Any particular wart is pretty much indistinguishable from its neighbors. (I know. They're not really warts. It's poetic license.)

But Tableau was hatched pretty much wart-free. So those it does have look and feel, well, warty when one comes across them.

The examples: "Naked viz" – the worksheet framing lines vanishing when displayed in a dashboard; and "2H Cell Table" – when the Column Dividers are set to "None" in a single Dimensional organization; are like this. In isolation not too bad, maybe even an OK choice for the particular case, but as the exceptions to Tableau's otherwise clear complexion they stand out like as oddities, anomalies. Warts.

About "Naked viz".

From a larger design point of view, the presence of the "Drop field here" flags and framing lines (hints) in an empty Worksheet are enormously helpful in alerting the User to actions they can take to achieve something. I very much like it.

The design breaks down in the larger context of the same worksheet's presentation in a dashboard. Worksheets and dashboards are different environments, and need different presentations. In one sense this discussion is about what the differences should be, and why they should be that way.

Tableau's Design Paradigm

Tableau Software has been very clear in their desire to provide a single environment for creating and consuming Tableau analytics. There are very strong and good reasons for this philosophy.

However, in not displaying the worksheet hints in a dashboard presentation Tableau is violating their basic premise of not separating development/authoring and consuming into distinct operational modes. Unless of course one considers that worksheets and dashboards are different environments, each with its own separate mode, in which case we're discussing what the different presentations of the same viz in the different environments should be.

Fair enough. (But it feels like a thin argument, and once there's a crack in the ice...)

Dropping the "Drop field here" hints in dashboard worksheet presentations makes good sense because there's no dashboard mechanism to add content to worksheets. If the functionality isn't there it makes little sense to hint for it.

I don't like the dropping of the framing lines because, to me at least, it says "there's nothing here", which is a very different message than "this is a place for a viz to be but there's no data being presented". (I wanted to say vizzed but that's pushing it).

There is a great deal of value in providing a consistent presentation for the same thing, to the limit of it making sense, across a product. One of Tableau's great attractions when it came out was that this pretty much held true. It continues to be pretty much the case for Tableau Desktop—in this discussion we're contemplating what differences make sense for a couple of specific cases. On the other hand, Tableau Server has far too many different presentation idioms for similar things; this makes it much less approachable, much more difficult to become proficient with than it should be.

I believe that there is a legitimate need for separating authoring and consuming activities, e.g. the authoring features of a dashboard are intrusive and annoying for someone who's only consuming it. And that opens an entirely different can or worms of another color.

About Smart Defaults.

I'm in full agreement with Joe about Tableau's double-edged nature. When it works, and the great majority of the time it works beautifully, it's a marvel and a delight. It's pruning off the warts that gets a bit vexing.

It really would be useful to be able to configure the smart defaults. It would complicate things, but if it were done smartly the burden wouldn't be too great. I can do a lot of this stuff today with hacking the XML but that is risky and grows wearisome.

Why care about these things?

As much as I love Tableau, and I really do, making my living as a BI/Tableau consultant, I'm aware that it's biggest danger is in becoming one of the products it disrupted. Its singular grace—approachability, usability, low friction, etc., is fragile and easily neglected. If Tableau doesn't take care and continue to expunge its warts, or if you prefer the sand in the gears, it will inevitably lose ground to competitors who are what made Tableau successful: being a faster, easier, less expensive, more effective tools for accessing, organizing, and visualizing data.


  1. I see development/authoring and consuming as two different modes.

    On the Worksheet, the display of the visualization is for dropping pills onto.

    When on a Dashboard, or when looking at a worksheet that is published to Server/Public, there is no way to drop more pills, so the mode is different.

    I fail to see why you think this is "a a thin argument" or what you mean by "and once there's a crack in the ice..."

    Two modes: create and view

    It just so happens that everything you can do in the view mode, you can also do in the create mode, and I think this is wonderful.

    But you can only do a subset of the create things in the view mode, specifically because you cannot drop pills onto the visualization in the view mode, the visualization displayed is different, the "helps" are removed.

    > "I don't like the dropping of the framing lines because, to me at least, it says "there's nothing here", which is a very different message than "this is a place for a viz to be but there's no data being presented". (I wanted to say vizzed but that's pushing it)."

    Are you saying you want to display the framing lines and "Drop field here" text in the view when you place a worksheet that does not have any pills on either/or the Rows/Columns shelf?

    On the worksheet, in create mode, it is clearly sending the message that there is nothing here, and tells the user that they should try placing some pills here. On the dashboard, there is no method for placing pills, and the result of there being nothing, is a blank view of nothing. So is is displaying the result of what the user created on the worksheet.

    Or are you saying that the framing lines and "Drop field here" text should go away, and never be displayed on the worksheet in create mode? That a blank gray empty screen is better because it is more consistent across modes?

    If so, I'll ask again, how would you answer the user's question "How Do I Get Started?"

  2. Now this is getting interesting.

    The last time I asked, Tableau Software's position is that they don't think there should be different modes for creation and viewing. Clearly this isn't strictly the case, and it gets muddy and murky. Worksheets in Desktop are truly the same things when creating and viewing; there's only one mode (unless you count presentation mode, which I don't). Worksheets in Reader are view-only, as is analytic content published to Tableau server.

    Dashboards in Desktop are odd-there's no separate view-only dashboard mode for the dashboard components; everything you do to create and manipulate the dashboard as its creator is exposed for someone who only wants to view it. This is one of the things that's annoying about dashboards - they're "creation-live" all the time in the workbook. But dashboards are also a view-only context for the worksheets they contain, with some limitations, e.g. a filter can be created for a worksheet from it's dashboard view. Which then begs the questions: "where is the dividing line between creation and viewing?" and "where should it be?"

    That there's a distinct creation/view context duality for Desktop worksheets depending upon whether they're naked or in a dashboard establishes the precedent that there is value in having the separate modes. So it's not a great leap to wondering why there shouldn't be separate create/view contexts across the board. Worksheets and dashboards could benefit from having view-only modes in Desktop.

    Re: "On the Worksheet, the display of the visualization is for dropping pills onto."
    I have to disagree with this. The purpose of the visualization is for displaying the visualization of the data that the user selects. There are multiple mechanisms for selecting the data, and the pill placement on the shelves is a technical implementation that is necessary but isn't the point.

    The current naked worksheet presentation, outside dashboards, is good for informing the user how they can get started with an empty worksheet. The "Drop field here" and framing lines provide useful action and structure hints.

    But when an empty worksheet is in a dashboard, it's more meaningful and helpful to present the framing lines for an empty worksheet. The positive signal that they provide, that "this is a place for data to go" (for inexperienced users)/ "this is a worksheet" (for the savvy ones), is better than a blank space, which requires the user to puzzle over. Even an experienced Tableau user faced with a blank space in a dashboard has no way to know that it's a worksheet, a 'real' blank spacer, an empty text field, etc.

  3. The goal of "No Modes" is a good cause, but it is clear Tableau is not mode-less.

    > Re: "On the Worksheet, the display of the visualization is for dropping pills onto."
    "I have to disagree with this."

    I see your point, I phrased my comment poorly. I should have said: On the Worksheet, the user can drop pills onto the display of the visualization. This is one route for getting pills onto shelves. This is the route that the "Drop field here" text is encouraging. I did not mean to discuss the purpose of the visualization.

    I think I see what you are saying in regards to wanting the framing lines to be displayed on the Dashboard, it would give you a clue that there are no pills in use on this worksheet.

    I believe the user can know what object is on the dashboard based on the context menu options, and when you place a Worksheet on a Dashboard, the Title defaults to on.