The Tableau Public-published dashboard "Proposed Placement of Measures in Interior Viz Columns" (below) illustrates one of my favorite alternate vizzes, shown in the "Measures in the Middle" worksheet in the top of the dashboard.
In it, the sums of the measures of interest are placed in the body of the viz, not hanging out way over at the right end, as is the standard Tableau layout.
There's a lot of value in promoting the measures to the more cognitively valuable left-hand side of the via, e.g. they're picked up more quickly in the standard visual scanning pattern; and they're closer to and thus more intimately linked to the Name as ID of the Dwarf to whom they belong.
Even though "Measures in the Middle" and "Measures to the Right - Tableau's Layout." contain the same data there's a very large visual difference between them the effect of moving the Measure's bars from the right side to near the left side is dramatic.
I had intended to write up some more about this (published it late in the evening). As luck would have it, Joe Mako commented with an alternate example worksheet that's visually cleaner than my faked-up dashboard. In responding to his example and comment I covered much or most of what I intended to add here. So I'm pulling it up from the comments to make it a little easier to see. But you should see Joe's example.
My emphasis is on how to make Tableau better by making it easy to do reasonable things. And I believe that liberating the measures' presentation from its current rightmost-only position in the viz is reasonable and valuable.
I wrote "there's no data-structural reason that this placement can't occur." and I stand by this.
There's nothing in the structure of the source data, nor in the structure of the data in the viz that precludes what I want Tableau to do. The elements on display are identical in my two views - they're all at the same level in the data hierarchy. (this is a simple case, because there's only one record per Dwarf, but the principle holds for multi-dimensional data that's aggregated to a common level)
Re: Tableau's VizQL foundation
I wish I knew how VizQL works. I don't. I've never seen documentation on it. Not a grammar, not a write-up, nada. One of the things that drew me to Tableau was its basis in a data management and presentation language, but Tableau has seemingly stopped promoting, even surfacing, VizQL as its underpinning.
I do know very well the original 4GLs that invented the data structuring and presentation space. FOCUS was created for exactly these purposes, and had all of the data-operational constructs necessary to access, organize, aggregate, and present data, some of which were much clearer than Tableau's analogs. Unfortunately, since it originated in the age of mainframes, COBOL reporting, and data processing, it lacked Tableau's deliberate central focus on data visualization capabilities. I've often wondered what the structural similarities, and dissimilarities, are between them.
I don't think that VizQL is somehow incapable of accomplishing what I'm asking for, either as-is or with a modicum of adjustment. I see no structural barrier for it, and think I see the shape of the problem domain well enough to be confident in my assessment. If nothing else, if VizQL isn't capable of being improved in this way, or Tableau is unwilling or unable to do it, it opens the door for the innovator who will.
Is this visualization, or is it reporting?Where's the bright line between what Tableau does and what reporting software does? I don't see one. Tableau is a data visualization product. Reports are data visualizations.
The biggest differences I see between Tableau tables and normal reporting software reports are things I consider to be deficiencies in Tableau and hope to see corrected soon.
- The strict left-right ordering of dimensions in the same row is a big waste of space compared to dimensional folding, with each succeeding dimension underneath and slightly offset from its predecessor.
- Strict sub-totaling for every most-granular dimension (when sub-totaling is on), even those with only one record. This is worse than useless, it dramatically increases the cognitive load on the user who has to sort out the true sub-totals from simple restatements of a single data value.
- Granular formatting of the elements; it would be extremely helpful to be able to provide richer formatting, with control over the individual formats for each structural element in the viz.