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.
Some examples:
- 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.
Here is another option:
ReplyDeletehttp://public.tableausoftware.com/views/Alternate
if you want to force Tableau to generate this. Yes it is a little fiddly, but it would enable a scroll bar, unlike your faking view.
Also, I am not sure I agree with your statement that "there is no reason that this placement can't occur".
The reason, as far as I can tell, is VizQL would need to be altered in some major ways to accommodate your ideal mocked up image. I would be glad to discuss my perspective with you, but it is much too long winded for a comment.
In short, with the way VizQL works I would have no expectation for Tableau to create what you mocked up.
Additionally, in my opinion, what you have mocked up is what "Reporting" software would generate, and I would not expect Tableau to perform that task.
Nice work, Joe. Your example doesn't have the vertical split between the bars and the dimensions to the right that mine does. But it's more complicated, requiring technical proficiency in data munging and a deep insight into how Tableau works.
DeleteMy 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.
My original statement is more nuanced than your quote. 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)
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.
Even so, I don't accept the idea 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.
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.
Some examples:
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.
I gained my perspective of VizQL from http://vadl.cc.gatech.edu/documents/5_Hanrahan_CNVAC-PatHanrahan.pdf and http://rogerking.me/wp-content/uploads/2012/01/infovis-paper-showme-vfinal1.pdf combined with years of trial and error, pushing Tableau to do anything.
ReplyDeleteI would not consider a Tableau a Reporting tool, because Tableau approaches data and the display of it very differently. Yes Tableau can make a view that looks like a Report, but it is not a Report, just an imitation of one.
> "Where's the bright line between what Tableau does and what reporting software does?"
Reporting software makes a table, kind of like a spreadsheet, a grid with columns of cells. Tableau draws marks on a Pane, and then arranges those panes into a Trellis chart that looks like a table. Tableau is overloading terms, effectively causing confusion, especially when the result looks very similar but does not behave or have built-in capabilities that are expected from Reporting software.
The result Tableau can produce can look like a report, but it is not a report.
You are correct the data-structure would not be limiting in any normal Reporting software, but is it limiting in Tableau, hence I used custom SQL to reshape the data to enable Tableau to create the view you are looking for.
> "Even so, I don't accept the idea 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"
We should have a discussion, a conversation; a comment is not the best medium for this.
> "The biggest differences I see between Tableau tables and normal reporting software"
A table in Tableau may look like a table, but it is not like a table in normal reporting software, apples to oranges here. I look forward to a conversation with you to discuss the details of this viewpoint.
> "Your example doesn't have the vertical split between the bars and the dimensions to the right that mine does"
I set them to None, if you want them, you can go to Format->Borders, and in the Column Divider section, right-click on Pane and select Clear from the context menu.
> "But it's more complicated, requiring technical proficiency in data munging and a deep insight into how Tableau works."
This is correct. I still believe that nearly anything is possible in Tableau with effort and know-how, that the data structure you connect Tableau to sets your boundaries, and if you can transform your data prior to Tableau, anything is possible. If it is desirable or efficient, is something else. If someone wants the display you mocked up in your image, Tableau is not the ideal tool to do this.
From my viewpoint Tableau was not designed to do this, and to make it easy for Tableau to make this, would require a fundamental change in how Tableau and VizQL works, and that is not something that I want. I really like how VizQL works, while I agree that it can be rough around the edges, adding friction with the user interface, the core of what VizQL is and does is exactly the solution that I want and need in my daily life with data, and I would not want to change the core of VizQL.
If this is what you want Tableau be able to do, to generate report tables, then I believe that would require another mode, something separate from VizQL, because VizQL is not for traditional Reporting.
Tableau can add all the friction that they want and I will continue to use their software, but if they turn their back on VizQL, then I will move on.
I love Tableau for VizQL, I put up with the friction of the Tableau user interface in order to take advantage of VizQL.
Please get in touch, I would be glad to share my perspective.
While there is a workaround (and I've used it), it's a limited one. For example, since Tableau only has global or per-sheet filters, the only ways to filter both worksheets at once are through Action filters or parameters, and both come with their limitations. If a dimension on a chart has a hierarchy drill-down and is expanded, that only happens in that worksheet and not the other worksheet, so they stop lining up. There's a workaround for this to use a parameter, but that adds just that more work in building the view. Also, if dual axes are used in the in-cell charts, getting alignments to fit and stay the same is painful.
ReplyDeleteI can see where Joe is coming from re: Tableau and reporting software, and at the same time I'm in the camp of wanting Tableau to enable what I think of as in-cell charting, for two reasons: 1) I want Tableau to bring their UX genius to the "reporting" I have to do, so I can say goodbye to Access and Crystal. 2) With higher resolution aka Retina-quality displays, our screens are approaching print resolution and with this kind of functionality we could much more easily create useful, data rich views. In my self-centered view of the world, I don't want Tableau's distinction between Measure and Dimension, or nitty-gritty details of VizQL to get in the way of me building the views that I want to build.
There's an Idea in the Tableau forums for this feature, here's the URL: http://community.tableausoftware.com/ideas/1181
Jonathan
Please post the measure in the middle suggestion on http://community.tableausoftware.com/community/ideas
ReplyDeleteAnd get your readers, colleagues, customers to vote on it...
Thanks Chris
This comment has been removed by the author.
ReplyDeleteHi, I've come up with a simpler alternate way of getting Measures in the Middle - http://public.tableausoftware.com/views/MeasuresintheMiddlePlacement-JZChewAlternate/ProposedPlacementofMeasuresinInteriorVizColumns
ReplyDeletePros: Sorting, exclusions and data extraction now operate at worksheet level.
Cons: Column widths identical. Manual aliasing inefficient with many-valued dimensions, though arguably this then precludes "Measures in the Middle" - dimensions become more relevant (ideally as hierarchical sets).
Happy to hear your thoughts.
Very nice work, C. I quite like it, and it'll be a really good new tool for the kit.
DeleteI've been doing a lot of pondering on what it'll mean for Tableau to work with hierarchical data, starting with a simple two-level master-detail relationship, working all the way out to multi-level, multi-path networked data.
In the simple situation there's a real benefit to being able to show the master level aggregate data separate from the detail level data, and I'm thinking that your technique might be a good solution, or at least provide the initial launchpad.