saul goode wrote: >> So here is a short spec: >> >> <http://gui.gimp.org/index.php/Save_%2B_export_specification> > > If you are accepting feedback on the spec, yep > I should like to submit the following: > Under the section "exporting files", the command names "Export...", > "Save back", and "Save as template" are confusing. For the latter two, > using the word "save" runs counter to one of the main purposes of this > exercise -- that is to say, we don't want the user to think that > exported data is "safe" so why would we use the word "save" when > exporting. I think you are bringing up some good points. I had already been doubting between ‘Export back’ and ‘Save back’. up to now I felt that the ‘Save back’ construct had the benefit of some familiarity. but your arguments bite. good also that you point out about ‘Save as template’ that does not even go through a (save) file dialog. I think ‘Create template’ will solve the problem. > "Save back" in particular is confusing. Not only does employment of > the term "save" lead to expectations of data safety and behavior > consistent with the other Save commands, but "back" is ambiguous and > generates more questions than it answers (what is being saved, a > back?, or if back is a place, where?, how far back?). first of all I want to point out that the full text of the menu item would be “Save back to <filename>” when the item becomes available. Example: “Save back to foo.jpg” but now I will speed straight past the alternative “Export back to foo.jpg” and optimise that to: “Export to foo.jpg” that looks clear. greyed out the item would read “Export to” > Would it not be preferable to substitute "Export" for the spec's 'Save > Back' command label, and to substitute "Export As..." for the spec's > 'Export...' command. I don't see the reasoning behind the name > juggling -- why deviate so dramatically from the logic underlying the > naming of the "Save" and "Save As..." commands? Excepting for the > name/status handling of the image, the correlation should be > Save<=>Export and SaveAs...<=>ExportAs... although tempting the equivalence does not hold. this is because there is a strong, 2-way link between GIMP files and what you see in the document window, and a weak, 1-way link between file exported to and what you see in the document window. > I also think that it must be possible to "export" to GIMP file types. > This is necessary so that more than one version of GIMP data files can > be supported. (ie, GIMP 4.0 might still need to create GIMP 2.x > compatible files). In fact, "Saving" should be limited to the latest > preferred GIMP-native file format, while requiring that deprecated > formats should be "Exported". when the time comes it will work like that. but to be clear, there will be no export to the latest preferred GIMP-native file format, because it is not an export. > It may also be useful if this "export" capability permitted the saving > of single-layers, layermasks, channels, or eventually groups/branches > of layers (under GEGL) to native GIMP formats. Such may not be, or > ever become, useful but nonetheless I see little benefit to > prohibiting exportation to native GIMP formats. the challenge will be to elegantly save/export layers and masks without ballooning the number of menu items/buttons involved, or hurting the main priority of saving the whole document. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
