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
them.
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
