> Date: Tue, 7 Aug 2012 18:28:56 -0400
> From: j...@jaysmith.com
> To: gimp-user-list@gnome.org
> Subject: Re: [Gimp-user] HATE the new save vs. export behavior

> I just wish the developers would be open to conversation of how both 
> types of workflows could be accommodated efficiently (both efficient for 
> users and in the code).  Closing off that possibility of conversation is 
> perhaps what hurts most of all.  I wish I had enough knowledge to 
> contribute ideas of how to accomplish this while meeting the needs of all.

I agree.  IMHO the quickest way to solve this with MINIMUM total compromises 
is to turn the existing export-not-save message from a
 static message into a prompt with a choice of export/cancel buttons.  
That would require maybe less than a dozen lines of actual program code 
(basically just one logic branch) and rewriting one message string, total.  The 
only developer response 
I've heard to that is a rather terse "go DIY".

...which, if I had the energy to set up a GIMP compiler one of these days and 
do exactly that on my own time, I probably would. :)

I understand that developers don't like how this issue keeps coming up over
 and over again:  It hurts their feelings when, after all the time and 
effort that they spent working on program code (a right thankless 
blue-collar task in and of itself), the first thing they hear out of the
 mouths of their broad userbase is vocal complaints from the 
portion who doesn't like change X.  Unfortunately, as Jay describes the 
hurt emotions are already 100% mutual:  It's the users whose workflows relied on
 the old model who have their feelings hurt first.

Maybe it could have been avoided in advance with better communication 
routes.  The save/export change was e.g. NEVER mentioned 
front and center on GIMP's homepage news, the only discussions were in 
dedicated venues that aren't easily found when not specifically looking for 

Maybe the devs weren't 
expecting the change to be seen as so significant or so controversial?  But 
either way you
 have a lot (not speaking proportionally) of GIMP users downloading the new 
version and feeling 
emotionally blindsided because they heard absolutely zero about GIMP 2.8 not 
letting them "Save" standard file formats like 2.6 did.

BTW, I remember browsing the MS Visual Studio forum archives at some 
point while migrating a program from Visual Basic 6 to VB.Net (what a hell that 
was).  One of 
the VB topics that was highly controversial back in its day was how 
Visual Basic 6 had a convention of a "default form instance" but Visual Studio 
did not:


In C, you create a new form window just like any other object variable -- by 
instantiating its class definition:

> instance = new class_name(...)

> instance.method(...)

In Visual Basic 6.0 and earlier, if your application used only one 
instance of a given form class at a time you could simplify it by 
skipping instantiation altogether and just treating the class name 
itself like a live object variable (comparable to creating a singleton):

> formclassname.method(...)


There were a few conceptual problems with this model in the VS 
environment (e.g. makes it difficult for the IDE to tell between static 
and instanced properties and methods), so when MS released VS2008, they 
dropped it in favor of traditional C-style instantiation.

A lot of old VB users were shocked (insert negative emotion here)
 because the latter method was the user-preferred way of doing 
this in old Visual Basic versions.  (It was the primary way the program's very 
own documentation taught users about accessing form methods, with the 
traditional C-style instantiation held back as an "advanced usage")  The former 
method may be better for several reasons but in 
the end old habits die hard, and a lot of VB users complained about the change.

With VS 2010, MS added (to the VB language bindings only) the notion of a 
"default form instance", where any reference to a 
non-static classname.method() will internally map to something like 
Application.Forms.getDefaultInstance(classname).  The end result is 
similar to the old VB6 behavior:  Convenient, singleton-like references to a 
form object if they need to have it.

> Users become very attached to the software they use.  They start to 
> think of it as "theirs".  They have made a very real investment in time, 
> energy, learning, etc. to use the software.  Users also develop a "brand 
> attachment" that is deeper than most product makers comprehend (users of 
> products will often stick by a product that even they themselves 
> complain about as being inferior -- sort of a Stockholm Syndrome in a 
> different kind of way).

A user's investment in learning how to USE a piece of software is indeed very 
real and absolutely no less than the developer's own investment in building it.

My mother regularly uses Microsoft Works 4.5 (originally designed for Windows 
95) despite knowing that it has a known critical bug in its printing routines 
that prevents her from doing anything print-related (pagination, page margins, 
actual printing).  She refuses to use the newer (and more stable/capable) 
versions of Works.  Why?  It is almost solely because Works 4.5 is an MDI 
application with one master window containing its own child windows inside it, 
so you only have one application window on the system taskbar (loosely 
comparable to Internet browser tabs and GIMP 2.8's single-window mode); the one 
particular thing you can do only with an MDI application is you can tell the 
MDI parent to tile its child window positions within its client area (analogous 
to telling your window manager to tile all open windows), this makes 
copy/pasting between them faster.  It is literally the ONE feature of that 
version that's absolutely critical to her particular workflow (she does a lot 
of copy-paste and side-by-side comparisons between files), which also happens 
to be the same feature that MS deliberately scrapped when designing newer 
versions of Works (which use one application window per file, à la GIMP's 
default multi-window mode, Inkscape and so many other apps).

-- Stratadrake
Numbers may not lie, but neither do they tell the whole truth.

gimp-user-list mailing list

Reply via email to