confusion with Publish and Settings Tab in Publish dialog



16 years ago
8 years ago


(Reporter: sujay, Assigned: jag (Peter Annema))


Firefox Tracking Flags

(Not tracked)


(Whiteboard: custrtm-,publish)



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


16 years ago
Whiteboard: publish

Comment 1

16 years ago
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,  <-- not supposed
to include this file because you're already declaring it in the
other tab(Settings)

Comment 2

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

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


Comment 4

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

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

16 years ago
Jayesh: Can you describe more specifically what is confusing? Screen shots of 
another program would be great! thanks.
Assignee: brade → cmanske
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0

Comment 7

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

FTP adress:
Folder: public_html

In Mozilla I have to write:

Publishing URL:

It's simpler, but less obvious.

Comment 8

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

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

So if I want to give something an address like 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:

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

16 years ago
1. I agree that most ISPs instruct your to use "". 
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.


16 years ago
Keywords: nsbeta1 → nsbeta1+


16 years ago
Whiteboard: publish → publish [adt2 rtm]

Comment 11

16 years ago
Adding custrtm+; may have impact on customization.


16 years ago
Whiteboard: publish [adt2 rtm] → publish [adt2 rtm],custrtm


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


16 years ago
Target Milestone: mozilla1.0 → mozilla1.2beta

Comment 12

15 years ago
-> me
Assignee: cmanske → jaggernaut


15 years ago
Whiteboard: publish [adt2 rtm],custrtm- → [adt2 rtm],custrtm-,publish


15 years ago
Target Milestone: mozilla1.2beta → mozilla1.4alpha

Comment 13

15 years ago
Composer triage team: need info.  We need a UI spec on the dialog changes. 
Lori, can your team provide this?
Keywords: nsbeta1+ → nsbeta1
Whiteboard: [adt2 rtm],custrtm-,publish → [need info],custrtm-,publish

Comment 14

15 years ago
Editor triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info],custrtm-,publish → custrtm-,publish
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.
Product: Browser → Seamonkey
QA Contact: sujay → composer
Target Milestone: mozilla1.4alpha → ---

Comment 16

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

8 years ago
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
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.