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

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...2164...e.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel