Here's a friction point that's pretty simple and straightforward on the surface, but whose reach and roots are surprisingly broad and deep.
General Principle
Whenever Tableau provides the ability to configure an element's property value it should provide a mechanism for the User to specify a precise value. The values the User can enter shall be subject to the domain requirements of the element being configured, i.e. of the appropriate type and limitations on value.
Specific Example – Viz Field Size
When configuring the Size for a field in the Marks card, the User should have the opportunity to enter a precise value in addition to being able to adjust the position of the Size control slider, which is the only current adjustable mechanism.
In the specific case of the Marks Card's Size control, Tableau only provides the horizontal slider, which isn't good for precisely specifying the size value. Contrast this with the Color Transparency configuration, which provides an numeric(%) input field along with a synchronized slider which enables a level of precision in specifying the Transparency value unavailable in the Size configuration.
This image shows the Color Transparency and Size configuration controls.
The inability of the User to precisely specify a numeric value for Size may not seem like a big deal—the slider lets you adjust the Size value simply and quickly.
You may think to yourself: "This is not a big problem, why make a fuss?"
I'm glad you asked.
It's simple: small variations in Size, e.g. bar widths have significant impacts in cognition. It's a primary reason we visualize data using geometric properties.
Suppose you have multiple renderings of the same base chart in a dashboard. It's important for them to be as visually consistent as possible so that variations in the data are easy to spot. With Tableau's current design it's almost impossible to ensure precisely the same useful Size configuration across the worksheets unless it's either the minimum, middle, or maximum value. (the min and max are the end points, the middle has a 'detent' feature)
This situation arose when I was creating a dashboard for a very particular client; in working with them even tiny variances caused hesitation and a "That's not quite right." reaction.
I ended up hacking the TWB to make sure that the individual size values were the same, but that's not a realistic solution for most people, nor should it be.
An Improved Design
This Size configuration design adopts the Color Transparency slider/input control combination. This provides the flexibility and specificity we're looking for.
There's the additional benefit of function/presentation similarity—having the same mechanism for configuring similar things eliminates the cognitive impedance imposed when the User needs to switch mental gears to adjust to different ways of doing the same thing. Since Color Transparencey and Size aren't simultaneously visible this is currently a subliminal discontinuity, which in some regards is more perplexing.
Input Constraints
Configuration inputs need constraints on the user-entered values to ensure that only legitimate values get applied. For example, it makes no sense to set the Size for a bar chart to "Guy Fawkes Day". Tableau Parameters implement a reasonable starting point for constraints. Examples of constraints include:
-
type, e.g.: numeric – integer, real, percentage, etc.; string; boolean; date & datetime
-
range, if applicable, including less then, greater than, from-to. not equal to, etc;
-
set of allowable values, either enumerated or data-dependent, including set membership, not in set; etc.
-
others (this isn't intended to be an exhaustive survey of constraint elements)
Existing configuration controls like the Size slider have the constraints built in—the User can't move the slider past either end so the Size value, and therefore the bars' width, cannot exceed the minimum or maximum values.
Example: Size configuration
The question is: "What should the Size value indicate, and what should its range be?"
As shown below, the minimum Size value corresponds to very narrow but visible bars and the maximum value correponds to bars whose width spans the full width of the row,
As shown above, the new Size input control is at maximum—100%. Whether sizing on a percentage scale is appropriate is a legitimate consideration, one that needs to take into account the full spectrum of potential Size configuration scenarios. But for now it seems reasonable that Size can be a percentage scale, with possibly a floor value of 1%—it's not clear whether or not the current
Current Size Range
This dashboard has three versions of the same chart, with the Size adjusted, in left-right order, to its leftmost (min), middle (mid), and rightmost (max) positions.
I've included the actual TWB Size values below the charts, as we see, the min value is slightly less than one percent, mid is precisely 1 and max is precisely 2.
About the min value: many of Tableau's internal values are odd in this high-precision fashion, which helps understand some oddities, but that's a topic for another post.
As we see here, the range of Size values is fairly limited, from slightly more than zero to two. It's not at all clear why Tableau chose this range, or whether it would be meaningful and useful to a User trying to configure Size—my initial feeling is that it wouldn't be.
A percentage range from 0-100%, or 1-100% seems like a good candidate Size range. It feels likely that a correspondence of zero to effectively an invisible point and/or one percent to one pixel (or whatever the size unit is) would provide a robust range, and the use of integers for the percentage values avoids the messiness associated with real numbers. It's also easy to accommodate values greater than 100%, although I'm not clear on whether this makes sense.
Extending Configuration Functionality
Parameterization
All configurable elements should be responsive to parameterized values which can be data fields, calculated fields, or Parameters. These values must conform to the appropriate element-specific constraints, .
In addition to its configuration benefits adding this functionality cracks opens the door to Tableau being able to analyze data it's currently unable to interpret and present. This data is variously called post-relational, non-tabular, NoSQL, etc. (I'm working on posts covering this.)
It also brings in the longstanding discussions about the relationship between Parameters and data, particularly the community's desire for Parameter values to be dynamically populated by the current data.
An example of this extension's value is in Axis configuration, where there are two levels of configuration and multiple configuration values. In the first level are the configurations for Automatic, Fixed, Uniform, or Independent row and column axes. The second level configuration values are Start and End for Fixed range axes; providing for data-based Start and End values provides the opportunity to fine tune data-sensitive presentations that are impossible with the current fixed-value configuration.
Expanded Data Access
Configuration Files
It would be extremely helpful if Tableau could digest common forms of configuration data, e.g. XML, INI, JSON, and YAML. Consuming these would provide the ability to establish common sets of configuration values, which could among other benefits be the platform for uniform styling and branding.
Configuration files are notably different from the data files Tableau was designed to work with. One major difference is that the config files are (roughly) organized around a parameter per line/element structure while data files are collections of records, each with its own value for each of the enumerated fields.
Tableau already consumes at least XML and YAML files. TWBs are XML and Tableau Server uses YAML for configuration information, so it doesn't seem to be that big a technical reach to implement their use for configuration information.
Data Analysis Consequences
Starting with Tableau's use of different data structures for configuration information, it's a relatively straight path to accessing these new data sources for traditional Tableau analysis.
But although it's a straight path it's not simple and trivial. There are multiple challenges involved, with subtleties, complexities, and consequences that make providing the necessary general data modeling and mapping of complex data to Tableau's analytical semantics a real and interesting challenge.
Simultaneous Multi-Element Configuration
This will be a big step forward. Providing the ability to configure a property for multiple elements at the same time will be a tremendous boost to Tableau Users' productivity, and to a lesser degree output quality. For example, it will reduce and in many cases eliminate the drugery and error-prone tedium of switching back and forth between multple worksheets and dashboards to make sure that they're consistent.
But it's not a simple and easy change. Tableau's not set up for this operational mode, and there are deep and serious implications that reach to the core of the mechanisms necessary for presenting the configurable elements and in providing sensible means to configure them.
The good news is that the mechanisms, models, and functionalities required to implement this ability are those required to model, manage, and analyze complex non-tablular data, so there is a virtuous positive feedback loop between this feature and accessing complex data for configuration and traditional Tableau analysis.
