This is an example about printing. The premise here is that you devote one sheet/dashboard to filtering criteria, and a second to the printing output. In the example below, the selection sheet also has boxes to fill in various comments - these will show up on the printed version. The second tab below is a well-formatted dashboard which is set to print to letter portrait mode.
I find some of these techniques to be annoying - too much tabbing and too much "I need to know how to navigate a priori" - perhaps I am just complaining. It's not that hard I guess. Also, this viz breaks my rule about creating small vizes in 2011 (the goal was to print a letter portrait dashboard however) Anyhoo, a work in progress.
5 comments:
You could also add a worksheet to the bottom with a filter action that looks like a click-able button to give the user another convent way to navigate to the printing tab.
I really like this concept. Another use case would be for dashboards that have a lot of filters, you could put all the filters on one tab, and then you can have a bunch of dashboard sheets dedicated to the views (although this would not make sense for options that need to be frequently switched while looking at the views).
I like this technique. My concern is how it highlights a common problem when trying to create flexibility for end users. What you've done offers some customisation - that's great, and it works for you, and, I guess, the couple of users you've tested it with. The problem we find with this kind of thing is that as soon as you roll it out, other users come up with perfectly valid use-cases that can't be accommodated by this technique. So, you've got a report that does 80% of the work, but alienates people because the last 20% doesn't work. How do you get around this? Either by reworking the report every time someone has a problem (resource intensive) or ignoring it (alienating the end user).
If you can be sure this technique solves 99% of users' needs, you've got a big fat win!
Good idea Joe; forgot about that one. I also wish that parameter input could be a text area field as opposed to single line input field...
Ty, does tableau server support passing params like you use above in the URL? Much like it does for filters? If it did, you could make this work really well, and accommodate a few more user requets by simply making the first page HTML, and then passing the results of all the fields as a URL with a query string.
Cheers
Tom
It does support it, Tom. However, there is also a defect in the shipping product which Tableau is aware of, which is making this concept unusable as of current writing. Otherwise, I would most definitely be using it... :)
Post a Comment