Closed
Bug 136236
Opened 22 years ago
Closed 14 years ago
confusion with Publish and Settings Tab in Publish dialog
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: sujay, Assigned: jag+mozilla)
Details
(Whiteboard: custrtm-,publish)
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.
Updated•22 years ago
|
Whiteboard: publish
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)
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.
I totally agree with #1. I still can't understand what data is requested for "HTTP address to browse to:".
Comment 4•22 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•22 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•22 years ago
|
||
Jayesh: Can you describe more specifically what is confusing? Screen shots of another program would be great! thanks.
Comment 7•22 years ago
|
||
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•22 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•22 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: 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•22 years ago
|
||
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.
Status: NEW → ASSIGNED
Updated•22 years ago
|
Comment 11•22 years ago
|
||
Adding custrtm+; may have impact on customization.
Updated•22 years ago
|
Whiteboard: publish [adt2 rtm],custrtm → publish [adt2 rtm],custrtm-
Updated•22 years ago
|
Target Milestone: mozilla1.0 → mozilla1.2beta
Assignee | ||
Updated•22 years ago
|
Whiteboard: publish [adt2 rtm],custrtm- → [adt2 rtm],custrtm-,publish
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.2beta → mozilla1.4alpha
Comment 13•21 years ago
|
||
Composer triage team: need info. We need a UI spec on the dialog changes. Lori, can your team provide this?
Comment 14•21 years ago
|
||
Editor triage team: nsbeta1-
Comment 15•21 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
QA Contact: sujay → composer
Target Milestone: mozilla1.4alpha → ---
Comment 16•15 years ago
|
||
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
Status: NEW → UNCONFIRMED
Comment 17•14 years ago
|
||
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
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•