Nobody but Aaron has acknowledged that the button in the App Manager
dialog is called "Help and Options". Everyone else seems to think this
is just called "Help". As Aaron mentioned, this was called this because
when 7.0 first came out this was the only way for a user to get help or
options without knowing a specific hotkey an app may or may not provide.
We later realized that having all users go to the App Manager dialog for
help and / or options was not a good approach. It was far to
complicated for most users. This is exactly why we now have the Apps
menu option right off the main Window-Eyes menu bar. This is far easier
for a user. Than it is up to the app author as to what they put in
their entry under the apps menu. GW Micro has standardized on creating
a sub menu with at least a help option and if necessary an options entry
and/or anything else relevant to that app. Take a look at the factory
GW Micro apps in the Apps menu.
We left the Help and Options button in the App Manager for backwards
compatibility but do not (and I stress do not) believe this is or should
be expected to be the main interface into your app for help or options.
The apps menu should be the first place any new user to an app should be
going. The App Manager really is a more advanced dialog that beginning
users should have no need to go into. The Help and Options button is
just grandfathered in.
Doug
On 5/24/2011 7:47 AM, Chip Orange wrote:
Yes, and I think Aaron was proposing mostly the same solution (except
for the help in app manager going directly into a preferences dialog).
Yes, nothing says I have to, but I think it's better for our users if
we present them with a consistent interface from one app to the next,
as far as it's possible. and of course, I wanted to hear other
opinions, so thanks for yours.
I think I will change my ways, and if it's more than a single menu
choice, I think I'll add a choice for "preferences" to go to a dialog;
like you though, I don't care for help in app manager not going
directly to help, so I'll leave that as standard help dialog.
Chip
------------------------------------------------------------------------
*From:* J.J. Meddaugh [mailto:[email protected]]
*Sent:* Monday, May 23, 2011 9:28 PM
*To:* [email protected]
*Subject:* Re: a "best practices" question
Chip,
Also, just because GW does it a certain way doesn't mean it's the only
option. I would likely have a preferences option under Edit or Tools
in my menu structure to handle things like this. I can still link the
dialog to the WE menus plus have it available from my app where I'd
expect it. If I'm in a mainstream app, I look for options or
preferences under tools, edit, file, etc. I wouldn't think to look
under help.
Best Regards,
J.J. Meddaugh
A T Guys
Your Assistive Technology Experts
(269) 216-4798
http://www.ATGuys.com
----- Original Message -----
*From:* Chip Orange <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Monday, May 23, 2011 8:48 PM
*Subject:* RE: a "best practices" question
Hi Aaron,
I will, in order to be consistent, do it as you suggest if that
seems to be the overall opinion.
However, I find dialogs of controls (especially large ones) more
confusing than menus usually, and harder to go into and make a
change to one setting than to do that in a set of menus, where
it's easier to find the particular item you seek.
However, Vic points out it's harder to change many settings at once.
I also don't like going into a dialog via a "help" choice, only to
have to choose another "help" button to get to the help. I wish
here the standard help dialog gave us an option to add an
"options" button which would lead to the configuration dialog.
Also, I do this just because I start out with a menu with a couple
of options to turn on/off, and then I keep adding to it until it
turns into menus 2 or 3 levels deep with a dozen options.
But if I'm to redesign things, I wanted to do it in a consistent
way, and a way most people found the easiest to use.
thanks.
Chip
------------------------------------------------------------------------
*From:* Aaron Smith [mailto:[email protected]]
*Sent:* Monday, May 23, 2011 9:24 AM
*To:* [email protected]
*Subject:* Re: a "best practices" question
On 5/21/2011 6:13 PM, Chip Orange wrote:
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.
Why not have one dialog that provides configuration options, along
with a help button that will launch the standard help dialog? That
dialog will then get called regardless of whether the user select
the Help and Options button, or the configuration option in the
app's menu entry. The Progress Indicator script demonstrates how
this should be done.
Aaron
--
Aaron Smith
Web Development * App Development * Product Support Specialist
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
