<div dir="ltr">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.<div>
<br></div><div style>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. </div>
<div style><br></div><div style>Regards,<br>Nathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 4:59 AM, John C. Tull <span dir="ltr"><<a href="mailto:jctull@gmail.com" target="_blank">jctull@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Larry,<div><div class="h5"><div><br><div><div>On Apr 24, 2013, at 10:09 AM, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hi,<br><br><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull <span dir="ltr"><<a href="mailto:jctull@gmail.com" target="_blank">jctull@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Antonio,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><a href="http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png" target="_blank">http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png</a></div>
<div>
<br></div><div>I think we can achieve the customization desired while maintaining the HIG for OSX.</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div></div></div></div></div></blockquote><div><br></div></div><br></div></div></div><div>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]:</div>
<div><br></div><div>"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."</div>
<div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>John</div><div><br></div><div>[0] <a href="https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html%23//apple_ref/doc/uid/TP30000356-TP6" target="_blank">https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP30000356-TP6</a></div>
</div><br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br></blockquote></div><br></div>