Hi Chip: I don't think you should blame yourself for not phrasing the question well enough, it might be tatit was probably I, who didn't read it carefully enough. Also, I thought there was a post on this thread talking about people not wanting to memorize a lot of hotkeys, and I was speaking to that. At any rate, concerning your point, The App menu exists for a reason and it would seem to make sense for app authors to use what has been given to us. Some months ago, I tried putting the options of my proofreading script into the app menu, but it didn't work out well so I abandoned the effort. Kevin Huber
On 5/30/11, Chip Orange <[email protected]> wrote: > 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:[email protected]] > 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 <[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. >> >> > >
