The GW-Scripting list is a discussion list for information regarding the development and use of Window-Eyes scripts. Any subscriber of the GW-Scripting list has the ability to post on-topic messages.
From:
BTSubject:
Re: a "best practices" questionDate:
Sat, May 21, 2011 9:20:42 pmHi Chip,
Just getting started on this, I found myself going to the menu for all
those settings. I just completed my first working menu at the point you
speak of.
I have the options dialog for that menu inside my main menu and that
allows me to go to options and clean up the screen; as you mentioned in your
response to me.
I think the only problem as you hint at, is how many options and such.
But having menu labels for each option and a pull down to each individual
option is a nice and clean way.
Some times there is a lot of enabling or disabling, but those can all be
done when designing by id names and passing them in since all stuff is
almost text oriented.
so far, as I have just experienced, I think that would be a good idea.
At the moment I call up just the main menu with Options and Help for a
choice.
My lack of experience thoughts at the moment; work in progress.
bruce
Sent: Saturday, May 21, 2011 6:13 PM
Subject: a "best practices" question
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
Just getting started on this, I found myself going to the menu for all
those settings. I just completed my first working menu at the point you
speak of.
I have the options dialog for that menu inside my main menu and that
allows me to go to options and clean up the screen; as you mentioned in your
response to me.
I think the only problem as you hint at, is how many options and such.
But having menu labels for each option and a pull down to each individual
option is a nice and clean way.
Some times there is a lot of enabling or disabling, but those can all be
done when designing by id names and passing them in since all stuff is
almost text oriented.
so far, as I have just experienced, I think that would be a good idea.
At the moment I call up just the main menu with Options and Help for a
choice.
My lack of experience thoughts at the moment; work in progress.
bruce
Sent: Saturday, May 21, 2011 6:13 PM
Subject: a "best practices" question
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


