Nicolas wrote: > Peter: > I think you misunderstood what gg is suggesting:
no I did not. I pointed out some facts that close many, many routes in this kind of reasoning. closed and done, yes. 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 founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture _______________________________________________ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list