From:

 Chip Orange

Subject:

 a "best practices" question

Date:

 Sat, May 21, 2011 6:13:58 pm

Hi all,

I'm hoping for everyone's opinion, but especially for some sort of
"official" position from GW on this design question:

When we started scripting we always put configuration options for our apps
somewhere in their help dialogs.

then, the "script/app" menu came along, and we at least put a menu choice
for "help" there, to keep users from having to go into the app manager to
get to help.

Now, I find myself usually designing my app interfaces so that all
configuration options are controlled via the app menu entry (and it's
submenus), so I can leave the help dialog managed as a standard help dialog
by the help dialog object.

This is a significant savings to me if I don't have to write two
configuration option interfaces (one for menus and one for dialogs);
especially since I can leave the help dialog as a standard dialog, and not
write a dialog interface at all, and since I'm having to write a minimal
menu interface anyway.

What does everyone think of this practice as our new "paradigm"? That is,
allowing users to get to all configuration options via the app menu for the
app, and not writing a custom replacement for the standard help dialog
(which always seem "clunky" to me)? It seemed just as "clunky" if you had
to design your app with a hotkey which served no purpose other than to bring
up a configuration dialog.

I realize not all configuration can best be done with menu choices, but I
see no reason why a menu choice can't bring up a dialog when needed.

I think it's good for our users if we all agree on some design goals, so all
of our apps are consistent, and thus present less confusion for the users,
and there's obviously less memorization needed as to how each app handles
it. I think it's also good if we can minimize the use of hotkeys, and the
need for going into the app manager.

What do people think?

Chip