Is there a precedent for this general user confusion? To my knowledge,
we've not had many calls or complaints about this issue. There will
always been a certain set of users who just want to know how to do
something without investigating or reading documentation. An app's
author also has many different ways to tackle user confusion aside from
the methods we provide. Take the Quick Start wizard, for example. It
pops up in your face the first time it's run after installation -- that
has nothing to do with the toolkit, or Help and Options, or the Apps
menu; it's all the app itself. Many software programs do the same thing
with "Tip of the Day" dialogs, or launching a readme in Notepad, or
something similar. It seems to me that there already exist countless
ways to help users get at whatever documentation exists.
Aaron
On 5/24/2011 7:51 AM, Chip Orange wrote:
Yes David, it's precisely because of the confusion you mentioned when
users don't know how to operate an app, that made me wonder what's the
best way for us to handle it, and then once we've settled on
something, shouldn't we make it known to all app developers so that
all apps present a consistent interface.
thanks for your response.
Chip
------------------------------------------------------------------------
*From:* David [mailto:[email protected]]
*Sent:* Tuesday, May 24, 2011 12:40 AM
*To:* [email protected]
*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 <mailto:[email protected]>
*To:* [email protected] <mailto:[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 <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.
--
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.
