|
> Date: Sat, 16 Jun 2012 09:16:08 -0400
> From: nicolas robidoux gmail com > To: peter mmiworks net > CC: gimp-developer-list gnome org > Subject: Re: [Gimp-developer] present xcf as what it is, a gimp project file format > > Terminology matters. > > A lot. > > > - I would be yanking the chain of one million users if I specced > > that the only way to get a non-GIMP file into GIMP is by File->Import... > > I just don't understand this statement. If it is yanking their chain, > when actually this is what is being done, there is cognitive > dissonance. If "open" actually imports, call it import. > The term "Import" also has a well-entrenched meaning of "copy and paste from source file into current document". GIMP already has such a function, the "Open As (Layer/etc)..." commands. > From: peter mmiworks net > Date: Sat, 16 Jun 2012 16:23:57 +0200 > To: nicolas robidoux gmail com > CC: gimp-developer-list gnome org > Subject: Re: [Gimp-developer] present xcf as what it is, a gimp project file format > > let me first make a statement: > > _every_ time (yes, that is around a hundred times now) that I > see this kind of user feedback (that it is normal to open a > non-GIMP file, do some edits, then save it to the same format) > I start to think like interaction designers should: > > let’s assume he is right. make it ‘just work.’ > > and every time I run into the same problems, that are giant > usability bloopers. > > - to really Save the contents of the file has to match what is > on the screen (save, quit, restart, open file: no change--undo > history excepted). this is not just a good idea, this is the law. > breaking the law: usability blooper. > > - this means that either all users would have to have intimate > knowledge of file formats to know why the option to save to them > disappear as edits are done (usability blooper. bit of alpha is > introduced? no more jpeg; any layers? no more png; paths and > layers? tiff is still there???) or one is doing the whole export thing > anyway, so what is the difference (exporting is not safe, remember?) > where are the extra hoops? > > - the alternative would be to limit things: > > > - it is 100% impossible to arrange it for popular non-GIMP files > > (png/jpeg/tiff) there would be a mode where one could Open one, > > make edits within the limits of the file format, and write the > > bits straight back to a file in the same format. > > a multi-personality application: complete usability disaster. > > and that is where it stops. > > --ps Various apps that still support saving in other than their preferred native formats (e.g. MS Word) frequently detect and warn the user that the non-native format may not support some of the features in their document, in other words that what gets written to disk cannot necessarily be a perfect representation of the open document as it looks in the editor. It may be an ACCEPTABLE facsimile of it depending on how much was and was not recorded (i.e: the presence of an alpha channel means only that the image CAN contain transparent pixels; it does not mean the image DOES in fact contain transparent pixels), but it is the user's responsibility to make that call, not the program's. Remember, GIMP up to 2.6 was perfectly capable of detecting whether or not the image contained data that could not be stored in the target file format and offering the user options to resolve these differences before writing to disk. -- Stratadrake strata_ranger hotmail com -------------------- Numbers may not lie, but neither do they tell the whole truth. |