I don't know about all this but what about changing the literal displayed to
"HelpAndAppSettings" or "HelpAnd AppOptions" or something descriptive of the
combined functionallity - a quick DownAndDirty solution that might work well
enough.
Rick USA
----- Original Message -----
From: David
To: [email protected]
Sent: Tuesday, May 24, 2011 12:39 AM
Subject: Re: a "best practices" question
Well, could definitely agree with you here. Never understood the logic, for
GW to even start out a practice, where they put all the options and settings
for an App under the Help button. OK, you get used to it, but for anyone who
first put their hands on WE, it will not even occur for them to look under
HELP, to make any settings changes. If GW wants us to put things under that
menu, or button, why not simply change its name to OPTIONS. They changed from
scripts, to apps, to be more in line with general computing terms. Then why not
make the change from HELP, to OPTIONS, to fulfill that change. It would make
more sense, and actually more and more apps hold only so much for help, whilst
they are loaded with settings for the user to interact. And, how many times, do
we get questions here, on how to make this and that app change behavior. Guess,
half of the amount of questions, would have vanished, if people knew where to
look for the settings. But if you see a help-button, NOONE would ever think of
going there, to look for settings. Further, in many cases, if now you decide
to go to look for your settings under that HELP button... Well, where does that
take you? Into another screen, where there is little or no settings. You now
have to follow practice, and go under yet another HELP button. IF the first one
was meaningless, what about the other one.
I guess, we have many a user backing us on this: Please have the help button
changed to something more descriptive; or, simply add on a new OPTIONS, or
SETTINGS, button. Then let all developers put their adjustables in there.
----- Original Message -----
From: J.J. Meddaugh
To: [email protected]
Sent: Tuesday, May 24, 2011 3:28 AM
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.
