1 of 2 people found this helpful
This actually makes sense to me, even if the behavior is not what you want.
In scenarios #1 and #2, you are interacting directly with the measures. If you hover over the selected marks in either scenario, you'll get the standard "X items selected" dialog, a summary of the values of what you've selected ("Sum of Sales), etc. Note, too how the marks in #1 and #2 are "surrouneded" with the bold selection border. Example:
Now, compare that to scenario #3. Hover any of the marks in that row. Do you get the same "x marks selected" info? Nope.
So, I'd argue that the fact that a mark selection event fires in Scenario #3 is actually a bug...but that the fact you can't get at the marks which have been "selected" is correct and by design because no marks have really BEEN selected - they're just being highlighted, really.
I'm happy to bug this for you if you'd like.
Russell, I understand what you are saying, and it makes sense regarding the highlighting vs selecting.
However, there is also a case for #3 as a selection, and it is to do with precedence--what Tableau Server is already doing. As I mentioned, on dashboards, scenario #3 is recognised by filter actions that respond to selecting. In my example, if the sheet is set to be a source of such a filter action, I will get the same result by doing either #2 or #3, in spite of the tooltips reporting differently on the summary.
The implication of #3 not being recognised as a selection is: suppose I set up a view that uses both Tableau in-built filter action and JS API for filtering (MarksEvent, getMarksAsync(), applyFilterAsync()), the user will have different behaviours on the same screen for doing #3.
So I think if scenario #3 is to stop being a select action, so should it on Tableau Server as well. Or it is a selection action on both.
Well, action filters and mark selection are different things (at least I think we handle them differently). Action filters, of course, involve grabbing a dimension value (or dimension values) and applying them elsewhere - I can get dimension values from clicking ON marks (scenarios 1 & 2) OR intereacting with a header (secnario 3)
The key thing to keep in mind here is that the name of the method includes "mark" - In scenarios 1 & 2, you are selecting marks. In #3, you are not.
Hey Justin Rockwood, care to chime in here?
Yes, Russell is correct here. Although, I totally understand your confusion, Nay Lin, and also understand your desire to get at those marks which have been highlighted.
We really need to support marks brushing/highlighting as well, which is what you want in your case. We have it on our backlog, but I can't guarantee when (or if) we'll get it implemented.
I agree, the highlighting is distinct from the bold outline which indicates selection in Tableau. Should it be in this case? I suspect it should and that there has been no lack of thought about this question.
In theory, I understand how selecting a header can be considered highlighting a mark, and not selecting it; however, in practice, if a user clicks a header, they are likely interested in all of the associated marks of that header, and the fact that Tableau highlights those marks (and allows for action-filtering at this level) also suggests that this was implicitly understood in the design.
For this reason, I would argue that marks "highlighted" in OP's scenario #3 should function and return the same as multiple marks drag-click selected in scenario #2.
There are obviously hacks to get around this, using hidden Viz's and arrays to populate non-Tableau HTML elements, but that defeats the ease-of-use purpose of an API. Just my $0.02.
+1 on your thoughts and the dev team (including Justin, earlier in the thread) is aware of the issue. Hopefully we'll see something like this at some point in the future...
I'm actually in a scenario where i really like to catch marks selected in scenario 3. Since for Dashboard actions 1,2,and 3 are the same when i embed dashboard in html page ad attach event handlers to mark selection, i can get strange (for user point of view ) behaviours.
Someone mentioned some hacks that can get around this: can you give me some clues about that?
can you tell me some of the hacks you mentioned?
I'm also stuck with the example 3 bug.
Any work-around would be appreciated..
I was referring to actually rebuilding the table outside of Tableau in HTML/CSS/JS, using only data retrieved from Tableau.
If you are an experienced Web developer and know how to dynamically build tables and charts in your Web environment, outside of Tableau, I'm happy to share more.
Since it isn't fixed yet, is there a way to disable clicking on the a header as in scenario 3, or a way to catch the highlighting of the bars (something like the select event)?
You mentioned to have scenario 3 in your backlog back in 2014, the issue is still the same for us. did we miss any new functions that would allow us to catch Scenario 3 events and property?
Your support is highly appreciated.
Bumping this thread. Any tickets open for supporting this event type ? Timelines etc. ?