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.

Tableau Visualization Coloring - Under the Hood

Tableau introduced the effective use of color as a strategic element in data visualization. By promoting data coloring to a top-level concern, and implementing highly effective data coloring as the default, Tableau blazed a trail leading out of the garish wilderness populated by ill-considered and wildly discordant colorings that did little but, well, be colorful.

It's odd, then, that Tableau makes it extremely difficult to apply the same coloring to non-data elements as it does to the data. Coloring fonts, borders, and lines can be very frustrating. Harmonizing the color schemes for data and non-data viz elements is much more difficult and frustrating yet.

There are several main reasons for the difficulty in coloring non-data elements:

• Tableau uses at least three different UI controls for presenting the initial color palettes, this is because coloring is only a subset of formatting, and the controls include not only the color palettes, but the other formattable aspects of the viz element-see the "non-Data Color Palettes" in the Workbook to see the different controls. Having similar but different controls for a common function is confusing and imposes a cognitive burden upon the user to recognize and remember not only that there are different controls, but that there are different palettes in use. On top of this, it's very difficult to keep straight what is configurable for a given element since this can only be inferred by the content of the format control.
• There are two different and incompatible palettes used: a pastel palette for shading areas; and a dark palette for fonts and lines (lines include borders) — further, neither of these palettes is compatible with the data coloring palettes. All in all, matching colors for the different visual elements in a single viz is difficult, multiply so for an entire Workbook;
• Associating the viz elements with their components in the format property sheets is not obvious. Although not strictly related to coloring, this compounds the problem by making it very difficult to determine which element to color in order to achieve the desired effect.

The Tableau Public-published Workbook below illustrates the major components of visualization coloring. I hope that it helps clear up some of the mystery, that it helps you achieve the effects you want, and to hear from anyone who finds it useful or has suggestions for improvement.

Powered by Tableau

General Observations - Rough Notes

I've been collecting the following notes for a while. Rather than waiting until I get them all nicely organized with format examples and suggestions for corrections I'm just going to go ahead and drop them in here. Again, to be clear: they're just my raw jottings and I expect them to have lots of typos and such like.

Friction Points

Tableau Desktop
- Edit dialogs should accept <Enter> as "OK" (Submit) as default instead of adding a new line to the content
- the current model requires one to move one's hand from the keyboard to the mouse, move the cursor to the "OK" button, and then click on the button.
- this is really cumbersome, time consuming, and annoying
- it's a common convention to:
  -- use <Enter> as "OK" and <ctrl>-<Enter> to enter a new line;
  -- <ctrl>-<Enter> as "OK" when <Enter> adds new line;
  -- configure the <Enter> and <ctrl>-<Enter> behavior
the existing Tableau text editing dialogs do none of these


Tableau Desktop
- when duplicating a map and changing it to an area map, the map changes dimensions, this makes it very difficult to create two versions of a given map for comparison purposes

Tableau Server
- adding Project to site
- permissions show "inherited" even though the Default Project's Permissions are explicitly set to "Allow" or "Deny"


Tableau Server
- The "Check user permissions:" pull-down list shows "Guest" as an option, when there are no Guest Users in our Named User Tableau Server installation.

Tableau Server
- Creating a Site creates a Default Project for the Site
- I'm not sure that this is documented anywhere, my expectation was that there was one Default Project for the Server installation
- the new Site's Default Project does not inherit the original/existing Server’s Default Site’s Default Project's Permissions, which is contrary to expectations


Tableau Server
- sometimes deleting a Site other than the one you're currently "in" bumps you out to the "Select Site" chooser.
- Sometimes it doesn't.
- there also needs to be a better Site-switching mechanism.

Tableau Server
- there appears to be no way to reconfigure who has the Add/Manage Users permission for the Site after the Site's creation; this functionality should be configurable by System Administrators for the lifetime of the Site.

Tableau Server
- the entire Permissions mechanism be deterministic from an internal programmatic perspective, but it’s nearly impossible to decipher from the perspective of someone trying to use configure the Permissions and predict, observe, or understand the Permissions in place for any given User for any given piece of content (and the question of what content includes is open).
- As near as I can tell, the only way to have any predictability to what the Permissions will be for is to construct the Permissions for the Server's default Project, then the Default Project of Sites as they're created, then create Groups, then check and assign individual Project's Permissions upon Project creation, then check Permissions upon individual Workbooks upon Publishing… etc., etc., etc.
and where does the interaction between Users and groups come into play?
- I've spent quite a bit of time trying to puzzle this out, and every time I think I have a handle on it I see something that doesn't fit the model I've built up.
This entire Permissions model needs to be reworked into a form that is:
- understandable
- predictable
- transparent
- easy to manage

Tableau Server
- publishing downloaded Workbook that's been saved to new name provides old name in Publishing dialog.
- the name provided in the Publishing dialog should be the local Workbook name, not the previous server Workbook name
- the user's intent in saving the Workbook to a new name is to make a new Workbook with the new name
- publishing a revised renamed workbook back to the Server with the old name overwrites the old Server workbook, this is a big risk of unintended alterations to the old/original published workbook

Tableau Server
- Add User page
- Active Directory authentication
- success and failure messages appear in different locations
  -- Success message is at top, failure message at bottom of page; it's easy to overlook the failure message if one errs in entering the User ID
- successfully added User does not show up in the Users list, it should

Tableau Server
- User relationship to Site
- the Site switching mechanism is extremely confusing and counterintuitive
- The whole concept of being logged into a Site should be revisited.
- There's no obvious compelling reason for there to be a "I'm -in- this site" concept.
- The only thing I see about why someone needs to be -in- a site is that the License Level, Admin, & Publish config can vary per site, but this is manageable via other means, and this mechanism should be part of Tableau's core information management paradigm.


Tableau Server
- Installation directory shown in dialog doesn't match actual, i.e.
- says: Tableau Server 7.0
- is  : Tableau Server\7.0


Tableau Friends and Users Group - LinkedIn
Impressed with MicroStrategy's response to Tableau
http://www.linkedin.com/groupItem?view=&gid=118463&type=member&item=130065376&qid=5bf629e2-94aa-4ac9-b4a5-c08287495652&trk=group_most_recent_rich-0-b-ttl&goback=.gde_118463_member_128471878.gmr_118463
- interesting stuff here

Tableau Server
- in general the overhead configuration bar in the UI is neat and tidy but it's not as informative or useful as it should be.
- When the User wants to configure the properties of an object they should be informed of the full members set of options available to them; the current implementation only surfaces them when they click on the link, and then only in a pull-down menu which only shows the members available for selection, not the ones already in effect.
  -- exception: "Tag",         shows list with current tags and an "Add..." link
  -- exception: "Permissions", shows current with "Add..." link
- a better UI would be to use the element as a filter and show the complete member set in situ with indications of which ones have been selected, which not, and a way to select and unselect them in context.


Tableau Server - changes to the internal state should be pushed to the surface rather than requiring a refresh activity by the User.
e.g. if I'm looking at a Site's Data Sources in my browser, don't see the one I'm looking for and then go to Desktop and publish it I should see it upon switching back to the browser.
There is, I believe, no technical reason for not doing this - push to browser has been around for quite some time.
There is an argument that it would create User expectations for push across the product line. There are consequences to surfacing this behavior in on place, mostly that people would expect it across the board, which might be very difficult to pull off. Still, employing the push model when possible is better than not, and user expectations can be addressed.

Tableau Server - publishing to a Site other than the current one requires logging off and then back in.
This is clumsy, and after the first publishing event it isn't obvious to the User that they are in fact publishing to that Site on subsequent events.
There should be a Site-context switching opportunity during the publishing process.

Tableau Server - configuring caching, need explanations of different options, esp. how long is "as long as possible"
Not sure if this is documented, but it's important and a Help link in situ would be really helpful.
General principle: need Help access from everywhere.

Tableau Server
- Add New Site: Site ID should auto-adjust to reflect Site Name
- currently contains "site99", which is technical, not human
- is this just a programming oversight, or is there an underlying reason for it?

DATA SOURCE / DATA CONNECTION
-----------------------------
Tableau Server - There appears to be nowhere to see what the Authentication configuration of a DS/DC is.
--
A downloaded Data Source published with embedded password loses the password when it's opened in Desktop; this might be difficult to address, and it brings into question the whole notion of credentialing and security.
--
Confusing nomenclature - Data Source/Data Connection
Are they different, if so how? There's a lot of confusion about what they are, how they're useful, how they're similar and different, and when you'd use one versus the other.
- publishing a workbook with an existing Data connect/extract produces message ~"data source exists, replace?" - what's a data source here?
- from Desktop with a data connection you can:
  -- "Publish Tableau Server..." - which adds it to the Data Connections on the Server
  -- "Add to Saved Data Sources" - which creates a TDS file.
  ** When is it a Data Connection and when a Data Source?
- I published a Data Connection from Desktop to Server, once there it shows up in the:
  -- "Data Sources" list
  -- "Data Connections" list
  ** This is hugely confusing - is this thing a Connection or a Source?

Inconsistent data presentation
- the results returned by a successful search in Server's search box are presented in a very nice format.
  This format, however nice, is very different from anything one can create as a data visualization in Tableau Desktop, and is similarly very different from other information presentations across the products.
General Principle: all data presentations should conform to a consistent model, and should all be capable of being created by the Tableau User for their own purposes.
There are multiple sides to this:
- the products should be a case of Tableau eating its own dog food
- the products should limit themselves to presentations achievable by Tableau Users of their own data, for their own purposes
- if there's a presentational model that is required for the product, one that is highly advantageous and desirable, the ability to create that presentation should be cooked into Desktop as soon as possible.
--
Examples
- Tableau Server
  -- : Maintenance page
=============================
Tableau Desktop
- Adding Tables dialog should offer way to filter table names to help find the table(s) to use in constructing the joins
  -- when connecting to a database with many tables it's quite a chore to locate the table name you're looking for


The language of Tableau
In general, Tableau documentation, and the Products themselves, assume a common body of knowledge that the great majority of Users are not going to share.
--
No Glossary - references to things that are not explained
Server: ownership, content, asset - encountered in the past 2 days.
Server: in the sidebar, "This Site:" means a specific thing that almost certainly isn't what the User thinks it is.
Desktop: the whole formatting model assumes that the User knows what the different parts of the view are, but there isn't a real course of this information, leaving the User to puzzle out what's what from poking around, trying things, and seeing what happens, at which point they can deduce: "this says it's the [format item] for [this thing] and when I change it I see that [this visible change happens] to [this UI element] so I conclude that [this UI element] is a [this thing]
This is a huge burden to place on the User when it works well, and it very frequently doesn't work well.
There are many ways in which this inference chain can break, e.g. when changing something has no obvious visible effect.
And even when the correct conclusion is reached it's often of little value because the very thing that makes it difficult to see the causal chain - the awkward, confusing UI model for configuring UI elements - makes it very difficult to reorient oneself to the location where the change was made. This is a frequent occurrence with people who haven't already grokked Tableau, the sensation of having accomplished something interesting and valuable without knowing or being able to recreate the actions sequence that you undertook to cause the thing to happen.
--
Data Blending:
  -- "...one of the common dimensions from the primary data source to the view."
     but "primary data source" is a term that hasn't been defined, and is not subsequently defined on the help page.



Tableau Server - previews should include embedded Web pages, esp. when they refer to other views of the Tableau Server - these images already previews already exist


General Principle: remember the User's selections unless there's an extremely good reason otherwise
--
Publishing to Tableau Server
- Tableau should remember the last options chosen, e.g. state of "Include External Files" checkbox
- Tableau should remember the tags provided esp. within the same session
--
Tableau Desktop
- Should remember previous options configuration when publishing to PDFs, particularly when publishing the same viz-it's extremely annoying to have to select the size and orientation every time you publish the 35 or more versions of the view


Tableau Server - Deleting Users may not be what you think it is.
Deleting Users only completely deletes them if they hadn't published or created anything
so if they publish you can't fully deleted them
but if you delete everything they publish or create, e.g. a project then they are cleanly deleted
--
It's the same with taking away permissions
if you give a standard user content permissions
and they publish
you can't fully remove the permissions
until you delete everything they publish
and then you can remove the permissions
which seems draconian
exactly
hence my panic about permissions and the production environment
I have tested this a little today and from what i can see that is the case
now maybe on our call tomorrow we can check a few things around that
--
General Principle - there should be a server dashboard within which it's possible to what the relationships between the content elements are.



Tableau Server - the navigation among Sites, Projects, and Workbooks is awkward and counterintuitive.
--
Example
Use this sequence:
- log in to Tableau Server, select a site
- select "Admin | Server | Sites" - TS shows a list of the sites
- select a site from the list - TS shows the "Site: [selected site] page", which shows these links:
  -- Workbooks (n)
  -- Data Sources (n)
  -- Groups (n)
  -- Users (n)
  and in the sidebar are these links under "This Site"
  -- Users
  -- Groups
  -- Projects
  -- Data Connections
In the two lists of Site links:
  -- Groups and Users are in both, although ordered differently
Navigation
  -- the sidebar links are to the "current site" elements
  -- the "Site: [selected site] page" links go to the [selected site]'s elements
This is inconsistent and confusing, on many levels
 

Tableau Desktop - multi-click on sheet names doesn't select the full name for editing after first click. This results in an awkward series of clicks trying to get the name selected, then falling back to the keyboard for manual editing.

The Tableau Server Select a Site presentation should provide links, requiring the User to select one and then press the OK button is a mismatch in a Web hyperlinking world, and out of mode for most of Tableau Server.
There are many instances in Tabeau Server where seleting options in lists navigates to the linked-to location.
This should be standard - also applies in navigating to Sites, Projects, etc.


Tableau Desktop - saving a data connection to a tds file.
The option is "Add to Saved Data Sources..."
Data Sources and Data Connections are different things (but it's not entirely clear how and why), so the label stating that a data connection will be saved as a data source is misleading, and confusing.
There's quite a bit of confusion surrounding data connections and sources, Users are at some level aware that there's a distinction, but it's not obvious, and this muddies the water.
Larger principle: clarify and describe the natures of data connections and sources, their relationships, and areas of applicability.



Different presentation of authentication method when publishing Workbooks and Data Sources to Tableau Server.
- Publishing a workbook - authentication accessed via a button, so is hidden one layer deep
- Publishing a data source - authentication available in drop down in top section, 3rd component down.
Having two structurally different presentations of the same functionality is problematic - multiple reasons could be cited.
Basic principle: same/similar functionality should have same/similar presentation.


Publishing Data Sources and Connections
- Table structures are lost
- Global filters are lost
- Renamed fields retain their new names - this is good
- connection dialog solicits connection information, it's looking for database connection uid/pwd, not Tableau Server uid/pwd but this isn't clear from the dialog's messaging
- published data sources should default to the embedded credentials specification provided when the Workbook was published, if any. And vice versa. (don't know if it does this, but I suspect not)


Desktop
There really should be keyboard access to the right-click menus in lots of places.
e.g. when renaming a number of fields' name, it's really unhelpful to be waving the mouse around right-clicking, selecting "Rename" from the menu, then pointing to the next field name.
It takes a lot more time, energy and effort to constantly repoint with the mouse than it would to be able to navigate through the fields and renaming each as you go.

Switching Sites in Tableau Server should be a top-level action.
It happens as a side effect of selecting one of the options displayed in the Site: [sitename] page.
This is unexpected.
It makes much more sense to switch sites upon the selection of one from the Sites list than the current behavior.
Best would be a consistent mechanism for switching context across Tableau Server, and that should be a web implementation of the cross-products Tableau interactive model.


In the Tableau Serve admin guide section: Enabling Access to the Tableau Server database
there are these steps:
1. Open a command prompt as an administrator and type:
2. Next, use the following command to enable external access to the database...
3. Restart the server.
...
Step 3. says to restart the server, but where is the instruction to stop it?
Must the server have been stopped before this process began?
What happens if the server is running during steps 1. and 2.? Anything? Nothing?
Even assuming there's no difference between the server's running/not state for steps 1. and 2. this ambiguity opens up a lot of uncertainty on the part of the user.
And, in any case, how is one to restart the server?
Is there a restart command or is it the "tabadmin stop" - "tabadmin start" sequence?
Either way, steps 1. and 2. have their tabadmin commands specified, why not step 3.?


Data Connections and Data Sources need to be clearly identified in Tableau Server.
They are displayed together without any means to determine whether which one a given object is.

Tags on published Workbooks should be comma delimited.
The current space delimiting prohibits two- or multi-word tags, requiring underscores for them. This is an inconvenience and an imposition upon the user, favoring programmer expedience over usability.

Publishing a Tableau Workbook - show selections
The Tableau help doc says: "When this option is selected, any selections you've made in the workbook will be published to the server"
The problem: there's no definition for selections to be found (easily), so there's no way for the publisher to know what effect this will have, aside from experimenting. And experimenting to determine what a feature/function is and how it works is an inefficient and error-prone approach.

General principle: Tableau should provide clear and meaningful descriptions of the parts of the product.
There are many, many examples of things are dumped into the product, and the doc, without a proper explanation of what they are, how they work, and how they relate to other things.
Examples:
- Selections - they may be preserved when publishing a Workbook, but what are they? see above

Republishing a Workbook to Tableau Server should preserve tags.
Requiring the User to remember and provide the tags upon republishing is not good.

In general, there's no way to easily construct business-oriented data connections that can be created and shared.
All of the existing methods are deeply flawed.
- Saving connections to TDS files does not store their filters.
- Saving/opening workbooks doesn't preserver the global state of Global Filters, although it does preserve their structure and members
- Publishing Data Sources to Tableau Server and then downloading and using them strips off the table structure, flattening the field into a single namespace

Bookmarks - data connections accompanying bookmarks need to retain the global state of their filters.
This is likely related to data connections losing their global filters when they're persisted to tds files or published to Server.

Need to be able to configure bookmark to embed password.


Formatting objects in Tableau Desktop is awkward, counterintuitive, and needlessly frustrating.
see:
When the User is formatting objects in Tableau Desktop, selecting a new object should switch the Format window to adjust to the new selection.
This is the expected behavior. Not doing so leaves the state of the workspaces in conflict.
Second best would be to close the Format window when the User switches selects a new object to work with.
The way it actually works is no better than the third best approach.


Sometimes the Format Shading option presents a slider with a %scale, sometimes it doesn't.
- Does    : Dashboard Title (right-click select) "Format Title"
- Does not: Dashboard-embedded Worksheet
            - right-click Header select "Format"
            - right-click Pane   select "Format"
The inconsistency is frustrating.
In this specific case I want to apply the same color to the background for a Dashboard Title and the background for a worksheet presented adjacent to the Title. It's very difficult to match when the Title uses a slider-adjusted color.

Color specification is inconsistent.
See above.
Using the shading slider control affects the displayed color in ways that have no apparent match for color specification in the absence of the slider.



It would be very, very helpful to be able to spec a filter without constructing it through the UI.
- When dealing with large and/or slowly responding data sets waiting for a view to be populated so that members of the view can be selected for use in a filter can be very frustrating.
- It's possible that the business values for a filter are known even when they may not be present in the data, so selecting them from a view isn't possible.

Show a positive indication that there's no data to display in a view.
e.g. when there's no data to display Tableau currently displays and empty view, instead of a signal to the viewer that there would be data shown if there were any, but there's not.
There are different kinds of empty views, reflecting the distinction between structure and content.


Tableau Desktop should display global filters for a data connection when that connection is selected
- the current practice of only displaying the global filters when the data is actually being visualized inhibits the management of data connections as top class objects
- when trying to create or edit a business data connection

Tableau Desktop - Menu system
- sub menus should get activated when item in parent menu is selected, e.g. Worksheet | Extract should activate extract options, it shouldn't take another keystroke to do it


Data sources and Extracts
- although it's not clearly documented, data extracts can be published stand-alone to Tableau Server, just like Data Connections can


Aggregating data extracts is not well documented and implemented.
- there is no real description of what data aggregation is or how it works, only a couple of descriptive use cases of "do this then that then this" and your data will be extracted. If the user is not following the specific use case model their data may well not be aggregated when they think it should.
- the key to data aggregation appears to be "visible dimensions", but "visible dimensions" are never defined or described. Their definition is only vaguely hinted at, implied in that they are not hidden when the User selects the "Hide All Unused Fields" option in the data window.
- the use case for employing data extracts is implicitly restricted to those circumstances where it's advantageous to restrict the data volume for efficiency/performance purposes.
  -- this may well have been the case in early versions of Tableau where someone would construct narrow vizzes with a small subset of the data and create and aggregated extract that would be much more performant than accessing the original data source.
  -- however, with the advent of the new data extract engine (in v6?) the use cases for using extracts are much broader; Tableau has encouraged people to use extracts much more broadly than in the past because of the performance on the new engine
  -- in these circumstances it's much more likely that people will want to use extracts that contain all of the original source fields, maximizing the analytical opportunities provided by the extract
  -- in which case, since no fields are hidden, aggregation is meaningless since there's nothing to aggregate up to, unless there are multiple records for a unique combination of the dimensions' members - which brings up the question: would aggregation work here?
-- in the general case, if it's true that aggregation is only conducted when dimensions are hidden, then if no dimensions are hidden the "Aggregate data for visible dimensions" option should not be presented.



Parameter - need to let String value be blank
- currently chances to (Blank)
- a calculated field can have single space value, why not a param?




Database Connection dialog needs to be resizable
- it's hard to see things when names get long
- only 3 table names fit in the window
- table names should retain the order they are added in, the list sorts them alphabetically


Duplicating Worksheets
- function should be in menu system & keyboard accessible
- when duplicating a map sheet the Map Options card hidden/visible card state should be respected

Tableau Server - Add Site
http://onlinehelp.tableausoftware.com/v7.0/server/en-us/sites_intro.htm
The Content and System Administrator Roles
The "Add New Site" dialog does a poor job of surfacing the information that the "Add Users:" option configures whether or not Content Administrators can add Users.
Since System Administrators will always be able to add and remove Site Users, the only real choice here is whether Content Administrators will also be able to.
Solution: redesign the dialog to:
- Communicate essentials
- make the "Permit Content Admins to add and remove Site Users" choice a toggle - yes/no, on/off, etc.

Remember User ID and password between publishings to Tableau Server
- or at least provide the option to remember them

Tableau Server - see User details shows differently depending upon which link is used
- from the Administration | All Users list, clicking on a User name shows table with Site, Last Login, Admin, Publish, Workbooks, Data Sources
- from the This Site | Users list, clicking on a User name shows a page with the User's fully qualified name and sections for Workbooks, Tags, and Comments
= presentation should be consistent where common, i.e.
== Admin | All Users - User info should show fully qualified name

Highlighting sheet/dashboard name awkward
- difficult to highlight full text, particularly with multiple words
- initial click works, but subsequent multi-clicks do not

Need menu option to duplicate sheet
- was there in pre-7.0, when it was removed from the menu system
- alt-e,h is much easier and faster than moving the mouse to the sheet tab, right-clicking and selecting "duplicate sheet" from the menu

Local installation of Tableau help does not provide the location of the installation, nor how to access it.

Tableau has no mechanism for managing hierarchically organized data, and hierarchical relationships are pervasive

Tableau Desktop
- does not reveal the Workbook file system location

Tableau Server
- Workbooks presentation is awkward - goes through filtering page, e.g. shows a link for each year during which a Workbook has been published
- this is contrary to standard approach, which shows content with filter, not filter-then-content

"Connecting to a Custom SQL Query"
Is this true and/or meaningful?
It implies that there is an existing SQL query external to Tableau that Tableau connects to.
The truth is (as I understand it), that Tableau uses the custom SQL query to pre-select the data, and this preselected data is then queried with the view query.
So it seems more appropriate to title this:
Connection with a Custom SQL Query

Tableau Desktop
- Closing a Data Connection clears worksheets using it.
- this may be valuable as a means to bulk-clear a number of sheets, but the erasure of existing worksheets is a powerfully negative side effect in most cases
- the "Close" operation could/should:
  -- be limited to severing the connection to the underlying data source, preventing additional querying of it
  -- preserve existing Worksheets referencing the connection, with their current data displayed, but absent the ability to refresh the data

Understanding Data Blending
In the help system, the 2nd para begins:
  "To integrate data, you must first add ..." - it should begin with:
  "To blend     data, you must first add "
- using "integrate" here is confusing.
===
further, the same sentence ends:
  "...one of the common dimensions from the primary data source to the view."
but "primary data source" is a term that hasn't been defined, and is not subsequently defined on the help page.
--
Solution: define primary and secondary data sources
- Note: there is a description of primary and secondary sources, but it's in the "Adding a Secondary Connection" help page, where it's buried below the necessary level of awareness,

Calculated fields builder
- double-clicking a formula in the list should:
  - insert a complete formula skeleton into the code area, including place holders for all parameters
  - keep the formula highlighted in the list, with the attendant explanation; the current behavior abandons the list, leaving the user in the dark, when there are multiple params there's no way for the User to know what they are
- the various dialog lists should be resizeable, it's hard to distinguish fields with similar leading characters
- improve the documentation,
  - explaining the parameters, e.g.
    - CONTAINS - identifies 2 params 'string', 'substring', but the User is left to infer which is which
  - CASE: lay out the example code in a structired format, e.g.
    CASE <expr>
      WHEN <value1> THEN <return1>
      WHEN <value2> THEN <return2>
      ...
      WHEN <valueN> THEN <returnN>
      ELSE               <returnN>
    END

Calculated fields:
- CONTAINS formula is case insensitive - should be case sensitive
- COT example is confusing: COT(PI()/4) = 1
  - the User has to know how to interpret PI()/4 as a number
  - should have the form COT(num) = result - using appropriate num and result values
- DATE(expression)
  - what's a date expression?
  - what's a legitimate date expression?
  - there's no readily accessible description of what legitimate data expresssions are
 

Tableau Desktop
- Tableau needs a full set of data calculation formulae to match the ones it uses when configuring date through the menu system.


Data Access
- Excel and CSV data connections do not honor trailing spaces in data values - they get stripped out.

Functions
- String functions are asymmetrical in handling terminal spaces, i.e. STARTSWITH recognizes leading spaces, ENDSWITH does not recognize trailing spaces.
- DATE fields - need to surface the information on "date_part" in the calculated fields documentation, at a minimum identify its location, a hyperlink to it would be really handy

Tableau Desktop
copy/pasting content into text dialog inserts extraneous trailing new lines.

Tableau Desktop
- number formtting
- inconsistent number formatting - varies according to data source, not data content
e.g. Dwarves data loaded from CSV is integer, pasted from HTML is 99.99 format
- same data, should be the same format, i.e. integer
- lack of a dedicated integer format for numbers; would make a lot of number handling much easier

Tableau Desktop
- duplicate worksheet command removed from menu system

Tableau Server
- order of elements in Server admin window inconsistent (elaborated on in prev post)

Tableau Desktop
table border vanishes when adding content

Tableau Server & Tableau Public - 2 servers, 1 connection

Tableau Public login should be able to remember, or at least offer to remember, your login ID & password

Tableau Public should offer the option to set display options, at least sizes - it's highly likely that someone viewing a published viz will want a different form factor than it was published in.

Tableau Public -
 - "Save To Web as" Show Sheets as Tabs
 - "Save to Web"    - doesn't offer "Show Sheets as Tabs" option
multiple problems
- "Show Sheets as Tabs" option hidden from view for people who practice good workbook hygiene
- "Save to Web" has a keyboard option, "Save to Web as" option does not.


Tableau Desktop
No vertical alignment option in Dahboard text objects