<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<b>Thanks to Blake for that very considerate list</b>, and for the
courage and transparency of sharing and putting it up for
discussion.<br>
<br>
On 23.03.2012 19:24, Blake Winton wrote:
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
Here's the list, in the order I think they should be (highest
priority to lowest priority):<br>
<ul>
<li> Papercuts! (Fix the easy little things that are making
Thunderbird worse to use.)</li>
<ul>
<li>Things like the tab you go to after closing the current
tab (bug 508776).</li>
<li>Maybe some <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/buglist.cgi?quicksearch=product%3Athunderbird+whiteboard%3A[UXPrio]">UX
Priorities</a>.</li>
</ul>
</ul>
</blockquote>
I could not agree more: Small things can hurt a lot, especially as
we have so many of them, for a long time.<br>
<br>
According to <a href="http://www.getthunderbird.com/">getthunderbird.com</a>,
<b>TB is an *email* application</b> "made to make email easier".<br>
So I suppose our <b>core functions are reading, writing, and
managing of emails.</b><br>
<br>
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: <b>More papercuts, the little and
not-so-little age-old things that are making TB worse to use or
wasting potential, every day.</b><br>
<br>
<b>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.<br>
</b><br>
<u><b>Reading messages<br>
</b></u><br>
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 (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=525210">bug
525210</a>), and disorganized ("Other actions" button cornered
somewhere), wasting screen real estate, can't be collapsed or
compacted out of the box (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=634831">634831</a>),
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 (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=511408">511408</a>).
If I scroll the list of recipients, the buttons disappear altogether
(<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=649496">649496</a>)<span
title="enhancement"></span>, 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 (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=523544">523544</a>).
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 <a
href="http://weblog.latte.ca/blake/tech/thunderbird/UIFutures.html">UX-roundup</a>:
"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 (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=508250">508250</a>)
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 (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=99997">99997</a>).
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 (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=647036">647036</a>).<br>
<br>
<u><b>Writing messages</b></u><br>
<br>
Ftr:<br>
- Replacing the editor component is *not* required for compose in a
tab<br>
- 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.<br>
- Similarly, I'm not sure if we need new CSS features at this time.<br>
<br>
Between the obvious (Compose in a tab, +1) and the radical illusion
(replacing the editor component), again, there are the little
papercuts:<br>
<br>
While we have sucessfully prevented <b>drafts </b>from terminating
the application (just in time before releasing, <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=738907">738907</a>),
we still annoy local draft users with creating multiple instances of
the same draft (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=482836">482836</a>),
and stubbornly saving them in the main draft folder even if the
draft was opened from a draft subfolder (<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=263114">263114</a>,
since 2004)<span title="normal"></span>. Again, basic I/O operations
behaving badly. Thank you for fixing <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=397975">397975</a>
which was a major painpoint, never mind that adding new <b>identities
</b>will not show them immediately on the list of identities in
current trunk (probably needs a new bug).<br>
<b><br>
Attachments </b>- 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:<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=270292">270292</a>
- <span id="summary_alias_container"><span
id="short_desc_nonedit_display">Unable to drag multiple
attachments to a folder (since 2004, 14 duplicates, and
counting)<br>
</span></span><a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=229224">229224</a>
- <span id="summary_alias_container"><span
id="short_desc_nonedit_display">Ability to reorder attachments
during composition (by Drag&Drop, or context menu, or both)
(since 2003)</span></span><br>
Both of these have initial patches from Jim, it would be great to
see them completed.<br>
<a title="NEW ---; assigned to nobody@mozilla.org; Target: ---"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=335783"> 335783</a>
- Support attaching image screenshot/files/anything from clipboard<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=292385">292385</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Need indication of detached
attachment (overlay icon, 'Detached:' note etc.)</span></span><br>
<br>
Finally, there's my good old friend, <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=378046#60">378046</a>
- I wonder if it was perhaps the first bug I filed - and it's
sibling, <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=722929">722929</a>:<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=378046#60">378046</a>
- 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!);<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=722929">722929</a>
- 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.<br>
<small>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).<br>
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.<br>
<br>
</small>For more: <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=579473">Bug 579473</a>
-<span id="summary_alias_container"> (<span
id="alias_nonedit_display">attachUXtracker</span>)</span><br>
<br>
<b><u>Managing messages / Searching</u><br>
</b><br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=512942">Bug 512942</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Implement <b>Copy/Cut/Paste
to/from clipboard for selected messages</b> (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)</span></span><br>
<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=460737">Bug 460737</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display"><b>Quickfilter</b> 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)</span></span><br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=586131">Bug 586131</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Quickfilter bar has lost OR
functionality using | (Pipe character)</span></span> - (Perhaps
we need a grouping character for that feature, too.)<br>
Note that neither global search nor quickfilter has optional OR
functionality.<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=258371">Bug 258371</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display"><b>Advanced "Search Messages"</b>
results should have a message preview pane (quick win, has draft
patch).<br>
Contrary to popular myth, advanced "search messages" still
exists and it doesn't deserve the neglect that it gets.<br>
After all, it's the *only* search tool that allows advanced
precision searches, OR searches etc.<br>
Btw, it's another candidate to live in a tab (probably needs a
new bug).<br>
</span></span><a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=302609">Bug 302609</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">right-click on message in search
messages (advanced) results should show contextual menu</span> </span><br>
Unbelievable, but true: there's no context menu on advanced "Search
messages" result messages... (quick win)<br>
For more: <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=519202">Bug 519202</a>
-<span id="summary_alias_container"> (<span
id="alias_nonedit_display">qfasfailtracker</span>)</span><br>
<br>
<b>Global search:</b><br>
- 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...)<br>
- Implement option to have global search "Open as list" as default<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=528044">Bug 528044</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">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]</span></span><br>
For more: <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=541349">Bug 541349</a>
-<span id="summary_alias_container"> (<span
id="alias_nonedit_display">glodafailtracker</span>)</span><br>
<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=686851">Bug 686851</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Implement <b>"Open containing
folder" contextual action for messages in search results</b>
(faceted search, open in conversation, open as list, advanced
search messages dialogue, saved searches) [Show found message in
folder location]</span></span> (quick win)<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=522768">Bug 522768</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">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]</span></span><br>
<span id="summary_alias_container"><span
id="short_desc_nonedit_display"></span></span><br>
Finally, <b>TAGS</b> (<span title="minor"></span><a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=432710">Bug 432710</a>
-<span id="summary_alias_container"> (<span
id="alias_nonedit_display">tb-tagsmeta</span>))</span><br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=456169">Bug 456169</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Add "Tag" button to new
interface for message headers (missing widget in header pane
toolbar customization palette)</span></span> (quick win)<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=370076">Bug 370076</a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">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)</span></span><br>
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.<br>
<br>
<u>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.<br>
</u>
<br>
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
<ul>
<li>Clean up the landed features.</li>
<ul>
<li>Have an easier way to add and remove OpenSearch providers.</li>
</ul>
<li>Compose in a tab.</li>
</ul>
</blockquote>
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.<br>
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
<ul>
<ul>
<li>Also address book in a tab.</li>
</ul>
</ul>
</blockquote>
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.<br>
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
<ul>
<li>Attachment tab.</li>
</ul>
</blockquote>
<b>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.</b><br>
<br>
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
<ul>
<li>Social Search.</li>
<ul>
<li>Extend OpenSearch to social networks.</li>
<li> Also <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/">http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/</a></li>
</ul>
<li>Thunderbird Button.</li>
<ul>
<li>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.</li>
</ul>
<li>Address Book.</li>
<ul>
<li>re-design as a web-app, possibly targeting Mobile first…</li>
<li>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.</li>
</ul>
</ul>
</blockquote>
<b>Small stuff or not, I fully support any approach of working on
existing outstanding bugs and RFEs before diving into new large
things.</b><br>
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
<ul>
<li>Perspectives!</li>
<ul>
<li>Could include a Facebook-ish Timeline view.</li>
<li>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.</li>
</ul>
</ul>
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.<br>
<br>
I plan on presenting the list, and the feedback, at the Product
Council meeting next Thursday.<br>
</blockquote>
Is there any information online about the members and agenda of
"Product Council Meeting"?<br>
<br>
N.B. Allowing a bit more time for the feedback might improve quality
and quantity of feedback.<br>
<blockquote cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite"> <br>
Thanks,<br>
Blake.<br>
<pre class="moz-signature" cols="72">--
Blake Winton Thunderbird User Experience Lead
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:bwinton@mozilla.com">bwinton@mozilla.com</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
Big thanks to the team for all the work and efforts.<br>
</body>
</html>