Re: [Gimp-developer] Specs for Export/Save User Interface
Hi, Akkana Peck wrote: [EMAIL PROTECTED] 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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
[EMAIL PROTECTED] wrote: This is definately not a bug. [..] Gimp does all these things correctly. It is aimed at a competant user base, it does not try to be a beginner's guide using different formats. It is true that GIMP provides correct functionality for export/save. The corresponding user interface however must allow the user to form habits. It wouldn't be an urgent problem even if five confirmation steps were required for writing a simple file format. Users form a habit out of it. The problem begins when these steps become unpredictable. Suddenly, the user's habits are considered wrong (this is why users are so upset). The problem gets serious when this may lead to data loss [1]. This is not talking GIMP into an educational tool for beginners. Habits are an inevitable part of human nature. In fact, they are the workhorse of advanced users. If users are not allowed to form secure habits it is a serious bug in the user interface. peter [1] Alexia gave an example: https://lists.xcf.berkeley.edu/lists/gimp-developer/2008-June/020296.html -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
Hi, thank you all for taking the time to consider and being patient with me. It seems what's lacking most is the virtue of patience on my side... I understand now that multiple UIs are too expensive. (As a sidenote, the forking idea doesn't imply to anticipate the UI team's work. More appropriate labels would have been GIMP and GIMP-dirty-and-feature-ladden). The issue of Export/Save/data-loss-protection is in my regard more of a bug which should be fixed as soon as possible than part of UI redesign. As with any fix this might be superseded by a more general solution later on. Now it's not clear to me where to draw the line between useful discussion of potential fixes and uselessly anticipating the UI redesign. Probably by the severity of changes, seen a from user perspective. Any guidance? peter -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
Hi all, Sven Neumann wrote: [..] JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. this is totally true. The problem is that this violates widely accepted UI standards. Usability shows it's ugly side here by demanding conformance to users' expectations even if those were formed by broken standards. In fact, the whole concept of 'Save to Harddisk' is fundamentally broken from a pure UI perspective [1]. Despite of that, the GIMP will have to support the Open-Edit-Save cycle for quite some years. This hints at providing different UIs: one that emphasises on technical soundness and a standard one which potentially jumps through hoops to meet users' expectations. While beeing an ugly thought at first, this opens up a lot of possibilies. Looking from outside, i've gotten the impression that the GIMP project has been beaten by similar issues before. I feel like too many GUI changes got discussed to death, because no one managed to come up with solutions which fit all user groups (let alone the coding perspective). At times, the project gets partially paralyzed by the lack of usability input. Sven's unanswered calls for specs are strewn throughout the archives. Quite paradoxically, splitting UI development into GIMP-Pro and GIMP-Standard could be beneficial for the GIMP as a project. This is not saying that such a split is desirable or unavoidable, the point is that it may speed up UI development by not hunting for the one unified GUI anymore. In case of the Export/Save logic such a solution may even be impossible due to problem roots outside the GIMP. I see the current state of Export/Save as the result of a not-untangled development process. The Pro users, in utter need of Export workflow automation features, get thwarted by useless dialogs (from their perspective), while Standard users are confused and usability measures are shurely subterraneous. No one is happy with that. The corresponding arguments in turn have been ping-ponged for years. Every now and then, someone new comes by and restarts the whole cycle, like myself. If all this energy could be freed for speccing coding less universal UIs, i guess GIMP would make quick advances towards both an efficient Pro interface and a reasonably conforming Standard UI. The golden way, of course, would be to follow the Firefox path and allow new UIs to ripen as plug-ins [2]. This requires an omnipotent plug-in API, thus putting even more burden on the coders (as far as i can see). Dreaming of Adam's Pupus Pipeline[3] for nearly a decade now, i doubt the upcoming GEGL goodness will fill in that role anytime soon. Is it imaginable to have multiple GUIs for the GIMP? peter -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
Hi all, Carl Karsten wrote: proposed spec: File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1] What about using just Import/Export? The GIMP could take care of saving automatically, e.g. by writing XCFs to a private folder. Import/Export work on all filetypes. Closing an image writes an XCF to the private folder. Closed images can be retrieved via File-Recent This leaves open the problem of when to delete the XCFs. Throwing out Open/Save/Save_as_Copy as a whole solves a lot of issues. cheers, peter -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Specs for Export/Save User Interface
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
Re: [Gimp-developer] Specs for Export/Save User Interface
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 -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
Hi, Alchemie foto\grafiche wrote: gib_mir_mehl wrote: Don't all those export troubles disintegrate once we presume a little more confidence in the undo function? More confidence will require a option to save undo history. As it is now once the image is closed its Undo History vanish,forever lost, so can't be used to correct saving's errors This keeps me thinking. Given the case gimp cares for saving the undo history, where should it be stored? Saving inside the image file would create bloat and is not possible for most formats. So it must be saved separately. This is feasible on the local computer. But what if files are transferred between computers and users suddenly miss their undo history? What would a user interface look like for exporting undo history and for merging the history with the image again? Are there already proposals for this? peter -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
Jon Senior wrote: [EMAIL PROTECTED] wrote: What would a user interface look like for exporting undo history and for merging the history with the image again? Are there already proposals for this? Just my take... is this not something that GEGL and the non-destructive editing will take care of? Given the possibility to adjust a curve applied 25 steps ago at any point, the only remaining use for undo will be on drawables. No, i'm thinking of the case where you saved those 25 steps to a jpeg and the next day, sitting in the plane to your customer, you discover that this curve should be tweaked a litte bit more. peter -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Export File dialog question
Hi, from the docs: The export file dialog shows up if the image type does not match the format capabilites. If the user chooses 'Export', a suitably altered copy of the image is used for saving. If the user chooses 'Ignore', the image is fed directly to the save plugin instead. Are there examples where choosing 'Ignore' benefits the user, other than being possibly able to save the current drawable alone? thanks, peter (couldn't find any examples in past discussions) -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
Carl Karsten wrote: proposed spec: File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1] Add File/Import and Export to handle alien formats. Save_as_Copy and Export are the same (the user should be able to export as .xcf). This approach shifts the problems from saving to opening. Additionally, the 'forced .xcf' behaviour can be quite nagging - consider user experience for a quick Levels adjustment to a photo: 1- Open doesn't work 2- Import 3- adjustments, all jpeg-compatible 4- Save only allows .xcf, which is overkill here 5- Step back to Export 6- remaining image mysteriously nags on closing Where i agree with you, is that gimp should support the typical workflow which centers around a .xcf main document with several regularily updated offsprings. But that is another topic. To answer your question: please, A and B. Another idea i'm currently tinkering with: Don't all those export troubles disintegrate once we presume a little more confidence in the undo function? What if Save foo.jpg would actually flatten the image? If that was not intended, the user could easily undo and use Export the next time. Advantage: The result can be seen, with layersalpha being lost. This is much more intuitive than textual explanations... so long, peter -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More intelligent user protection from information loss
Sven Neumann wrote: Hi, On Sat, 2008-06-07 at 14:51 +0200, [EMAIL PROTECTED] wrote: The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'. Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers. That means it makes sense to work on a temporary solution before the big UI overhaul happens? Sounds like a good place to start hacking the gimp .- peter -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] More intelligent user protection from information loss
The current protection mechanism for closing images is insufficient as it
doesn't
differentiate between 'saved' and 'exported'.
Symptom 1:
exporting to .png requires clicking a nag-screen
Sympton 2:
closing a multi-layered image which has been exported before
doesn't give a warning about loosing the unsaved layer information!
So the problem is displaying the correct warning at the wrong time.
The information loss doesn't happen when exporting to .png, but
when closing an image which hasn't been saved to .xcf
Solution:
1) the export warning for flat file formats should be optional ('do not show
this dialog again')
2) closing images, which have not been saved to .xcf, should trigger a warning
('you have already exported this image to .png, but you will loose all your
layering/path
information if you close the image now')
The UI Brainstorm didn't seem the right place to post this,
should i file it as a bug report?
peter
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
