UX Priorities.

Thomas Düllmann 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
>         <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=product%3Athunderbird+whiteboard%3A[UXPrio]>.
>
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 
emails.*

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, 
every day.*

*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.
*
_*Reading messages
*_
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 
<http://weblog.latte.ca/blake/tech/thunderbird/UIFutures.html>: 
"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>).

_*Writing messages*_

Ftr:
- 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 
new bug).
*
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 
counting)
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 
them completed.
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 
<https://bugzilla.mozilla.org/show_bug.cgi?id=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 
<https://bugzilla.mozilla.org/show_bug.cgi?id=579473> -(attachUXtracker)

*_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 
functionality.
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 
<https://bugzilla.mozilla.org/show_bug.cgi?id=519202> -(qfasfailtracker)

*Global search:*
- 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 
<https://bugzilla.mozilla.org/show_bug.cgi?id=541349> -(glodafailtracker)

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 
<https://bugzilla.mozilla.org/show_bug.cgi?id=432710> -(tb-tagsmeta))
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
>         http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/
>   * 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 
Council Meeting"?

N.B. Allowing a bit more time for the feedback might improve quality and 
quantity of feedback.
>
> Thanks,
> Blake.
> -- 
> 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...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120329/15463046/attachment.html>


More information about the tb-planning mailing list