Re: [Gimp-developer] Bring back normal handling of other file formats

[Jon Nordby <jononor gmail com>]

On 20 June 2012 22:04, Jay Smith <jay jaysmith com> wrote:
> People seem to learn best from adversity.  If you corrupt your own image
> file and did not make a pre-editing backup copy, you just might learn
> something.  However, if that same user is "protected" from doing something
> stupid, then the user will learn nothing.  They will not become a better
> user.  There is a fine line between successfully using the software and
> everything being a "learning by making mistakes" experience.  However, if
> users are coddled, you will simply end up with users that become
> progressively even more ignorant.  If users choose not to read warnings or
> don't take the time to think about and comprehend the meaning of warnings,
> then maybe the users deserve the spanking that they will receive as a result
> of their own action / inaction.  Or is spanking illegal now too?
I do not believe punishment is not a good foundation for teaching
users of software. While perhaps effective in isolation as a teaching
tool, basing the teaching method on it will lead to users being
worried or fearful (due to receiving or anticipating punishment) more
often. We want people to enjoy their tools, not fear them.

Furthermore it encourages dangerous arguments around interaction
design decisions like "we need to teach the user" -> "we need to
punish him for wrong behavior" -> "there needs to be ample opportunity
for wrong behavior" (otherwise he will not learn).

People also learn best when different outcomes follow clearly from
difference actions. The new model of save/export/overwrite makes this
clearer: save will now _always_ save all your data, export will never.

> [Not a serious suggestion] Maybe Gimp should, upon opening a file, make an
> archival copy of that file so that he user who fails to make a pre-editing
> backup copy, the user will be protected from his/herself.
Making a "pre-editing backup copy" shall not be necessary in the first
place. Just follow the model that opened files cannot be changed in a
non-destructive fashion.

We are not there in the general case yet, but for the workflow you
describe below, we are already there. And we have made this more clear
in 2.8+

Open file "myfile.png" -> work -> Export As "myfile_withchange.png"

> Unless something is done to arrive at a reasonable solution, my only remedy
> for my company is to lock down Gimp upgrades at the pre-change (save/export
> mess) level.  When the time comes when the "old" Gimp will no longer run on
> our workstations, we will have to switch to another program ... and retrain
> staff on that other program.  It is a real shame.  I would much prefer that
> my staff would be able to use one SINGLE program for both highly productive
> workflow (open TIFF, make minor tweaks such as Curves, save/close as TIFF)
> and major editing/creation work that does need everything that XCF has to
> offer.
The following article provides information about the workflow in 2.8+,
and suggestions how to get the old one back if you really want it:
http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes


-- 
Jon Nordby - www.jonnor.com