On 06-Mar-2013 16:55, Chris Mohler wrote:
On Wed, Mar 6, 2013 at 6:32 PM, mathog <mathog@...1176...> wrote:
And by real, I mean real. Something most be done faster, or fewer errors made, and so forth. Some tangible benefit must accrue or the change is not worth putting in.
File->Save File->Close File->Open (same file)
If things are missing or changed from step #1, it's not really much of a "save". And I fail to see how using one shortcut instead of another is "having to relearn an important part of the user interface".
The 3 command sequence described above is fine, and that is what happens, and what should happen, when the document creation or Inkscape SVG open (both implicit step 0) has taken place. What we are debating is the meaning of "Save as" and its proposed _redefinition_ which is needed to allow the addition of the proposed "export". In my opinion, and a lot of other peoples', these changes are unnecessary and counter productive for the majority of users. Google for "save as vs. export" and you will find lots of unhappy end users when similar changes have been made elsewhere, notably in GIMP. What you won't find are lots of naive end users demanding these changes before they were implemented.
Historically, and I mean going all the way back to the oldest GUIs (some of which I am old enough to have actually used) the following meanings applied:
1. Save as... (no standard keyboard shortcut, often Ctrl-Shift-S, file menu selection is "Alt-F S" on Windows) Save the file with a new name and possibly also a different format. [Emphasis]It was never intended that these operations would all be conservative[/Emphasis]. Some were of course, but most were not. For instance, saving an MS Word file to plain text was obviously never a conservative operation. Most programs warned when something could or would be lost.
2. Save (keyboard shortcut ctrl-S or apple-S or the equivalent standard for the user interface, file menu selection is "Alt-F A" on Windows) If the working document started from an opened file, save back to it in that format. If a previous "Save as..." had been executed, save to that file in that format. If the document is "new" execute a "Save as..." with the default file format (always conservative) and sometimes a default file name.
3. Export Historically there was no such thing, only "Save" and "Save as..." were used.
I will refer to this for brevity's sake as TSM ("the standard model"). It is pervasive and describes the majority of all applications and notably, as far as I can tell, is used in all of the most common Microsoft applications. In other words, for a lot of people the first two operations have been trained into their wrist ganglia and they do not even think specifically about how they induce these operations, they sort of "just happen". (Similar to typing in one's password, where, at least for me, my hands do the work and I am not consciously thinking about the actual sequence of letters, numbers, and/or symbols.)
Recently the theory has been espoused that the ability to do a nonconservative "save" is dangerous, even if the user is warned, and that the code should "help" the user avoid this tragedy by altering the user interface away from TSM. This theory says that both "Save" and "Save as..." must be conservative. Unfortunately, as I mentioned in a previous note in this thread, the only way to accomplish this is to restrict the supported save formats to whatever the native file format is for the program, perhaps with a few minor variants (compression, older versions, and so forth). These special formats are rarely if ever the desired end format of the person using the program, but they do support every possible document feature. In this model:
1. Save as... (same shortcuts as above) Save the file with a new name in a conservative format. Naive end users will in many cases have no idea what these formats are (ai, xcf, and so forth). If the session was started by opening a file of another type this will change the type of the file stored back to disk to a conservative type.
2. Save (same shortcuts as above) Save the file with a conservative format and the same filename root as a prior "Save as..." or "Export". If the session was started by opening a file of another type, or an "export" to a nonconservative type has been performed, this will change the type of the file stored back to disk to a conservative type.
3. Export (no standard shortcut, no standard file menu selection) Save the file with a new name and a nonconservative format of the user's choice.
I will refer to this as SUM ("Stupid User Model"), since its purpose is to save a dumb end user from losing data by unknowingly saving data to a nonconservative file type.
If the user happens to be working in the program's native file type then "export" will never be used and the program will behave the same as in TSM. However, if the user is NOT working with the native file type, and they are used to TSM, then this is a radical change. From the end user's perspective "save as" is broken because it no longer allows selection of the desired output type. Similarly, "save" is broken in several ways. The first is that if a file of another type is opened, "save" will insist on converting it to the conservative type, which is typically not what the end user wants to do. The second is that when a previous "Export" has been applied to specify the desired output filename and type, save will override the chosen type and default back to the conservative type. The end result is that to save the file to disk as the end users desire they must always employ Export. There is no short form of Export analogous to "Save". Moreover, since "Export" is not part of TSM, there is no standard keyboard shortcut for it. In GIMP (2.8.2) they bound "Shift Ctrl E" to "Export", but there is no keyboard navigation to it, at least as I see it, since "Alt F" pulls down the file menu, but no letters under "Export" are underlined.
For myself, the net result of the SUM changes in GIMP were a degradation in the end user experience. I never had the problem these changes were trying to solve, since I knew already when to save in a conservative format, and when to save in a nonconservative one, so these changes did not "help" in that regard. What they did do is cause me to make numerous saves in the undesired xcf format when I reflexively did a "ctrl-S" followed by an "enter". Even though I know this change is present, since I do not use GIMP frequently, I still reflexively select "save as..." the first time in most sessions, then have to back out, and do "export" to get it to do what I want. I rarely remember the shortcut for "export", as it is nonstandard, and find having to select "export" with a mouse for all of my desired store to disk operations an obnoxious feature of SUM. In summary, these changes only degraded my interaction with GIMP, while providing me with no benefit whatsoever.
The proposed SUM changes to Inkscape would be even more annoying for me than the changes to GIMP were. A great deal of my work with Inkscape revolves around EMF files, I darn well want to be able to open and save those TSM style, and I want my intended end users to be able to do so as well. That we cannot save a filter (for instance) to this format is perfectly acceptable, and having to deal with "export", instead of the STM mechanisms is a net loss in usability for us.
Also, does anybody have evidence that SUM actually saves naive end users from damaging their data? Perhaps it might in some instances, but since there are so many other ways to destroy a drawing, I suspect that the users who were naive enough to lose data through the STM "Save" "Save as" mechanism are probably also degrading their drawings in countless other ways, including minimally, drawing something unintended and then not being able to undo, or applying excessive compression.
How pervasive is TSM and what sort of inroads has SUM made? That is, is there a clear trend from TSM to SUM? Below are the results of a quick survey of some programs on my PC and the first Mac I could find. This table will only look right with a fixed size font, notes are indicated by {number}.
Program Name Save as Export Platform Model MS Word (2010 & 2003) Y N WinXP TSM MS PowerPoint (2010 & 2003) Y N WinXP TSM Firefox Y{1} N WinXP TSM Internet Explorer 8 Y N WinXP TSM Opera Y{11} N WinXP TSM MS Paint Y N WinXP TSM MS Wordpad Y N WinXP TSM ImageMagick Display (1.0) Y N WinXP TSM ImageJ Y N WinXP TSM Chemsketch 12.0 Y Y{2} WinXP TSM Inkscape 0.48.4 Y N WinXP TSM Gimp 2.8.2 Y{3} Y WinXP SUM Scribus 1.3.7 Y{4} Y WinXP SUM LibreOffice 3.6 Draw Y{5} Y{6} WinXP SUM LibreOffice 3.6 Write Y{7} Y{8} WinXP ~SUM Adobe Illustrator CS3 (13.0.1) Y{9} Y{10} Mac SUM Adobe Elements 9 Y N Mac TSM Povray 3.6 Y N WinXP TSM
{1} slight variant: "Save page as" {2} In this program "Save as" and "Export" are synonyms, they list the same file types {3} variants of .xcf {4} variants of .sla {5} variants of .odg {6} 20 common image and object drawing formats {7} variants of .odf and many common word processor formats {8} PDF, .xml, and "MediaWiki" .txt {9} .ai, .eps, .pdf, .svg {10} many common image and object drawing formats {11} Top bar "Save" button invokes the same dialog as "Save as" from the Opera->Page menu.
The results of this limited sample indicate that TSM is pretty much everywhere on Windows and present on at least one commercial program on Macs. SUM is present in a single commercial application (AI CS3) and a few open source programs. There are a few which were a little hard to categorize: LO Write listed some file types in "Save as..." which are so old that I doubt they are fully conservative. I cannot but help wonder if the move to SUM for this group of programs is being advanced by a relatively small cadre of programmers, without benefit of any real analysis of the actual requirements of the end users, or of any demand for this on their part. (Some of the people pushing for this in Inkscape seem to have played the same role in GIMP.)
Finally, what is the evidence that the problem SUM addresses is really so serious that we should consider moving away from TSM? Have any of the developers ever had a naive Inkscape end user actually request the SUM behavior??? (We can count a report of an instance where data loss could have been avoided had SUM been implemented as a request.) Personally I think that if a user did lose data in this way they would learn from their error and not make that mistake again, obviating the need for that user for the SUM change going forward. (Conversely, if they are to dim to learn from this simple error, then SUM isn't going to save them from themselves in hundreds of other places in Inkscape, where plenty of other things can go wrong.)
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech