New View Type for Dashboard "Child" Views (not same as Ref view)

[Jamie]

I don’t see this request already submitted, but if so let me know and I will upvote the original. I think there should be a view type specifically for dashboard “element” views that should only show up within their assigned dashboards. This is necessary because Ref Views have way too much impact throughout the App (globally changing the inline view for the associated table being the most significant). And don’t even get me started on managing multiple Ref views for the same table. Using a menu view is also problematic because you then have to go through all kinds of gymnastics to hide it from the menu. Please don’t suggest complicated work arounds in response to this request. This should be a simple and unambiguous view type IMO.

[Steve]

I have no idea what you mean here.

[Marc_Dillon]

I believe he is asking for there to be a new category for a Views to be set as, additional to the 3 existing “Primary”,“Menu”, and “Ref”.

Since any type of view can be set as a Dashboard’s sub-view, (which isn’t going to be changed so as to not break existing apps) I don’t think the dashboard portion of this request is relevant. I think more importantly is that any views in this new category would not override things like inline views, which this following feature request would also help towards this goal:

Specify which inline view to use in a detailed view Feature Requests

It is too difficult to guess/change which inline view will be used while using a related field in a defailed view. Should have a way to just point on the desired inline view rather that trying to guess which one it will choose (or the need to create a specific slice and create a ref to it, just to force it to use the inline view of that slice)

I do think it is a decent request, if only just to allow further organization of things within the editor.

[Grant_Stead]

I agree. I was fighting with her today… The hardest part is that maps and charts are valued highly above other views.

[Jamie]

I guess my original description was poorly worded. I was interchanging “Views” with “Tables” when describing my request. But I think both @Grant_Stead and @Marc_Dillon got my gist.

For context, I make heavy use of (mostly dynamic) dashboards in my App, some of which will have as many as 6-8 views within them. And in many cases, I want these dashboards and their embedded views to differ based on the user (role, department, etc.) To keep myself sane & organized I have created all of these embedded views from scratch using a naming convention which ends in “_Element”. This makes it easier to find them either while editing them or while adding them to a dashboard. The issue is that I now have scores of these and I don’t want them to show up anywhere but in their assigned dashboard. Of course the simplest way to hide them is to make them Ref views but that has the undesired side effect of changing the layout, content, behavior of the inline view for that table/slice. So what I am asking is that certain views can be designated as only visible within a dashboard. Perhaps not even an entirely new view type, but an attribute of the existing dashboard view type itself? This would save me a ton of time hiding them from all menus (currently I am using a CONTEXT expression in the view’s SHOW IF which is far from ideal). With a little additional work this could also have a secondary benefit when constructing dashboards, in that perhaps the editor could filter on this new view type.

Maybe I am far from typical in having this challenge and I’m sure there are many big features in line ahead of this. But it seemed (from someone who knows nothing) like a relatively minor tweak - thanks for listening!

[MultiTech]

Steve:

I have no idea what you mean here.

Same

@Jamie, you said inside your second repsponse:

Jamie:

(currently I am using a CONTEXT expression in the view’s SHOW IF which is far from ideal)

How is this less than ideal? Doesn’t this give you complete control over where things should be shown?

You know you can use Context() inside a column’s ShowIF, right?

• So if it’s a matter of only showing certain columns (like a virtual Ref_Rows() or something), you can hard-code those to only show on a specific view.

So I’m not sure exactly what you’re asking here; seems like we’ve got the tools to do what you want… and you’re already using them.

What’s the problem?

[Jonathan_S]

I believe @Jamie is just Requesting for a more user friendly, more intuitive and more organised way to bring this about.

The tools are all here in order to do what he is asking, but don’t see anything wrong with this request. Ill go for anything to make things easier and more organised. Especially once get you larger apps. Can be a lot of clutter.

[MultiTech]

Jonathan_S:

Especially once get you larger apps. Can be a lot of clutter.

So true

[Jamie]

Show/hide columns, sure, but what about dynamically changing the entire view type or the column order? If I want one dashboard to display a deck view and another dashboard to display a card view of that same data but I also want the inline view to remain a table then I have to create two new views (not touching the Ref view) and then hide those new views from the menus since they have no relevance outside the dashboard. Using Context() I can hide the views unless currently looking at their appropriate parent dashboard, but even then they are still visible on the menu while the user is in that particular dashboard.

Perhaps this all comes from me not wanting to go crazy creating slices, but I kind of feel like that shouldn’t be necessary since I am not looking to filter the data, but simply change the way it is presented based on who the end user is.

[MultiTech]

The beauty of the AppSheet platform is that customization is almost a certainty. You just have to figure out HOW to get that functionality.

Anytime you’re trying to do something that’s not “AppSheet Standard” you’ll run into the necessity of having to build out “extra” bits in your app to support and make them work.

Jamie:

but even then they are still visible on the menu

Not sure what you mean by this? You mentioned using a custom menu system, wouldn’t you just filter out the options available in the dropdown/list/whatever? (Based on role or something?)

[Jamie]

I couldn’t agree more - I have been amazed at what I have been able to do. I have taken it further than I ever thought I could/would. The challenge is now the complexity and the sheer quantity of assets that now have to be managed, which goes to the heart of my suggestion.

I’m not using a custom menu, but the standard AppSheet side menu. Since I am not using Ref views for these dashboard sub-views each of them will show up as an icon on the standard menu. So I hide these views unless the context is their parent dashboard (Show If: CONTEXT(“View”)=“HypotheticalDashboard”) which allows them to be displayed in the dashboard but it also makes them reappear in the menu while the user is in that dash.

[Grant_Stead]

@MultiTech_Visions Currently the CONTEXT function only works for the “outermost” container view… i.e. what is in the URL… So, show/hide can get quite complex around inline in a details view within a map view pop-out that’s nested inside an interactive dashboard… Especially when you can expand that map, and now it’s not in the dashboard…

[Jamie]

And I thought I had troubles

[MultiTech]

Jamie:

I’m not using a custom menu, but the standard AppSheet side menu.

Might I suggest you instead create your own menu system? This is quite easy; basically a table with some “display” info along with maybe a tag or something, and a navigation action (or actions with conditions) that takes a user wherever they need to go based on the option they select in the menu.

You can do all sorts of filtering then of the options available.

---

But I hear you about having a HUGE number of assets inside your AppSheet editor. Naming conventions become essential at some point.

[Jamie]

Yes, it is a good suggestion and I believe I was headed down that path anyway to address certain other scenarios. I know there is a lot of good content and tips on that topic in these forums. Someday I knew I would probably be getting back to them, but was putting it off until I really hit the wall. Seems that day has finally come. Thanks!

[Marc_Dillon]

Bumping this request as I’m struggling with it today.

Wanting to specify a set of table views to live solely inside of a dashboard. I put them in Menu prominence so that they don’t have any chance of overriding some inline views for the same table somewhere else. To get them to not actually show in the Menu, I set a Show_if of FALSE. Oops! Now they aren’t even visible in the dashboard. I change the show_If to CONTEXT("View") = "dashboard view". Now they don’t show up in the menu, and do show up in the dashboard. But Oops! again, when I’m in the dashboard view, now they also show up in the menu.

I fix this for now by creating slice copies of the table, and set the table sub-views to point to these new slices, then move those views back to Ref prominence, and delete the show_ifs.