Closed
Bug 148924
Opened 22 years ago
Closed 14 years ago
[RFE] Reorganize Composer Primary Toolbar
Categories
(SeaMonkey :: Composer, enhancement)
SeaMonkey
Composer
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: bamm, Unassigned)
Details
The composer main toolbar should have the following buttons. This list was formed based on user's expectation from an editor. Those marked with an asterisk (*) are already present in composer. New * Open * Save * -- Print * Print Preview Spelling * -- Find -- Cut Copy Paste Delete -- Undo Redo -- Preview * Publish * I understand that this is quite a lot, so some adjustments might have to be made to make them fit.
Reporter | ||
Comment 1•22 years ago
|
||
The above list purposely leaves out the following buttons already in composer's main toolbar: Insert Image Insert Horizontal Rule Insert Table Insert Link Insert Named Anchor These buttons should be placed in the Edit Toolbar instead and made into a dropdown similar to what is found in the Message Compose window for HTML mail. This should produce more UI consistency between components.
Comment 2•22 years ago
|
||
A few suggestions: - We can make the Print button like it is in Navigator, with a dropdown menu that includes Print and Print Preview. - We can put Publish close to Save, since those actions are kinda related. - We can give the Publish button a dropdown menu that includes [Page] Preview, making the Publish button like the Print button. - We can omit the Redo button, since it's used less often than the other buttons. Redo would still be available under the Edit menu. - If the toolbar's still too long, we can omit the Find button and possibly the Delete button, since these aren't used quite as much as the other buttons. Find and Delete will still be available under the Edit menu. Making this toolbar short might help solve Bug 94581. And if this bug gets fixed, I'd like to see the toolbar icons themselves get a facelift, at least in Classic. Right now, they look pretty ugly and inconsistent w/ the rest of Mozilla. This has been a problem even with Composer 4.x. Is there a bug on this?
Reporter | ||
Comment 3•22 years ago
|
||
Composer should follow the "word processor" paradigm. This means catering to people's intuition. The icons should be 16x16 (as opposed to Navigator which is 24x24) and should have no text. If you look at the Composer module using Mozilla's IE Skin, http://mozillako.hypermart.net/ieskin/ you will find that there is a lot of space left over, and there is no need to remove any icons. Furthermore, the icons are intuitive enough for people to immediately know their functions. This is a good time to give Classic and Modern's composer module a facelift.
With my module owner hat on: I strongly disagree with a large part of this bug. A word processor and a web editor don't have the same goals at all. A lot of documents edited in word processors are MADE to be printed; web documents are made to be viewed. I can bet Composer users almost never print from Composer. Having Print button at the left of the toolbar seems to be useless. Preview and Publish are MUCH more important and I certainly don't want to see those buttons pushed to the right end of the toolbar. Furthermore, Standalone Composer will have, as soon as Nvu's code returns to the trunk, customizable toolbars. If we want it, that code will find its way into the MozAppSuite too. This will solve this bug. In the meantime, I am futuring this bug and will refuse patches for the proposed reorganization since I find counter-productive for our product.
Target Milestone: --- → Future
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Assignee: composer → nobody
QA Contact: sujay → composer
Target Milestone: Future → ---
Comment 6•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 7•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
•