Hi all,

here is a spec which claims to clean up the existent save/export features in a consistent manner.

Problems addressed: - insufficient protection from data loss regarding layer & alpha information. This is considered a UI bug [7]. For an example see [1]. - too many dialogs which pop up in an unpredictable manner [5]. Not a bug, but an annoyance - obsoleted Bugs:
#75328 - Add "skip this question" to export dialog boxes. #75459 - Add persistent defaults for the Export dialog #119545 - Merge Export features into the Save dialog #164709 - Export dialog should not allow to ignore mandatory export actions

Rationales: a) the image window must be a reliable view on the image file data. This rules out showing a .png as flagged clean while multiple layers are present [1]. b) the user's data should be protected by warnings. Usability experts disagree here [2], but consistency with the other parts of the application is more important within the scope of this spec. c) format converters should follow the principle of least surprise. That means that the image window of a re-opened converted file should look like the image window of the original file, as closely as possible.

Notes: - Spec Version: Draft 0.6
- Gimp 2.4.2 is referenced as current implementation. - for clarity, the more technical term 'Export' is used in favor of 'Save_a_Copy' throughout this document. See Discussion below.

## User Interface

# Semantics from a user's point of view

Save: Store all my work. I will continue working from there or finish. Save_as: Same as Save, possibly with a notion of changed artistic direction. Export: Store an independent and possibly incomplete copy of my work. I will continue working from what i have in the image window.

Regarding the workflow, Save and Save_as are inline with the workflow, while Export means branching.

# Export

Export never touches the current image (as before). Export and Save_as form the sole interface for file format conversions. In general, there is no need to warn the user about conversion loss as the current image remains unchanged.

The current Export implementation lacks separation of concerns: Format conversion means preserving as much information as possible in the new format, following rationale c). Anything else is part of workflow automation, which should have it's own facility with an interface of it's own (for examples see [3], [4]). Hence the various 'Export File' pop-ups become obsolete. A future automation mechanism might enable users to recreate the removed bits of functionality.

The interface for file sub-type specification (rgb, indexed or grayscale) is Image->Mode. While this menu is not easily discovered in the context of format conversion, its is relevant only for advanced users who desire optimal files. Most users will be satisfied with the defaults (as specified in Conversion Rules below).

Steps: 1 - file selection dialog, titled 'Export image'. Former: 'Save a copy of the image'. 2 - overwrite protection (as before) 3 - internal file type conversion using a copy of the image. See Conversion Rules below 4 - file type specific settings dialog, defaults to OK (as before).

# Save

A successful Save operation syncs the image window with the file contents, flagging the image as clean. Save and Open must be roundtrip save (not considering compression loss). Anything else is considered unsuccessful. The File->Save menu command must be independent of the currently selected drawable [5]. Quite ironically, the Save operations are only place were actual data loss may happen besides the Close operation.

Steps: 1 - check if image is a new, yet unsaved one. In that case switch to Save_as (as before). 2 - check file format capabilities: if successful saving is impossible, offer alternatives in a nag-screen:

# You might loose some data: PNG plugin can't handle layers [...] #
# | Save as .xcf | Use gimp's native format XCF, storing all your data. # You can export your image to PNG format later on. #
# | Export | Only store a copy of your image as PNG. Your image will remain unchanged. #
# | Convert to PNG | Discard all data which doesn't fit into PNG format #
# | Cancel |

3 - possible results: - successful saving possible: do as before. The image gets flagged clean. - 'Save as .xcf': switch to Save_as dialog with extension forced to .xcf. The image gets flagged clean, provided saving is successful. - 'Export': switch to Export dialog, thereby not flagging the image as clean. - 'Convert to PNG': has the same consequences as exporting the image and opening the exported file: all losses are reflected in the image window and the image is flagged clean. The ability to Undo this operation is mandatory. - 'Cancel': as before, of course

# Save_as

differs from Save only by: - first showing the filename selection dialog instead of Save Step 1. - overwrite protection
- and finally updating the image's filename on successful write (works as before regarding the diff).

# Conversion Rules:

All conversion options must be available to the wary user striving for optimal results. Still, the ignorant user should be allowed to rely on sensible defaults without further inquiry.

While gimp_export_image() already handles most conversion details automatically, most of the remaining dialogs are obsoleted by following the WYSIWYG rationale c).

The individual dialogs:

1) Format can't handle layers: merge visible layers or flatten image?

common format affected: .png [3]

Always merge visible layers: If the image has a background, the result will have a background, too. If the image lacks a background, the result will do so as well.

2) Base type conversions

common format affected: .gif [4]

The ignorant user might pay the penalty of suboptimal files sizes. The wary user will convert to the desired base type prior to export.

Image Type Format Capabilities Export Format RGB 0 RGB INDEXED 1 indexed GRAY 1

RGB 1 GRAY INDEXED 1 rgb GRAY 0

RGB 1 INDEXED INDEXED 0 rgb GRAY 1

3) Plug-in can only handle layers as animation frames

options: merge/flatten image, save as animation common format affected: .gif

This case is distinct from the other dialogs: for one of the options it is not possible to manually perform conversion prior to export, notably the animation feature [6].

Making flatten/merge a hard-coded default would disable animations in consequence. Making animations the default would surprise new users.

Thus, it's probably best to nag both advanced and new users by keeping this dialog, as an exception. A future change according to [6] might obsolete the dialog.

4) Warnings dependent on current Drawable

"You are about to save a layer mask" [5] and "You are about to save a channel" common format affected: .jpg

These are obsoleted by the now mandatory use of the generic export routine.

## Coda

# Workflow Examples

1) working with .xcf files: as before.

2) Simple photo editing on a .jpg - Open
- Levels adjustment
- Crop to selection
- Save works as before. Only jpeg-compatible changes were made, so no warning is necessary. - Close no warning here

3) Putting Text on a .png (in-place file editing) - Open bla.png
- Text layer created
- Export to bla.png exporting to currently opened file is admittedly ugly, but consistent. The image stays dirty as the layer data has not been saved. - confirm overwrite protection - check result in web browser
- Modify Text size
- Export to bla.png again
- confirm overwrite protection - check result OK
- last finetuning, e.g. brightness - Save dialog pops up, warning of layer data loss - Convert to PNG (dialog button) layers get merged, image gets saved to bla.png and flagged clean. - Close no warning here

# Bonus

Nag-on-Save could educate the user about the Export/Save distinction by including a hint like "your image has not been saved before. It has only been exported to forgotthat.png 10 minutes ago."
Probably not worth the effort, but might become a spin-off of future workflow automation features.

# Implications

1) It must be allowed to export to a file which is currently openend. Gimp does not monitor file modifications on disk, so this is not a problem. See Workflow example 3)

2) Possibly the plugin-API gets broken by the modified semantics of Save.

# Unresolved Issus (Summary)

- consequences of removing the Export Dialog's Ignore button. This button was introduced for supporting old features of save plugins (true?!?). Currently known use cases: saving the current drawable

- Export to .gif: show 'animation or flatten' dialog?

- Naming: 'Export' or 'Save_a_Copy'?

- plugin-API affected?

- this text features too much discussion for a spec, excluding the following section...

# Discussion

Export vs. Save_a_Copy Despite the thorough use of 'Export' in this document, both names are considered as essentially equal. Export emphasises format conversion, while Save_a_Copy puts the accent on workflow branching. New users probably grasp the meaning of Save_a_Copy faster than that of the technical term Export. For future shorthands, Export might provide cleaner namings. Consider:

Export as analogous to Save as : Export to a file Export analogous to Save : Export to currently openend file Export again : Repeat last export action

In any case, the dialog nomenclature must be consistent. (currently, Save_a_Copy ends up in an 'Export File' dialog, which in turn takes care for format conversion)

## Appendix

[1] Image window bla.png is flagged clean although there is unsaved layer information. Steps to reproduce:
- New image
- Duplicate layer
- Save_as bla.png
- choose 'Export', then 'Save' Save_as_Copy explictly addresses the image as a whole.

Steps to reproduce: - New image
- Duplicate layer (top layer is selected automatically) - Add layer mask (e.g. full opacity) - Save_as bla.jpg
Warning "You are about to save a layer mask" appears - Cancel
- Select the Background layer
- Save_as bla.jpg
Export File Dialog appears instead of above warning

This dialog is now obsolete.

[6] This hints at making 'Animation' a GimpImageBaseType bit, so that the image modes 'Animation RGB', 'Animation GRAY' and 'Animation INDEXED' become available. Thus, an image could be explicitly converted to an animation and back. As an additional advantage, the animation parameters like the framerate could be presented as image properties instead of querying them on saving.

[7] The risk of data loss has been implied in http://bugzilla.gnome.org/show_bug.cgi?id=75328#c4 but is currently not filed as a bug report.

comments, flames, hugs & kisses?

sorry for the length, peter

Hi again,

here's the first correction:

in section Conversion Rules, read 'common format affected' as 'one example of a format affected by this dialog'.

The conversion rules are listed by the current dialogs' texts to present the user's point of view. These dialogs are triggered by format capabilities mismatch and cover all file formats, not just the examples mentioned. Btw, this is a great strength of gimpexport.c

peter

Hi,

Akkana Peck wrote:

gib_mir_mehl@gmx.net writes:

3) Putting Text on a .png (in-place file editing) - Open bla.png
- Text layer created
- Export to bla.png exporting to currently opened file is admittedly ugly, but consistent. The image stays dirty as the layer data has not been saved. - confirm overwrite protection - check result in web browser
- Modify Text size
- Export to bla.png again
- confirm overwrite protection - check result OK
- last finetuning, e.g. brightness - Save dialog pops up, warning of layer data loss - Convert to PNG (dialog button) layers get merged, image gets saved to bla.png and flagged clean. - Close no warning here

Two problems/questions on this workflow:

1. Every checkpoint of the file (saving in case of disaster), something which now is just a Ctrl-S, becomes an operation that requires going through at least one scary dialog (the overwrite one) and sometimes two (at least the first time, where the user has to select the same filename that GIMP already knows).

yes, this is tedious. To support this workflow, an 'Export' command should be added as a companion of the 'Export as' entry. Analogous to Save/Save_as, Export would write to the current file without confirmation while Export_as would ask for a filename. This way, checkpoints become a one-click operation.

Please note that currently Save doesn't work as in 'Save my life' and there is one nag-screen included.

2. Why would a user use Export for every save except the last one, then suddenly switch to using a completely different command to save?

The basic idea is to forbid 'Save' to PNG here. Instead of just disabling the 'Save' command, the nag-screen offers all sensible alternatives. By clicking 'Convert to PNG' in the dialog the data loss is made explicit.

So the reason to use 'Save' in the last operation is to mark the endpoint of the workflow. This way, GIMP knows that no confirmation on Close is required.

How would they learn to do this? Because of GIMP warning them when they try to quit that the file hasn't been properly saved? Won't most users say "But I just saved it!", click Quit Anyway, and then go complain to someone about how GIMP often, but not always, says images haven't been saved when they really have?

yep, they will learn this workflow by the nag-screens if they don't read the manual. From an uninformed user's point of view the sense of 'Export as' is to avoid the nag-screen on 'Save as'. 'Save', in turn, looks like a workaround for the 'Close?' confirmation. Poor user.

This model seems much more confusing for users

agreed, 80%. I don't think the nag-on-save behaviour a good solution myself. It may get accepted as technically sound by advanced users for it's workflow support, but shurely gets low usability grades. I'm quite confident with the Conversion Rules though.

peter

Ingo Ruhnke wrote:

On Sat, Jun 14, 2008 at 4:29 PM, wrote:

The basic idea is to forbid 'Save' to PNG here.

Which of course would be stupid, since PNG is a perfectly valid information-loss-free choice in many cases

err, that sentence was with regard to the example in discussion.

Where loss free saving is possible, no nags would appear (compression loss get neglected). Still this would give some user surprise: "last time ctrl-s worked, but now that i have added some text, ctrl-s gives a nag screen?"

[..]

A useful addition to Gimp would be an auto-save. Not only could it be used to periodically save the image to prevent data loss in case of crashes, it could also be used to store .xcf files for exported files automatically

i bet that's the path GIMP will finally follow.

peter