We'd like to add a button labeled "Troubleshooting" to the Publish Progress dialog. This button will only appear if one or more of the user's files fail to publish. The button will point to a new section (not yet written) called "Troubleshooting" in the Composer section of the help system. The context ID for the button should be: comp-doc-publish-troubleshooting.
I'm going to expand this bug to cover all the closely-related UI improvements in the Publish Progress Dialog: 1. Only show the "key" that explains file success/failure: [checkmark]Succeeded X Failed when there are failures. 2. Add the "Troubleshooting" button as Robin suggested. A good place for this is just to the right of the "X Failed" string. It will display only if there is a failure. 3. Use two status lines above the list of files being transferred. The first has the bold string "Publishing..." during upload, and then changes to "Publishing Completed" if publishing succeeds, or "Publishing Failed" if we aborted publishing. Note that if the only error we get is failure to find one or more image files, we *don't* fail completely (see bug 137641). In all other cases, an error results in aborting publishing (i.e., we don't switch the document URL to the remote URL and we restore original image URLs. See bug 134883 for fix to restore image URLs.)
Severity: normal → major
Status: NEW → ASSIGNED
Summary: add Troubleshooting button to Publish Progress dialog when there's a publishing problem → Improve error status reporting and helping user to fix problems in Publish Progress dialog
Target Milestone: --- → mozilla1.0.1
Created attachment 85845 [details] Screen shots showing Publish Progress in various status with the suggested improvements.
Note that the second status line shows a specific, user-friendly message that describes the cause of any failure. The need for these strings was already reported in bug 136432, but we need to do more than simplys add new strings, thus this bug better covers the complete issue of improving the UI. I'll dup that bug to this one.
Summary: Improve error status reporting and helping user to fix problems in Publish Progress dialog → Improve error status reporting and helping user to fix failures with publishing in Publish Progress dialog
*** Bug 136432 has been marked as a duplicate of this bug. ***
As noted in bug 136432, we should help the user solve the error as well as simply giving an error message. Putting all of this in the same string will be very difficult and wordy, so the above suggestion to have a "Troubleshooting" section in the help accessible via a new button seems like a much better solution.
Whiteboard: publish[adt2] → publish[adt2 rtm],custrtm-
Keywords: patch, review
Whiteboard: publish[adt2 rtm],custrtm- → publish[adt2 rtm][FIX IN HAND][need r=,sr=],custrtm-
Comment on attachment 86118 [details] [diff] [review] patch v1 this patch is pretty close; just a few things for Charley to clean up (discussed via aim) Charley is going to have robin give r= to the strings (especially regarding use of punctuation or lack there of) and then put up a final patch.
Attachment #86118 - Flags: needs-work+
+SubdirDoesNotExist=The subdirectory "%dir%" doesn't exist at this site or filename is a subdirectory. I don't understand the second part of this message "...or filename is a subdirectory." Suggested text: "The subdirectory "%dir%" doesn't exist at this site." +FilenameIsSubdir=Filename %file% is a subdirectory name. Please use a different filename. I don't understand how a file name can be the same as a subdirectory name. Doesn't the file name have to end in with an extension (.html, .jpg, etc.)? +Offline=You are currently offline. Click on icon in lower-right corner to go online. "You are currently offline. Click the icon in the lower-right corner of any Composer window to go online." +DiskFull=There is not enough disk space available to write file %file% "There is not enough disk space available to save the file %file%." +FileTooBig=File %file% is to big to upload What is the maximum file size? Is this determined by the server, so can be different for different servers? "The file %file% is too large to upload." +NameTooLong=File or subdirectory name is too long What is the maximum number of chars for the file or subdirectory name? Is this determined by the server, so can be different for different servers? "The file name or subdirectory name is too long."
First, a general question: Should all these messages be sentences and end with a period? re: "SubdirDoesNotExist" and "FilenameIsSubdir" Unfortunately, I found another case in which we get this error code: when subdir is correctly, but user's filename is same as an existing directory. I can't tell the difference between those 2 cases. We don't force ".html" extension for user's filename (they may be saving text and brade doesn't want to do this) and technically "foo.html" is a legal subdirectory name. So if we don't say something like " or filename is a subdirectory.", we will be showing an incorrect message. If user didn't enter a subdir, then we know the real error and can use the "FilenameIsSubdir" message. Yes, I agree this is messy and sucks! I wish we got 2 different error codes. re: "offline" I was trying to keep message as short as possible! Let's use: "You are currently offline. Click the icon in the lower-right corner of any window to go online." (It doesn't have to be a composer window) re: "FileTooBig". This is a file system error and is probably rare. Each file system in each OS will have different limits. re: "NameTooLong" This is also OS-specific and seems to be determined by both source machine and server. Mac, for example only allows 31 characters and filenames will get truncated if longer. We really should add some feedback or limit the length at the time user enters the name, but I didn't want to do that for this release (I plan to for next one). How about: "The filename or subdirectory name..." We use "filename in many places. (again, just trying to be as compact as possible! I'll use exactly what you suggest for others. These are more errors that I don't think we encounter during publishing, so we don't have error strings yet. Are there any here that anyone thinks we should include now? (cc'ing Darin and Doug to get their opinion) //kIsLocked = 2152857614; //const kReadOnly = 2152857619; //const kErrorBindingRedirected = 2152398851; //const kAlreadyConnected = 2152398859; // in netCore.h //const kInProgress = 2152398863; // netCore.h //const kNoContent = 2152398865; // netCore.h //const kUnknownProtocol = 2152398866 // netCore.h //const kFtpLogin = 2152398869; // ftpCore.h //const kFtpCWD = 2152398870; // ftpCore.h //const kFtpPasv = 2152398871; // ftpCore.h //const kFtpPwd = 2152398872; // ftpCore.h //const kDestinationNotDir = 2152857605; //const kTargetDoesNotExist = 2152857606; //const kAlreadyExists = 2152857608; //const kInvalidPath = 2152857609; //const kDirectoryNotEmpty = 2152857620; //const kUnrecognizedPath = 2152857601; //const kUnresolvableSymlink = 2152857602; //const kUnknownType = 2152857604; //const kNotDirectory = 2152857612;
>First, a general question: Should all these messages be sentences and end with >a period? Yes. +SubdirDoesNotExist=The subdirectory "%dir%" doesn't exist at this site or filename is a subdirectory. Suggested text: "The subdirectory "%dir%" doesn't exist at this site, or the file %file% uses the same name as the subdirectory." +FilenameIsSubdir=Filename %file% is a subdirectory name. Please use a different filename. Suggested text: "The file %file% uses the same name as the subdirectory. Please use a different filename." Your other suggestions are OK.
Robin: But your message "The file %file% uses the same name as the subdirectory" implies they used the same text for both filename and subdirectory name. That's probably not the case. The "subdirectory" in this case is *another* subdirectory under the one they enterred: E.g.: Filename = myfile subdirectory = htmlfiles and site has a directory: .../htmlfiles/myfile/ So in this case, the subdirectory "htmlfiles" is correct. The filename "myfile" causes the error because "myfile" is already a "sub-subdirectory". Confusing enough? :-\ So maybe use something like: "The file %file% uses the same name as another subdirectory" ? This really makes me mad. Until I discovered this other problem, a bad subdirectory was one of the clearer messages we had :-(
> Suggested text: "The subdirectory "%dir%" doesn't exist at this > site, or the file %file% uses the same name as the subdirectory." I prefer something like: "The subdirectory "%dir%" doesn't exist at this site, or the file "%file" already exists as a directory on this site." Robin--can you fix it more? Also, Charley--please be consistent about when we use double-quotes and when we don't.
"The filename "%file%" is already in use by another subdirectory." and "The subdirectory "%dir%" doesn't exist at this site, or the filename "%file%" is already in use by another subdirectory."
Created attachment 86261 [details] [diff] [review] patch v2 Changes from reviewers comments. Note one change in feedback for failed file upload: Instead of showing "Some files failed to publish", we now show number of files like this: "X of Y files failed to publish" for the case when there are broken images and we still are "completed" as long as the html file succeeds.
Attachment #86118 - Attachment is obsolete: true
Suggested changes to error message text >>indicated like this<< : +SubdirDoesNotExist=The subdirectory "%dir%" doesn't exist on this site or the >>filename<< "%file%" is already in use by another subdirectory. +FileTooBig=The file "%file%" is >>too<< large to publish. +ServerNotAvailable=>>The server<< is not available. Check your connection and try again later.
Created attachment 86285 [details] [diff] [review] patch v3 More changes from reviewers. Dropped kIsDirectory and kTooBig since we probably will never see those errors.
Attachment #86261 - Attachment is obsolete: true
Comment on attachment 86285 [details] [diff] [review] patch v3 r=brade if the following is removed: -TableCell=Table Cell +TableCell=Table or Cell also, I'd like to see the commented out constants ordered numerically but that shouldn't block this checkin
Attachment #86285 - Flags: review+
r=robinf on error message text
Comment on attachment 86285 [details] [diff] [review] patch v3 sr=hewitt
Attachment #86285 - Flags: superreview+
checked into trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: adt1.0.1, mozilla1.0.1
Resolution: --- → FIXED
Whiteboard: publish[adt2 rtm][FIX IN HAND][need r=,sr=],custrtm- → publish[adt2 rtm][fixed in trunk],custrtm-
When do you expect to have these changes ready to be checked into the branch? l10n really needs all UI changes checked in now. Please advise.
Created attachment 86441 [details] Update to screen shots showing number of failed files message
Attachment #85845 - Attachment is obsolete: true
This fix is a direct result of usability feedback on publishing. People were really confused about the feedback and this bug fixes the problems identified. It's really important to take this for RTM otherwise all the work that we did on publishing will be usability impaired and confusing for users.
sujay, can you verify this on the trunk? Please check in the string changes to after getting drivers approval. Once it's been verified, we'll + the rest of the bug.
l10n approved. Please check this into the branch ASAP. thanks
Comment on attachment 86285 [details] [diff] [review] patch v3 a=chofmann for 1.0.1. add the fixed1.0.1 keyword and remove mozilla1.0.1+ keyword when your checked in on the branch
Attachment #86285 - Flags: approval+
I see the Troubleshooting button. I presume there is a bug filed for the yet to be implemented help section. verified in 6/5 trunk build.
Status: RESOLVED → VERIFIED
There's no bug for adding the Troubleshooting content to help, but it will be done shortly. I'll work with Charley on this. I'll use the help context ID that Charley has defined in his patch: openHelp("comp-doc-publish-troubleshooting");
Just the strings (editor.properties and EditorPublishProgress.dtd) checked into branch.
adt1.0.1+ added, please add fixed1.0.1 keyword when landing.
Keywords: adt1.0.1 → adt1.0.1+
checked into mozilla1.0.1 branch
Keywords: mozilla1.0.1+ → fixed1.0.1
Whiteboard: publish[adt2 rtm][fixed in trunk],custrtm- → publish[adt2 rtm][fixed in trunk and branch],custrtm-
Checked in to commercial trunk and branch: the "Troubleshooting" button now points to a new help section "Solving Common Publishing Problems."
verified in 7/22 branch build.
Keywords: fixed1.0.1 → verified1.0.1
You need to log in before you can comment on or make changes to this bug.