|
> Date: Tue, 7 Aug 2012 18:28:56 -0400
> From: jay 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_ranger hotmail com -------------------- Numbers may not lie, but neither do they tell the whole truth. |