LinkedIn
Twitter
Sample App: Customizable Menus/Navigation
If your app has many different views/sections or your app’s home screen looks like this
you may be looking for a solution to simplify the home screen experience while still giving the users full access and flexibility to decide what they want to pin to their home screen.
Cleaning up the home screen has the benefit of not overwhelming users when they first start using an app. To present a more minimal menu, you may want to create sub menus that group similar views/sections together on the the main home screen. While this is helpful for new users, you will soon get complaints that is takes “too many clicks” to navigate to their destination in the app.
To create an app that has the best of both worlds, you can develop apps that introduce sub menus while still giving your users the ability to add sections or views to the main home screen and navigation bars without the need to modify the app definition.
I have created a sample that does just this: Customizable Menus/Navigation
This app shows you how you can create a customizable interface for each single user of your app. You can take the above overwhelming experience and transform it into a less intimidating first impression.
How it Works
There are 3 data tables that are used to create this functionality:
userAccess Logs the customized inputs for each user, the columns “homescreenpinned” and “footerviews” are enumlists used to store the view preferences for each user.
subMenus this table simply lists each submenu that is in your app.
menuItems (optional) This is a table that describes each menu item you have in your app, they are used by the enumlists as a reference to select views they want pinned. This isn’t required but could help you manage action to view mapping if you have a complex setup. When setup correctly you can manage the menus through the table and not need to update the app definition.
The Home Screen
The home screen is a detail view for a single record that is linked to the userAccess table. The userAccess table has a security filter that will only allow the record through that matches the user’s email. You can store all relevant information for this user in a single record.
The home screen displays all the app views as an action. Each of these actions has a “only if this condition is true” behavior that will check that it is listed as a view in the user’s customized setting. Any actions that go to the submenu will always be shown, actions that go to “pinned” actions will be set with this “only if this condition is true” formula.
Sub Menus
Submenus are also a detail view that are connected to the subMenus table. Each of the actions that navigate to the subMenu are actions with a linktorow expression. This allows you to navigate to the specific subMenu record. When you add views to the submenu (actions that go to views) you will simply make these actions show if the key column is equal to the desired subMenu. This allows you to show all Menu A items in Menu A and Menu B items in Menu B.
Methods of Pinning Views
Once you have the two views up you can create actions that “pin” views to either the Home screen or the Bottom Navigation bar. I have a few examples in the app on where you could place these actions but the general concept is simple:
- Create an action “Date: set the values of some columns in this row”
- Set either the footerviews or homescreenpinned columns to the following expression:
To add a view: [footerviews]+list(context(view))
To remove a view: [footerviews]-list(context(view))
Wrapping Up
I realize this is a niche use case and won’t apply to most apps created, but I know from working with some AppSheet developers that there may be a need for some of you out there. Please play around with the sample app and let me know if you have any questions. I’m sure there will be even better ideas that surface in the comments below.
