Page 1 of 1

File-gt;Save As

Posted: 16 Aug 2009 12:24
by JonAxtell
A simple request to move the File->Gedcom File Tasks->Save a Gedcom File Copy.. menu option to File->Save As.

http://www.fhug.org.uk/wishlist/wldispl ... lwlref=430

ID:3931

File-gt;Save As

Posted: 16 Aug 2009 15:19
by brian1950
Gets my vote, Jon. Why does FH have to be different from virtually every other Windows-based software?

File-gt;Save As

Posted: 16 Aug 2009 17:13
by jmurphy
When I saw your comments that FH4 has moved the 'File -> Save As' command to another menu, I was aghast.

Just because Microsoft has gone mad, and is busily re-arranging the Office menus into some demented new order, does that mean that all programmers must now follow them, like lemmings off a cliff? [eek]

Jan

File-gt;Save As

Posted: 17 Aug 2009 07:39
by ColeValleyGirl
For consistency, should there also be a menu command to save a copy of a project? Where would you suggest this command should go?

File-gt;Save As

Posted: 17 Aug 2009 08:11
by Jane
Jan the reason it's moved I suspect is because if you are using projects, it does not save as for the project only the gedcom file. Hence the move down from the main menu.

File-gt;Save As

Posted: 17 Aug 2009 11:04
by JonAxtell
If File->Save As is not appropriate because of the use of projects, why is there still a File->Save which seems to save just the Gedcom file.

Yes, FH uses projects but it doesn't do much beyond using it to organise sub-folders containing settings and media. Since most of the project's data is in the Gedcom, and most users recognise that the Gedcom is the 'file' a File->Save As would still be logically correct.

If it was an issue, it would be better to have a checkbox in the Save As dialog which allowed the user to save the whole project under a new name. This keeps the File menu structure similar to many other programs which users have become familiar with.

One of the key points in making a program easy to use is to use standard conventions as much as possible. This is because users will have learnt common tasks in other programs, reinforced by the number of program using the same conventions. When a program decides to go a different way the learning curve for users is very steep and can lead to users giving up using the program altogether, therefore such a decision has to be made only when absolutely necessary and when upsetting users is something that is worthwhile in the end because the change increases productivity for example.

Other conventions that FH breaks is the clicking of columns headers for sorting - most programs will alternate the sort on each click whilst FH is different and requires Alt to be pressed, and the method of dragging a diagram - FH is different in requiring a mode button to switch between dragging or not (mode buttons are generally not a good thing in a UI) whilst most programs implement dragging with the mouse button pressed.

File-gt;Save As

Posted: 17 Aug 2009 12:26
by brian1950
Like you, Jon, it bugs me that FH ploughs its own path, yet is Windows-based. So why can't it use standard Windows conventions we all are used to?

I want programs that are consistent and productive, and enjoyable to use. When they aren't, it bugs me that I have to learn a different way of doing things for no good reason.

Also, it frustrates me that user error isn't better shown up. I refer to the awful 'Auto Source Enabled' reminder that is so easily overlooked - still I'm leaving it switched on when its not needed (my request for a clearer reminder is on the Wish List).

For me, FH is the best by a long way of its genre out there. Quite frankly, without it, I'd be lost, and I do enjoy using it. I love its multimedia facility and its customisability. But...

before Calico Pie adds more 'bells and whistles' for its next version, I'd like to see them address as a matter of priority the simple fundamentals first.

Brian

File-gt;Save As

Posted: 04 Sep 2009 12:25
by AdrianBruce
I have some sympathy with this request. Since moving to V4 and projects I've got my project set to auto-open, which means I don't use those dialogs much. So when I came to create a free-standing GEDCOM file the other day, I was floundering around a bit because I didn't remember where things were.
As FH edges towards a 'database' view of the world (i.e. projects) it's only to be expected that there won't be a conventional FILE/SAVE AS menu item. But the present set up feels clunky with a 'Project Window' but menu items for the GEDCOM file.
Maybe there should be a PROJECT menu item _first_, with FILE as the second (despite what I said above!) The 1st menu would have PROJECT/NEW PROJECT; PROJECT/OPEN PROJECT, etc and the 2nd would have FILE/GEDCOM FILE NEW; FILE/GEDCOM FILE OPEN, etc.
Maybe if you're operating in 'project mode', the FILE menu items would be greyed out in favour of PROJECT/EXPORT... menu items.
It is, I feel, important that people should not be confused when choosing between free-standing files and projects - hence my suggestion of the grey-out.