[AccessD] Switchboard

Arthur,

<<The one I'm
currently working on is based on code from our lister and guru Jim Dettman,
whose code I inherited and began to modify. >>

 Actually, I'm not the author of that one.  I cleaned it up quite a bit, but
that was about it.

 I have a three panel version of the one you have, which I did author, but
the 3 panel concept is not mine. I have seen both those style of menus done
as Tree View controls.

 My own original menu you haven't seen.  If was a single panel of 10 items.
You could have up to 10 panels (pages) on a level.  Any item could lead to
another menu level or reference an object or process.  Last two items on the
panel allowed you to move back up a menu level or straight back to the main
level.  I can send it along if you want to see another alternative<g>, but
it's old and outdated.  There are better interfaces out there today.

 For example, almost every menu system today allows a user to place their
own items in a favorites or shortcut list.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, September 08, 2012 02:20 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Switchboard

I'll show you mine if you show me yours, and in case any internet police
are reading this, I meant switchboards!

I have several versions of the basic switchboard concept, which I would be
happy to share with you, and will send them to you privately, The one I'm
currently working on is based on code from our lister and guru Jim Dettman,
whose code I inherited and began to modify. My last version I also
inherited and modified. Both have virtues and limits.

But I guess that what I'm after is an answer to the question, "If you don't
use a switchboard, how do you map the navigation into your app?" Do you
even begin with a switchboard or its equivalent, or do you immediately take
the user to the "Do Right Now" list of tasks? Which obviously may vary
widely from app to app, but nonetheless there could be an opening form that
lists, for example, "Overdue Invoices", "Purchase Orders Unfulfilled" and
so on as its top items, followed by general (i.e. time-insensitive) items
such as "Maintain Lookup Tables" which leads to a sub-menu of Regions,
Cities, Employees etc.

Or would you prefer to begin with a list of Customers and drill down from
there? Ah! I think that I'm finally beginning to discover the abstract
nature of the question I'm asking, which goes much deeper than the most
desirable front end: What is the most intuitive hierarchy (not from the
developer's perspective, but the user's)? Do Actions lead to Objects and
then Events? Or to Events (i.e. Overdue Invoices) lead to actions, and only
after that lead to Info Forms such as Customer_Edit_frm? Of course, there
must also be a way to get to that form directly, but what I'm attempting to
address in this overlong question is this: should one design the interface,
whether switchboard or any other presentation model you use, most
immediately present the tasks or actions the user is facing upon login? And
in the latter case, ought we do dispense with the switchboard as the
initial presentation, and instead move right away to the "S**t we have to
deal with RFN (if English is not your first language, think about it)
list(s), which conceivably could be several subforms on an opening master
form, and a double-click on any item in any of the subforms could open a
dialog on same detail, and invite an action upon same item?

I don't know. I'm groping for your approaches to these questions/approaches.

A.
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com