Re: a "best practices" question

[David]

Chip,
In case I understand your point correct, I'd absolutely go for a 
combination. There would, as you said, be cases where a simple menu would be 
the solution. IF, on the other hand, that menu would hold things like twenty 
or fifty entries, with a good mix of checkboxes for this activity, buttons 
for that one, and drop-down lists for the rest - well, in such cases, it 
would by far be easier to have it split into several submenus. That is, you 
would have one submenu for all the settings that has to do with the layout, 
another for all speech adjustment, and maybe one for all that has to do with 
hotkeys for the given app - for an example. Don't know, if I am sidetracking 
here, from what you are trying to communicate, but at least something to 
keep in mind.

Still, I wish there was easy access to the menus, being one big, or several 
smaller ones. I.e, you easily could hit a hotkey, so as to get directly to 
the menu(s), without having to go the 'lengthy' way around the App list. 
Specially so, if your app does carry a characteristic that calls for 
frequent user interferance.


Guess, there might be times where the chocolate will do, and still others 
where you better bring a bottle of water. One thing to keep in mind, which 
not all software developers are good at (just have a look at the net), is to 
keep the menus themselves, and each entry as short and accurately labelled 
as possible. Sometimes, you see things like a checkbox, that has a label 
lasting over several lines. And the screen speckled with ten such 
checkboxes. Trying to move around in such a screen with the speech, is a 
rather tidious process. (for one example, just try Microsoft Essentials. 
There is some of the settings that are rather lengthy reading. Even in 
Windows Controlpanel, you could find certain setttings, where each checkbox 
or button has a whole novel for a label Smile!) And, again, sometimes the 
labels on menus and entries, become that general, that it is hard for the 
user to have any idea as to what will happen when they press Enter or 
Spacebar on the entry. - All just for a general reminder...

----- Original Message ----- 
From: "Chip Orange" <lists3...@comcast.net>
To: <gw-scripting@gwmicro.com>
Sent: Monday, May 30, 2011 11:42 PM
Subject: RE: a "best practices" question


Kevin,

so you're suggesting we provide both?  I'm all in favor of that.

My original question though, not well phrased I see, was should we try to
make configuration options appear in the app menu rather than in their own
dialogs?  Obviously not all configuration options can be done with a 
simple
menu choice, but sometimes, they are just a series of checked/unchecked
options, which can.

Most people seemed to say we should just place a menu choice in the app 
menu
(labeled something like "options") which takes the user to a configuration
options dialog, and that seems fine to me, and so is what I'll work 
towards.

What made me consider this question to begin with was that I had seen some
complex dialogs for setting configuration options, which were not easily
understood.  if the same options were presented as a series of menus and
submenus, they seemed easier to  me to understand and navigate.

menus could only take the place of checkboxes, command buttons,  and radio
buttons, but obviously nothing else.  I happen to have an app being
redesigned though, which had nothing but these for it's configuration
options, and was just wondering which people thought would make the best
design.

Chip


-----Original Message-----
From: Kevin Huber [mailto:kevin.hub...@gmail.com]
Sent: Monday, May 30, 2011 10:38 AM
To: gw-scripting
Subject: Re: a "best practices" question

Hi:
My opinion on the matter is that we should be able to give users a choice 
of
where they want to access the options in an app through a menu or use
hotkeys.  For some, they would rather not memorize keystrokes and just 
have
a menu that allows them to set the options the way they want to set them,
where others would rather memorize the keystrokes so that they don't have 
to
go into a menu every time they want to set or change an option in a
particular script.
I hope I am making sense here.


On 5/24/11, Chip Orange <lists3...@comcast.net> 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:eleph...@tele2.no]
Sent: Tuesday, May 24, 2011 12:40 AM
To: gw-scripting@gwmicro.com
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:j...@bestmidi.com>
To: gw-scripting@gwmicro.com
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  <mailto:lists3...@comcast.net> Orange
To: gw-scripting@gwmicro.com
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:aa...@gwmicro.com]
Sent: Monday, May 23, 2011 9:24 AM
To: gw-scripting@gwmicro.com
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.