Hi!
when reading all of this I did notice that my options menu goes directly to
the dialog menu and that is perfect. Even that menu has the help options built
in.
I even have a hotkey that goes directly to the same options menu and those
2 different approaches seems adequate as far as I can tell.
The only help/options which I think you are referring to is in the apps
manager menu and the only place where it is a pain. For there you go into the
so called help and options menu and have to click a second time to get into the
options menu displayed in the first menu you placed in, the Apps menu...
This can be confusing, time consuming, but it depends on whether you are
debugging or just wanting to find options.
My 2 cents is, it seems to be OK, but I am just starting and maybe down the
road there may be issues. But for now I have 2 menu's, one that is created by
the wizard where I placed my options menu in, and added the second menu which
is the options menu.
where by doing this my 2 menu's do get displayed on the main WE menu under
apps, but not the same, but is, inside the app manager for there it is a
duplicate of the first menu and no different...
so, for quick reference, which Aaron points to and Doug reminds us, seems
to be OK when one only wants to know specific history and such in the basic
help menu.
Just getting started and when be spending today testing and running all
those menu items to see which are the best to use. And, yes chip, apparently my
text file was outdated and a pain. As I said last night, going back to the
standard help menu manual, I got a better picture of everything and all
explained in a bare bones way. Still only lacking when and where to use which
format; maybe notes for a future upgrade of the manual. It tries to do it by
placing a link for the other, but no explanation.
so, on to doing my first app for everyone and so far, "EVERYTHING IS
WORKING!"
Bruce
Sent: Tuesday, May 24, 2011 9:55 AM
Subject: Re: a "best practices" question
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
To: [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.
