Re: [Flightgear-devel] Minor menu renaming
On Tue, Dec 28, 2010 at 12:15 PM, Torsten Dreyer wrote: How about adding legendX/legend to the small close button? I've tried that, but unfortunately the X isn't quite centered in the box, and looks very much like the character X rather than a cross. A better solution would be to modify the GUI code so we had an actual close button. I haven't looked to see how difficult that would be. -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
On 1 Jan 2011, at 10:19, Stuart Buchanan wrote: A better solution would be to modify the GUI code so we had an actual close button. I haven't looked to see how difficult that would be. Based on writing some rather complex custom widgets for PUI, I'd say that adding a custom close button should not be tricky. I'd even say it would be 'trivial', but PUI has a knack for making trivial things confusing, if not complex. James -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
For newcomers I'd say it is essential that there are close buttons. When new users try out software they won't browse any documentation. And I'd say that many (most?) users would get confused without close buttons. This seems to be an important non-issue. Maybe there already is an expert option in fg, if not why not add one, and then use this option to generate different dialogues? Cheers, Jari Stuart Buchanan skrev 2010-12-28 01.44: On Mon, Dec 27, 2010 at 8:51 PM, Gijs de Rooy wrote: (Why) do we need two buttons to close a dialog? I recently removed the ones that say Close on most dialogs, replacing them with small buttons in the top right corner. There are quite some dialogs that don't have a normal close button (like Route manager, Aircraft help, Common keys, Property Browser). I personally very much prefer those. You are an expert user, who already knows that the unlabeled box in the top right corner is a button, and what it does. Don't over-estimate the computing knowledge of a new user - they have none of that knowledge, and simply won't know how to dismiss the dialog. Remember - the FG Plib-based FG UI is going to be quite alien to them, as it's not got the same look and feel to the window systems they might be used to. They aren't going to guess that the object in to the top right corner is a button that acts like the X button in the top right of their Windows box, assuming that they even use that. Putting this another way, I'm not aware of any other GUI targetted at non-expert users (i.e. people specifically trained to use that software) that does not provide a clearly labeled button (OK/Cancel/Close) to dismiss every single dialog box within the UI. Frankly, if I'd been aware that you'd removed all the Close buttons, I'd have complained very loudly. I consider that to be a serious usability regression. The reason I've left the top-right button in place is partly for consistency with some of the expert and long-lifed dialogs, and partly so that the top of the dialog box looks like a title bar, with the title of the dialog, the small close button, and a horizontal line. The Close buttons just take up space and block my view on the instruments and environment even more... The dialogs I have added it to are ones which a user will use and then dismiss. I have not added it to dialogs such as the MP Pilot List and Stopwatch, nor do I intend to add it to expert dialogs such as the Property Browser. What other dialogs do you leave open for prolonged periods while flying? IMO, much worse is cluttering up a new users display with dialogs that they cannot dismiss! :) We should teach our users to use the small button in topright corner, else they will have a problem in those dialogs that only have such small button. Besides that, less buttons make things look easier, something that FlightGear lacks accordint to a lot of users. How would you teach our new users? They don't read our documentation. We cannot teach our users to use a small unlabeled button in the top right corner. There simply has to be a clearly labeled button to close the dialog, which is what I'm attempting to ensure it present on all dialogs. On Mon, Dec 27, 2010 at 9:07 PM, Gary Neely wrote: I'd like to back Gijs up here. I've worked in usability studies, and these things make a difference in the user's experience. Minimizing clicking and placing buttons in consistent locations makes for a considerably more pleasant experience. I've also worked on usability studies. One consistent result from them is not to over-estimate the competance of the average user. The change I've made has improved consistency and usability by ensuring that there are clearly labeled buttons to dismiss the dialog on (almost) all the dialogs. I think I've covered all the XML dialogs. In my next pass, I'll go through and modify the C- and Nasal generated ones, with the exception of the dialogs that are clearly intended to remain active for a long time (pilot list, stopwatch), and dialogs targeted specifically at expert users, like the Property Browser. -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise,
Re: [Flightgear-devel] Minor menu renaming
How about adding legendX/legend to the small close button? Torsten -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
On Sun, Dec 26, 2010 at 1:08 PM, Stuart Buchanan wrote: On Sat, Dec 25, 2010 at 11:54 AM, Gijs de Rooy wrote: Looks good to me Stuart! But I do wonder why people feel the need to capitilise each single word. Why isn't it Traffic options, or Tanker controls? I know it's not a big deal, but to me it looks cleaner and clearer... As Jacob pointed out, this varies across applications. A quick check of my open windows shows Firefox using full capitalization, while Code::Blocks uses mixed case. As we've previously used full capitalization in FG, I've made the menu items consistent. On a related note, I've just committed some minor work to make that XML-based dialogs in the GUI consistent. They each now have: - a title on the top - a close button on the top right - a horizontal line separating the title from the rest of the dialog - at minimum a Close button at the bottom of the dialog - a horizontal line separating the buttons on the bottom from the rest of the dialog. There are a couple of exceptions which I've left as-is. For example, the MP pilot list and stopwatch are intended to be left on the screen for extended periods of time, so screen real-estate is important. -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
Hi Stuart wrote: - a close button on the top right - at minimum a Close button at the bottom of the dialog (Why) do we need two buttons to close a dialog? I recently removed the ones that say Close on most dialogs, replacing them with small buttons in the top right corner. There are quite some dialogs that don't have a normal close button (like Route manager, Aircraft help, Common keys, Property Browser). I personally very much prefer those. The Close buttons just take up space and block my view on the instruments and environment even more... We should teach our users to use the small button in topright corner, else they will have a problem in those dialogs that only have such small button. Besides that, less buttons make things look easier, something that FlightGear lacks accordint to a lot of users. Cheers, Gijs -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
On Mon, Dec 27, 2010 at 8:51 PM, Gijs de Rooy wrote: (Why) do we need two buttons to close a dialog? I recently removed the ones that say Close on most dialogs, replacing them with small buttons in the top right corner. There are quite some dialogs that don't have a normal close button (like Route manager, Aircraft help, Common keys, Property Browser). I personally very much prefer those. You are an expert user, who already knows that the unlabeled box in the top right corner is a button, and what it does. Don't over-estimate the computing knowledge of a new user - they have none of that knowledge, and simply won't know how to dismiss the dialog. Remember - the FG Plib-based FG UI is going to be quite alien to them, as it's not got the same look and feel to the window systems they might be used to. They aren't going to guess that the object in to the top right corner is a button that acts like the X button in the top right of their Windows box, assuming that they even use that. Putting this another way, I'm not aware of any other GUI targetted at non-expert users (i.e. people specifically trained to use that software) that does not provide a clearly labeled button (OK/Cancel/Close) to dismiss every single dialog box within the UI. Frankly, if I'd been aware that you'd removed all the Close buttons, I'd have complained very loudly. I consider that to be a serious usability regression. The reason I've left the top-right button in place is partly for consistency with some of the expert and long-lifed dialogs, and partly so that the top of the dialog box looks like a title bar, with the title of the dialog, the small close button, and a horizontal line. The Close buttons just take up space and block my view on the instruments and environment even more... The dialogs I have added it to are ones which a user will use and then dismiss. I have not added it to dialogs such as the MP Pilot List and Stopwatch, nor do I intend to add it to expert dialogs such as the Property Browser. What other dialogs do you leave open for prolonged periods while flying? IMO, much worse is cluttering up a new users display with dialogs that they cannot dismiss! :) We should teach our users to use the small button in topright corner, else they will have a problem in those dialogs that only have such small button. Besides that, less buttons make things look easier, something that FlightGear lacks accordint to a lot of users. How would you teach our new users? They don't read our documentation. We cannot teach our users to use a small unlabeled button in the top right corner. There simply has to be a clearly labeled button to close the dialog, which is what I'm attempting to ensure it present on all dialogs. On Mon, Dec 27, 2010 at 9:07 PM, Gary Neely wrote: I'd like to back Gijs up here. I've worked in usability studies, and these things make a difference in the user's experience. Minimizing clicking and placing buttons in consistent locations makes for a considerably more pleasant experience. I've also worked on usability studies. One consistent result from them is not to over-estimate the competance of the average user. The change I've made has improved consistency and usability by ensuring that there are clearly labeled buttons to dismiss the dialog on (almost) all the dialogs. I think I've covered all the XML dialogs. In my next pass, I'll go through and modify the C- and Nasal generated ones, with the exception of the dialogs that are clearly intended to remain active for a long time (pilot list, stopwatch), and dialogs targeted specifically at expert users, like the Property Browser. -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
On Sat, Dec 25, 2010 at 11:54 AM, Gijs de Rooy wrote: Looks good to me Stuart! But I do wonder why people feel the need to capitilise each single word. Why isn't it Traffic options, or Tanker controls? I know it's not a big deal, but to me it looks cleaner and clearer... As Jacob pointed out, this varies across applications. A quick check of my open windows shows Firefox using full capitalization, while Code::Blocks uses mixed case. As we've previously used full capitalization in FG, I've made the menu items consistent. -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
I've been updating The Manual for the upcoming release, including updating the command reference to include the changes to the menus. Looks good to me Stuart! But I do wonder why people feel the need to capitilise each single word. Why isn't it Traffic options, or Tanker controls? I know it's not a big deal, but to me it looks cleaner and clearer... If we change it, we should do it for all menu items at the same time though, so there's some sort of uniformity. I volunteer for doing that, if there's support for it ;) Cheers and merry Christmas! Gijs -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
On Sat, Dec 25, 2010 at 6:54 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Looks good to me Stuart! But I do wonder why people feel the need to capitilise each single word. Why isn't it Traffic options, or Tanker controls? I know it's not a big deal, but to me it looks cleaner and clearer... If we change it, we should do it for all menu items at the same time though, so there's some sort of uniformity. I volunteer for doing that, if there's support for it ;) Cheers and merry Christmas! Gijs I'm not really partial to one way or the other, and I believe guidelines vary across platforms and such so I think either is fine. I am a believer in consistency though, so I'm definitely in support of making sure they all match. cheers...happy holidays! --Jacob -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Minor menu renaming
Hi Guys, I've been updating The Manual for the upcoming release, including updating the command reference to include the changes to the menus. I came across a couple of menus which seemed mis-named, and for which I've just committed some changes. Specifically: 1) The AI menu had AI prefixed on all the menu items, which seemed redundant given that all these menu items exist under the AI menu. I've made the following changes: AI Options - Traffic Options AI Formation - Wingman Controls AI Tanker - Tanker Controls AI Carrier Options - Carrier Controls AI Scenario Select - Scenario Select 2) Moved Common Aircraft Keys up from the Key References section, and renamed it to Aircraft Help, given that it usually includes more than just key bindings. I think both these changes are pretty uncontroversial and reflect much more closely the dialogs themselves, hence I've just gone ahead and committed the changes. If anyone really objects, or has a better suggestion, I'm happy to back them out. Happy Holidays to everyone! -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
