Re: Specs for Export/Save User Interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Akkana Peck wrote:
> gib_mir_mehl@xxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux