UX Priorities.
Blake Winton
Now that all the big features are landed, and we have some time to breathe again, I've been thinking a little bit about what we want to do on Thunderbird's front-end over the next couple of releases.
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.)
- Things like the tab you go to after closing the current tab (bug 508776).
- Maybe some UX Priorities.
- Clean up the landed features.
- Have an easier way to add and remove OpenSearch providers.
- Compose in a tab.
- Also address book in a tab.
- Attachment tab.
- Social Search.
- Extend OpenSearch to social networks.
- Also http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/
- Thunderbird Button.
- 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.
- re-design as a web-app, possibly targeting Mobile first…
- 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.
- Perspectives!
- Could include a Facebook-ish Timeline view.
- 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 plan on presenting the list, and the feedback, at the Product Council meeting next Thursday.
Thanks,
Blake.
-- Blake Winton Thunderbird User Experience Lead bwi...@mozilla.com
Unicorn.Consulting
Hey TB-Planners,
Now that all the big features are landed, and we have some time to breathe again, I've been thinking a little bit about what we want to do on Thunderbird's front-end over the next couple of releases.
Bug 250539 is one that appears in support on a regular basis and clearly is a big issue.
Users also complain that they can't edit the HTML directly (I think this is an offshoot of the clunky design tools, not a real interest in HTML editing. Although it would be nice to be able to switch to HTML ala Blogger)
I would also suggest that introducing Compose in a tab without fixing the composer code would be worse than doing nothing at all. Users are disgruntled but sort of accepting that the composer is clearly not getting any attention. Introducing the 'compose in a tab' without due fixes to the composer would rightly or wrongly lead users to the view that the composer is receiving attention, but it is the fancy stuff, not the basic usability of the composer and it more than likely going to upset them
Matt
JoeS
On 24/03/2012 4:54 AM, Blake Winton wrote:
Hey TB-Planners,In general I think that the compose in a tab (optional) should be at the top. In saying that, I don't see this as a compose in Tab so much as either replace for fix the existing composer. The pain point for users is not the absence of the tab, it is the creaking and unwieldy composer code.
Now that all the big features are landed, and we have some time to breathe again, I've been thinking a little bit about what we want to do on Thunderbird's front-end over the next couple of releases.
Bug 250539 is one that appears in support on a regular basis and clearly is a big issue.
Users also complain that they can't edit the HTML directly (I think this is an offshoot of the clunky design tools, not a real interest in HTML editing. Although it would be nice to be able to switch to HTML ala Blogger)
Edit>>Select all>>Insert HTML will allow you to edit the raw code.
I would also suggest that introducing Compose in a tab without fixing the composer code would be worse than doing nothing at all. Users are disgruntled but sort of accepting that the composer is clearly not getting any attention. Introducing the 'compose in a tab' without due fixes to the composer would rightly or wrongly lead users to the view that the composer is receiving attention, but it is the fancy stuff, not the basic usability of the composer and it more than likely going to upset them
Matt
Compose in a tab is just another rendition of broken editor.
My personal opinion is that there will never be any headway on this issue unless the Editor components are forked.
Compose in the browser context can never be fully reconciled to the message context IMO
- Papercuts! (Fix the easy little things that are making Thunderbird worse to use.)
- Things like the tab you go to after closing the current tab (bug 508776).
If we are going to push "tabs" vs standalone windows, then that alternative should be superior.
That certainly is not the case today.
Bug 392328
After using the standalone windows mode for so many years, it's really hard to change.
(I'm trying , but still occasionally close the app, thinking I'm closing the window.
- Social Search.
- Extend OpenSearch to social networks.
- Also http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/
I think folks are too entrenched in the "browser" way of doing things here.
Which leads me to my next point:
If we want to attract the "social media" crowd, then we must make that easy for them.
The basic requirement for that is easy html and multimedia access.
The Conversations extension made a step in that direction by adding an option to convert Youtube "links" to automatic iframe conversion.
This is what I consider a progressive agenda, It gives folks what they want.
Sadly, I still see comments relating to the age-old html vs. plaintext controversy around and about.
Further we should facilitate CSS in email to make email more web-like.(maybe some nice clean CSS templates)
Certainly these could be better than folks resorting to microsoft word or incredimail.
(We do support CSS, but it is discouraged in most forums)
--
JoeS
Ludovic Hirlimann
- Thunderbird Button.
- I think that we might want to skip a UI-refresh and go straight to the Australis Menu Button
Ludo
-- @lhirlimann on twitter https://wiki.mozilla.org/Thunderbird:Testing my photos http://www.flickr.com/photos/lhirlimann/collections/
Jb Piacentino
On 3/23/12 7:24 PM, Blake Winton wrote:That doesn't ring anybell to me. What's Australis , in a mozilla context ? (the new UI from ff ?)
- Thunderbird Button.
- I think that we might want to skip a UI-refresh and go straight to the Australis Menu Button
Ludo
-- @lhirlimann on twitter https://wiki.mozilla.org/Thunderbird:Testing my photos http://www.flickr.com/photos/lhirlimann/collections/
_______________________________________________ tb-planning mailing list tb-pl...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
Mike Conley
There are also some mock-ups for Australis for Thunderbird at
http://breakingtheegg.tumblr.com/.
-Mike
On 26/03/2012 8:35 AM, Jb Piacentino wrote:
>
> On 26/03/2012 08:37, Ludovic Hirlimann wrote:
>> On 3/23/12 7:24 PM, Blake Winton wrote:
>>>
>>> * Thunderbird Button.
>>> o I think that we might want to skip a UI-refresh and go
>>> straight to the Australis Menu Button
>>>
>> That doesn't ring anybell to me. What's Australis , in a mozilla
>> context ? (the new UI from ff ?)
> https://addons.mozilla.org/en-US/firefox/addon/australis/ + newly
> designed FF button.
>
>
>>
>> Ludo
>> --
>> @lhirlimann on twitter
>> https://wiki.mozilla.org/Thunderbird:Testing
>>
>> my photoshttp://www.flickr.com/photos/lhirlimann/collections/
Ludovic Hirlimann
> Ludo:
>
> There are also some mock-ups for Australis for Thunderbird at
> http://breakingtheegg.tumblr.com/.
indeed but it was hidden from my view :-)
Axel
On 3/23/2012 7:41 PM, Unicorn.Consulting wrote:On 24/03/2012 4:54 AM, Blake Winton wrote:
Hey TB-Planners,In general I think that the compose in a tab (optional) should be at the top. In saying that, I don't see this as a compose in Tab so much as either replace for fix the existing composer. The pain point for users is not the absence of the tab, it is the creaking and unwieldy composer code.
Now that all the big features are landed, and we have some time to breathe again, I've been thinking a little bit about what we want to do on Thunderbird's front-end over the next couple of releases.
regards
Axel
Unicorn.Consulting
> Ludo:
>
> There are also some mock-ups for Australis for Thunderbird at
> http://breakingtheegg.tumblr.com/.
And another new button that is so intuitive that it needs text to
describe which it is on the mockup. This is shades of the "wheel thingy"
in the add-on manager. No one can find it, what makes you think this
will be any better?
Talk about feature discover-ability, it will be an effort for some to
even find the menu. The real users that appear in the support forums are
still having difficulty with Tabs and the need to close them. They talk
of the home page and their inability to login. With a move to a Glyph
only UI starting point and 4 or 5 different Themes as default. Each with
it's own version of the Glyph. This will make supporting these users
very difficult indeed.
Matt
--
“Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.” Benjamin Franklin
Mike Conley
1. I would love, *love* to do a papercuts release.
>> * 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.
I really want to get into this, but yeah, maybe our time would best be
spent fixing and polishing for a little while before diving into another
massive feature...
>> * 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.
+1. Are we any closer to a TestPilot study for menuitem usage? Is that
still something we want to do?
>> * Compose in a tab.
Since it was before my time, I'm curious to know what happened to the
previous attempt at this...what went wrong?
Anyhow, it's an exciting list. Thumbs up, and I can't wait to dive into it.
-Mike
On 23/03/2012 2:24 PM, Blake Winton wrote:
> Hey TB-Planners,
>
> Now that all the big features are landed, and we have some time to
> breathe again, I've been thinking a little bit about what we want to do
> on Thunderbird's front-end over the next couple of releases.
>
> 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]>.
> * Clean up the landed features.
> o Have an easier way to add and remove OpenSearch providers.
> * Compose in a tab.
> o Also address book in a tab.
> * Attachment tab.
> * 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.
> * 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.
>
> Thanks,
> Blake.
>
> --
> Blake Winton Thunderbird User Experience Lead
> bwi...@mozilla.com
>
>
>
Nomis101
two main things which will bring the Thunderbird UX a big step forward.
So I'm anxious waiting for that. :-)
What I also was using for a while and liked (but I don't now what the
status of this is) was the Attachment Tab experiment
(https://bitbucket.org/clarkbw/attachments).
Advrk Aplmkt
If Mozilla provides a way to donate to specific projects, my money is definitely going to the Modern Address Book.
Chris Ilias
> Matter of fact, what _are_ the advantages/gains in having compose in a
> tab ? Or Tabs vs. Standalone windows for that matter.
> Maybe a more modern look, but that's not much in the way of "bang for
> the buck".
Off the top of my head:
* a popular use case is when focusing away from a compose window, having
it in a tab makes it easy to get back to the compose window/tab.
* It also helps keep in mind any windows you have forgotten to close.
* By moving tabs, you can pair the compose tab with the message it is in
reply to.
* It keeps the OS UI free of clutter.
I'm sure there are more gains listed in
<https://bugzilla.mozilla.org/show_bug.cgi?id=449299>, and if you look
up the advantages of tabbed web browsing, there's a large overlap.
P.S. Whenever you put phrases in quotes, I never know what you mean. :)
Thomas Düllmann
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.)
- Things like the tab you go to after closing the current tab (bug 508776).
- Maybe some UX Priorities.
According to 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), and disorganized ("Other actions" button cornered somewhere), wasting screen real estate, can't be collapsed or compacted out of the box (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). If I scroll the list of recipients, the buttons disappear altogether (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). 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) 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). 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).
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), we still annoy local draft users with creating multiple instances of the same draft (482836), and stubbornly saving them in the main draft folder even if the draft was opened from a draft subfolder (263114, since 2004). Again, basic I/O operations behaving badly. Thank you for fixing 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 - Unable to drag multiple attachments to a folder (since 2004, 14 duplicates, and counting)
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 - Support attaching image screenshot/files/anything from clipboard
292385 - Need indication of detached attachment (overlay icon, 'Detached:' note etc.)
Finally, there's my good old friend, 378046 - I wonder if it was perhaps the first bug I filed - and it's sibling, 722929:
378046 - 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 - 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 - (attachUXtracker)
Managing messages / Searching
Bug 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 - 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 - 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 - 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 - 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 - (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 - 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 - (glodafailtracker)
Bug 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 - 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 - (tb-tagsmeta))
Bug 456169 - Add "Tag" button to new interface for message headers (missing widget in header pane toolbar customization palette) (quick win)
Bug 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.
- Have an easier way to add and remove OpenSearch providers.
- Compose in a tab.
- Also address book in a 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.
- Attachment tab.
- Social Search.
- Extend OpenSearch to social networks.
- Also http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/
- Thunderbird Button.
- 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.
- re-design as a web-app, possibly targeting Mobile first…
- 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.
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.
- Perspectives!
- Could include a Facebook-ish Timeline view.
- 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 plan on presenting the list, and the feedback, at the Product Council meeting next Thursday.
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 bwi...@mozilla.com
Joshua Cranmer
Hey TB-Planners,
Now that all the big features are landed, and we have some time to breathe again, I've been thinking a little bit about what we want to do on Thunderbird's front-end over the next couple of releases.
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.)
- Things like the tab you go to after closing the current tab (bug 508776).
- Maybe some UX Priorities.
-- Joshua Cranmer News submodule owner DXR coauthor
Roland MoCo Tanglao
> A big one that gets me: when I switch to a tab containing a message in
> the preview pane, it reloads that message... and resets my scroll
> position.
we up the priority on this one!
...Roland
Magnus Melin
> On 12-03-29 7:19 AM, Joshua Cranmer wrote:
>> A big one that gets me: when I switch to a tab containing a message in
>> the preview pane, it reloads that message... and resets my scroll
>> position.
> That's a paper cut bug that we should fix as soon as we can! Blake: can
> we up the priority on this one!
> ...Roland
This is https://bugzilla.mozilla.org/show_bug.cgi?id=487386 - and yes,
it's probably the most annoying tab bug we have.
-Magnus
Andrew Sutherland
> This is https://bugzilla.mozilla.org/show_bug.cgi?id=487386 - and yes,
> it's probably the most annoying tab bug we have.
It's worth calling out that while hacking persistence of the scroll
position is a easy-but-brittle fix[1], the underlying problem is that
our 3-pane tabs are multiplexed so that they all use the same widgets
and is a more complex/potentially breaking set of changes.
When we change tabs, we swap out the nsITreeView/nsMsgDBView backing the
thread-pane and re-stream the message. The major upside of this is that
the multiplicity of the message reader and the thread pane has always
been 1. Extensions can listen for MsgMsgDisplayed and are at no risk of
getting confused by dealing with multiple tabs because we either swap
the references of a number of globals (gFolderDisplay, gMessageDisplay)
or there really is just one global (currentHeaderData).
The tradition of having only a single effective JS namespace/global per
window has also been maintained through this. (The contrasting example
is that the faceted search UI lives in an iframe. The multi-message
summaries, however, are loaded by messenger.xul and I believe just use
the iframe as a DOM they can manipulate.)
The dominant potential fixes are
1) Encapsulate each tab entirely in its own (XUL) iframe. This breaks
extensions, but can potentially just be fixed by changing their overlay
URL and potentially simplifies their lives because their code gets
instantiated once per tab. Invariants about accessing things by DOM ids
will be maintained.
2) Leverage the tab implementation and FolderDisplayWidget to swap out
what are currently presumed singleton globals, as well as possibly
changing who gets labeled with specific DOM ids (and changing existing
CSS on DOM ids to be on css class.) Some extensions would probably
survive without changes if all of their activity occurs synchronously on
MsgMsgDisplayed notifications and we are careful to only issue them for
the foreground tab. If attempting to provide perfect
backwards-compatibility, XUL overlay contributions and their CSS would
probably need to be processed at window load-time to ensure that some
type of cloning would be successful by re-writing #id rules to class
rules and inferring DOM ids that would need to be switched on tab changes.
I think no matter what happens, extensions would break and need to be
updated, so a lot of the question would be which model is less horrible
for development of Thunderbird and extensions.
Andrew
1: It's easy to save off the scroll position. However, if we still
re-stream the message when tabs are switched, we may have to wait for
the message to stream enough to restore the scroll position. This will
tend to be visually glitchy.
Robert Kaiser
> 2) Leverage the tab implementation
I think we should get to a point where all tabs are "content tabs" in
the sense that they are (almost) just like browser tabs
implementation-wise, just that those with a 3-pane or message window or
such have a chrome:// URL and therefore chrome privs and probably XUL
laoded inside. That would give the possibility to leverage a lot of
Firefox <tabbrowser> code and to have the tab contents cleanly separated.
The UI tabs with chrome privs should have some way to access stuff in
the main/parent window in some way though for some global objects and
similar things, but where we can easily separate and not degrade
performance or memory use, we should do it.
(And if you see some hidden agenda behind this to make Thunderbird and
Firefox more similar in some ways, you might not be wrong about it *g*)
Robert Kaiser
Tech163
On a related note (to the address book), not being able to right click
and copy email address (or select it for that matter) is quite annoying.
Hopefully that's something that comes along with the web-based? modern
address book.
Another thing I thought of is some sort of built-in "Minimize to Tray"
feature similar to bug 208923 -
https://bugzilla.mozilla.org/show_bug.cgi?id=208923 for both Linux and
Windows. Perhaps something to prompt the user on their first time
closing Thunderbird, and checkbox in TB Options/Preferences same place
as where it asks about default mail client.
Also https://bugzilla.mozilla.org/show_bug.cgi?id=724100, perhaps
something that can be fixed along with everything else related to the
message header.
--
Tech163
http://www.fusionswift.com/