<jdub> xkahn: maybe the html toggle should be [x] HTML on the toolbar?
<xkahn> jdub: instead of a button have text?
<jdub> xkahn: yeah, i would not think to look at the main toolbar, or identify that icon
<xkahn> jdub: There certainly is a lot more space now...
<jdub> perhaps at the far right on the editor toolbar?

Looking at the HTML mode again, this might not be doable due to space issues - but I'm pretty sure pushing this to the editor toolbar and self-documenting the switch would help.

Alternatively, perhaps it's reasonable to just leave this in the menu only...

I am actively using Evolution and addition to that supporting Outlook users on every day basis and I can say that leaving it only in a menu defeats it's purpose, because it is heavily used toggle and should be easily accessible (otherwise users are confused). I think it should look more like Ben Kahn have described it here: 
http://xkahn.zoned.net/blog/2007/02/18/fixing-the-evolution-composer/

Moving the list modes out of that popup will create some weird interactions
between the controls; you can't have a paragraph which is both "preformat"
and "bulleted list", which is obvious with the current controls, but might
be confusing with yours.

Maybe just changing "Normal" to "Word wrap" is fix enough? (Although there's
also the problem that "Word wrap" suggests that that's the *only* style that
does word wrap, when in fact, it's only "Preformat" that *doesn't*.)

I've always hated the name "Preformat" too anyway (bug 203079). If we weren't
tight on horizontal space, we could do "Word-wrapped Paragraphs" and
"Preformatted Text". If we moved the HTML-only bits onto a separate toolbar,
that would give more space for the style names, and also give enough room to
improve the font size pop up by changing "-1" to "Small", etc.

> Solution:
> 
> * Remove the insert toolbar items from the top toolbar and replace it with a
> toggle button for switching HTML mode

Sounds fine. As jdub pointed out, it might introduce space constraints in some resolutions (800x600 atleast, not sure of 1024x768). I like the idea to have a toolbar item to switch to html. But it may not be a nice idea to replace the insert tool buttons with a menu. I would prefer this to go as toolbuttons only.

> * Move the list types OUT of the style dropdown and make them toggle buttons in
> the lower toolbar
There are few ambiguity as Dan pointed out. One thing that can be done, is to see what others do and take a decision towards that. I dont say that all of them are correct, but atleast helps us to reach an concensus.

> * Rename "Normal" to "Wordwrap"
Should be fine. But we need to see, do we really hide out any meaning that the other word conveyed.

> * Provide separate toolbar items depending on editing mode
This will be really cool IMHO. 
> 

*** Bug 262005 has been marked as a duplicate of this bug. ***

Something else to consider for the style toolbar:

   (Bug #262005)
   In the composer window, the menu Insert->Smiley could be difficult to use
   if gconf key /desktop/gnome/interface/menus_have_icons is false.
   A good compliment would be a Gaim-style smiley button in the formatting
   toolbar, with a popup chart showing all the smileys as WYSIWYG.

Bumping version to a stable release.

If configured to compose in plain text, the drop down list of Normal, HeaderN, Preformatted, etc, lists the HeaderN's and Address grayed out/non selectable between Normal and the remainder of the selectable entries.  Can the list be designed to not show non selectable entries at all, or ordered such that non selectable items are at the bottom?

Add this to my "new composer" tracker bug (bug #522153).

Ben, any other thoughts here?  I'm looking to actually implement these recommendations soon.

Some other related bugs to consider:

Bug #238255: Format->Heading is a bad name for the paragraph mode
Bug #244888: No standard formatting shortcuts available in message editor
Bug #245426: Duplicate functionality in menubar in Compose a message dialog
Bug #246238: Consistent order of items in Format menu and toolbar of composition
             window

*** Bug 246238 has been marked as a duplicate of this bug. ***

Created attachment 113225 [details] [review]
Proposed patch

Thought I'd take a crack at some of the ideas here, particularly Dan's idea of having a separate toolbar for HTML-only items.  With Bonobo out of the way it was suprisingly easy.  See the subsequent screenshots.

Couple outstanding issues:

  - I'd still like to use names instead of numbers to describe font sizes,
    but I ran out of adjectives around +3.

       -2 -> Smaller      +2 -> Larger
       -1 -> Small        +3 -> ????
       +0 -> Normal       +4 -> ????
       +1 -> Large

  - Paragraph style choices could still use some rewording and/or reordering,
    but I don't have any strong opinions here.

Created attachment 113226 [details]
Toolbar Proposal (Text Mode)

Created attachment 113227 [details]
Toolbar Proposal (HTML Mode)

Note: The screenshots are from the test editor program in GtkHTML, not the full message composer in Evolution.  But you get the idea.

*** Bug 202638 has been marked as a duplicate of this bug. ***

*** Bug 203985 has been marked as a duplicate of this bug. ***

Matt, looks awesome, but I have no great suggestions for wordings. 

Ben / Dan / Reid / anyone - Care to weigh in before I commit this?

The mockups look fine to me.  I don't see anything off-kilter.(In reply to comment #19)
> Ben / Dan / Reid / anyone - Care to weigh in before I commit this?
> 

The mockups look fine to me.  I don't see anything off-kilter.

The HTML-mode toggle button is really confusing, but I assume that's part of the test program, not part of your changes?

No, it's part of the changes.  It just matches what's in the menu.

How can we make it less confusing?

Don't use a toggle button. When it's untoggled, it looks just like it's just a label, telling you that "HTML" is the *current* mode. I think making it a combobox with "Plain Text" and "HTML" options would be clearer.

Created attachment 113278 [details]
Revised Toolbar Proposal (Text Mode)

I see your point, though a combo box seems a tad excessive if there's only two modes to choose from.  What about using two toggle buttons?

(I also altered the Format menu to use radio items for the two modes.)

Created attachment 113279 [details]
Revised Toolbar Proposal (HTML Mode)

Created attachment 113280 [details] [review]
Revised patch

Implements the two screenshots above.

yeah, that works

Matthew, I really like the two toolbar solution.  It looks good and probably
feels nice to use.

But I agree with Dan.  A dropdown for the mode switch would look and feel a lot
better:

 [ Plain Text \/ ]
   ---------------
  | Plain Text    |
  | HTML          |
   ---------------

Your screenshots also don't list what the "Normal" drop down should look like. 
As in my first comment, I'd like to see "Normal" renamed to "Word Wrap".  I
think removing the "Header" and "Address" lines from this list would also help.
 And, I think there should only be one list item here:

 [ Word Wrap \/ ]
   --------------
  | Word Wrap    |
  | Preformat    |
  | List         |
   --------------

Although I don't feel strongly about it, what if the alignment buttons were
instead a dropdown, similar to how thunderbird does alignment?  In this case,
the icon should always reflect the current alignment state.

Two toggle list type buttons should be immediately to the left of the indent
controls without a separator: bulleted and numbered.  These buttons work in the
following way:

* If the user selects the "list" item in the dropdown, the bullet toolbar
button is selected. 
* If the user un-toggles the bullet toolbar button, the dropdown changes to
"word wrap" again
* If the user activates the bullet item when the numbered item is selected, the
list type is changed to bullet from numbered
* If the user activates the numbered item when in "word wrap" mode, the
dropdown changes to "list"

As for the second toolbar:

I like the idea of renaming the font sizes away from the +n scheme.  Maybe this
naming scheme:

Smaller
Small
Medium
Large
X-Large
XX-Large
Huge
---------
Header 1
Header 2
Header 3
Header 4
Header 5
Header 6
Address

I like "medium" much better than "normal," especially as a default.  The
"Header" items should also be in this menu, especially since font size and
header can't both be selected at the same time.

I'll attach a mockup.

Created attachment 113287 [details]
Mockup of slightly modified composer toolbars

Actually, maybe you don't even need a text/html switcher on the toolbar. I suspect most people want to use one or the other most of the time, and only rarely need to switch to the other kind, and so having it only in the menu is probably fine. (No, I don't have any actual data. :-)

(In reply to comment #28)
> I like the idea of renaming the font sizes away from the +n scheme.  Maybe this
> naming scheme:
> 
> Smaller
> Small
> Medium
> Large
> X-Large
> XX-Large
> Huge

But "+4" means base size *plus* 4, not base size *times* 4. It's hardly "Huge".

Maybe drop the menu altogether and use a slider instead? (With a tiny "A" on one side and a big "A" on the other.)

(And I'm just nitpicking at this point.)

(In reply to comment #30)
> Actually, maybe you don't even need a text/html switcher on the toolbar. I
> suspect most people want to use one or the other most of the time, and only
> rarely need to switch to the other kind, and so having it only in the menu is
> probably fine. (No, I don't have any actual data. :-)

That's certainly true for us hacker types, but see comment #2.

I guess this gets back to Ben's first point.  "It isn't immediately obvious that there are two modes: HTML and text mode".  Personally, I kinda like seeing some sort of mode indicator/switcher on the toolbar, even if I'm not going to be changing modes much.  And since we do have a little more screen real estate to work with now, I don't see the harm in having it there.  But I too can't back that up with hard data.

Also, FWIW, I'm trying to think in terms of both a simple, generic markup editor and Evolution's mail composer.  The editor widget may yet prove itself useful in other contexts, especially now that it's Bonobo-free.  And I don't see it being bound to GtkHtml forever, especially with WebKit on the horizon.  Probably pipe dreams, but that's my current thinking.

Anyway, I'll prototype Ben's suggestions and see where that takes us.

Created attachment 113363 [details]
Implementation of Ben's mockup

Ben, here's everything you suggested in comment #28.  There's still some kinks to iron out but it more or less works.  Would be really helpful if you and Dan could apply the patch and play around with it to make sure the interactions all seem correct.

Some thoughts:

  - Overall this does feel like an improvement over the old UI.

  - You were right about using a combo box for the mode selection.
    I do like that better.

  - Still haven't warmed up to the alignment combo.  I think I still
    prefer the three toggle buttons.  Feels more familiar, I guess.
    Maybe I just need to get over it.

  - Something seems awkward about the bulleted and numbered list buttons
    on the toolbar.  Seems like we could just as easily add "Bulleted List"
    and "Numbered List" to the paragraph style combo and skip the buttons.
    Also, getting the widget interactions right was a pain in the ass.

  - The "Header" items in the font size combo are not yet working correctly;
    mainly because GtkHtml considers those to be /paragraph/ styles, not
    /font/ styles.  I think I just need to wrestle with it a bit more, but
    I'm working against GtkHtml's design here.

  - I renamed "Huge" to "Largest", but I'm not sure if that really addresses
    Dan's complaint.

  - The current UI lets you get into some weird situations, like trying to
    pick both "Preformat" and "Header 1" which are mutually exclusive in
    GtkHtml.  Need more thought here about desensitizing things.

  - Finally, someone please explain to me the purpose of "Address".  I can't
    tell if this should really be a font style or a paragraph style.  GtkHtml
    considers it a paragraph style, and so it lets me pick different font
    sizes while using it.

Created attachment 113364 [details] [review]
Revised patch

Applies to the current GtkHtml trunk.

As everyday user of Evolution I would second that alignment buttons should be toggle, not combobox, because it is just what common people are used to. Other changes are nice, especially combobox with HTML/Text mode.

Cheers people for great work :)

So I think there's consensus here that the HTML control toolbar and editing mode combo box (as shown in comment #32) are an improvement.  Plus the coding changes are straight-forward and low risk, so I'm going to commit this much of it for the next 2.23 release.

Note, this commit does not include the font size renames, numbered/bulleted list toolbar items, paragraph/font style rearrangements, or alignment button changes (which were reverted anyway).  Those are still under development and evaluation.

Committed as revision 8886.

Created attachment 114032 [details] [review]
Revised patch

Patch from comment #33, minus the parts committed.  Also reverts the alignment combo box back to the three toggle buttons.

Mbarnes, is it gonna be there in time ?

I'd rather wait and do more testing on this.

The patch mixes up GtkHtml's concept of font styles versus paragraph styles and introduces some weird corner cases that need to be dealt with sanely.  But I do think it's a more logical approach for users, so I'll continue to pursue this.

(Marking the patch as Needs-Work per the comment above.)

GtkHtml is not under active development anymore. 
Evolution (its main consumer) switched to a WebKit backend a while ago. 
It is currently unlikely that there will be any further GtkHtml development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping (bug 778387) to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.