148924 - [RFE] Reorganize Composer Primary Toolbar

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, enhancement)

Description

[Bamm Gabriana]

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.

Comment 1

[Bamm Gabriana]

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

[Minh Nguyễn]

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?

Comment 3

[Bamm Gabriana]

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.

Comment 4

[Kathleen :Brade]

reassign to new account

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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.

Comment 6

[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 7

[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