148425 - Improve error status reporting and helping user to fix failures with publishing in Publish Progress dialog

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[robinf]

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.

Comment 1

[Charles Manske]

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.)

Comment 2

[Charles Manske]

Attachment: Screen shots showing Publish Progress in various status with the suggested improvements.

Comment 3

[Charles Manske]

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.

Comment 4

[Charles Manske]

*** Bug 136432 has been marked as a duplicate of this bug. ***

Comment 5

[Charles Manske]

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.

Comment 6

[Charles Manske]

Attachment: patch v1

Comment 7

[Kathleen :Brade]

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.

Comment 8

[robinf]

+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."

Comment 9

[Charles Manske]

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;

Comment 10

[robinf]

>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.

Comment 11

[Charles Manske]

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 :-(

Comment 12

[Kathleen :Brade]

> 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.

Comment 13

[robinf]

"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."

Comment 14

[Charles Manske]

Attachment: 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.

Comment 15

[robinf]

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.

Comment 16

[Charles Manske]

Attachment: patch v3

More changes from reviewers. Dropped kIsDirectory and kTooBig since we probably

will never see those errors.

Comment 17

[Kathleen :Brade]

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

Comment 18

[robinf]

r=robinf on error message text

Comment 19

[Joe Hewitt (gone)]

Comment on attachment 86285 [details] [diff] [review]
patch v3

sr=hewitt

Comment 20

[Charles Manske]

checked into trunk

Comment 21

[Michele Carlson]

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. 

Comment 22

[Charles Manske]

Attachment: Update to screen shots showing number of failed files message

Comment 23

[Lori Kaplan]

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. 

Comment 24

[scottputterman]

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.

Comment 25

[Michele Carlson]

l10n approved. Please check this into the branch ASAP. thanks

Comment 26

[chris hofmann]

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

Comment 27

[sujay]

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.

Comment 28

[robinf]

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");

Comment 29

[Charles Manske]

Just the strings (editor.properties and EditorPublishProgress.dtd) checked into
branch.

Comment 30

[Syd Logan]

adt1.0.1+ added, please add fixed1.0.1 keyword when landing.

Comment 31

[Charles Manske]

checked into mozilla1.0.1 branch

Comment 32

[robinf]

Checked in to commercial trunk and branch: the "Troubleshooting" button now
points to a new help section "Solving Common Publishing Problems."

Comment 33

[sujay]

verified in 7/22 branch build.