Tableau Friction: March 2014

It's a common scenario: you connect to a new data source and when Tableau shows you the data in the data window you're presented with lists of Dimensions and Measures with technical names, not the nice human-oriented names real people would find useful and engaging. For example, you see something like "customername" when "Customer Name" would make more sense to the person using Tableau.

There are a number of reasons for this, among the most common being we're frequently accessing data that was never intended for analysis by non-technical people, and that even when we are the database folks are reluctant to use human-oriented field names. In the customer name example above I've run into the situation time and again where the DB admins are reluctant to, and in some case flat refuse to put spaces in the names. From their perspective this makes no sense; if nothing else, it would mean enclosing the field name with quotes every time a SQL query is written. In their minds, this adds up to an enormous amount of extra typing because SQL querying it the only way one gets at the data, isn't it?

So time and again we need to supply real-human names for the fields so that they're more useful in Tableau. I know there are some skeptics out there who scoff at the necessity, but there are couple of compelling reasons. It's easier for people to read the names when they're spelled using normal conventions – that's why the conventions are there, with hundreds of years experience behind them. It also makes a difference in Tableau vizzes, making it easier for Tableau to display the field name in frequently limited header space (this would be dramatically enhanced if it was possible to use markup in display names, but that another friction point, for another post).

What's the big deal?

If you don't like the field names, you can just go ahead and change them, can't you?
Yes, you can. But it's a tiresome, boring task that takes much longer than it should, and it's boringness leads to mistakes and unnecessary rework.

Here are a couple of examples of the same data source.

Technical Names

While not as obscure as some of the data sources encountered in the wild, this data source's field names are missing spaces.

Human Names

In this example, the field names have been adjusted to contain spaces between their individual names. It might not look like much of a difference, but imagine what it would be like if all the field names were the really obscure technical names assigned with strict adherence to IT database design standards.

Changing names—how it's too much bother.

Invoking the field renaming.

This diagram shows the process required to get to the opportunity to rename the field.

There are four separate actions needed:

Find the cursor. (it may not be where you expect it to be)
Sweep the cursor to the field in the data window.
These first two steps might not seem like much, but locating the mouse onscreen and then moving it to the field isn't a trivial action. The further away the mouse is, the more effort is required.
Activate the field's context menu.
There are a couple of ways to do this:
- clicking on the down-glyph to the field name's right selects the field and activates the context menu in one action; or
- clicking on the field, then right-clicking the field name takes two actions.
Navigate to the menu's "Rename..." option.
This example shows the option below the field name, but it's above the name when the field name is lower in the list.
Select the "Rename..." option.
Two ways: click it, or use the <Enter> key.

This is a lot of mouse-sweeping and selecting just to get to the point where we'll be offered the change to change the field's name.

The "Rename Field" editor.

Really. All the work done to get to this simple little one-field editor. Hardly seems worth the effort. (it's not)

And it's worse than it seems. Tableau always presents this editor smack in the middle of the screen, which means that the bigger the screen the farther away from the Data window it is, assuming that Tableau is normally positioned onscreen.

"Customer Segment" renamed.

Now the job's done, all nice and tidy, and we can relax.

But maybe it's not that simple.

What if we'd set out to rename all of the field names that need spaces added? If so, it would be really helpful to do them one at a time, top to bottom, to make sure that we got them all. A nice, organized approach.

It sure would be helpful if Tableau helped out in this undertaking. Little things could really help, like keeping "Customer Segment" selected in the Data window, showing us our last selection and making it easier to make the next.

But Tableau doesn't help us. In fact, for some odd reason Tableau unselects "Customer Segment" upon the name change, which makes no sense at all, and violates basic human factors and usability principles. Even stranger, if a field is selected, its "Rename..." option is selected but the name is not changed, Tableau keeps the field selected in the Data window. This doesn't make sense from a human standpoint and is an active impediment, and the different behavior upon rename/no rename is an active cognitive disruptor that generates confusion. The user gets the impression that Tableau is unpredictable and therefore untrustworthy and difficult to use.

Serial field renaming—an exercise in frustration.

Consider the situation where one wants to rename a series of field names. This happens quite a lot out in the wild.

One must go through this series of mechanical steps over and over:

Find the mouse.
Sweep the mouse to the field in the data window. (which field?)
Select the field.
Activate the field's context menu. (one or two actions)
Navigate to the menu's "Rename..." option.
Select the "Rename..." option.
Edit the field's name in the editor by: changing the name's text a submitting it via <Enter>; or selecting "Ok".
Find the mouse.
Move the mouse to the field in the data window.
Which field?
Surprise! Tableau unselected the last field you renamed so you have no visual clue as to which one it was, so you have to spend the cognitive capital to recognize and/or remember which one it is. This, coupled with the rote mechanistic series of operations is a horrible hodgepodge that creates real, and very substantial friction for the user.
etc. etc. etc.
Bored yet? Frustrated? Now imagine going around and around renaming a couple dozen or more field names. It's bad.

A Better Data Window

This data window improves upon the existing one by presenting both the user-facing human names and the internal/technical data source names.

The data names are on the right side, in the shaded zone, which conveys the sense that they're "behind the curtain" and not available for modification.

The human names are on the left side, in the lighter zone, and are editable. The rectangle around "Customer Segment" indicates that it is in an editable state, and that the user can rename it by simply changing its name in place. This is nicely simple and direct, a much better approach than the current renaming process.

It gets even better. Once the direct-configuration idea takes root, it's easy to imagine more of the field's characteristics being configurable in place. Obvious candidates are data type, formatting–notably for dates and measures, and measures' default aggregation. I'm seeing the field glyphs being used to trigger the in-place configurations.

Could this concept work? Yes, it could. There's no technical impediment, only the will to make improvements?

Is this the best design? Not very likely. This is a concept sketch, laying out one example of something that would work, and is a big improvement over the status quo.

An Even Better Data Window

Notice anything different about this Data window?

It might not jump out, but this Data window is a true independent Window, not a panel welded to the left side of the main Tableau application Window.

Freeing the Data window from the main Tableau Window's embrace has many real and substantial benefits. Most obviously, the Data window could stay open constantly, rather than needing to be popped up and down, which is a real pain, particularly given that the up/down toggle moves around sideways (itself a bit of vexation), and that it shares Tableau's left side with the Dashboard window and all of the formatting windows (and does anyone really know how many of them there are?).

I posted an initial bit on the desirability of scrapping Tableau's existing windowing architecture; it's a stub that I intend to keep working on, and the Data window is one of the top reasons I started down this path.

This is a bookmark post, I'll flesh it out later.

One of the very big frustrations of working with Tableau is the needless hiding, unhiding, and managing its various user interface components. The data window, dashboard window, and formatting windows (and there are far too many of them) all occupy the same real estate, and only one of them can be seen and interacted with at a time.

This basic architecture probably seemed like a reasonable idea when Tableau was created. The number of UI elements and zones was small and didn't get in each other's way too much. It was even probably good to have a fixed framework in that the user's attention could be focused on the analytical space without distraction. But those days are long gone and Tableau's UI architecture is now an impediment to accomplishing the things we really need to get done.

It would be much, much better if Tableau freed up the subordinate functional components so that they could be organized in ways that helped rather than hindered productivity. There are lots of examples of tools that do this well—I'll be adding some illustrative examples, mostly from a couple of my favourite tools: Inkscape and Paint.net

stay tuned, more to come

Sunday, March 23, 2014

Tableau 8.1 Keyboard and Mouse Shortcuts

Changing field names should be easier, and other Data window improvements.

Monday, March 17, 2014

Configuring Quick Filters Takes Way Too Many Actions

Tableau Needs a New Windowing Scheme