thomas.duellmann at gmx.de
Thu Mar 29 00:56:03 UTC 2012
*Thanks to Blake for that very considerate list*, and for the courage
and transparency of sharing and putting it up for discussion.
On 23.03.2012 19:24, Blake Winton wrote:
> Here's the list, in the order I think they should be (highest priority
> to lowest priority):
> * Papercuts! (Fix the easy little things that are making
> Thunderbird worse to use.)
> o Things like the tab you go to after closing the current tab
> (bug 508776).
> o Maybe some UX Priorities
I could not agree more: Small things can hurt a lot, especially as we
have so many of them, for a long time.
According to getthunderbird.com <http://www.getthunderbird.com/>, *TB is
an *email* application* "made to make email easier".
So I suppose our *core functions are reading, writing, and managing of
Since there seem to be enough people advocating for and implementing
bells & whistles (nice and useful as they might be), I'll focus more on
some of the basic things: *More papercuts, the little and not-so-little
age-old things that are making TB worse to use or wasting potential,
*The bottom line is that imho we need a strategy for fixing
long-standing painpoints for existing basic features before (or at least
alongside) adding more and more new features, usually with new
painpoints and bugs.
Presenting what's on the envelope seems to be one of the most basic
functions of a mail reader. Alas, the message header might be one of our
worst UI parts. It looks non-native with buttons that stand out from all
the rest of the UI (bug 525210
<https://bugzilla.mozilla.org/show_bug.cgi?id=525210>), and disorganized
("Other actions" button cornered somewhere), wasting screen real estate,
can't be collapsed or compacted out of the box (634831
<https://bugzilla.mozilla.org/show_bug.cgi?id=634831>), not even
resized, and when you want to see "25 more..." recipients, chances are
you will actually see *less* while scrolling mad in a static 4-lines
message header (511408
<https://bugzilla.mozilla.org/show_bug.cgi?id=511408>). If I scroll the
list of recipients, the buttons disappear altogether (649496
<https://bugzilla.mozilla.org/show_bug.cgi?id=649496>), and for multiple
selected messages, a lot of buttons for everyday message actions are
entirely missing and cannot be added to the message header toolbar
(523544 <https://bugzilla.mozilla.org/show_bug.cgi?id=523544>). And
there is still no obvious way of getting rid of that toolbar: It's not
listed in View > Toolbars. Most of the header pa(i)ne design mess could
be solved if we follow Blake's nice idea of the previous UX-roundup
"Compactify the header... we should move the buttons and their toolbar
out of the header, to float just above it." (no bug filed yet). Speaking
of buttons, each time I want to alternate between forwarding a single
msg inline vs. as attachment (and I think both are basic and frequent
usecases, including alternation), TB forces me to go through the main
menu instead of providing the obvious UI, make the button a dual menu
dropdown button (508250
<https://bugzilla.mozilla.org/show_bug.cgi?id=508250>) and the context
menu a dual menu (like the print button from Firefox button). Using the
same dual menu UI element, we could also fix that little joke that users
cannot even copy the full name and email address of a recipient from the
header (99997 <https://bugzilla.mozilla.org/show_bug.cgi?id=99997>). And
while having Jim's attachment bar is great, forcing *everybody* into an
extra click to see all or select some of their attachments is pretty
arrogant (647036 <https://bugzilla.mozilla.org/show_bug.cgi?id=647036>).
- Replacing the editor component is *not* required for compose in a tab
- Replacing the editor component will cost loads of developer time, and
has the potential for major uproar and support worries if composition
features get added, removed, relocated, etc.; personally, I don't have
many probs with the existing editor, but ymmv.
- Similarly, I'm not sure if we need new CSS features at this time.
Between the obvious (Compose in a tab, +1) and the radical illusion
(replacing the editor component), again, there are the little papercuts:
While we have sucessfully prevented *drafts *from terminating the
application (just in time before releasing, 738907
<https://bugzilla.mozilla.org/show_bug.cgi?id=738907>), we still annoy
local draft users with creating multiple instances of the same draft
(482836 <https://bugzilla.mozilla.org/show_bug.cgi?id=482836>), and
stubbornly saving them in the main draft folder even if the draft was
opened from a draft subfolder (263114
<https://bugzilla.mozilla.org/show_bug.cgi?id=263114>, since 2004).
Again, basic I/O operations behaving badly. Thank you for fixing 397975
<https://bugzilla.mozilla.org/show_bug.cgi?id=397975> which was a major
painpoint, never mind that adding new *identities *will not show them
immediately on the list of identities in current trunk (probably needs a
Attachments *- I know we have gone a long way to improve them, including
the bigfiles feature which is certainly great and I just hope we'll not
see new bugs and usability problems with that while we're still longing
for some age-old enhancements and bugfixes:
270292 <https://bugzilla.mozilla.org/show_bug.cgi?id=270292> - Unable to
drag multiple attachments to a folder (since 2004, 14 duplicates, and
229224 <https://bugzilla.mozilla.org/show_bug.cgi?id=229224> - Ability
to reorder attachments during composition (by Drag&Drop, or context
menu, or both) (since 2003)
Both of these have initial patches from Jim, it would be great to see
335783 <https://bugzilla.mozilla.org/show_bug.cgi?id=335783> - Support
attaching image screenshot/files/anything from clipboard
292385 <https://bugzilla.mozilla.org/show_bug.cgi?id=292385> -Need
indication of detached attachment (overlay icon, 'Detached:' note etc.)
Finally, there's my good old friend, 378046
<https://bugzilla.mozilla.org/show_bug.cgi?id=378046#60> - I wonder if
it was perhaps the first bug I filed - and it's sibling, 722929
378046 <https://bugzilla.mozilla.org/show_bug.cgi?id=378046#60> - Make
Mapi and Non-Mapi methods of adding attachments consistent and
predictable: By default, take an immediate snapshot of original file so
that editing the attachment means editing the snapshot (because original
might be on removed media, deleted, altered, etc.; webmailers also take
an immediate snapshot, and bigfiles uploads an immediate snapshot, too,
only normal attaching doesn't!);
722929 <https://bugzilla.mozilla.org/show_bug.cgi?id=722929> - In
addition, consider implementing a *consistent* and *predictable* feature
of "attach this file later when sending". Actually, that's pretty
similar to the concept of bigfiles, only for a local URL, and sending
the actual file instead of just the link. We might want optional "upload
when sending" for cloud files, too.
Believe it or not, the truth is that the point of time at which we
actually take the snapshot of a traditional file attachment varies in a
very intransparent manner depending on the *method* of attaching (Mapi
vs. non-Mapi methods), and other coincidences (e.g. if the draft was
ever closed and reopened).
I admit that bug is difficult to understand, and possibly not easy to
fix, but now more than ever with bigfiles as a new player in the game, I
think it's about time that we unify the handling of local attachments
independent of their method of attaching. I think we really owe it to
our users that the version of the file they are actually going to send
out is 100% predictable (i.e. the point of time of taking the snapshot),
regardless of the circumstances and without guru knowledge about the
internal workings of the attachment backend code. Nobody likes sending
out the wrong information, or losing data thinking he's editing the
attached snapshot while he's suddenly editing the original, and vice versa.
For more: Bug 579473
*_Managing messages / Searching_
Bug 512942 <https://bugzilla.mozilla.org/show_bug.cgi?id=512942>
-Implement *Copy/Cut/Paste to/from clipboard for selected messages*
(e.g. from inbox) via context menu or Ctrl+C, Ctrl+X, Ctrl+V (paste
emails into another folder, or as attachments, or as .eml files)
Bug 460737 <https://bugzilla.mozilla.org/show_bug.cgi?id=460737>
-*Quickfilter* ignores searches for friendly display names from address
book contacts, as displayed on message header and message list by
default (no or incomplete results for From, To, CC, BCC)
Bug 586131 <https://bugzilla.mozilla.org/show_bug.cgi?id=586131>
-Quickfilter bar has lost OR functionality using | (Pipe character) -
(Perhaps we need a grouping character for that feature, too.)
Note that neither global search nor quickfilter has optional OR
Bug 258371 <https://bugzilla.mozilla.org/show_bug.cgi?id=258371>
-*Advanced "Search Messages"* results should have a message preview pane
(quick win, has draft patch).
Contrary to popular myth, advanced "search messages" still exists and it
doesn't deserve the neglect that it gets.
After all, it's the *only* search tool that allows advanced precision
searches, OR searches etc.
Btw, it's another candidate to live in a tab (probably needs a new bug).
Bug 302609 <https://bugzilla.mozilla.org/show_bug.cgi?id=302609>
-right-click on message in search messages (advanced) results should
show contextual menu
Unbelievable, but true: there's no context menu on advanced "Search
messages" result messages... (quick win)
For more: Bug 519202
- Make "Open as list" a toggle button on the global search results
toolbar (with caveats for mail toolbar buttons; we discussed that in the
followup bugs for tabs-on-top, and we were almost there...)
- Implement option to have global search "Open as list" as default
Bug 528044 <https://bugzilla.mozilla.org/show_bug.cgi?id=528044> -Global
search: "Show/Open as list" results view does not remember columns
(should persist column visiblity, e.g. for "location") [faceted search;
search all messages]
For more: Bug 541349
Bug 686851 <https://bugzilla.mozilla.org/show_bug.cgi?id=686851>
-Implement *"Open containing folder" contextual action for messages in
search results* (faceted search, open in conversation, open as list,
advanced search messages dialogue, saved searches) [Show found message
in folder location] (quick win)
Bug 522768 <https://bugzilla.mozilla.org/show_bug.cgi?id=522768> -Search
Results: Add "Folder path" column / Missing full path tooltip in
"Location" column (Faceted Search: Open as List, Open in Conversation,
Saved Searches, Search Messages; Main 3-pane Window) [containing folder]
Finally, *TAGS* (Bug 432710
Bug 456169 <https://bugzilla.mozilla.org/show_bug.cgi?id=456169> -Add
"Tag" button to new interface for message headers (missing widget in
header pane toolbar customization palette) (quick win)
Bug 370076 <https://bugzilla.mozilla.org/show_bug.cgi?id=370076>
-Create/apply tags for messages by typing with the keyboard / Port
Firefox tagging UI to Thunderbird (implement new way of tagging, method,
system, applying tags too complicated)
I'm not sure why tags are so neglected. The current tagging system is
totally crippled. Imho this bug has a huge potential for making message
handling more efficient. Imagine you could just tag on the fly as in
Firefox and then retrieve such messages using your own tags by just
typing relevant words into quick filter (where tags should be included
into the default awesome quickfilter search as a separate set in
addition to recipients, sender, subject, and body). This caters for a
large variety of users, and as a side effect, it helps to fix and then
find mails with none or missing subjects, wrong terminology used,
missing keywords, etc.
_I admit it's kinda hard to pick from the vast list of things on bmo,
but I do believe we maintain that list for a reason and not for a
tendency of practically forgetting about existing bugs and proposals
over big new features.
> * Clean up the landed features.
> o Have an easier way to add and remove OpenSearch providers.
> * Compose in a tab.
Yes, but please do *not* wait with that until you have a new editor, and
even if you had one, I would probably not change the editor at the same
time you're putting compose into a tab.
> o Also address book in a tab.
If it's half-way easy to put the existing AB into a tab, fine, but
again, I completely agree with Blake's caveats about the time needed for
creating a completely new AB. And please don't make it all look
webstyle. I'm running TB as a *desktop application* for a reason. If I
wanted webstyle, I suppose I would use webmail instead.
> * Attachment tab.
*Fwiw, I have never missed anything from below this line in TB (except
the address book, possibly), and I wonder if we have any data on how
many of our users actually want things like Australis minimalist design
without menus, or "Social Search" and similar additions to happen in
their email application.*
> * Social Search.
> o Extend OpenSearch to social networks.
> o Also
> * Thunderbird Button.
> o I think that we might want to skip a UI-refresh and go
> straight to the Australis Menu Button instead, but there's
> still work to be done here figuring out what functions to make
> available on the toolbar, and on this button.
> * Address Book.
> o re-design as a web-app, possibly targeting Mobile first...
> o This seems important and useful, but it's also a very large
> task, and I think I'ld like the front-end team to work on some
> smaller stuff for a little while.
*Small stuff or not, I fully support any approach of working on existing
outstanding bugs and RFEs before diving into new large things.*
> * Perspectives!
> o Could include a Facebook-ish Timeline view.
> o This is even more important for the future, but it's also a
> very large task which I think will take a long time to pay
> off, so it falls in the same bucket as the Address Book for me.
> I would like people to respond with suggestions on things I've missed,
> as well as what they would change about the order, and reasons why.
> I plan on presenting the list, and the feedback, at the Product
> Council meeting next Thursday.
Is there any information online about the members and agenda of "Product
N.B. Allowing a bit more time for the feedback might improve quality and
quantity of feedback.
> Blake Winton Thunderbird User Experience Lead
> bwinton at mozilla.com
Big thanks to the team for all the work and efforts.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning