Suggestions for Menu System

[richlocus]

Hello:

Fifteen years ago when I started developing Access applications I used a menu system recommended by Microsoft at that time. It is called a "Switchboard".

There can be many levels of the menu, and they all reside in the same space on the screen. Each level produces different options for reports, queries, etc. Each level just overlays the previous one... so each level has a button to return to the main menu or previous menu.

This was great for some applications that had perhaps 30 to 50 different functions (Forms, Reports, Editing functions, etc.)

Is there a better or newer way to present the user with many options? Perhaps just a form with many buttons?

I included the user interface of the previous switchboard, along with the underlying table which describes what action to take. It is just a little cumbersome to maintain.

Suggestions for a better system?

Thanks,
Rich Locus

[HansV]

Many developers now view the Switchboard as old-fashioned. I still use it in a customized form (a nicer font, flat buttons, different colors).

An alternative could be creating your own ribbon (requiring that you learn Ribbon XML), with custom tabs and custom groups. This would make the interface similar to that of many Microsoft applications.

You might also look into navigation forms: a navigation form has tabs, each of which can contain another form or report.

Or - as you mention yourself - create your own menu forms.

[ChrisGreaves]

Suggestions for a better system?

Hello Rich Locus.
I don't think that there is a "best" or "better" system as much as different systems serving different people/purposes.

Untitled.png

I am blessed with being able to write applications in Office2003, so I have very easy access to toolbar menus. The example above shows me running a macro from an application "Under" which has its own one-inch toolbar.
I make use of shortcut keys for frequently-used macros, and make use of GUI forms for configuring run-time values.

Untitled2.png

With a new application I try to ask "What will best suit the user?" for each macro. And of course, sometimes the user gets a choice!
Cheers, Chris

[richlocus]

Hans and Chris:

Thanks for your valuable service and suggestions. An "old timer" like me needs a little update now and then :)

Rich Locus

[ChrisGreaves]

... An "old timer" like me needs a little update now and then :)

So, RichLocus, let me ask you two questions:
(1) Have you yet written VBA code to raise a GUI form and obtain data from it? Such code will probably include a construct such as "frmOptions.Show"
(2) have you yet, as an end-user, created a toolbar menu system?
Cheers, Chris

[HansV]

@Chris:

(1) frmOptions.Show is for a VBA userform, not for a form in an Access database.
(2) It's possible to create toolbars in ribbon-based Office applications, but they are all dumped into the Add-ins tab of the ribbon, so they don't provide an attractive interface.

[ChrisGreaves]

(1) frmOptions.Show is for a VBA userform, not for a form in an Access database.
(2) It's possible to create toolbars in ribbon-based Office applications, but they are all dumped into the Add-ins tab of the ribbon, so they don't provide an attractive interface.

Thanks Hans.
(1) I should have re-read the first post
That said, I think that a great deal of the VBA code I write to deal with data in GUI forms in Word would be similar to my forms in Access; I am thinking of the events code for the various controls.
(2) Agreed. I never did understand a stated rational (fifteen years ago) that the ribbon would free up space on the screen. Most Word/Excel configurations had only the Standard and Formatting toolbars with all their useless junk.
Cheers, Chris