Portal Based Menu Systems
Navigation - it's a fundamental piece to the whole UX problem of a growing database solution. When you first start out, things are pretty easy. You may have a few buttons taking users to dedicated layouts.
However, as things continually grow, you end up adding more and more places to go and things which can be done. Managing this growth, and how you present the possible options, is something which requires a bit of forethought.
When you start to consider the number of layouts which may need to be modified, you quickly come against the ever constant limitation of time. Who wants to have to make modifications to many different layouts if they don't have to - especially to multiple layout objects on those multiple layouts. The fewer objects you need to copy and paste the better.
Even better than that is the ability to dynamically show whatever menu options you wish at whatever time and based on context as well. How about if we throw in some re-usability as well?
Well, how about a Portal Based Navigation menu, inclusive of icons? It may be exactly the solution we're looking for when considering the issue at hand. This video and sample file will provide you with the know-how to implement both a flexible and powerful navigation menu for maximum navigation effect.
Comments
Direct relationship to "@Menus" TO
¿Could the virtual list and related scripting be avoided by creating a cartesian relationship directly to the "@Menus" TO?
For not showing beta menu items, the relationship could be a based on a constant calc "1" not equal to "beta".
Another option, the navigation portal could be filtered based on on an sql select "id" where "beta"=0, or otherwise a global variable containing the list of ids that are result of the sql query executed on the open file script.
Downloadable example:
https://www.dropbox.com/s/stbdrlr7us07v2u/Portal%20Based%20Menu%20System...
Removing relationships
Part of the reason for using a virtual list and variables is to reduce the number of "lookup" relationships used to show UI related features.
If you use the Separation Model and made your virtual list table local to a file, then you never need the roundtrip to the server once the menu has been established.
Putting relationships in place mean that FileMaker needs to evaluate those each time the context is established.
We want to do it once and then read from memory if we can.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Makes sense, thank you!
Makes sense, thank you!
Horizontal
Awesome work. How about horizontal nav or sub-menu integration? It would be great to nest this in popover button bars.
You can certainly do this
Using the same portal, with the same virtual list within multiple popovers used in a button bar would be a very easy adaptation. Simple store your menus in discrete $$GLOBAL.VARS for each submenu.
Using the OnObjectEnter script trigger on the popover would be used to populate the virtual list.
Don't have the bandwidth to implement right now but will consider it for a future modification.
Nice suggestion!
-- Matt Petrowsky - ISO FileMaker Magazine Editor
multifile portal-menu bar
Matt,
can you think that this menu items list could be made to work in a multi-file solution.
So that you can maintain it all in one file, the UI file and it.
I have a 13 file solution, 4 of them are really often used and I look for a centrally stored Menu system.
Thanks for your great videos. Sometimes they are a bit over the top... .or I am just under the top..hehe.
Yours
Pierre