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 <[email protected]> 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] > 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:[email protected]> 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. > >
