136236 - confusion with Publish and Settings Tab in Publish dialog

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[sujay]

Opening this bug for discussion between Lisa, Sarah and Kathy/Charley.
Lisa/Sarah are having some confusion with the tabs in this dialog.
Other users may have the same confusion.

Lisa/Sarah, what issues do you have here? thanks.

Comment 1

[sujay]

just talked to Sarah, I think the main confusion
here is that users are not sure whether they should include
the filename with the Publish URL and HTTP address to browse
to URL.

for example, http://www.test.com/file.html  <-- not supposed
to include this file because you're already declaring it in the
other tab(Settings)

Comment 2

[lchiang]

My initial confusion was with Site Names.  I saw some URLs listed under site
names and thought that this field was where I would specify the publishing URL.
 I didn't think of going to the Settings tab.    I kept trying to figure out how
to modify the site name since it's just a drop down list.  I wanted to be able
to type in it.

Comment 3

[Kasumi]

I totally agree with #1.
I still can't understand what data is requested for "HTTP address to browse to:".

 

Comment 4

[Susie Wyshak]

Re comment #3 the browse to info is so after editing a page you can see it
published live on the server instead of on your desktop. 

Overall I really think this publishing needs some informal usability testing.
I'm not able to figure it out even after following my ISP's ftp setup info, and
I've previously been using an FTP program. There isn't enough feedback in the
error messages. 

Comment 5

[Jayesh Sheth]

I was having a hard time too figuring out how  the dialog boxes for publishing
work. I have been using FTP for a long time, but Mozilla's publishing feature
really has me confused. (I would like to write the Help information for it, once
I figure it out.) Maybe I can attach screenshots of Arachnophilia's publish
feature ...)

Comment 6

[Charles Manske]

Jayesh: Can you describe more specifically what is confusing? Screen shots of 
another program would be great! thanks.

Comment 7

[Lasse Marøen]

The publishing URL is a bit confusing. Normally one would enter just
ftp.mysite.com, and have a different field for specifying the folder. Like this:

FTP adress: ftp.mysite.com
Folder: public_html

In Mozilla I have to write:

Publishing URL: ftp://ftp.mysite.com/public_html

It's simpler, but less obvious.

Comment 8

[Kathleen :Brade]

Lasse--actually you could configure it separately as you'd like, but you'd need
to put public_html in the other tab (publish) in the Site subdirectory
editfield.  I do understand your point and we'll consider that suggestion along
with the other feedback we'll receive in the next month or so.

Comment 9

[Lasse Marøen]

Brade: Yes I could, but that setting is not available in edit - publishing site
settings. I shouldn't have to enter that folder every time I publish. Most ftp
accounts I use are like this:

ftp://ftp.mysite.com/public_html --> http://www.mysite.com/

So if I want to give something an address like http://www.mysite.com/folder/ I
would have to put public_html/folder in the site subdirectory field. That's a
bit confusing. 

Also a person's site is not necessarily on the top level of the domain. Consider
a case where employees have homepages, like this:

http://www.company.com/people/lasse/

In this case I would like the top level of my site to be specified to the folder
people/lasse even if the ftp account is to the top level of the domain.

Comment 10

[Charles Manske]

1. I agree that most ISPs instruct your to use "ftp.mysite.com". 
I think we should look for "ftp." and automatically prefix the "ftp://" if it
is not there. So the logical next question is, if user's entry doesn't start 
with "ftp." or "ftp://" or "http://", should we automatically prepend "http://"?
2. The issue of user subdirectories is tricky. For my web hosting site, I find
that I do not need to include the subdirectory in the publish url. When file is
published, files go to that subdirectory automatically. But I'm sure there are
servers that require "user" subdirectories to be explicitly appended.
The best way to configure a site is to use the full "base url", including any
user subdirectories as the publishing url. Any other subdirectories should be
entered in the Publish Tab. These subdirectories are remembered for each "Publish
Site" and is much more efficient than creating separate sites whose publish url
includes the subdirectory. This issue is difficult to explain to users, 
especially when the "user" or some other document directory is hidden from the
user, which is often the case (you can see them only if you use a sophisticated
FTP program.)
This is all good feedback and we will definitely use it to write good help 
support and other changes in the UI.

Comment 11

[Christine Wozniak]

Adding custrtm+; may have impact on customization.

Comment 12

[jag (Peter Annema)]

-> me

Comment 13

[Samir Gehani]

Composer triage team: need info.  We need a UI spec on the dialog changes. 
Lori, can your team provide this?

Comment 14

[Samir Gehani]

Editor triage team: nsbeta1-

Comment 15

[Bryce Mozilla Nesbitt]

I get confused because there seem to be three slightly different places to make
publishing settings --> "File->Publish", "File-Publish As" and "Edit->Publishing
Site Settings".  Worse, not all of them offer to set the "site subdirectory".

And if I delete a site publishing profile in one place, it often still shows up
in another.

Comment 16

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420