Re: [Qgis-developer] 'File' versus 'Project'
Hi, I agree - not a big issue to change the menu from File to Project. It also makes sense to me since all of the subentries in this menu relate to the project - and not to files (like shape files, tiffs, etc.) +1 for leaving the first menu entry as Project. It also helps to clarify for people that they are saving a project - and not their edits in files that are open in the project. Things in UI design change over time. Nothing is written into stone and users have to accept that and adapt. I think that the change of the icon set and the UI redesign are way more disruptive thant the change in the menu. But I think they are an improvement. Just look at your favourite applications - lets take webbrowsers - with every version their UI changes a bit - and people do not have problems adapting. Or - if you are a graphic designer - compare the versions of Photoshop, Inkscape, Gimp, etc. - all of them change their UI over time - and yet the users manage to do their jobs - and usually they can do their jobs better with each version. Andreas Am 24.04.2013 23:20, schrieb Nathan Woodrow: As much as HIGs are good they are guidelines at best, they are not meant to tell everyone what to do in every case all the time. Apple, MS, etc don't even follow their own HIGs. If I was proposing to change the colour and style of all the whole interface to red with pink borders and use fully custom widgets then I would say sure follow the HIG and scrap the idea. However changing File - Project was like changing File - Composer in the print composer, it was a bit of a ohh there is no file menu but people handled it fine and no one complained. I would say the composer even feels better now from a UX point of view because that first menu is named after the thing it takes action against. I ran a workshop the other day with some new users, and lots of existing users, all who had only just installed 2.0 for the first time and none freaked out. The menu will only take people two seconds to see and notice that it's the same stuff that is in File and move on with their work. Regards, Nathan On Thu, Apr 25, 2013 at 4:59 AM, John C. Tull jct...@gmail.com wrote: Hi Larry, On Apr 24, 2013, at 10:09 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull jct...@gmail.com wrote: Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Ignoring the other suggestions for a moment, changing the File menu name to Project (or Composer) does not go against the HIG for OS X (the initial discussion of this thread). This has be established. It does affect user expectations, however. I think this is debatable. Per our irc conversation yesterday, there are semantics to what constitutes a document-basis for a program versus a non-document basis. My understanding of the exception in the HIG is that a program that does not have a document that the program operates on can consider removing or renaming the File menu item. From the HIG [0]: In general, each command in the File menu applies to a single file (most commonly, a user-created document). If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it. I consider a map project to be a document, whether it is based off of a physical file, *.qgs, as it currently does or whether it is a record in a db, a possible feature for the future of QGIS. I don't see the wiggle room on the HIG for QGIS consequently. Regards, John [0] https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TP6 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
On 04/25/2013 09:26 AM, Andreas Neumann wrote: Things in UI design change over time. Nothing is written into stone and users have to accept that and adapt. +1 for me too, I didn't even noticed the name changed. I just went there and clicked. I think the main concern is for new users, but new users will be exploring what each menu has to offer. Experienced ones, will just go there automatically. furthermore, changing from file to project we make clear that save saves the project and not the data, maybe even helping avoiding what happened to mad_ on irc yesterday [0] ciao [0] http://irclogs.geoapt.com/qgis/%23qgis.2013-04-24.log -- Marco Bernasocchi http://opengis.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.auwrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Well, my original reaction when I saw the File-Project change was that it's very non-standard, and may cause more cofusion than it's worth. Certainly on OS X, maybe on other systems. People know what the File menu means, even if the main object of an application is a project, or video or email or whatever. Same goes for the Edit menu. And it's standard position is right next to the File menu. Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, and should work in dialog text boxes for copying and pasting text, as well as whatever document editing they may do. Do not move Undo/Redo, more confusion. I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be generally followed or adapted on other systems, and these File and Edit menu changes are a bit radical. On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote: Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
William, I can understand the concern, it was the same thing that went though my mind when I change the composer menu. In the end most people didn't care, or adapted. There are a lot of applications that don't use a file menu and work quite well, I would say better in fact. http://i.imgur.com/t0QZeJK.png Chrome and Firefox http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg AutoCAD Regarding the Edit menu, you will notice that the tools in there are not related to text or documents they only refer to the current feature, or selection of features. If you have a dialog open you can't use that menu, unless the dialog is non model and in that case still doesn't help you as there are no tools to use on text. If the Edit menu is to stay, that is fine however I would suggest a new menu called Feature/s which houses all the current tools in the edit menu minus the Undo/Redo and Copy/Paste Feature. Regards, Nathan On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Well, my original reaction when I saw the File-Project change was that it's very non-standard, and may cause more cofusion than it's worth. Certainly on OS X, maybe on other systems. People know what the File menu means, even if the main object of an application is a project, or video or email or whatever. Same goes for the Edit menu. And it's standard position is right next to the File menu. Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, and should work in dialog text boxes for copying and pasting text, as well as whatever document editing they may do. Do not move Undo/Redo, more confusion. I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be generally followed or adapted on other systems, and these File and Edit menu changes are a bit radical. On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote: Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye
Re: [Qgis-developer] 'File' versus 'Project'
Ok now I see what the discussion is about. Seriously changing File for Project what was the rationale for that? Pretty much standard to use File and it wont cause any confusions. I am going with William on this issue Ing. Antonio Locandro Tegucigalpa, Honduras +504 9503 5747 Need a GPS map for Central America, Asia or South America / Necesitas un mapa GPS para Centro America, Asia o Sur America From: madman...@gmail.com Date: Thu, 25 Apr 2013 01:24:37 +1000 To: kyngch...@kyngchaos.com CC: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] 'File' versus 'Project' William, I can understand the concern, it was the same thing that went though my mind when I change the composer menu. In the end most people didn't care, or adapted. There are a lot of applications that don't use a file menu and work quite well, I would say better in fact. http://i.imgur.com/t0QZeJK.png Chrome and Firefox http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg AutoCAD Regarding the Edit menu, you will notice that the tools in there are not related to text or documents they only refer to the current feature, or selection of features. If you have a dialog open you can't use that menu, unless the dialog is non model and in that case still doesn't help you as there are no tools to use on text. If the Edit menu is to stay, that is fine however I would suggest a new menu called Feature/s which houses all the current tools in the edit menu minus the Undo/Redo and Copy/Paste Feature. Regards, Nathan On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Well, my original reaction when I saw the File-Project change was that it's very non-standard, and may cause more cofusion than it's worth. Certainly on OS X, maybe on other systems. People know what the File menu means, even if the main object of an application is a project, or video or email or whatever. Same goes for the Edit menu. And it's standard position is right next to the File menu. Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, and should work in dialog text boxes for copying and pasting text, as well as whatever document editing they may do. Do not move Undo/Redo, more confusion. I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be generally followed or adapted on other systems, and these File and Edit menu changes are a bit radical. On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote: Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu
Re: [Qgis-developer] 'File' versus 'Project'
Hi Nathan, Here are both of your example programs on OS X. You will see that the menu observes the OS X HIGs with a File and Edit menu item in the main menubar of the OS for both of these applications. http://imgur.com/NaxyYMi Adding changes to Edit to the list of desired updates to the GUI takes this even further afield from standard interface design for OS X. I think you will be disenfranchising one of the supported operating systems with these changes and that it will make more sense to keep the File and Edit layout, in addition to cleaning up some of the other OS X gui issues, like having the Analysis menu item from plugins showing up between the Window and Help menu items. Regards, John On Apr 24, 2013, at 8:24 AM, Nathan Woodrow madman...@gmail.com wrote: William, I can understand the concern, it was the same thing that went though my mind when I change the composer menu. In the end most people didn't care, or adapted. There are a lot of applications that don't use a file menu and work quite well, I would say better in fact. http://i.imgur.com/t0QZeJK.png Chrome and Firefox http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg AutoCAD Regarding the Edit menu, you will notice that the tools in there are not related to text or documents they only refer to the current feature, or selection of features. If you have a dialog open you can't use that menu, unless the dialog is non model and in that case still doesn't help you as there are no tools to use on text. If the Edit menu is to stay, that is fine however I would suggest a new menu called Feature/s which houses all the current tools in the edit menu minus the Undo/Redo and Copy/Paste Feature. Regards, Nathan On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Well, my original reaction when I saw the File-Project change was that it's very non-standard, and may cause more cofusion than it's worth. Certainly on OS X, maybe on other systems. People know what the File menu means, even if the main object of an application is a project, or video or email or whatever. Same goes for the Edit menu. And it's standard position is right next to the File menu. Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, and should work in dialog text boxes for copying and pasting text, as well as whatever document editing they may do. Do not move Undo/Redo, more confusion. I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be generally followed or adapted on other systems, and these File and Edit menu changes are a bit radical. On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote: Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour
Re: [Qgis-developer] 'File' versus 'Project'
Oops, links for last post: [0] https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/art/mn_dualtoggleditems.jpg [1] http://drive.dakotacarto.com/qgis/layer_datasource_submenu.png Larry On Wed, Apr 24, 2013 at 10:46 AM, Larry Shaffer lar...@dakotacarto.comwrote: Hi, On Wed, Apr 24, 2013 at 9:24 AM, Nathan Woodrow madman...@gmail.comwrote: William, I can understand the concern, it was the same thing that went though my mind when I change the composer menu. In the end most people didn't care, or adapted. There are a lot of applications that don't use a file menu and work quite well, I would say better in fact. http://i.imgur.com/t0QZeJK.png Chrome and Firefox http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg AutoCAD Regarding the Edit menu, you will notice that the tools in there are not related to text or documents they only refer to the current feature, or selection of features. If you have a dialog open you can't use that menu, unless the dialog is non model and in that case still doesn't help you as there are no tools to use on text. If the Edit menu is to stay, that is fine however I would suggest a new menu called Feature/s which houses all the current tools in the edit menu minus the Undo/Redo and Copy/Paste Feature. While the Mac HIG clearly states that changing the name of the File menu, or removing the File menu, is fine, the following are definitely not a good idea in my opinion: * Having anything except Edit to the right of File/Project That would not only be unconventional and confusing to users, it gains very little compared to the significance of the change. IMO it should absolutely be avoided. Clearly the Mac convention here is to have File, Edit, [View], [Main Component], [Lesser Component], etc. (older Mac conventions had View more towards right end of bar) This is shown in Apple's Mail program [0], where the main component is a mailbox and the lesser a message. In Photoshop it is: File, Edit, Image, Layer... Following these conventions any Feature menu should be located just right of the Layer menu, and the Layer menu just right of Edit or View. * Moving Layer items into Project menu While using almost all Mac software the File menu is visited only when initiating, saving, exporting, printing, or ending a work session, regardless of whether it is file-based in nature. While working within the session, almost always component menus are used. For example, a similar layer-based program, Photoshop, places all it layer-related actions under the Layer menu, not the Image menu. IMO the Layer menu actions should stay where they are However, the menu could be cleaned up a bit. Having a submenu for adding data sources, and sub-grouping by type with separators, will allow growth of the submenu without cluttering the main Layer menu [1]. * Moving editing function out of Edit menu The main editing currently done in QGIS is on features, aka 'Digitizing' for the toolbar, so it is logical for those editing functions to be under the Edit menu. I agree with William in that undo/redo should always be located there, as well as copy/cut/paste and delete functions. Currently copy/cut/paste refers to only 'features,' which makes no sense if you are not editing features. Those should be generic and only be Copy/Cut/Paste and Delete or Clear, or be dynamic and change relative to what is being edited (that would be more work, though). So, maybe there should be a Digitizing submenu under Edit. Other items that programs commonly place under the Edit menu (some not currently implemented in QGIS) are spell-checking, text manipulations (upper, lower, etc.), special character inserts, select functions (currently under View), find/search functions, and others. So there is functionally room to grow in that menu, outside of just feature editing actions, i.e. Edit menu should not be considered for removal. As a separate suggestion: if we wanted to minimize our menus better and prepare for unknown future functionality grouping and expansion, we could create a Tools main menu, which could have Vector, Raster, Database and Analysis submenus. This would make room for a Feature main menu, for example, and allow future growth within Tools without forcing yet more horizontal growth of the menubar. Downside is that it adds an extra layer of submenu mousing to get to commonly used actions. Regards, Larry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Cheers, John On Apr 24, 2013, at 9:10 AM, Antonio Locandro antoniolocan...@hotmail.com wrote: I am having a second look at the menus and can I ask why would you want to crowd the menus with the same actions you already have icons for in toolbars? e.g. Edit menu has all the same tools as the Advanced Editing Toolbar (I highly doubt users doing serious editing would use menus instead of icons) Layer menu has all this add layer types the same as Manage Layer Toolbar (would look better with just an icon that opens a file dialog to whatever data you need, an universal add data button type) IMHO it seems a waste of space and makes things crowded Ing. Antonio Locandro Tegucigalpa, Honduras +504 9503 5747 Need a GPS map for Central America, Asia or South America / Necesitas un mapa GPS para Centro America, Asia o Sur America From: madman...@gmail.com Date: Wed, 24 Apr 2013 21:07:58 +1000 To: cust...@westnet.com.au CC: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] 'File' versus 'Project' Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi Larry, On Apr 24, 2013, at 9:46 AM, Larry Shaffer lar...@dakotacarto.com wrote: As a separate suggestion: if we wanted to minimize our menus better and prepare for unknown future functionality grouping and expansion, we could create a Tools main menu, which could have Vector, Raster, Database and Analysis submenus. This would make room for a Feature main menu, for example, and allow future growth within Tools without forcing yet more horizontal growth of the menubar. Downside is that it adds an extra layer of submenu mousing to get to commonly used actions. +1 This would help with the problem of the Analysis menu item showing up between the Window and Help menu items. I've often felt that a more consolidated approach like you describe would be much better. And we have the ability to customize all menu item functionality with custom shortcuts, so those that don't like the extra clicks can work around that by creating shortcuts. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi, On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull jct...@gmail.com wrote: Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Ignoring the other suggestions for a moment, changing the File menu name to Project (or Composer) does not go against the HIG for OS X (the initial discussion of this thread). This has be established. It does affect user expectations, however. Cheers, John snip ---8 - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi On Wed, Apr 24, 2013 at 8:10 PM, Antonio Locandro antoniolocan...@hotmail.com wrote: I am having a second look at the menus and can I ask why would you want to crowd the menus with the same actions you already have icons for in toolbars? e.g. Edit menu has all the same tools as the Advanced Editing Toolbar (I highly doubt users doing serious editing would use menus instead of icons) Layer menu has all this add layer types the same as Manage Layer Toolbar (would look better with just an icon that opens a file dialog to whatever data you need, an universal add data button type) IMHO it seems a waste of space and makes things crowded This is frowned apon by HIG folks - all tool buttons etc should be accessible by menus as far as possible - a user may have disabled a toolbar, may have accessibility software that uses the menu system to activate functionality etc. In short adding a toolbar button should never be an excuse for removing a menu item. Regards Tim ** ** *Ing. Antonio Locandro* Tegucigalpa, Honduras +504 9503 5747 Need a GPS map for Central America, Asia or South America / Necesitas un mapa GPS para Centro America, Asia o Sur Americahttp://store.gpstravelmaps.com/?Click=63 http://store.gpstravelmaps.com/?Click=63 -- From: madman...@gmail.com Date: Wed, 24 Apr 2013 21:07:58 +1000 To: cust...@westnet.com.au CC: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] 'File' versus 'Project' Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.auwrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support
Re: [Qgis-developer] 'File' versus 'Project'
Hi Larry, On Apr 24, 2013, at 10:09 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull jct...@gmail.com wrote: Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Ignoring the other suggestions for a moment, changing the File menu name to Project (or Composer) does not go against the HIG for OS X (the initial discussion of this thread). This has be established. It does affect user expectations, however. I think this is debatable. Per our irc conversation yesterday, there are semantics to what constitutes a document-basis for a program versus a non-document basis. My understanding of the exception in the HIG is that a program that does not have a document that the program operates on can consider removing or renaming the File menu item. From the HIG [0]: In general, each command in the File menu applies to a single file (most commonly, a user-created document). If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it. I consider a map project to be a document, whether it is based off of a physical file, *.qgs, as it currently does or whether it is a record in a db, a possible feature for the future of QGIS. I don't see the wiggle room on the HIG for QGIS consequently. Regards, John [0] https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TP6___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
As much as HIGs are good they are guidelines at best, they are not meant to tell everyone what to do in every case all the time. Apple, MS, etc don't even follow their own HIGs. If I was proposing to change the colour and style of all the whole interface to red with pink borders and use fully custom widgets then I would say sure follow the HIG and scrap the idea. However changing File - Project was like changing File - Composer in the print composer, it was a bit of a ohh there is no file menu but people handled it fine and no one complained. I would say the composer even feels better now from a UX point of view because that first menu is named after the thing it takes action against. I ran a workshop the other day with some new users, and lots of existing users, all who had only just installed 2.0 for the first time and none freaked out. The menu will only take people two seconds to see and notice that it's the same stuff that is in File and move on with their work. Regards, Nathan On Thu, Apr 25, 2013 at 4:59 AM, John C. Tull jct...@gmail.com wrote: Hi Larry, On Apr 24, 2013, at 10:09 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull jct...@gmail.com wrote: Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Ignoring the other suggestions for a moment, changing the File menu name to Project (or Composer) does not go against the HIG for OS X (the initial discussion of this thread). This has be established. It does affect user expectations, however. I think this is debatable. Per our irc conversation yesterday, there are semantics to what constitutes a document-basis for a program versus a non-document basis. My understanding of the exception in the HIG is that a program that does not have a document that the program operates on can consider removing or renaming the File menu item. From the HIG [0]: In general, each command in the File menu applies to a single file (most commonly, a user-created document). If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it. I consider a map project to be a document, whether it is based off of a physical file, *.qgs, as it currently does or whether it is a record in a db, a possible feature for the future of QGIS. I don't see the wiggle room on the HIG for QGIS consequently. Regards, John [0] https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TP6 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
On 25/04/2013, at 02:59 , John C. Tull wrote: Hi Larry, On Apr 24, 2013, at 10:09 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull jct...@gmail.com wrote: Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Ignoring the other suggestions for a moment, changing the File menu name to Project (or Composer) does not go against the HIG for OS X (the initial discussion of this thread). This has be established. It does affect user expectations, however. I think this is debatable. Per our irc conversation yesterday, there are semantics to what constitutes a document-basis for a program versus a non-document basis. My understanding of the exception in the HIG is that a program that does not have a document that the program operates on can consider removing or renaming the File menu item. From the HIG [0]: In general, each command in the File menu applies to a single file (most commonly, a user-created document). If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it. I consider a map project to be a document, whether it is based off of a physical file, *.qgs, as it currently does or whether it is a record in a db, a possible feature for the future of QGIS. I don't see the wiggle room on the HIG for QGIS consequently. True enough. It'll look a little odd. It's not going to be quite expected. I'll even agree that a project file is a document of a sort. But GIS programmes, particularly the way QGIS thinks about things use at least 3 different sorts of documents. In this case, Project files, vector files, raster files, then arguably database files and web service files. The menu has them lumped up as File (or Project) and Layers[1]. I think while it will be odd for about 30 seconds, it will make sense and most people will be happy. -ramon. (with apologies for side tracking everyone) [1] I suppose I've always felt a bit odd about the use of File in QGIS's menus because I might touch that once a session, but the vast majority of the files (documents) I use come in through the Layers menu. Doesn't make a great deal of sense to me but such is life. If we're allowed to rename it to something that better reflects the content, then shouldn't that happen? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi, On Tue, Apr 23, 2013 at 2:28 PM, John C. Tull jct...@gmail.com wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John, for bringing this up for consensus. A little of background. The change was made as a GUI setup for the future, for use with database-based projects (which are not currently implemented), and so it matches what a Project is, semantically. It is definitely not Mac-like to not have the File menu, but it does not go against Apple's HIG to rename the File menu... 'If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it.' [0] It does go against what normal Mac users may expect. +1 for keeping it as Project (and for keeping Composer instead of File, too), so we can have 2.0 docs and their screen snaps be as future-proof and cross-platform as possible. [0] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TPXREF105 Regards, Larry Thanks, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
