[Qgis-developer] 'File' versus 'Project'
a.neumann at carto.net
Thu Apr 25 00:26:29 PDT 2013
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
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.
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.
> On Thu, Apr 25, 2013 at 4:59 AM, John C. Tull <jctull at gmail.com> wrote:
>> Hi Larry,
>> On Apr 24, 2013, at 10:09 AM, Larry Shaffer <larrys at dakotacarto.com>
>> On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull <jctull at 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.
>>> 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 :
>> "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.
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
More information about the Qgis-developer