> 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 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
strata_ran...@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.
_______________________________________________
gimp-user-list mailing list
gimp-user-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-user-list
