06-30-2025, 01:22 AM
Geoff: The application knows exactly what it was attempting to do when it failed. The error could have told me that it was trying to write to Google Drive and Google Drive was preventing it. It cxould have told me that the backup set was too large and it ran out of space. It could have told me that there was a failure on my iPad when attempting to assemble the cache file. It could have told me that one (or more) of the songs that it was trying to back up were corrupted and could not be read from. It could have told me that Google Drive was refusing access and that credentials were needed (although I don't know why the process wouldn't check this before it started).
When I posted here, I expected an experienced user would come back and say, "This is a known issue and this is the workaround." Or even: "You're not using the application properly. Go back and read the manual." Instead, we've got to pretend that despite the fact that backing up to Google Drive is a standard part of the application's feature set (i.e., user is not attempting to do something untried and/or unsanctioned), the error I'm experiencing has never occurred before - either in testing or in practice. This is highly unlikely.
In "The Essential Guide to User Interface Design" by Wilbert O. Galitz (3rd Ed., Wiley Publishing, 2007), p. 573, (considered since 1984 the "bible" of U/I design), the author details the constituents of an error message, which include providing user the precise point where the process failed, avoiding technical jargon (e.g., error codes), and providing as much background information as possible to assist user in remediating the issue, including known workarounds and links to online resources. In other words, "An error has occurred" or "The process failed" are wholly rude and improper ways of treating users. (Providing error logging, too, wouldn't hurt.)
The logic that if I back up to my iPad and still cannot upload to Google Drive does not necessarily mean that I do not have a problem with the application. When vendors offer feature sets as part of the licenses that customers purchase, customers have the right to expect that these will work until and unless it can be shown that the issue is indeed "outisde of MS". For example, there could be something about the backup process that Google flags as illegitimate. There could be the case where Google lets user backup directly but not via MS. Regardless, if the vendor has told users that they can back up directly to Google Drive, then we should be able to do so, or at least be provided official doco as to how to get around Google's idiosyncracies. If not, then don't offer the feature in the first place.
How this all plays out is that there is a difference between a "technical" solution (such as backing up locally) and a practical one (actually getting the backed up file to Google Drive). MS offers only four options for backing up: local, Dropbox, Google, OneDrive. On an iPad, "Local" means: sending to iCloud. Even if there's another way to configure this, I can't find it, and now I'm sent down a rabbit hole of trying to figure out how to get a backup file that has been stored in iCloud over to Google Drive. In other words, I cannot tell MS to send the backup to "On My iPad" because whatever it's internal instructions are for "Local", it won't let me choose what local.
Thanks.
When I posted here, I expected an experienced user would come back and say, "This is a known issue and this is the workaround." Or even: "You're not using the application properly. Go back and read the manual." Instead, we've got to pretend that despite the fact that backing up to Google Drive is a standard part of the application's feature set (i.e., user is not attempting to do something untried and/or unsanctioned), the error I'm experiencing has never occurred before - either in testing or in practice. This is highly unlikely.
In "The Essential Guide to User Interface Design" by Wilbert O. Galitz (3rd Ed., Wiley Publishing, 2007), p. 573, (considered since 1984 the "bible" of U/I design), the author details the constituents of an error message, which include providing user the precise point where the process failed, avoiding technical jargon (e.g., error codes), and providing as much background information as possible to assist user in remediating the issue, including known workarounds and links to online resources. In other words, "An error has occurred" or "The process failed" are wholly rude and improper ways of treating users. (Providing error logging, too, wouldn't hurt.)
The logic that if I back up to my iPad and still cannot upload to Google Drive does not necessarily mean that I do not have a problem with the application. When vendors offer feature sets as part of the licenses that customers purchase, customers have the right to expect that these will work until and unless it can be shown that the issue is indeed "outisde of MS". For example, there could be something about the backup process that Google flags as illegitimate. There could be the case where Google lets user backup directly but not via MS. Regardless, if the vendor has told users that they can back up directly to Google Drive, then we should be able to do so, or at least be provided official doco as to how to get around Google's idiosyncracies. If not, then don't offer the feature in the first place.
How this all plays out is that there is a difference between a "technical" solution (such as backing up locally) and a practical one (actually getting the backed up file to Google Drive). MS offers only four options for backing up: local, Dropbox, Google, OneDrive. On an iPad, "Local" means: sending to iCloud. Even if there's another way to configure this, I can't find it, and now I'm sent down a rabbit hole of trying to figure out how to get a backup file that has been stored in iCloud over to Google Drive. In other words, I cannot tell MS to send the backup to "On My iPad" because whatever it's internal instructions are for "Local", it won't let me choose what local.
Thanks.