Yes, Keith, I found that to be the case as well. All I can say to that, based on my own experience, is don't do that.
But let me offer this: I have a dashboard that swaps a handful of sheets, and each sheet has its own filter. If I align the filters perfectly on top of each other, only the top filter works because the top container blcks the filters below it. You can see the filters OK, but you can't click on a valure. I got around that by positioning the top filter a bit to the right of the next filter below it, and the third filter a bit more to the left... This made the check boxes accessible, which was what really mattered in making the lower filters functional. You can still see the filter values that are positioned behind the upper containers, and you can check the boxes (or radio buttons, if that's what you need), and the user doesn't know trhe difference.
I'll say this. I don't like to position any object on top of some other functioning object below it. I described the line graph, and the totals sheets, but that works in my preferred design principles because the line will always run from lower left to upper right on that screen. So the totals sheets are positioned in the upper left, and our business logo is positioned in the lower right, and nothing conflicts. I can't think of a time when I have poisitioned a parameter or filter or legend over data in a sheet that the user might need to click on. By convention at my job, we place those things outside the perimeter of the actual data sheet.
And if a sheet getds too busy, we just move some stuff to a second dashboard and create actions to go there (and come back.)
I demoed that in the video, Ville. You opened a new world to me in one of the exampes you shared with me one time. I looked at it at first and just said, HUH??? And then I saw what you did there, and the lights came on for me.
So yeah, for the sake of others tying to mess with this stuff, I added that into the example, even though there was plenty of space on the sample dashboard.
Having tinkered with this and found the three dozen ways to fail, I believe I know the way forward now. Still, ya never know its going to work until you try. Mine is a complex dashboard to begin with: there's a lot going on. Not so easy to move half to another place either, because in the end, it all belongs together.
One interesting observation, after publishing to server, I've seen its occasionally possible to click thru the "barrier vertical", in a web browser, and get to the thing underneat, if the thing underneath is a text entry quick filter. Not true in desktop, tho.
Probably, I'm going to have to rebuild the entire dashboard from scratch, with a pre-meditated pixel-perfec plan for exactly where every object needs to go; which ones are tiled & which ones are floating; and when & where to build the actions between them.
if I'm not mistaken, there are two different ways to pop within a vertical container? One, where the lower boundary of the vertical container always stays in the same place. And another, where the lowest edge of the verticle layout container moves up & down. Is that right ?
If so, then I'll go with an outside the dashboard approach & lay two of the 'second kind of popping verticals' exactly overtop of one another: when one is down, the other is up, and vice versa. Thing is, I always need to be able to click on the one that's down.
Yes, I have encountered what you described regarding published vs desktop. I didn't start seeing it until 8.2. Doesn't mean it wasn't there in 8.1, but I just encountered it for the first time in 8.2.
I didn't want to bring it up in this discussion as a way to get the underlying objective to click. I don't understand why it behaves this way, and I just considered myself lucky for it to happen. (I saw it on popped legends. My users don't use the functionality of legends wherein if you click the red block on the legend, all the red marks get highlighted. So it wasn't crucial to pursue at the time.) Seems inappropriate to count on something that seems buggy, and even worse to suggest someone else to leverage it.
Regarding two ways to pop... Everything I've done was using a fixed boundary for the container I'm popping in. The point is to expand the dummy sheet when it's time to see the actual sheet, and by expanding the dummy sheet, it pushes the viz sheet into view from behind whatever is hiding it. (And, as was mentioned, anything off the limits of the dashboard effectively hides whatever is out there.)
As for needing to click on the "one that's down", you can ensure it is accessible by swapping rather than by popping.
I have two text entry quick filters and I want to pop them in & out of precisely the same small piece of real estate on my dashboard. When the parameter is set to "A" then I want for Quick Filter "A" to be there. When the parameter is set to "B", then I want for Quick Filter "B" to appear in exactly the same space.
Is this possible ?
So far, with popping, I'm unable to accomplish this because the top vertical container blocks the bottom one. And swapping doesn't seem possible with quick filters.
Any ideas on how to make this happen ?
I don't want you to think I've been ignoring your comments/questions. I wanted to create a video for this topic, because questions about sheet swapping were coming up so frequently on the Forums -- but I honestly don't use it much in my own production work, for a variety of reasons. I do worry that something will change in a future release that could cause workbooks relying on this 'hack' to break in the future.
That being said, my initial thoughts are that it will be difficult to utilize the exact same space for this purpose. Joe and Ville have a lot more experience in using these techniques than I do, so hopefully they'll be able to chime in as well.
Cheers, and I hope you are well!
I run into this at times. I haven't figured out why it sometimes works and other times does not.
Attached is a similar workbook as the one in the video. It is using an overlapping filter, and it is demonstrating the behavior you described.
But!!! If you publish it, it behaves as you would expect. I have found that in all cases (so far) where I experience this behavior, the published workbook behaves properly.
If you don't publish at your site, then the workaround trick I have been using is found on Dashboard2 of the same twbx. I offset the upper container enough to expose the selection buttons/boxes in the lower container. The appearance of the filters will not be as transparent to the user as when they were perfectly aligned. They will see the filter bounce back and forth a little when they swap, but at least the filters function that way.
Hope this helps.
And here is one more idea, though it could be a bit tedious. Put both filters in one container, and both pop-control sheets there too. Make one of the pop control sheets twice as large as the other. The smaller pop control sheet would push both filters down a given amount (the size of one filter), exposing the lower filter. The second pop control sheet would push down two segments, exposing the second filter. Add an opaque blank text box to hide the lower filter when the upper one should be exposed. (Or have it push behind another object already on the dashboard.)
Popping and Swapping overlap.twbx 977.0 KB
So, Ville -- In the example I just posted, why does one filter block the other on Dashboard1?
Simple superstore example. Nothibng complicated.
Well it's just because you can have multiple layers on top of each other but only click the top one. So you should move those objects in the same layer if you want to keep them clickable.
OK. Then your MP4 shows something like I described in my last paragraph above -- basically pushing things up and down one way or another so that the appropriate object is in the exposed area. Correct? (Perhaps using the technique of the control sheet having different numbers of rows based on what needs to be displayed?)
And what do you make of the fact that layered containers DO work when it is published? An undocumented feature, (aka bug) subject to closure in a future release?
Yeah it's same kind of method which I explained earlier by email. This is just a modification of that one.
I haven't have time to test but I guess you mean that layered filters work? I think it's just because of that they changed those filters to be movable in 8.1 or 8.2. so they will pop up in dashboards. Or can you also click normal worksheets if they are under another layer?
So to summarize, from Joe's example:
The lower of the two quick filters in Dashboard 1 is:
- blocked in Tableau Desktop
- not blocked after publishing to Server
We're afraid that the "not blocked on Server" behavior is perhaps buggy. And might therefore be a loophole that Tableau could close in a future release (even though it's really nice).
If that concern is real, then Ville suggests to keep both quick filters in the same layer. This could be done by taking an approach similar to the one Joe described in the last paragraph of his post with the attachment on Dec 4th:
Put both filters in one container, and both pop-control sheets there too. Make one of the pop control sheets twice as large as the other. The smaller pop control sheet would push both filters down a given amount (the size of one filter), exposing the lower filter. The second pop control sheet would push down two segments, exposing the second filter. Add an opaque blank text box to hide the lower filter when the upper one should be exposed. (Or have it push behind another object already on the dashboard.)
To me, that "same layer" approach sounds really tedious. Especially because the pixel-perfect behavior you manage to accomplish in Desktop isn't always the same pixel-perfect behavior that you get after publishing to Server.
Therefore, my suggestion would be that we can speak to Tableau directly & ask for their input. We can ask them to confirm whether the "not blocked on Server" behavior is something they'll continue to preserve in future versions.
If anything, the best route forward, in my opinion, would be to preserve the "not blocked in Server" behavior and to even go so far as to fix the "blocked in desktop" behavior so that both server & desktop are aligned (not blocked).
Matthew, since you're quite close with a number of the folks at Tableau, is there somebody we could @mention to ask for confirmation ?