94581 - remove Composer graphic from toolbar; no room on toolbar

Status: RESOLVED FIXED

(SeaMonkey :: Composer, defect)

Description

[Kathleen :Brade]

We should move the Composer graphic (currently on the left side of the toolbars) 
to the right side.  This will help us better distinguish Composer from Mail and 
Navigator.

Comment 1

[Simon Fraser [no longer active]]

Shouldn't the UE/themes folks be cc'ed on this bug?

Also, I'm not sure that I agree with moving it. I don't see how that helps to 
distinguish us from the other components.

Comment 2

[rubydoo123]

yes the UE and themes folks should be in on this, adding them

Comment 3

[Akkana Peck]

Is this regarding the huge image with html tags floating around the world that's
making it impossible to see the last three icons in our toolbar and messing with
muscle memory since toolbar icons aren't in the same place?  If so, yes, let's
please move it or remove it.  

It's obviously not part of the "modern skin look", since the browser window
doesn't have anything remotely like this.  The effect is that the browser is one
skin and composer and mail are a different skin which happens to have similar
colors.

Where is this image going to go when we add support for "images only" or "text
only", since the image is taller than images+text combined?

Comment 4

[Syd Logan]

spam composer change

Comment 5

[Kathleen :Brade]

we need this moved; our toolbar is much too big (doesn't fit in window)

Comment 6

[andreww]

Adding marlon to CC list.

IMO the toolbar's too long regardless of whether the masthead is there.  
Moving it to the right would essentially be the same as removing it 
altogether which is not the intent of the design. But Marlon knows more 
about this than I.

Comment 7

[Kathleen :Brade]

Yes, there is another (separate) bug on further theme changes to reduce the size 
of the toolbar to fit in the default window size.  This is just one part of the 
overall problem (the graphic taking up too much toolbar space).

This is a serious problem for Composer's users.  The common tools to author 
documents need to be on the toolbar but right now 3 of them are hidden.

Also, we have decided to not add a separate publish icon to the toolbar because 
there simply isn't room.  :-(

Comment 8

[marlon bishop]

isn't this a dupe of #78843?  and wasn't #78843 marked invalid?  the problem with the composer toolbar lies not in this image, but in the intention to fill the toolbar with too many buttons.

Comment 9

[Kathleen :Brade]

Marlon--are you suggesting that we should have only 6 or 7 icons on that toolbar?  
Could someone in UE please help us decide which those should be?

Perhaps Composer shouldn't have this toolbar at all?

Comment 10

[marlon bishop]

well i didn't want to step on anyone's toes about the UE design ownsership for 
composer, not knowing the rationale and background for that part of the product.  
but my first notion was that we need some kind of floating palette to group 
various tools. the goal being that the main tool bar would only have the broad 
set of tools including file i/o, publish etc. and the floating palette would 
carry the actual editing tools.  this scales much better for future features we 
may need.

the other option i can offer, is something we could do strictly from a visual 
design standpoint, is create a set of composer buttons which are much smaller, 
allowing us to squeeze more of them into the toolbar.  however, i don't feel this 
address the UE issue very well.

Comment 11

[Kathleen :Brade]

I don't believe that we have working floating palettes in xul so unfortunately
that won't work right now (it's something we've hoped to do for 5+ years now).

Right now, in Composer, the toolbar buttons seem to be spaced a bit far from
each other.  This should be fixed (I'll file a new bug on it if no one else
has).  I would prefer the icon sizes not be much smaller than the circles in
Navigator since the target size will become cumbersome for users (Fitts Law).

Comment 12

[Kathleen :Brade]

Attachment: patch #1 to remove image

Comment 13

[marlon bishop]

buttons are about 45x35 right now, that's much more generous than fitt's law. 
We could make them smaller, if you want to give that a shot.  Otherwise palettes
are the way to go, is there an RFE for floating palettes?

Comment 14

[andreww]

why would you change xul to effect a style change?  Removing the class is 
just causing the style rule not to apply, and you would be breaking all the 
other skins.  

Changing the xul is the wrong thing to do if you just want to remove the 
image.  

Comment 15

[Kathleen :Brade]

Attachment: preferred patch

Comment 16

[Kathleen :Brade]

Bug #104206 is assigned to Marlon (at the moment) for the issue of icon size and
gap between Composer's icons on the top toolbar.

Bug #104200 is for the floating palette issue.

AndrewW--please review the preferred patch above
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=53097)

Comment 17

[andreww]

Comment on attachment 53097 [details] [diff] [review]
preferred patch

1) why comment out the style rule which applies to the specific element and add a new rule ? seems like you'd   instead comment out the specific line "backgroud-image: ..." and add the width, height, visibility,  etc. into the existing rule.
2)  this patch seems to be only fixing a symptom and not the core problem. it will make the modern skin very inconsistent to have mastheads on all primary windows except composer.

Comment 18

[andreww]

I think it would be worth it to investigate re hewitt and co. about possibly 
changing things so that perhaps the buttons may appear over top of the 
masthead in some way, freeing up the space as well as keeping the 
masthead there.   

This has wider implications than just composer - if one takes a look at the 
app as a whole instead of just one window, decisions here may have to 
take into account all of the other windows. 

Regarding the premise that buttons are cut off. Is there a target minimum 
window width specced out anywhere? It would be of interest to see how 
far things are off from that.

Would it be worth investigating migrating the rightmost editor buttons into 
a new toolbar - since there is a natural division between the two types of 
buttons.  This would lose some vertical space but gain alot of horizontal 
space.

My only concern about this is just removing the  image seems like just a 
patchwork fix which makes people less inclined subsequently to vist the 
real problems of having too many buttons on the toolbar. 

Comment 19

[Simon Fraser [no longer active]]

> 2)  this patch seems to be only fixing a symptom and not the core problem. it 
> will make the modern skin very inconsistent to have mastheads on all primary 
> windows except composer.

I'm with you on that one. I like the masthead idea. It just needs to be improved.

Comment 20

[german]

Same here. Just because we can we should not stuff millions of controls into a
small space. The masthead idea is not useless as it aids recognizing what app
the user is in, and it helps adding visual "breathing room" to an otherwise very
crowded toolbar. 
So I find the argument that it somehow takes room away from adding more controls
all backwards from a usability perspective. 

Comment 21

[Akkana Peck]

I don't understand the consistency argument ("mastheads on all primary windows
except composer").  The browser window -- the main window that everyone sees --
doesn't have one of these masthead images.  They make composer and mail look
completely different from the browser window, not like the same app at all. 

I won't argue about the "zillions of functions on the toolbar"; I tend to agree
with that.  But the composer toolbar has been this way for quite a while, and no
one asked about whether it should be redesigned before adding this image that
made two more buttons disappear off the right edge of the window.  It would be
nice if the people who had such strong feelings about putting a masthead on the
toolbar were willing to help in redesigning the toolbar first so as not to lose
functionality. 

Re minimum window size: I don't think there's a spec (there should be), but a
good start is the default window size you get when you start the app on a new
machine (no existing profile).  Arguably the minimum supported size should be
even smaller than that; but it certainly should be no larger (i.e. we shouldn't
start out smaller than our minimum supported size).

Finally: even if there were only a few items on the toolbar, the masthead images
still interfere with muscle memory (if I hadn't already stopped using our
mail/news client, this would have put me over the edge, losing the known
position of "send" in the mail compose window) -- people who are longstanding
users of the product know what the leftmost few icons are, and end up clicking
on the masthead instead.

I like Andreww's suggestion about putting the masthead somewhere else.  (They're
pretty images, they just don't belong where people expect to find buttons.)  How
about on the far right-hand side of the menubar?

Comment 22

[marlon bishop]

>I don't understand the consistency argument ("mastheads on all primary windows
>except composer").  The browser window -- the main window that everyone sees 
>doesn't have one of these masthead images.  They make composer and mail look
>completely different from the browser window, not like the same app at all.

the idea is to differentiate other apps from browser.  So if composer were
missing the image, it would not be consistent with the other toolbars which are
differentiating themselves - AIM, MSG Compose, Mail, etc.


>I won't argue about the "zillions of functions on the toolbar"; I tend to
>agree with that.  But the composer toolbar has been this way for quite a
>while, and no one asked about whether it should be redesigned before adding
>this image that made two more buttons disappear off the right edge of the
>window.  It would be nice if the people who had such strong feelings about
>putting a masthead on the toolbar were willing to help in redesigning the
>toolbar first so as not to lose functionality. 

We did ask.  Before we even designed the first image, we found that there was
space available in composer toolbar, buttons weren't disappearing.  We designed
it to fit comfortably within an 800x600 screen, which is a guideline set by
design at Netscape.com.  



>Re minimum window size: I don't think there's a spec (there should be), but a
>good start is the default window size you get when you start the app on a new
>machine (no existing profile).  Arguably the minimum supported size should be
>even smaller than that; but it certainly should be no larger (i.e. we
>shouldn't start out smaller than our minimum supported size).


upon first launch a Navigator Browser window is about 790x538.  And first launch
of composer is about 630x512.   hmmmm.  It seems if we take advantage of some
extra 160 pixels in width, we wouldn't lose a button.  When we designed the
toolbar we took that into consideration.  Otherwise we wouldn't have done it in
the first place.


>Finally: even if there were only a few items on the toolbar, the masthead
>images still interfere with muscle memory (if I hadn't already stopped using
>our mail/news client, this would have put me over the edge, losing the known
>position of "send" in the mail compose window) -- people who are longstanding
>users of the product know what the leftmost few icons are, and end up 
>clicking on the masthead instead.

First, our users aren't developing any muscle memory, especially since when you
are talking about unfixed features such as floating windows (average users don't
run everything maximized).  Second, the non-critical nature of firing that 1st
or 2nd button on the toolbar, combined with relatively low frequency (for
average users), nullifies that argument.  We aren't designing an app to suit
ourselves - we who'd spend 18 hours a day on the internet.  Muscle memory
applies to fixed position features such as the windows start button at the lower
right corner of the screen. Or "My computer" which is always at the top left. 
More accurately, muscle memory really only applies to things like the distance
between your steering wheel and the blinker switch. Fixed objects, relative to
your position, things you could hit with your eyes closed.  When you replace an
old car, i doubt you're going to gripe (very long) about the fact that the
blinker and the steering wheel are located differently.  Isn't this minor
adjustment overshadowed by the fact that you have a brand new car, an exciting
new experience?



>I like Andreww's suggestion about putting the masthead somewhere else. 
>(They're pretty images, they just don't belong where people expect to find
>buttons.)  How about on the far right-hand side of the menubar?


We've been over this alot, believe me, if was going to work, we'd have done
that.  We when throught the process of deciding mastheads we're going to add
value, and be appreciated by our target audience.  It was by no means an
arbitrary decision.

Comment 23

[Kathleen :Brade]

>We did ask.  

I do not think that the Composer team was consulted or even informed ahead of 
time about adding any image to our toolbar.

As for muscle memory, you are right about it being a fixed relationship between 
objects.  In the case of Composer, it's from the fixed edit area to the New 
button or the fixed edit area to the Save button.  These have now drastically 
changed (what was once a 45 degree angle to the left for me is now straight up).  
In other parts of the product I also have problems.  

I don't understand the 2nd argument about the 1st and 2nd items being non-
critical.  Those are the ones that users use all of the time, aren't they?  Or 
don't users actually use the toolbars?

>When you replace an
>old car, i doubt you're going to gripe (very long) about the fact that the
>blinker and the steering wheel are located differently.  Isn't this minor
>adjustment overshadowed by the fact that you have a brand new car, an exciting
>new experience?

The above might be true for some, however, if you moved the break pedal to the 
left to make more room for a bigger accelerator on the right, I bet a lot of 
people would go back to their old car after their first near-accident (assuming 
they bought the car in the first place).

This is exactly why I can't use 6.x Modern theme with the graphic for Mail.  Too 
many times, I've gone to send a message and the message didn't get sent because I 
clicked in the wrong location and didn't realize it.  Using Mail Compose in 6.x 
has become mentally tiring and cumbersome (for me) with the toolbar shifted 
relative to the editing area.

Comment 24

[marlon bishop]

>>We did ask.  

>I do not think that the Composer team was consulted or even informed ahead of
>time about adding any image to our toolbar.


"asked" in the sense that we investigated the issue of space in the toolbar,
ourselves.


>As for muscle memory, you are right about it being a fixed relationship between 
>objects.  In the case of Composer, it's from the fixed edit area to the New 
>button or the fixed edit area to the Save button.  These have now drastically 
>changed (what was once a 45 degree angle to the left for me is now straight
>up).   In other parts of the product I also have problems.  


Ok what i am wondering is that if you have been using the product, as i assume
we all have been, by now your "muscle memory" should have adjusted. 


>I don't understand the 2nd argument about the 1st and 2nd items being non-
>critical.  Those are the ones that users use all of the time, aren't they?  Or 
>don't users actually use the toolbars?


Functions which are critical include: scrolling, or cursor movement, tabbing,
repositioning or resizing tables, etc.  If you look at this realistically, i
wouldn't expect *our* users to hit "New File" from the edit area more than once
or twice per session. that makes it very non-critical.


>>When you replace an
>>old car, i doubt you're going to gripe (very long) about the fact that the
>>blinker and the steering wheel are located differently.  Isn't this minor
>>adjustment overshadowed by the fact that you have a brand new car, an exciting
>>new experience?

>The above might be true for some, however, if you moved the break pedal to the 
>left to make more room for a bigger accelerator on the right, I bet a lot of 
>people would go back to their old car after their first near-accident (assuming 
>they bought the car in the first place).


But we aren't causing any life threatening "near accidents".  Are users losing
their data here?  I don't think so.  If they accidently hit "open" instead of
"new" i doubt they're going to sue us for damages.  And I also doubt there are
many people who are zen-masters at Composer, focusing their "Chi" to hit buttons
while blindfolded. 

Comment 25

[Kathleen :Brade]

>Ok what i am wondering is that if you have been using the product, as i assume
>we all have been, by now your "muscle memory" should have adjusted. 

Yes, I would have thought that by now, I would stop clicking the icon when I want 
to "Send" in mail compose but I haven't.  Shocking (at least to me) since it's 
been this way for many months!  Then again, I've been using our product for many 
years so it'll take more than a few months to relearn where items are on the 
toolbar.

Since users shouldn't use "New" more than once or twice per session, I guess we 
should remove it from the toolbar.  That will bring us down to 9 icons and should 
help.

As for my car analogy, yes, it's not the same as a brake pedal but not sending an 
e-mail I intend to send could be *very* important to my life.

Comment 26

[Kathleen :Brade]

removing EDITORBASE per meeting

Comment 27

[Ryan Cassin]

See also bug 96133 "editor toolbar doesn't fit in default window length". My 
patch creates a customizable toolbar where the user can pick and choose which 
buttons they want to see on their toolbar.

Comment 28

[Serge Gautherie (:sgautherie)]

Kathleen,
Are you still working on this ?

Comment 29

[Kathleen :Brade]

This bug was fixed in Seamonkey (long ago).