New features landed for Beta 1 - Reporting bugs/issues
Mark Banner
As some of you will have already seen, we have just landed some features
in time for beta 1. With some of this bugs, we are still working on
polishing the display etc, before reporting bugs, please could you check
through the lists referenced on either the original bug, or against one
of the bugs reported here:
https://wiki.mozilla.org/Thunderbird:QA_TestDay:2008-09-18
For anything that is a bug and is not on those lists, please do file it
- we have probably missed it.
For general comments (i.e. I don't like that, I do like ....), please
use the talk pages on the wiki pages or the other suggested forms of
feedback (or maybe even this group).
This is just for this intermediate stage - we've landed things early,
before they are ready, so that our l10n community can get their strings
updating, hence we're still polishing a few things before the beta 1
code freeze - we know where a lot of the problems are, so there's no
point in filing duplicates if we already know about them.
If you feel there is something major we haven't addressed by
Monday/Tuesday, please do feel free to post it here, and we can take
appropriate action.
Thanks
Standard8
Mike Cowperthwaite
Lucky me to discover this disaster in the middle of a computer switchover.
I think the buttons on the envelope panel are absolutely horrible.
Redundant, oversized, ugly, bad bad bad bad BAD. I DO NOT WANT THEM
THERE. There is already a toolbar that has most of those functions; why
was that not considered sufficient? And the "hide details" button is
beyond lame -- what used to be a tiny elegant twisty is now a chunk of
miscolored real estate the size of fucking Delaware.
I also dislike the all-lowercase labels, and I'm not keen on
light-colored text on a dark background, either.
This is SO bad.
I found the bug where this was implemented and searched for "pref"
hoping to find a way to turn the buttons off, and the only place that
turned up was in Bucksch's whinging about his tired old complaint about
the failure of the panel to scroll. (He's wrong; it shouldn't scroll.
I couldn't tell whether scrolling is in place now with a pref, or coming
soon.)
I'm going to have to dig into the chrome now and figure out CSS rules to
turn these horrid buttons off. I can't believe you did this. I just can't.
Andrew Sutherland
> THERE. There is already a toolbar that has most of those functions; why
> was that not considered sufficient? And the "hide details" button is
The other shoe has the toolbar buttons in them.
Andrew
Wayne Mery
Aesthetics aside, because I'm sure that will be improved, I suspect this
will be good for mouse-centric ppl. But I'm not one of them so I'm not
even in a good place to decide if it's good or bad for them.
So for me, as long as it does not substantially impact screen real
estate it's OK. But if it does use more then Id be in favor of a means
to remove them.
Eric Rizzo
> Redundant, oversized, ugly, bad bad bad bad BAD. I DO NOT WANT THEM
> THERE. There is already a toolbar that has most of those functions; why
> was that not considered sufficient? And the "hide details" button is
> beyond lame -- what used to be a tiny elegant twisty is now a chunk of
> miscolored real estate the size of fucking Delaware.
>
> I also dislike the all-lowercase labels, and I'm not keen on
> light-colored text on a dark background, either.
>
> This is SO bad.
>
> I found the bug where this was implemented and searched for "pref"
> hoping to find a way to turn the buttons off, and the only place that
> turned up was in Bucksch's whinging about his tired old complaint about
> the failure of the panel to scroll. (He's wrong; it shouldn't scroll. I
> couldn't tell whether scrolling is in place now with a pref, or coming
> soon.)
>
> I'm going to have to dig into the chrome now and figure out CSS rules to
> turn these horrid buttons off. I can't believe you did this. I just can't.
Although I find the tone and manner of delivery of that message kind of
offensive, I do agree with each of the objections. I, too, tried to grok
that bug report that went on and on about the scrolling, but gave up
after 10 minutes of reading back-and-forth.
I like the overall look of the latest build, but the buttons in the
header area are indeed ugly and unnecessary. Although I'm sure their
ugly appearance is just because of the pre-beta status, I'm definitely
what you'd call a "mouse person" but I still find them out of place and
distracting.
Eric
Rick Logan
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
>
Eric Rizzo
> I just right click in the header, and closed the buttons out.
On Windows XP, I can't right-click anywhere in the blue header area and
get any menu options other than the standard Cut/Copy/Paste/Select All
text commands.
Can you post a screen-shot of what you're doing?
David Ascher
First, apologies -- we've been remiss in not advertising on this
newsgroup as much as we probably should have what the plan is for the UI
changes. We _have_ been discussing all of the relevant bugs in the
weekly calls, and the minutes should reflect that, but it's hard to
always hit all of the right channels of communication.
Then, a note and a request -- it's a bit hard to get to the substantive
points in your note because of the overall tone. I understand the
frustration, especially as it came as a surprise (see above). But it'd
be nice if everyone could take a breather before ranting. I'd like this
newsgroup to be a place where people can safely express tehir opinions,
and suggestions for positive changes. High emotion posts are likely to
keep people with the best ideas from posting them, for fear of eliciting
that kind of reply.
Third, a framing point: I'm not the UX lead, Bryan Clark is.
Unfortunately, he's travelling today, so while I'm not going to speak on
specific UX direction, I can explain what our strategy has been about UI
evolution, and why today's build looks like it does.
Hopefully the following context will explain why we're doing things, and
how people can help us get to an optimal conclusion.
Getting UI right is incredibly hard. That doesn't mean we shouldn't
try. Changing UI in existing products always results in surprise, and
often a negative first reaction. One could probably define "good UI
changes" as changes that result in a net increase in user experience
measured _after_ that first adaptation. The trick is that it's often
very hard to know at first glance whether a UI change is good, bad, or
bad-but-could-be-great-with-a-tweak. It's helpful, therefore, to try
things out, refine them based on feedback, and be willing to back them
out if, after looking at enough data over long enough, the UI change
really seems bad. But change, especially as part of iterative
development, is the only way forward.
The betas are a place where we can test out these changes with a larger
group of users. Nightlies are a place where we can test out changes
with a small number of users, and sometimes a place where we must land
half-baked things, on the way to fully baking.
The message pane rework is a case in point. There was a bunch of
discussion about the design, and we decided to go ahead and try it out.
Dan had done the XUL work involved in the new design, but it needed a
lot of polish, chrome, adjustment, before it was release-worthy. Rather
than do all of that work in a patch, which makes it hard to get feedback
until a lot of investment has been put in, we decided to land the
rework, basically unstyled, and proceed with refining the design in a
second phase.
That, all things considered, has been successful, I'd say. Among the
feedback were some very constructive comments, which have already
influenced the code. We've also iterated over skins in patches a few
times, including a light-on-dark theme
(https://bugzilla.mozilla.org/attachment.cgi?id=339148), and a
dark-on-light theme
(https://bugzilla.mozilla.org/attachment.cgi?id=339383), which is closer
to what we're likely to go with for b1 because the former will take
longer to get right. It's been a bit crazy for us because we're trying
to meet the b1 code freeze deadline, but I feel we've made a lot of
progress there.
The theme isn't finalized, and there have been some interesting
suggestions which we definitely want to look at post b1, such as wesley
johnston's https://bugzilla.mozilla.org/attachment.cgi?id=339435
micro-toolbar approach.
No one claims that today's build is final. Part of the deal of using a
nightly is that you will, some days, use software that's not release-ready.
A few other points: one of the general themes that we're working on in
the Thunderbird UI is to try to bring affordances (menus, buttons, etc.)
closer to where they are relevant. This allows the product, which is
already quite feature rich, to have a user interface that scales with
the interaction choices that the user makes. As an example, the "View
source" menuitem is currently always visible (if sometimes disabled) in
the most global of UI contexts, the toplevel menubar. It is only ever
relevant when looking at a message, so it makes sense to have it
"closer" to the message. I'm not suggesting any particular UI change
here, only that if you bring UI affordances that are only relevant in
some "spatial" contexts closer to their target area, you make them more
discoverable and you simplify the overall UI (Thunderbird has a lot of
menu items, many of which are hard to understand for new users, or users
with little experience with the technical underpinnings of email).
The addition of the reply/delete/etc. affordances to the message pane
fits into that general theme. The idea is to make the default toolbar
include things that are often needed independent of context, like the
Write button, or the search interface. People who really want specific
buttons back in the toolbar can clearly add them using the customization
feature.
On that note, if you do poke around the source, you'll notice that we've
already started talking about how to make the buttons in the message
pane customizable, as the toolbar is. We don't have that bug in
bugzilla yet, but if you felt like taking that on, it'd be great.
Hope this helps,
--david
Rick Logan
to get it back, I would gladly
Mike Cowperthwaite
I suspect that Rick clicked the "Hide Details" button, perhaps
inadvertantly, and now has a single-line envelope at the top of his
message. If so, there's a little + sign to the left of the Subject;
click that and it will re-expand.
JoeS
Screen real estate is the key for me also, for graphics and multimedia content.
There is an answer, and that is to implement fullscreen f11 functionality.
Single keypress to see content only.
This is available as an extension to branch. Morelayoutsforthunderdird from mozdev.
http://morelayoutsforthunderbird.mozdev.org/
I like it a lot.
Mike Cowperthwaite
Thank you for your thoughtful response, which is far beyond what my rant
deserved. Your assessment of the tone of my post is on the money.
FWIW, I posted late at night after an evening of getting a new computer
up to speed; I downloaded the latest trunk with no expectation that it
would be any different than the trunk I'd d/l'd over the weekend. I was
shocked (and tired) and I vented on the newsgroup.
It wouldn't have made any difference if there had been a lot of posts
warning people about the changes coming, because I've not been too
active in Mozilla for the past eighteen months or so, and check this
group quite infrequently.
I guess I can understand the idea of putting affordances close to the
point of interest, but I think that's a strategy targeted at relative
newcomers. I've got years of experience with GUIs and I know where the
things I want to use are located. I've long been an opponent of
"skinning," preferring a consistent look and feel to apps (and
preferring that developer time be spent on substance rather than flash),
so the sudden dark grey-blue appearance to the banner was immediately a
flag that something was "wrong." But the buttons really bother me, as
clutter; as I said, I will render them invisible as soon as I can figure
out how.
There are now *five* different paths to marking a message as junk. The
junk column is the best one, and quite "affording"; plus a toolbar,
context menu, main menu, and now this envelope button. Oh, and then
there's the keyboard shortcut. I don't usually use a shortcut for
marking junk, but I do use the shortcut for replying all the time. And
message forwarding (a practice that, in general, should be
discouraged... I don't need to see those jokes again) I do infrequently
enough that I don't mind at all reaching for the toolbar or menu --
actions that I for one don't find onerous in the least.
FURTHERMORE, the forward button still does the same thing as the toolbar
and the context-menu Forward -- nobody has figured out a reasonable
solution to the real Forward UI problem, which is -- sometimes inline is
better, sometimes (usually) as attachment is better, but the only way to
choose the non-default one is to dig down through the main menu. The
effort spent putting this new envelope panel together *could* have been
spent turning the Forward toolbutton into a dropdown-style button that
offers both choices.
Yes, the buttons are ugly too; but I didn't realize that no skinning had
been done to them yet. I saw the sample (proposed?) screenshots at the
bug, and as far as I could tell there was a bug that was causing them to
look quite bad in situ. But really, I don't want more attractive
buttons there, either.
What I'd really *like* to see in the envelope, in terms of affordances,
is better control of the message-specific *view*. A three-way toggle
for Original HTML | Simple HTML | Plain Text in that space would have
tickled me pink. *That* is an item with only a single point of change,
buried in the main menu, and happens to be something I use frequently.
Every time I use it, I have to hit a two-level menu, and then have to go
reset it afterwards because the setting is sticky. Same for Display
Attachment Inline, altho that's less frequently accessed. And I don't
want these controls to be big clunky text-labeled buttons; I want them
to be tiny, elegant, and iconic. (One of my favorite improvements is
the look of the "junk" icon in the default theme; while the little flame
doesn't really mean much, it looks fabulous. As opposed to the "Mark"
eyeglasses on the toolbar, which... don't.)
I'm generally not thrilled with the UI "improvements" that TB has taken
on over the past several years, but they haven't impacted my use of the
tool. There have been quite a few worthwhile refinements, but the new
features have generally left me uninterested. I don't like the
implementation of tabs, for instance -- no problem, I can simply not use
it. The envelope panel, I see every single day, sometimes hundreds of
times.
Oh, two more complaints about the new panel: several of the tag texts
now show up in low contrast because the tag color is of similar
saturation to the new panel. And, mail addresses that used to be
highlighted in blue, so you'd know they were active, are now the same
color as the inactive text (such as Subject). I know this is following
a trend on the web to not make links stand out -- I think that's a bad
trend because I don't want to have to point my mouse at a piece of text
*hoping* it will be active. (URLs, as in RSS feeds, still show
highlighted in the envelope panel.)
Rick Logan
Thank you!!! That was driving my nuts!! I didn't know how to get it
back, yes this is exactly what I did.
To get it back:
Joshua Cranmer
> Is this group top-posting now?
No, in-posting is still the preferred method.
JoeS
Here is a start:
/*
* Make the message header view pane scrollable
*/
#collapsedHeaderView {
max-height: 14em !important;
overflow: auto !important;
}
#expandedHeaderView {
max-height: 14em !important;
overflow: auto !important;
}
#expandedHeadersButtonBox {
display: none !important;
}
You can't make a change, unless you stay involved.