4 of 4 people found this helpful
Oh, I left out the fact that I am aware of how dimension hierarchy inhibits sorting in Tableau.
My real point is that I believe this is a major design flaw.
When I, and every user I’ve met, encounter a grid of data with sorting capability, I assume the rows can be sorted. Call me crazy.
I rarely, if ever want to sort within a single category. I just don’t understand the logic behind this approach.
Tableau's sorting behavior is definitely not consistent with the expectations established by software like Excel and Access. The quick sort is still a fairly new feature and I imagine there are kinks to be worked out. For example, while I can get Tableau to sort the way I need it to, my UX design hackles are raised when the interface gives me the quick sort option and it does nothing. Given Tableau's sorting behavior, I'd rather the quick sort came and went rather than be there and not be usable.
I don't understand the why's of this, maybe someone like Ross Bunker can chime in?
1 of 1 people found this helpful
Jonathan I'm with you on the hackles! One note, I was reading the 7.0.6 release notes and found this:
- The quick sort options were incorrectly available in the toolbar when table calculation headers were selected. These fields can be manually sorted but computed sorts are now correctly disabled.
Good to know Tableau shares our outlook, and seems to be trying to sort out the sort issues
Completely agree with you guys regarding the UI/UX issues this creates for the typical end user.
I also realize that there are several workarounds an experienced developer can do to force the sort one would expect.
But I'm more concerned with yet another situation - that encountered by the basic Tableau Desktop developer.
I support users/developers who are not programmers in any sense. They only want to leverage the intuitive power of Tableau and create meaningful interactive analysis without having to program - you know, the main selling point of the product.
When I tell them you have to use parameters and complicated, non-intuitive table calculations to provide basic sorting functionality, they - understandably - are nonplused and annoyed.
10 of 10 people found this helpful
Hi George and Jonathan,
The short answer is that we know the current sorting behavior is frustrating in some cases, but we don't have a good solution to the issue yet. Read on for more gory details.
Jonathan, George mentioned the cause for this briefly above. The issue here is nesting (hierarchy inhibits sorting as George put it). When you sort by Date in this example, it is sorting by Date 'within' each of the previous groups (in this case Username and Project). Since each user only looked at the viz once in this data, sorting by date appears to do nothing. In fact, we are sorting a single date, so there is no noticeable effect. So that's why it behaves the way it does and as I mentioned, we know this is not what people expect in this case.
Now, the question is, why don't we change it? :-) Basically, the answer is that we don't know the right fix. The problem here is that in general (not this specific case), Tableau always nests. Displaying nested relationships has a lot of analytical value (we also know that people would like the option to not nest, again, we are trying to figure out the right way to do that). When nesting, there are times when you want to have sort behave the way it does today, and times when you want it to 'break' the nesting and sort the way you expect in this case. The problem is that we don't yet know the right way to support both, thus, we only support the nested sort.
An argument can be made that in this case, since there is no actual nesting going on (i.e. only one Date per username), we should know to perform the 'breaking' type sort. But now, imagine that this list of users is very long and at the very bottom, there is one row that has two dates for one user. Should that change the behavior? Do we need to count the number of nested vs. single rows and have a threshold? The fundamental problem we run into if we try to be too smart is that we are no longer predictable. "Sometimes it does what I want, and other times it doesn't!" I would say that Tableau already has too many of those situations (and I suspect many forum posters agree). Predictability is _very_ important to us. It is far better to have users be consistently frustrated and given a workaround, than for users to be confused. Confused users are often even more frustrated and may not even ask the question thinking that it is something they are doing wrong.
It is particularly unfortunate in this case because the view in question is one we have authored. In this case, we judged that the principal information in this viz is the user. But you are wanting to look at it by date. If nothing else, we really need to do something to address this very valid use case.
Bottom line is, we hear you. I mentioned this to Jock Mackinlay, our director of Visual Analysis and his first words were, "Oh, I know, that drives me crazy!". It's on our list of things to address, but we're trying to figure out how we can do the 'right thing' in the right way. Small comfort I know, but there are a ton of little things like these. We take them all very seriously. I'd recommend adding it to the Ideas page and voting it up if you want to raise the visibility (i did a quick look and didn't see it there).
Thanks for the feedback and sorry I don't have a more satisfying response,
Thanks very much for the open and honest explanation. Just knowing you guys are thinking about and working on this issue is really all I need to hear.
Thanks again for the response and all the hard work,
1 of 1 people found this helpful
One obvious solution that comes to mind is to create a new, additional view called, Data Grid. This would be different from the current Data Table view in that it would not be nested - each dimension would be repeated for each row. This view would behave more like a spreadsheet.
This would give developers two distinct options rather than you trying to cram every possible approach into one view, which is impossible to do well, as you described.
But I'm guessing you guys have probably already considered this.
Thanks for (another) thorough explanation! I really appreciate how you not only explain the "what" and the "why" and the thinking that got Tableau to where it is.
Yes, data grid is definitely something on the radar. It would solve this, and a number of other issues. Again, we're trying to figure out the right way to surface such a feature. It's too easy to simply add a knob or a button every time there is more than one way of doing things. How would the data grid fit in with other tableau views? How would you switch between data grid and traditional layout? These are just a couple of the many questions we have to think through.
Once we have good answers to these issues, we hope you'll be very pleased with the results.
I'm pretty new to Tableau, but already faced this issue in my first customer demo. As well, I was surprised (since it's hard to find) and really value an honest answer.
I guess there's no available fix for now, but is there a way to not have those "sort" buttons available to user if we're exposing Tableau Dashboard as an embedded-view? I prefer just taking the functionality out (until it works as expected by customer) than granting it and get lots of questions and inquires about how it works.
So there is no way to suppress the sort buttons today, though I can certainly see that it's desirable.
Note however that there is something you can do to make sorting work the way you want in some circumstances.
In the attached workbook, there are two sheets: Nested sorting and non-nested sorting.
Nested sorting has the problem we've discussed. If you click on the bottom axis and click 'sort' it sorts within each state.
In Non-nested sorting, i've added a set to the front of the rows shelf and hidden it (unchecked 'Show Header'). This set is made up of all the other dimensions on the rows shelf (State and City). Tableau is smart enough to notice this and when you click on the axis to sort by sales, it will sort everything.
That said, there are several ways this is not ideal. First, every bar has lines between it, there are no panes anymore (you could remove them with formatting). Second, sorting on the State and City headers still doesn't do anything. You have to click on the Sales axis at the bottom. Finally, it isn't grouped by State anymore at all.
Currently you have to decide which is more important to you. you can't do both.
I know it isn't ideal, but perhaps this will help in some cases.
NonNestedSorting.twbx.zip 1.1 MB
I undestand, however my problem is a bit different, since I'm showing a text table with sum of counts in an Area/Region/Market hierarchy. While ordering these counts, they all order by Area (higher level in hierarchy) which does makes sense when user is seeing info at Area level. However when they drill down to lower hierarchy levels like Region or Market, counts are still ordering by Area, which is very confusing.
I tried a set, even hiding the colum, prior to Area/Region/Market columns, and despite it does work for ordering and looks pretty good while at Market level, at higher levels of the hierarchy roll-up gets broken since set forces showing the Area for each row, instead of summing up all Markets into Region and all Regions into Areas
That issue is also present in the example you attached. If you use the set and hide it, but then rollup to State level, then the same state appears more than once in your table with different bars, which is confusing for the end-user...
Thus for now my only pick is to disable sorting (if possible).
I've tried from server side going to the dashboard and in permissions taking out "filter", since I read that filtering and sorting comes together, but that didn't change anything while using that Dashboard from a web application.
Any hints on disabling completely the sorting for a given Workbook or Dashboard? If not, I'll have to include this in my "known issues" section for my software.
Any new developments to address this question? I decided to ask on this thread because it had a promising outlook. I've encountered this behavior in many demos and was wondering if perhaps version 8 handles this differently now.
I know there are probably a ton of suggestions on how to approach this, but I'll throw mine out anyway fwiw. How about creating a right-clickable option similar to the existing 'Compute using...' but it would be called 'Sort using...' with similar functions as the advanced compute-using options. I would be able to control the partitioning and addressing fields in the sort as I can now with a table calc.
This would be the solution to my problem and I remember it working in the past, but when I download your workbook and click on the "city" and "state" columns to sort nothing happens. This this get broken again as of 8.0.3? I'm totally fine with not having the "panes" and having a line between every row.