GUI naming of an operation

[JohnH]

I have an application that has some data/settings that is stored locally, there's also option to backup/restore which zips the data files to local/remote storage.
Remote storage is used to transfer/sync data between computers at different locations.
Lately I added option to put/get the backup using Google Drive folder, which is a local folder that is indirectly sync'ed to web storage by Google synchronizing software.
Now what would I call such an operation?

• Backup to Google Drive (and Restore from)
• Save to Google Drive (and Load from)
• Upload to Google Drive (and Download from)
• Transfer to Google Drive (and Transfer from)

I think Save is the least fitting, that also conflicts with the option of directly saving the various data files at runtime.
As for remote FTP storage I call that operation Upload/Download for obvious reasons.
For Google Drive I initially went for Backup/Restore as it derives from the operation of putting aside a separate zip of the data, that is also what I call the operation of storing the zip locally. I am puzzled however, because every time I see that option in menu I get confused about what it actually means. The ultimate goal is of course to upload/download that zip to/from web storage, but that will not happen if the Google sync software doesn't/can't do its job, then the file will remain in the special local folder, and that is outside my control. Perhaps it would be best to use the more neutral word 'Transfer' after all, which at least in my understanding suggests something in progress?

Getting these thoughts out I'm now considering just using backup/restore and have sub-choices for which location to use, but as a concept it would be interesting to get some feedback as to how you perceive that 'local folder that is supposed to sync to remote storage' idea in terms of the above discussion.

The same goes for Microsoft SkyDrive and all the others of course, they all operate like this it appears.

 

[jmcilhinney]

Backup implies a second copy of data that can be used if the original data is lost or corrupted. If that is what you're doing then I would consider the terms Backup and Restore to be appropriate. If it's the only copy of the data though, I'd say that Save is more appropriate than Backup.

Given that the data is actually going to a local folder first, it's not completely accurate to say "Backup to Google Drive". If you don't mind that white lie in terminology then no harm done but it would be more accurate to say "Backup for Sync to Google Drive". Maybe that's to wordy and might lead to confusion though, although a tool tip could clarify what's actually taking place on that option.

 

[JohnH]

Backup implies a second copy of data

I agree with that when storing the second copy locally, but when I transfer that data to remote storage that is the only copy there.

it would be more accurate to say "Backup for Sync to Google Drive"

"Backup to Google Drive folder" is most accurate as for what this application do. The GD software also refers to the special local folder as "Google Drive folder". It puts the burden on user to know and verify that sync'ing takes place. I've since looked into the Google Drive API and can now make a request/poll to see when remote file is up to date with that stored in GD folder, and can provide this information within the app. With the API it would also be possible to put the file directly into the GD remote storage, the local copy would then be sync'ed down from there afterwards by GD software, but at least it would be a verified upload directly from my app. I think the information about whether sync has taken place is sufficient for my needs, though.