Is File >> Export always redundant when you have File >> Save As...?

Question

Is it better to keep both? Chose one? What criteria would you use to select one over the other? If you had a button you had to name, rather than the menu to store this, would "Export is shorter than Save As" be sufficient criteria to select one over the other? Edit: Would already having a File >> Save or a Save button influence your decision? I think my fear here is that saving to another name is implied in the As... bit.

Answer 1

I would usually consider an "Export" function to have the ability to write the file to a different format than the "native" format for the application. For example, an image editing app might have a "Save as" to save as a different file in the native format, and an "Export" to export the image to a JPEG or other format.

Answer 2

In most applications I use that have both, the Save As is used to save to a native format, but the Export is used to save to a format that is somehow lossy in that if you reopen the file (if that is even possible) some of the information used to create it will not be available any more.

Example: Say you've got a program that generates music. The editor has a score and some instruments to play. You can 'save as' and get a standard gmidi format file, which you can later edit some more if you want to change a track. The export option will also be there to save a MP3, but this won't let you change the file afterwards.

Answer 3

I view [Export] as changing the format of the saved data. Whereas, [Save As] is saving the same format to a different location.

Obviously you could argue this by pointing to the various image editing programs out there where [Save As] lets you do both.

Answer 4

No it is not redundant.

"Save" should be the primary way to save files in formats that don't cause a significant loss / degradation of data.

I would use "Export" for file formats where major loss of fidelity or information is expected (for example, exporting a spreadsheet to txt or csv).

Looking at the inverse operations ("Open" vs. "Import") may be useful -- I think "Open" should be able to immediately read a file, while "Import" may require specifying extra options for parsing it (e.g. marking columns or delimiters to use when getting a table from a txt file).

Export/Import may also imply partial/incomplete support for a format. When I use Save/Open, I'd expect to be able to use the format as the native one, with no loss of data ever.

Answer 5

I'm not sure how this works on other platforms but on the Mac there is the following clear distinction in document-based applications, which has little to do with file format fidelity:

Save As... causes all subsequent Save's to overwrite the file you just created using Save As..., so Save As... modifies the location of the document that you are working with and stores its current state in that new location, while leaving the original copy untouched.

Export does not have this effect, you export to a specific path only once, after that a Save operation will still save to the location of the document as it was before the Export was done.

So, even in an application that supports a plethore of file formats, such as e.g. Excel, which allows you to Save As... to various formats of varying fidelity, an Export command may still make sense.  In fact it makes way more sense than saving (as) a complicated document to .CSV, seemingly retaining any formatting/graphs/etc. in the document, while affecting any subsequent saves to also save to that same lo-fi .CSV file.

Summarizing:  The fundamental difference is not in file format fidelity, or 'how native' a format is, but the conceptual difference —as I described above— leads to a logical distinction in what qualifies (fidelity) a file format to appear in your Save As... choices, and when you might want to relegate it to an Export feature.