Accessible themes
James Russell
project so I hardly have time to post, much less proof...
Also, cross-posting to UI, since it's very relevant there, too.
James Russell wrote:
> One thing I've been waiting for from Netscape in the 6.x releases are
> themes that are not designed to be pretty, but that show just how themes
> are sometimes a _necessary_ part of the browing environment.
>
> An interface as fantastically flexible as Mozilla has is definitely an
> advantage over IE, but I don't think there's been enough done with the
> technology. Therefore I say it's time we show the world a more useful
> side of XUL. A couple examples of where these accessibility themes could
> be beneficial follow.
>
> Case #1 Not-quite-blind people
>
> Okay, some people can't see all that great. We know that. Our mothers
> and fathers and aunts and uncles are all starting to lose their eyesight
> to varying degrees, and many of them can't stand little buttons. You
> know those big buttons that they put on some phones, for people who
> don't like to use small buttons? Same concept.
>
> The funny thing is that this was implemented sort of with the Fog City
> theme for Netscape 6.1 and 6.2. Look at the background of the buttons:
> they show HUGE icons with nice, thick lines in the background. But in
> the background of course they're hard to see. Taking those same huge
> buttons, you could easily bring the big icons to the foreground and
> change the colors. An Accessibility option could even be added to the
> installation of the browser so that the user could pick from
> accessibility-related themes right off the bat.
>
> Case #2 Color-blindness and other sight disfunctions
>
> Some people have hard times seeing similar colors together. and make
> two high-contrast, big button themes: one with a white browser interface
> and buttons with black lines, and one with a black interface and white
> lines. You could even make more choices. For an example of this in
> Windows (any but 3.x or XP), go to Start-->Settings-->Control Panel, go
> into the Display Control Panel and click appearance, then look at the
> various themes. Some there say "High Contrast". This is what I'm talking
> about, but using XUL.
>
> Also, others could be made for color-blind people, such that the color
> they can't see is not crucial to that given theme. For example, some
> color-blind people can't see green, some don't see blue, others don't
> see red. Themes could be made for all major types of color-blindness
> just by making themes that didn't use particular colors at all, making
> it so the color-blind user won't miss any of the intended hues.
>
> Of course, Modern and Classic are gray, which may make this one moot.
> Still, it'd be so easy to implement this it'd be almost worth doing it
> just to do it. Color-blind themes would help fill out the Accessibility
> themes menu, if nothing else.
>
>
> James
>
Matthew Thomas
>...
> > One thing I've been waiting for from Netscape in the 6.x releases
> > are themes that are not designed to be pretty, but that show just
> > how themes are sometimes a _necessary_ part of the browing
> > environment.
You may be waiting for some time. Themes are not a necessary part of the
browsing environment -- as the existence (and overwhelming dominance) of
Web browsers other than Mozilla and Neoplanet demonstrates.
> > An interface as fantastically flexible as Mozilla has is definitely
> > an advantage over IE,
The only advantage is an indirect one: Mozilla can be developed more
quickly, because changing the UI -- for all platforms on which Mozilla
runs -- can be achieved simply by editing a text file. There is no
*direct* benefit to users; there are several disadvantages, including
inconsistent behavior and accessibility of GUI controls, and the fact
that some things (such as a text/icons/both option for toolbar buttons)
are considerably more difficult to implement.
>...
> > Case #1 Not-quite-blind people
> >
> > Okay, some people can't see all that great. We know that. Our
> > mothers and fathers and aunts and uncles are all starting to lose
> > their eyesight to varying degrees, and many of them can't stand
> > little buttons. You know those big buttons that they put on some
> > phones, for people who don't like to use small buttons? Same
> > concept.
Themability makes this harder to implement, not easier. If Mozilla was
not themable, having an option for small or large toolbar icons would be
relatively simple. Themability means that when that option finally gets
implemented, *all* themes will break unless they provide multiple sets
of toolbar icons.
> > The funny thing is that this was implemented sort of with the Fog
> > City theme for Netscape 6.1 and 6.2. Look at the background of the
> > buttons: they show HUGE icons with nice, thick lines in the
> > background. But in the background of course they're hard to see.
> > Taking those same huge buttons, you could easily bring the big icons
> > to the foreground and change the colors. An Accessibility option
> > could even be added to the installation of the browser so that the
> > user could pick from accessibility-related themes right off the bat.
Greater recognizability of toolbar icons would make the browser faster
to use for everyone, not just people with vision problems. If the
toolbar icons in Classic aren't as recognizable and distinguishable as
they can possibly be (and they aren't), that's a bug.
> > Case #2 Color-blindness and other sight disfunctions
> >
> > Some people have hard times seeing similar colors together. and
> > make two high-contrast, big button themes:
Again, increased contrast of toolbar icons would benefit everyone, not
just the color-blind. For example, in the toolbar icons which I'm
(slowly) working on for Classic, the Forward icon is a different shade
of green from the Back icon; hopefully that will make users a couple of
tenths of a second quicker every time they go to either of those two buttons.
> > one with a white browser
> > interface and buttons with black lines, and one with a black
> > interface and white lines. You could even make more choices. For an
> > example of this in Windows (any but 3.x or XP), go to Start-->
> > Settings-->Control Panel, go into the Display Control Panel and
> > click appearance, then look at the various themes. Some there say
> > "High Contrast". This is what I'm talking about, but using XUL.
I think you just disproved your own point. :-) When you change those
settings, Classic should pick up those colors without you needing to
switch to a different theme. If it doesn't, file a bug.
> > Also, others could be made for color-blind people, such that the
> > color they can't see is not crucial to that given theme. For
> > example, some color-blind people can't see green, some don't see
> > blue, others don't see red. Themes could be made for all major types
> > of color-blindness just by making themes that didn't use particular
> > colors at all, making it so the color-blind user won't miss any of
> > the intended hues.
>...
I think a much better way to approach the color-blindness problem,
rather than trying to maintain bugfixes across multiple themes each of
which avoid a particular color, is to use redundancy. You should rely on
shape *and* tone *and* texture *and* color to distinguish between items,
not just color.
> > Of course, Modern and Classic are gray, which may make this one
> > moot. Still, it'd be so easy to implement this it'd be almost worth
> > doing it just to do it.
Easy to implement, hard to maintain.
> > Color-blind themes would help fill out the
> > Accessibility themes menu, if nothing else.
>...
That sounds like a solution looking for a problem. :-)
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
hramrach
>>>An interface as fantastically flexible as Mozilla has is definitely
>>>an advantage over IE,
>>>
>
> The only advantage is an indirect one: Mozilla can be developed more
> quickly, because changing the UI -- for all platforms on which Mozilla
> runs -- can be achieved simply by editing a text file. There is no
> *direct* benefit to users; there are several disadvantages, including
> inconsistent behavior and accessibility of GUI controls, and the fact
> that some things (such as a text/icons/both option for toolbar buttons)
> are considerably more difficult to implement.
With the flexibility it should be easier to implement things like
customizeble menus/toolbars/keyboard shortcuts and macros. MS Office is
a good example of such flexibility. UI plugins implementing commands
bindable to menu/tool button/key combo could be written for Mozilla then.
Threre was already a patch for turning off items in context menu for 0.9.5.
BTW is anything like this planned ? It would be really nice.
hramrach
>>>interface and buttons with black lines, and one with a black
>>>interface and white lines. You could even make more choices. For an
>>>example of this in Windows (any but 3.x or XP), go to Start-->
>>>Settings-->Control Panel, go into the Display Control Panel and
>>>click appearance, then look at the various themes. Some there say
>>>"High Contrast". This is what I'm talking about, but using XUL.
>>>
>
> I think you just disproved your own point. :-) When you change those
> settings, Classic should pick up those colors without you needing to
> switch to a different theme. If it doesn't, file a bug.
>
>
Well this seems rather OS integration problem than lack of themes.
Mozilla should be good to look at if your desktop is good to look at. If
you use a BrokenOS that is not customizable and you cant see anything on
your desktop you should probably ask your admin to install the apps for you.
There are some problems, however:
- UNIX mozilla uses either GTK or Qt to get settings for classic theme
and on some systems it may be the only app using this prefs.
- when I tried to use GTK with a non-standard theme I was lucky when I
saw where the controls were in Mozilla not talking about their state.
There is a problem with GTK that button with foreground and background
both black could still look quite nice because of background bitmap. But
mozilla discards the bitmap.
Another GTK problem are rollover effects that are discarded by Mozilla
as well. In some themes all controls are just dim outlines unless you
point at hem with mouse.
There is already a bug http://bugzilla.mozilla.org/show_bug.cgi?id=67448
`GTK system colors don't reflect reality', but it is dead since May. I
understand that it would be hard to fix an has a low priority but you
cannot say that Classic is all that perfect unless this is fixed.
-Mozilla has to be restarted if you want Classic to reflect system theme
changes. Or you must at least close all windows rendered before theme
change under Windows.
-Under Windows (and possibly anywhere else) Classic still contains
elements that do not change whith system theme at all
Here is what I found in 0.9.6:
Caption in Preferences dialog has always a violet bitmap as background.
I wonder if it would change size if the text around it was larger than
its current size.
Single color button bitmaps are always black.
Rolled-over text on buttons always changes to blue and clicked to red.
Tree twisties are fixed color and fixed size. As they are important for
tree UI they should scale up with text in the tree.
look at a picture: http://www.ms.mff.cuni.cz/~msuc8339/mozgreen.png
-if I select to use system colors for web pages I have to set up link
color manually to something that is wisible on system background.
hramrach
There are problems with messages displayed in MailNews as well
- URLs in header
- message text is b on w but links are set to link color
Neil
> -Under Windows (and possibly anywhere else) Classic still contains
> elements that do not change whith system theme at all
>
> Here is what I found in 0.9.6:
>
> Caption in Preferences dialog has always a violet bitmap as
> background. I wonder if it would change size if the text around it was
> larger than its current size.
I think it would. The background does not depend on the theme.
> Single color button bitmaps are always black.
In fact all bitmaps (well, gifs) are always black (or for some strange
reason in menus, dark blue) and don't use the text colour, although
there is a bug to permit the recolouring of images.
> Rolled-over text on buttons always changes to blue and clicked to red.
True. But then there aren't any Windows colours for this.
> Tree twisties are fixed color and fixed size. As they are important
> for tree UI they should scale up with text in the tree.
They also have a fixed background: particularly in the thread pane, the
highlight extends for the width of the row, so that otherwise the twisty
would disappear. I haven't tried scaling the text in the tree.
Matthew Thomas
>
> > > > An interface as fantastically flexible as Mozilla has is
> > > > definitely an advantage over IE,
> > The only advantage is an indirect one: Mozilla can be developed more
> > quickly, because changing the UI -- for all platforms on which
> > Mozilla runs -- can be achieved simply by editing a text file. There
> > is no *direct* benefit to users; there are several disadvantages,
> With the flexibility it should be easier to implement things like
> customizeble menus/toolbars/keyboard shortcuts and macros. MS Office
> is a good example of such flexibility.
Heh.
MS Office is not written in the wonderfully flexible XUL; it has
customizable toolbars.
Mozilla Classic was not written in the wonderfully flexible XUL; it had
customizable toolbars.
Mozilla Seamonkey *is* written in the wonderfully flexible XUL; it does
*not* have customizable toolbars.
Peter Trudelle
>MS Office is not written in the wonderfully flexible XUL; it has
>customizable toolbars.
>
>Mozilla Classic was not written in the wonderfully flexible XUL; it had
>customizable toolbars.
>
>Mozilla Seamonkey *is* written in the wonderfully flexible XUL; it does
>*not* have customizable toolbars.
>
I must be missing something here. Are you implying that we don't have
customizable toolbars *because* we're using XUL? Are you saying it is
not possible, or just that we would have had such features by now? What
are we supposed to do about that, rewrite the entire UI, again, using
some other technology? What point are you trying to make?
Peter
Neil
> Matthew Thomas wrote:
>
>> MS Office is not written in the wonderfully flexible XUL; it has
>> customizable toolbars.
>>
>> Mozilla Classic was not written in the wonderfully flexible XUL; it
>> had customizable toolbars.
>>
>> Mozilla Seamonkey * is* written in the wonderfully flexible XUL; it
>> does *not * have customizable toolbars.
>
> I must be missing something here. Are you implying that we don't have
> customizable toolbars *because * we're using XUL? Are you saying it
> is not possible, or just that we would have had such features by now?
> What are we supposed to do about that, rewrite the entire UI, again,
> using some other technology? What point are you trying to make?
>
It could have had Communicator-style customizable toolbars. I know
because I wrote the patch for it. Apparently Mozilla is waiting for
someone to write something approaching IE's toolbars.
+-------------------------------+
|Customise Toolbar |
+-------------------------------+
|Note: Third party themes may |
|not support all button styles. |
|@ Theme default style |
|O Pictures and text |
|O Pictures only |
|O Text only |
|O Customize each button |
| +--------+---------------+ |
| |Button |Text |Pictures | |
| +--------+---------------+ |
| |Back |[X] |[X] | |
| |Forward |[X] |[X] | |
| |Reload |[X] |[X] | |
| |Stop |[X] |[X] | |
| |Print |[X] |[X] | |
| +--------+---------------+ |
+-------------------------------+
Matthew Thomas
>...
> There are some problems, however:
>
> - UNIX mozilla uses either GTK or Qt to get settings for classic theme
> and on some systems it may be the only app using this prefs.
That is really a Unix problem which Mozilla can't be expected to solve.
It should improve as the Unix GUI becomes more coherent and unified over
the next few years.
> - when I tried to use GTK with a non-standard theme I was lucky when I
> saw where the controls were in Mozilla not talking about their state.
I don't know what you mean here.
> There is a problem with GTK that button with foreground and background
> both black could still look quite nice because of background bitmap.
> But mozilla discards the bitmap.
That's partly a demonstration of the silliness of trying to reflect
system UI choices in CSS -- it has system UI colors, and system UI
fonts, but it doesn't have system UI textures, or system UI sounds, or
system UI animations, etc.
However, if a GTK theme has a foreground color and background color
which are the same, that theme is just asking for trouble when other
apps try to emulate it (which is, surely, why those colors are exposed
in the first place).
>...
> -Mozilla has to be restarted if you want Classic to reflect system
> theme changes. Or you must at least close all windows rendered before
> theme change under Windows.
* `Should respond to change of Windows colors immediately'
<http://bugzilla.mozilla.org/show_bug.cgi?id=67625>
* `Mozilla needs to respond to system Appearance Theme changed events
(fonts/colours)' <http://bugzilla.mozilla.org/show_bug.cgi?id=57799>
I don't see an equivalent bug for GTK. Perhaps you could file one.
> -Under Windows (and possibly anywhere else) Classic still contains
> elements that do not change whith system theme at all
Yes, they're bugs.
> Here is what I found in 0.9.6:
>
> Caption in Preferences dialog has always a violet bitmap as
> background.
`[CT] Should remove purple sparkle background in Classic skin'
<http://bugzilla.mozilla.org/show_bug.cgi?id=45886>.
>...
> Single color button bitmaps are always black.
That would depend on `Allow tinting of bitmap graphics for chrome'
<http://bugzilla.mozilla.org/show_bug.cgi?id=31726>.
> Rolled-over text on buttons always changes to blue and clicked to red.
`Personal Toolbar items shouldn't use HTML colors'
<http://bugzilla.mozilla.org/show_bug.cgi?id=67767>.
> Tree twisties are fixed color and fixed size. As they are important
> for tree UI they should scale up with text in the tree.
I don't think there's a bug on that, however Mac OS and Windows both
have the same problem with their native tree controls.
>...
> -if I select to use system colors for web pages I have to set up link
> color manually to something that is wisible on system background.
That bug is fixable on Mac OS -- there is an Internet control panel
where you specify preferred background, foreground, *and* link colors,
and Mozilla should (but doesn't) use those settings when `Use system
colors' is checked. However, AFAIK Windows doesn't have a system setting
for link colors. Does GTK?
Neil
>hramrach wrote:
>
>>...
>>
>>Rolled-over text on buttons always changes to blue and clicked to red.
>>
>`Personal Toolbar items shouldn't use HTML colors'
><http://bugzilla.mozilla.org/show_bug.cgi?id=67767>.
>
Actually, where does the red come from? There isn't a pref for it, is there?
Matthew Thomas
>...
> I must be missing something here. Are you implying that we don't have
> customizable toolbars *because* we're using XUL?
No, I'm just lightly mocking those who consider XUL to be a panacea for
flexibility problems, when an everyday user is completely incapable of
editing XUL themselves.
> Are you saying it is
> not possible,
No, it is possible. There are patches. Though they're probably not of
sufficient quality yet to be checked in by anyone outside Netscape
(compare and contrast with the patches for `full screen mode'), Netscape
people appear to be trying to stall them anyway, just in case. :-)
<http://bugzilla.mozilla.org/show_bug.cgi?id=49543#c28>
<http://bugzilla.mozilla.org/show_bug.cgi?id=22056#c89>
> or just that we would have had such features by now?
>...
Before Year Zero, Mozilla Classic did indeed have customizable toolbars,
so it's pretty clear what the answer to that question is.
> What are we supposed to do about that, rewrite the entire UI, again,
> using some other technology? What point are you trying to make?
Oh, don't mind me, I'm just slightly bitter that Mozilla is being
condemned to geek browser status because of the apparent assumption that
most users prefer to wade through menus than use toolbar buttons.
<http://mpt.phrasewise.com/stories/storyReader$35#chrome>
Peter Trudelle
>Peter Trudelle wrote:
>
>>or just that we would have had such features by now?
>>
>Before Year Zero, Mozilla Classic did indeed have customizable toolbars, so it's pretty clear what the answer to that question is.
>
Well then, since mozilla.org must still have that code, why not just
join the development community that has no doubt gathered to support
such wonderful features? ;-/
>Oh, don't mind me, I'm just slightly bitter that Mozilla is being
>condemned to geek browser status because of the apparent assumption that most users prefer to wade through menus than use toolbar buttons.
><http://mpt.phrasewise.com/stories/storyReader$35#chrome>
>
Don't mind me either, I'm just touchy about criticism of my teams' work
that isn't particularly constructive. I agree with much of what you
wrote at that URL, and have nominated some of the bugs you cite for
fixing in the next NS release. Are they all nominated for an
appropriate mozilla release?
I think some consensus on who we are building this for (personas?), and
what their goals are, would go a long way toward resolving these issues.
Once we agree on that, we can test to see how usable it is, and
improving it becomes an engineering problem, rather than a series of
arguments over whose personal preferences should win.
Peter
Matthew Thomas
>
> Matthew Thomas wrote:
>...
> > Before Year Zero, Mozilla Classic did indeed have customizable
> > toolbars, so it's pretty clear what the answer to that question is.
>
> Well then, since mozilla.org must still have that code,
Yes, but only on MozillaSourceClassic_19981026_BRANCH. It doesn't apply
to XUL. :-)
> why not just
> join the development community that has no doubt gathered to support
> such wonderful features? ;-/
Like I said in the Top Ten list, `You won't hear much about this problem
from Mozilla contributors ...'
>...
> > <http://mpt.phrasewise.com/stories/storyReader$35#chrome>
>...
> I agree with much of what you
> wrote at that URL, and have nominated some of the bugs you cite for
> fixing in the next NS release. Are they all nominated for an
> appropriate mozilla release?
I haven't checked. I haven't nominated them myself, since in my
experience of watching nominations, nominating an RFE for a particular
milestone has never affected when/whether it actually got implemented.
(Though I could be blinkered in that observation, from predicting
exactly that ineffectiveness when the mozillax.x keywords were
introduced in the first place.) The Mozilla 1.0 usability criteria set a
much lower bar than the problems I talk about, concentrating on utter
brokenness rather than unusability.
> I think some consensus on who we are building this for (personas?),
> and what their goals are, would go a long way toward resolving these
> issues. Once we agree on that, we can test to see how usable it is,
> and improving it becomes an engineering problem, rather than a series
> of arguments over whose personal preferences should win.
>...
Right. I'm designing out of self-interest, as follows.
Firstly, I'm designing for Philip M. Jones, C.E.T., in order to reduce
the amount of brain-sapping spam I get from n.p.m.general.
Secondly, I'm designing for the thousands of customers who visit the
Internet cafe each day, since I dream of a Mozilla distro displacing
MSIE 5.0 there in the same way that MSIE 5.0 displaced Netscape 4.5 a
couple of years ago.
And thirdly, I'm designing for my mother, who is still using Netscape
3.0 for e-mail because Netscape 4.7x doesn't scroll to the right place
in the message list when she opens her Inbox.
Peter Trudelle
>Firstly, I'm designing for Philip M. Jones, C.E.T., in order to reduce
>the amount of brain-sapping spam I get from n.p.m.general.
>
:-)
>Secondly, I'm designing for the thousands of customers who visit the
>Internet cafe each day, since I dream of a Mozilla distro displacing
>MSIE 5.0 there in the same way that MSIE 5.0 displaced Netscape 4.5 a
>couple of years ago.
>
Ever survey their browsing goals? Any metrics on their usage?
>And thirdly, I'm designing for my mother, who is still using Netscape
>3.0 for e-mail because Netscape 4.7x doesn't scroll to the right place
>in the message list when she opens her Inbox.
>
I'm guessing the 'right place' means to scroll to show her new messages?
I fought very hard for that behavior during 4.5. I can't tell you how
disappointed I am with the current default behavior, which doesn't even
open the Inbox when launching mail.
Peter
Matthew Thomas
>
> Matthew Thomas wrote:
>...
> > Internet cafe each day, since I dream of a Mozilla distro displacing
> > MSIE 5.0 there in the same way that MSIE 5.0 displaced Netscape 4.5
> > a couple of years ago.
>
> Ever survey their browsing goals? Any metrics on their usage?
I haven't surveyed it formally, but the following may be of interest. I
think I could get Mozilla set up as the default browser on at least some
of the computers in the cafe if most of the bugs mentioned below were fixed.
The overwhelming use of the browser (~80 %) is to read and write Webmail
-- Hotmail, Yahoo Mail, GMX, The9, and Outlook Web Access, among others.
The following problems would bite customers if they were using Mozilla,
though some of these problems are also present in MSIE.
* Mozilla doesn't add a vertical scrollbar to TEXTAREAs unless the
text is taller than the TEXTAREA, and whenever this becomes true or
false all the text rewraps alarmingly (bug 82160).
* Someone goes to type `Love, Wanda' (or Whatever) at the end of a
very long message, but hits Ctrl+W instead of Shift+W by mistake
(bug 48333).
* Backspace goes to the previous page if the user accidentally clicked
outside a text field, causing the (usually) unwary to lose their
half-written message (bug 108816).
* Mozilla has numerous text editing bugs (bug 108120), though these
would be less acute for our customers since they often place the
caret with the mouse rather than trying to use Ctrl+Right or Up or
Down.
Probably the second biggest use is tourists checking up on news from
their home country -- CNN, Sports Illustrated, Bild.de, Daum.net,
Sina.com, fm365.com, etc. A major advantage of Mozilla here would be
that many Asian Web portals have little ads which float interminably
around the viewport, and most of these ads don't appear in Mozilla. :-)
However, the disadvantages outweigh that advantage ...
* We can't customize the Toolbar to contain an `Encoding' button
(bug 15144).
* Mozilla's encoding submenu system is so complicated that it's
basically unusable (bug 10999).
* When opening a video or sound file (e.g. a RealVideo file on a news
site), in the `Do you want me to do what you told me to do with this
kind of file, or do you want me to do something else?' dialog, the
`FOAD, I always want to just watch the video' option isn't on by
default (bug 86640).
Other user tasks include participating in message forums for
Counter-Strike and other Half-Life games, doing online banking, and
(occasionally) searching the Web for information on a particular topic.
Possibly the only noticable advantage Mozilla has over MSIE here is that
Mozilla's Text Zoom function works on all pages, whereas MSIE's Text
Size function just works on some pages. As for disadvantages, probably
the biggest problem would be a huge number of evangelism bugs.
With regard to the cafe setup itself, our little timer proggie expects
to be able to close all open browser windows, and then open one new
browser window, within ten seconds. If this doesn't happen, the timer
gives up and sulks. A few of of our machines are Pentium 1s with 64 MB
RAM (IIRC). We could rewrite the timer to use a longer time interval,
but it would obviously be a pain to do so.
In sum, Mozilla is frustratingly far away from reaching the level of
usability required to surpass MSIE 5.0 for our customers. (I suspect the
same could be said when comparing Mozilla and MSIE 4.0.)
> > And thirdly, I'm designing for my mother, who is still using
> > Netscape 3.0 for e-mail because Netscape 4.7x doesn't scroll to the
> > right place in the message list when she opens her Inbox.
>
> I'm guessing the 'right place' means to scroll to show her new
> messages?
Correct.
> I fought very hard for that behavior during 4.5. I can't
> tell you how disappointed I am with the current default behavior,
> which doesn't even open the Inbox when launching mail.
>...
Gotta put that advertising somewhere ...
Stuart Ballard
>
> Peter Trudelle wrote:
> >
> > messages?
>
> Correct.
>
> > I fought very hard for that behavior during 4.5. I can't
> > tell you how disappointed I am with the current default behavior,
> > which doesn't even open the Inbox when launching mail.
> >...
>
> Gotta put that advertising somewhere ...
Sounds like a candidate for a pref. Then at least we could default it to
the sensible behavior in mozilla, even if Netscape is determined to suck
:)
Hey, if they want to make their browser less competitive, who are we to
complain? ;)
Stuart.