Hide filter depending on sheet in dashboard - tableau-api

Hope you can help.
I have attached my workbook. Basically, I have made swapping sheets. The sheets have different filters, and I need the filters to disappear depending on the sheet showing.
I have no problem with the sheet swapping. I been going through the internet for hours, without finding a good solution. I did look into this: New series of videos on swapping and popping on a dashboard(https://vimeo.com/294170859), but did not find it that helpful since it is not very flexible and too difficult to use if you have many filters, that need to change.
I have some kind of an Idea, of putting my filters in each of their container, and then have the container showing depending the sheet but do not how either.
But in the end, the filters needs to appear in the same spots too.
But I really need your help - Simply can't find a good solution!
Thank you!

Without putting your filters in containers and swapping those I can't think of any alternative way to alter which filters appear on your dashboard.
I don't know the exact specifics of your task, however, having perhaps faced similar issues almost always the best solution is to simplify. If possible instead of swapping sheets consider a new dashboard and just "show sheets as tabs". Altering a parameter is a click, just as clicking a dashboard tab - so no difference to the user. Also changing filters may be confusing to a user - they generally get used to seeing things in a certain place.
Of course none of this may apply to your specific situation.

Related

I am making a calculator that keeps all the different sums on the screen using flutter. Not sure how to approach this

I have been trying not to have ask but I need some help. I am building my first flutter app. It's a calculator and I can get a basic one working without problems I am even getting it to evaluate with each key press, whether it be from my numbers widgets or by typing directly into the textfield.
I want to make it a bit different. I have tried to come up with the best way to do this but am not sure how. I want multiple sums to stay shown in the textfield(I presume if it needs editing I need to use a textfield) with the result attached. (i.e 2+6+4=12 then on a new line have another 6*6=36 etc.) At any time updating the textfield with the keypad must update all the sums on screen.
I have tried to do this using just one textfield (splitting the text and adding the sums to a list then calculating each and adding them back), however seems very cumbersome and I don't think this is the best approach. I have also made a Dynamic list of textfields , but found it difficult to index each textfield widget (dont think this is the correct approach) Im not asking for code but ideas as to which route to take. Your help would be appreciated.

How to put a label to a hierarchical dimension in Qlik Sense

I would like to know if I can set a label to a hierarchical dimension, because If I have 2 dimensions, it will show like below:
That seems not beauty, so, there is a way to change this with a label or something in qlik sense?
Thanks, any ideas?
1. Unlink the Visualization
In the edit panel, click the chain icon and accept to unlink it from the master dimensions. This will allow you to edit the label accordingly.
Of course, this removes it as a master dimension so you it might not be the best if you have numerous sheets using the same chart.
2. Add the Label in the Master Visualization
I don't know what the rest of your app looks like, and I've found this to be finicky sometimes so it may not work --play around with it though.
While editing the master table, experiment with using ="Your Label Here" in the titles of the measures.
In my opinion and experience, Qlik Community Forum is more active than Stack Overflow. I highly recommend checking it out for help if you're finding Stack Overflow to be too slow: https://community.qlik.com/

Mark Labels Not Displaying In Tableau 2018

Others have asked this question before, but no one has provided an actual answer to it. I can't get all of the marks/labels to display in my Tableau visualizations.
Selecting "allow labels to overlap" does not fix the problem. That displays several hidden labels for the smallest of the areas, and it places those labels at the top of the bars, ignoring the formatting that sets the labels to the bottom. However, whether or not that option is checked, the empty areas in the screen shot stay empty. And those areas are clearly large enough to display the missing labels without encroaching on any other label.
I'm guessing this is a bug in Tableau because there's no reasonable explanation as to why this is happening, but I'm new to Tableau and unsure how to address this.
While I can offer no explanation, this has been a reported problem for several years. Tableau's own documentation states to check the Allow marks to overlap checkbox, yet that doesn't always work.
I don't know if it's a bug so much as it is a complicated calculation for the rendering engine to determine what will and won't fit into a space. To the human eye it will fit but it's possible the underlying calculations inside Tableau don't see it that way. I find that particularly on dual-axis charts (like yours) this happens more frequently. I've done two things to get around it when it comes up:
Change font family or font size
Put more info into the tooltips so the end user sees the data when they hover.
If you wish to pursue this as a bug, you will need to contact Tableau Support and file a case. They will ask you to submit a twbx file to reproduce the issue.
I hope that helps.
Label -> Font -> Automatic solved the problem for me
You can select individual marks, right click to pop up a menu, and specify whether to always hide or always show the labels for the selected marks (overriding the default behavior)

MS Word - Lock one column on first page?

We have a company 'letterhead' template with all company info in a left column/sidebar. I'd like to lock that section for editing, but still retain the option to edit and/or mail merge the rest of the document as normal. I've tried the Restrict Editing feature, but that seems like the opposite function of what I need; I'd like to specify a section that is not editable, as opposed to a section that is.
The main problem is that the mailmerge/add-envelope function is disabled when Restrict Editing is on, but also adding a section break to a second page (to change to a single-column format on subsequent pages) isn't allowed either.
I've considered just creating an image of the left sidebar, but that seems hacky. Does anyone have any other suggestions on this one?
Much appreciated
--michael~
I opted for a combo of ideas, and used your [Cindy] last suggestion to bury an image in the first-page header. The table/content control seemed too complicated. Yes, it's a hacky solution, but with the wrapping options to prevent text over the image, it's like a margin without having to set them, so I can get rid of the multi-column and Restrict Editing thing, and subsequent pages are completely normal without extra section break necessary. I appreciate the responses. Thanks!

Do edit pages and view pages need to have the same basic layout?

From a design and usability perspective is it best that an edit page mimics the layout of the view page?
Our view page is very dense. The data is tightly packed together, but when editing there are going to be extra controls next to each entry field. If we leave the layout the same it will be overly crowded. Will this cause problems with usability if the fields are rearranged?
It definitely impairs usability. Two hazards of re-arranging fields are:
Confusing users about which field they are editing
Making it difficult for users to find the field they want to edit.
These problems are exacerbated on high-density pages.
There are some times when this is ok. The best example I can think of is where the editor and viewer are different users. Another (more ambiguous) case is a situation where the edit screen needs to be highly optimized for fast throughput.
If possible, you might consider splitting the screen up, or making collapsable regions to give the user (and the screen) a little room to breathe.
In general you want to keep the edit page as simillar as possible to the view page. In general. There are cases where this just doesn't make sense especially if you have to input a lot of extra data that is not shown in the view, which it sounds like is your case.
What I would try and do is make sure you continue to group and order the fields in the same manner as if you were viewing so while they might be in slightly different places at least they would be logically grouped the same.
It depends upon your workflow.
If the user has to go back and forth between edit and view, it will be very confusing to the person, as fields may jump around, they might lose which field they are on, etc.
If your view page is very dense, you might try breaking it up into sections, each with its own edit function. You could have it shoot to its own edit page or be all 'web 2.0' and throw up a lightbox with the section edit form over the view page.
The more that things are similar, typically, the easier it is for a user to use. I don't know what your particular layout looks like but from a general point of view, a crowded view is often hard to look at and cluttering it up with additional controls would make it worse.
As much as I'm not a spreadsheet guy, editing in Excel or similar products is easy because it doesn't clog up the view with lots of controls. The edit panel is the view panel. For my own products, when things are consistent, the users are generally less confused.
I have had a similar problem. What I did was have a View page that lets you see everything, but you need to drill into individual edit pages for logical sections. Within the logical sections the fields are always in the same order (and with the same labels) as on the view page. It's things like this which make your application just feel a bit nicer.
Don't throw everything onto a massive edit page just because they all relate to the same thing in your database model. Break them out into sets that make sense each with 3-7 fields on them.
If they really need to edit everything (like when creating a new thing) then I would go for a wizard approach which steps through through, presents a view-only summary and then lets them save.