Doug, My Bad, in posing the question in the way I did. I didn't mean to focus on the "help and options" button, and I did just call it the "help" button. I was only trying to ask if people thought a menu only interface was friendlier than a dialog one for options (since we have this nice app menu now). In trying to say why I thought it might be, in somehow turned into unintended criticism of the "help and options" button. thanks. Chip
_____ From: Doug Geoffray [mailto:[email protected]] Sent: Tuesday, May 24, 2011 9:55 AM To: [email protected] Subject: Re: a "best practices" question Nobody but Aaron has acknowledged that the button in the App Manager dialog is called "Help and Options". Everyone else seems to think this is just called "Help". As Aaron mentioned, this was called this because when 7.0 first came out this was the only way for a user to get help or options without knowing a specific hotkey an app may or may not provide. We later realized that having all users go to the App Manager dialog for help and / or options was not a good approach. It was far to complicated for most users. This is exactly why we now have the Apps menu option right off the main Window-Eyes menu bar. This is far easier for a user. Than it is up to the app author as to what they put in their entry under the apps menu. GW Micro has standardized on creating a sub menu with at least a help option and if necessary an options entry and/or anything else relevant to that app. Take a look at the factory GW Micro apps in the Apps menu. We left the Help and Options button in the App Manager for backwards compatibility but do not (and I stress do not) believe this is or should be expected to be the main interface into your app for help or options. The apps menu should be the first place any new user to an app should be going. The App Manager really is a more advanced dialog that beginning users should have no need to go into. The Help and Options button is just grandfathered in. Doug On 5/24/2011 7:47 AM, Chip Orange wrote: Yes, and I think Aaron was proposing mostly the same solution (except for the help in app manager going directly into a preferences dialog). Yes, nothing says I have to, but I think it's better for our users if we present them with a consistent interface from one app to the next, as far as it's possible. and of course, I wanted to hear other opinions, so thanks for yours. I think I will change my ways, and if it's more than a single menu choice, I think I'll add a choice for "preferences" to go to a dialog; like you though, I don't care for help in app manager not going directly to help, so I'll leave that as standard help dialog. Chip _____ From: J.J. Meddaugh [mailto:[email protected]] Sent: Monday, May 23, 2011 9:28 PM To: [email protected] 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] 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.
