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

VERIFIED FIXED in mozilla1.0.1

Status

SeaMonkey
Composer
--
major
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: robinf, Assigned: Charles Manske)

Tracking

Trunk
mozilla1.0.1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: publish[adt2 rtm][fixed in trunk and branch],custrtm-)

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
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
Keywords: nsbeta1+
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
Whiteboard: publish[adt2]
Target Milestone: --- → mozilla1.0.1
(Assignee)

Comment 2

16 years ago
Created attachment 85845 [details]
Screen shots showing Publish Progress in various status with the suggested improvements.
(Assignee)

Comment 3

16 years ago
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
(Assignee)

Comment 4

16 years ago
*** Bug 136432 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

16 years ago
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.
(Assignee)

Updated

16 years ago
Whiteboard: publish[adt2] → publish[adt2 rtm],custrtm-
(Assignee)

Comment 6

16 years ago
Created attachment 86118 [details] [diff] [review]
patch v1
(Assignee)

Updated

16 years ago
Keywords: patch, review
Whiteboard: publish[adt2 rtm],custrtm- → publish[adt2 rtm][FIX IN HAND][need r=,sr=],custrtm-

Comment 7

16 years ago
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+
(Reporter)

Comment 8

16 years ago
+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."
(Assignee)

Comment 9

16 years ago
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;
(Reporter)

Comment 10

16 years ago
>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.
(Assignee)

Comment 11

16 years ago
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

16 years ago
> 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.
(Reporter)

Comment 13

16 years ago
"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."
(Assignee)

Comment 14

16 years ago
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
(Reporter)

Comment 15

16 years ago
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.

(Assignee)

Comment 16

16 years ago
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 17

16 years ago
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+
(Reporter)

Comment 18

16 years ago
r=robinf on error message text

Comment 19

16 years ago
Comment on attachment 86285 [details] [diff] [review]
patch v3

sr=hewitt
Attachment #86285 - Flags: superreview+
(Assignee)

Comment 20

16 years ago
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-

Comment 21

16 years ago
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. 
(Assignee)

Updated

16 years ago
Blocks: 137641
(Assignee)

Comment 22

16 years ago
Created attachment 86441 [details]
Update to screen shots showing number of failed files message
Attachment #85845 - Attachment is obsolete: true

Comment 23

16 years ago
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

16 years ago
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

16 years ago
l10n approved. Please check this into the branch ASAP. thanks

Comment 26

16 years ago
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+

Updated

16 years ago
Keywords: mozilla1.0.1 → mozilla1.0.1+

Comment 27

16 years ago
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
(Reporter)

Comment 28

16 years ago
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");
(Assignee)

Comment 29

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

Comment 30

16 years ago
adt1.0.1+ added, please add fixed1.0.1 keyword when landing.
Keywords: adt1.0.1 → adt1.0.1+
(Assignee)

Comment 31

16 years ago
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-
(Reporter)

Comment 32

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

Comment 33

16 years ago
verified in 7/22 branch build.
Keywords: fixed1.0.1 → verified1.0.1
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.