thunderbird design: mail client or web browser?

[brainchild]

I have begun to run Thunderbird, in order to evaluate whether I would find it suitable to be my primary desktop client.

I find that it has many of the interface features of recent Firefox versions, giving the basic look and interactivity and light, pleasant, and responsive feel.

At the same time, I am curious about some of the history and choices underlying Thunderbird. I hardly can help but to think that Thunderbird is really a web browser trying to burst out of the shell of a mail client. Obviously, its network layer is based on mail protocols, unlike a web browser (though it still retains a web client), and the very top layer expresses the features of mail client, such as a message list and calendar. Between the bottom and the very top, however, the application mostly looks like a web browser.

I find this design hard to reconcile with my hopes for what I might find in a mail client.

The following are some specific observations:

- Users are forced to use tabs, at least at some level, as far as I can
determine. Use of tabs in a mail client is an interesting idea, in the limited
case of multiple open messages, but many users would prefer simply to open one
message at a time, or multiple message in separate windows, and have no need
of a tab bar.
- In a similar vein, the calendar and todo list are opened using static buttons,
but once opened, remain open in tabs, until closed, which introduces clutter,
and seems unnecessary, due to the static buttons remaining available.
- Although the calendar and todo list open in the main window, they may change
the size of that window, whereas preserving the size would seem a basic
expectation of different components using the same window.
- Despite the calendar and todo list appearing in the main window, the address
book surprisingly and confusingly opens in a new window.
- Preferences and the extensions browser actually might seem appropriate for
opening in a new window, but instead appear as new tabs in the main window,
seeming to recycle another design element from the web browser.
- Extensions are obtained from an integrated web browser, a design which seems
to attempt to hybridize two categories of application, while capturing
the essence of neither.
- In a normal mail view, two tool bars are shown, both with a separate search
box.
- CalDav and CardDav support is available through extension only.

Overall, I just wonder whether Thunderbird might be a really excellent mail application, or more generally, a mail and PIM application, if it tried to be exactly that, and left the browser-centric design features to Firefox. Such a design might not rely on tabs, but instead might feature a set of static buttons that switch among core PIM components (contacts, calendar, todo), all in one window, whih would preserve the size set by the user.

Extensions simply might be downloaded in a real web browser and applied to Thunderbird by file-extension association, or other means.

I would be interested to hear thoughts about why Thunderbird has its current design or how it might be refined in the future.

[WaltS48]

On 7/4/20 8:55 AM, brainchild wrote:

<snip>

> I would be interested to hear thoughts about why Thunderbird has its current design or how it might be refined in the future.

You can view the Thunderbird/2020 Virtual Summit presentations on
YouTube. Unfortunately the Thunderbird Vision presentation isn't posted yet.

<https://wiki.mozilla.org/Thunderbird/2020_Virtual_Summit>

--
OS: Ubuntu Linux 18.04LTS - Gnome Desktop
https://www.thunderbird.net/en-US/get-involved/
https://give.thunderbird.net/en-US/
Why didn't he Make America Great Again in the first term?

[Jörg K (Android)]

In general, the move is to put everything into tabs. The options and
account settings were once in stand-alone windows, now they are in tabs.
The address book window is a leftover from to the past, personally I'd
like to see it in a tab, too. I have customisation that puts the activity
manager into a tab. Tabs reduce desktop clutter, there were even
movements to put composition into a tab, just like the calendar can open
events in tabs. That said, there is an option to open messages in one or
more stand-alone windows.

The two searches, global and folder search, are a pain, again
historically grown and from a time when TB was almost purely
volunteer-driven.

I believe that the integration of CalDAV and CardDAV is planned.

Finally an UI overhaul is planned to make the components you mentioned
more consistently accessible with buttons.

The videos Walt mentioned are a good place to get an idea of what is
planned long-term.

Jörg.

Haha, not using TB for this mail. A mobile version has been discussed,
too.

--
Sent with FairEmail for Android
https://email.faircode.eu

[The Wanderer]

On 2020-07-04 at 11:01, Jörg K (Android) wrote:

> In general, the move is to put everything into tabs. The options and
> account settings were once in stand-alone windows, now they are in
> tabs. The address book window is a leftover from to the past,
> personally I'd like to see it in a tab, too.

FTLIMBW, I find this (overall) move abhorrent. I do not want a tab bar
in my mail client, period, and anything that tries to force me to have
one there is a bad thing. Having an option for any given thing to be in
a tab, and even having that be the default, is just fine; having
anything be *forced* to be in a tab is not.

I get by to date simply because I don't use the features of Thunderbird
that (in the version which I run) are tab-only, so the tab bar doesn't
appear (outside of limited circumstances, which I keep to a minimum and
cringe my way through) - but IIRC there are already features that I'd
like to use if they weren't restricted to tabs, and if more and more
things move to tabs this posture will lock me out of more and more
features and that will eventually become unsustainable.

The result of that will be that I will stick indefinitely at an older
version (which I'm already doing for other reasons, also UI-related,
though I'm starting to work towards trying to deal with those other
reasons), which isn't good for either Thunderbird or me.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Mark Banner]

On 04/07/2020 13:55, brainchild wrote:

> Between the bottom and the very top, however, the application mostly looks like a web browser.

I don't think that actually matters. It is distinct enough from a web
browser that generally most users won't realise. Oh, and it doesn't have
anything by default that looks like an address bar.

> Overall, I just wonder whether Thunderbird might be a really excellent mail application, or more generally, a mail and PIM application, if it tried to be exactly that, and left the browser-centric design features to Firefox. Such a design might not rely on tabs, but instead might feature a set of static buttons that switch among core PIM components (contacts, calendar, todo), all in one window, whih would preserve the size set by the user.

I know lots of users do use tabs - to leave important messages open, or
for other things (I will also sometimes leave messages open). Using
different windows tend to be more of a context switch for me.

> Extensions simply might be downloaded in a real web browser and applied to Thunderbird by file-extension association, or other means.

The problem there is that it makes it difficult, and it is another
context switch. If I have to switch away to a browser to find add-ons
that what makes it less likely that I remember what I was doing or
remembering to come back. There would potentially be other challenges
regarding the different file extensions as we'd be inconsistent with
Firefox, and there are some add-ons which do work for both.

Keeping it within the same application reduces that context switching.
It also makes it really easy to install add-ons rather than the "go
somewhere else, find what you want, switch back again" route.

There's other uses as well - Add-ons frequently display sites in browser
like tabs or do site-like pages for options and other controls.
Thunderbird can display a what's new page loaded into a tab.

Generally a lot of the uses make a lot of sense. If you have web browser
technology in the back-end why not use it?

Mark

[Wayne]

On 7/4/20 8:55 AM, brainchild wrote:

I would be interested to hear thoughts about why Thunderbird has its current design or how it might be refined in the future.

In terms of history the basic design and layout is little changed from the Netscape days.  Sure there have been tweaks, color changes, additional functionality and modernization largely to follow changes in the OS. And yes, we borrow much from Firefox design and widgets (as was done in Netscape), which isn't necessarily a bad thing - because they we don't need to code our own. 

Regarding future refinement, personally I don't care about design unless it gets in the way of my productivity. Maybe it's just me but I am happy to ignore or not use parts of a product I don't like, as long as on balance I am productive.  (OTOH I find the proclivities of most people who post about design - whether they like or don't like a UI - are about about how adaptable people are willing to be, or matters of personal taste. Taste includes how busy the UI is or is not, or tabs vs no tabs, or how appealing something looks.)

So I'd rather developers focus on improving productivity and clarity of the UI (including accessibility improvements) versus trying to serve too many people's taste/desire for customization - but that's just me. 

[Frank-Rainer Grahl]

Jörg K (Android) wrote:
> In general, the move is to put everything into tabs. The options and account

...


Which is very unfortunate. As long as you "stay" in one task it is fine. I
don't want 50 open browser windows but then with mail it becomes blurry. It is
nice to see the folder pane and have a separate mail window. Chat in a tab
only would be horrendous. I only recently started to use Lightning because I
will loose my Notes access at work at the end of the year and a standalone
calendar would be nice. There is some interaction with mail wrt invitations
and other stuff but overall it is separate.

Undecided about address book. Not using it that often but for further
integration with calendar and mail tab only would probably not cut it too for me.

The preferences and account management are not uses that ofther so can be
either way.

I don't see many of the post 52 ux improvements as improvements but I am not
running TB so if TBs user base is ok with it so be it. I just find the current
crop of black, gray and white mobile alike UIs bland and uninspiring. They do
the job but so do others. As seen with Firefox this will imho hurt the brand
in the long term.

FRG

[brainchild]

I watched Magnus's and Alessandro's talks, from the Virtual Summit, as well as the one of Ryan's currently posted ("2020", not "Vision"). Among this selection, only Alex's talk directly addressed user experience.

Based on Jörg's previous comments, and Alex's talk, it seems, happily, that most of the topics I mentioned are currently being considered for near-term improvements.

Against this context, however, it is disappointing that current planning is for a likely expansion of the prominence of tabs in the application design. Perhaps more disappointing still is that Alex gave, in his talk, as far as I noticed, only scant mention of tabs, and no views on what value they may provide to users of Thunderbird.

Assembling the new information I have gathered over the past days, I sense that support for tabs has become deeply entrenched in the project organization. Yet I find no defense for them that I consider compelling, while also experiencing numerous annoyances because of them. Such observations lead me to worry that, for not only me, but for many similar users, usability will remain an unavoidable sacrifice associated with a choice to use Thunderbird.

Jörg explains that the value of tabs is that they reduce desktop clutter. I will address this rationale currently, in the context of common use cases, as it is the only one I yet have encountered for tabs in Thunderbird. Usually, in a mail client and PIM application, only one view is open at any time, either a list of messages, or one of the several PIM views. Occasionally, another kind of view is required, which may be for administration (e.g. preferences, extensions), message composition, or expanded display of a single message. Use of administrative views is relatively uncommon and short lasting. Often the user will open one such view, apply some actions, and then dismiss the view. Easy and direct access to that view, during its term of use, is of greatest importance. Occasionally, a user will put aside an administrative view before dismissing it, which window managers easily support if the view is open in a separate window. Very occasionally, a user will seek to examine an administrative view and another view together, side-by-side, which is possible only if each view is open in a separate window. If the layout of an administrative view requires a window larger than the main window is at that time, and if the view is opened in a new tab of that window, then two resizing operations on the main window are required to use the new view successfully without any lasting effect on the size of the window. In contrast, any new window may be sized automatically as appropriate for its content. Indeed, multiple windows open, of distinct size as well as layout, for the same application, remains an essential and established pattern in window-based application interfaces. In mail clients, message composition is generally limited to only one message, or at most several, at any single time. The draft feature safely persists an incomplete message without maintaining a representation of it within the user interface. Management of many concurrently active composition views is not a common or required use case. Opening a message in a view outside of the regular message view is perhaps the most compelling use case for tabs in a mail client, and extremely ironically, the only case in which their use currently may be disabled through direct configuration of the application. In most cases, however, the demand for a larger size of view for reading a message is best satisfied by a window that may be resized separately from the main window. Whenever many windows are open for the same application, a modern window manager consolidates them into a single point of access in a task switcher. Through workspaces, modern desktop environments give further support to work flows that require particular groupings of many windows. For every case within the context of modern desktop environments, tabs seem to offer limited value, compared to common alternatives, in a mail client and PIM application. The few compelling cases, meanwhile, may support tabs by user option rather than requirement, and indeed, the most compelling case already utilizes them only optionally, on contrast to others.

In the present design, the application initializes with a single tab. The label of this tab changes to the name of any mail folder that is selected, and may not specifically indicate its function for reading mail. If the calendar or task list is opened, usually from a button in the tool bar, then that other view opens in a new tab. Any other tab may be selected at some later time. If so, returning to the calendar or task list is possible using the tab that was created by the first access to that view. Alternatively, returning to either is possible using the same button that originally was the only direct access to it. Either tab may be closed at any time, making the button once again the only direct access to the corresponding view. During all such events, the message list is accessible only through the original tab, not any button, and that tab may not be closed.

Such details may seem arduous and unhelpful to a regular user, but to me illustrate a twisted web of convoluted relationships that would be easy to eliminate, and that are unfamiliar from contexts outside Thunderbird. An obvious design is a small set of static buttons for switching among basic views, without any tabs, and external windows for other views. Indeed, such design is precisely the one common in applications offering similar functionality as Thunderbird. I am led to fear that entrenched patterns latent in the current design and planning are preventing productive movement toward any number of superior alternatives.

If I today were shopping online for a new HDPI monitor, I might keep open five, ten, twenty, or even more tabs, each showing any of the countless possible product pages and search queries related to this task, and each given by a URI of perhaps more than one hundred characters. Often, tabs in the same window would hold various pages that share a similar layout, due to being part of the same site. Also, most web pages, following current design expectations, are highly adaptive to a wide range of window sizes. The effectiveness of tabs in a web browser owes largely to the combination of complex uses cases in web browsing and similar content in tabs in a browser window. Overall, whereas tabs have proven incredibly useful in web browsers, no means or reason is obvious, and no effective demonstration is proved, for transplanting that utility to a mail client and PIM application, which expresses only a few views and manages a relatively narrow set of messages and records.

At the moment, the Thunderbird community seems to include one group of users, represented in this discussion by Jörg, who seeks, through customization, to integrate tabs more completely into the user experience, and another group, represented here by the Wanderer, who seeks, by the same means, to eliminate them completely. Such division is hardly the making of a healthy product, a harmonious community, or a happy user base.

Alex, in his talk, showed a mockup for a redesigned interface, which he explained was intended very much to be provocative. He suggested that he was glad it generated strong reactions, because by doing so, it would stimulate discussion that has been badly needed. He joked that this mockup has been the "elephant in the room".

He spoke at length, among of a variety of topics, about revising the composition window for superior convenience over entry and management of long and heterogeneous lists of recipients. I am glad he is seriously analyzing such questions, because it is valuable that someone would do so, and if not he, then probably no one. Yet revisions of this kind appear to offer at best marginal incremental gains in overall experience, compared to the massive and immediate gains promised by resolving much more central and serious questions.

It seems to me that tabs are, in discussions over the design of Thunderbird, the "elephant in the room". It seems never to have been plainly identified which problems tabs may solve, or how they may do so better than existing solutions, and yet they seem to face no serious challenge from the core project organization.

I hope that this position will shift in the foreseeable future.

[Will]

On 04/07/20 17:33, The Wanderer wrote:

> On 2020-07-04 at 11:01, Jörg K (Android) wrote:
>
>> In general, the move is to put everything into tabs. The options and

>> account settings were once in stand-alone windows, now they are in
>> tabs. The address book window is a leftover from to the past,
>> personally I'd like to see it in a tab, too.
> FTLIMBW, I find this (overall) move abhorrent. I do not want a tab bar
> in my mail client, period, and anything that tries to force me to have
> one there is a bad thing. Having an option for any given thing to be in
> a tab, and even having that be the default, is just fine; having
> anything be *forced* to be in a tab is not.

+1

>
> I get by to date simply because I don't use the features of Thunderbird
> that (in the version which I run) are tab-only, so the tab bar doesn't
> appear (outside of limited circumstances, which I keep to a minimum and
> cringe my way through) - but IIRC there are already features that I'd
> like to use if they weren't restricted to tabs, and if more and more
> things move to tabs this posture will lock me out of more and more

+1

> features and that will eventually become unsustainable.
>
> The result of that will be that I will stick indefinitely at an older
> version (which I'm already doing for other reasons, also UI-related,
> though I'm starting to work towards trying to deal with those other
> reasons), which isn't good for either Thunderbird or me.
>
>

+1

Claws mail is great..... and just keeps getting better

[Will]

On 04/07/20 19:49, Mark Banner wrote:
> Generally a lot of the uses make a lot of sense. If you have web browser
> technology in the back-end why not use it?
>

Because it is an email client, and not a web browser.

I use a screwdriver with screws, not a hammer. Even if I happen to have
a hammer in my toolbox.

For us it has made updating the plug-ins that we use and rely on almost
impossible to upgrade because they rely on popups which now seem banned,
and do NOT work in tabs, at all.

Forcing everyone to use TB like a browser means we may as well just use
a browser and bin TB. There are plenty of webmail systems out there. We
may as well use them.

Is that what you really want? Because that is really the logical
extension of what you are doing.

Hey ho. We're sadly voting with our feet.

[Mark Banner]

On 15/07/2020 14:37, Will wrote:

> On 04/07/20 19:49, Mark Banner wrote:
>> Generally a lot of the uses make a lot of sense. If you have web browser
>> technology in the back-end why not use it?
>>
> Because it is an email client, and not a web browser.
>
> I use a screwdriver with screws, not a hammer. Even if I happen to have
> a hammer in my toolbox.

I think you're forgetting that a lot of the protocol layers, and message
display (at least for HTML) require significant parts of web browser
functionality. Sure you can write them from scratch, but that'll cost
you significantly more.

> For us it has made updating the plug-ins that we use and rely on almost
> impossible to upgrade because they rely on popups which now seem banned,
> and do NOT work in tabs, at all.

If we never had been branched from what was fundamentally a web browser,
we'd have likely had no add-on functionality or if we did, I suspect it
would have been limited in other ways, e.g. very limited UI additions.

> Forcing everyone to use TB like a browser means we may as well just use
> a browser and bin TB. There are plenty of webmail systems out there. We
> may as well use them.

I never said we had to force people to use tabs. I advocated for tabs
and to explain why some people like them.

One thing we talked about doing when I was working on Thunderbird was
making it so that you could have, for example, a calendar "tab" opened
in a separate window without a message "tab" - this would have gone at
least part way to allow everything opening in different windows.
Unfortunately the size and complexity of the work involved prevented us
from doing that at the time - a lot of the code assumes there will be a
message tab always available in the window.

Mark.

[The Wanderer]

I'm glad to learn that this is an option that people are at least open
to in principle, if one that would be difficult to arrive at in practice.

I've tried the integrated calendar, and immediately stopped trying
because of what it did to the Thunderbird window and available space
therein. (This was a while ago, so things may have changed in the
meantime, but I wouldn't particularly expect that.)

I miss the standalone Sunbird (and at least in theory still run it on
Windows, in Portable Apps form), and would love to see something
comparable to it return, including in a form which can be used on modern
Linux. I've even attempted to dredge into the depths of the VCS history
to identify the point where it was removed and try to fork it from right
before that point, in an attempt to resurrect it myself, but doing so
turned into enough of a fruitless slog that it went on the back burner
and I've yet to return to the effort.

[Tanstaafl]

On Wed Jul 15 2020 09:37:54 GMT-0400 (Eastern Standard Time), Will

<wi...@impamark.co.uk> wrote:
> On 04/07/20 19:49, Mark Banner wrote:
>> Generally a lot of the uses make a lot of sense. If you have web browser
>> technology in the back-end why not use it?

> Because it is an email client, and not a web browser.

Yes - and it must be able to properly render HTML emails.

HTML... web technology.

It is irrelevant if you don't like HTML email or disable it in
Thunderbird, the Thunderbird devs recognize that the vast majority of
email users expect their email client to be able to properly and safely
render HTML emails.

[Tanstaafl]

On Wed Jul 15 2020 09:53:54 GMT-0400 (Eastern Standard Time), Mark

Banner <mba...@mozilla.com> wrote:
> I never said we had to force people to use tabs. I advocated for tabs
> and to explain why some people like them.

I have no problem with the use of tabs.

What I have a problem with is forcing it on people... meaning, not
providing a simple option to not have to use them.

Provide a simple option to completely and totally disable tabs, that
would cause everything from Options, Addons, emails, Calendar, etc to

open in a separate window.

There is no technological or other reason that I am aware of to not
provide this as an option.

[brainchild]

> I think you're forgetting that a lot of the protocol layers, and message
> display (at least for HTML) require significant parts of web browser
> functionality. Sure you can write them from scratch, but that'll cost
> you significantly more.

Is the idea that you're expressing in this comment that it would be impossible for Thunderbird to continue to use the existing mechanisms for acquiring web content from a network source, or for rendering it to a display target, if it did not display a window with a tab bar at the same time?

Note that no one has suggested complete code independence between Firefox and Thunderbird. The immediate discussion is limited to what choices to make about integrating tabs in the user interface.

> One thing we talked about doing when I was working on Thunderbird was
> making it so that you could have, for example, a calendar "tab" opened
> in a separate window without a message "tab" - this would have gone at
> least part way to allow everything opening in different windows.
> Unfortunately the size and complexity of the work involved prevented us
> from doing that at the time - a lot of the code assumes there will be a
> message tab always available in the window.

Trying to support separate windows as an alternative to tabs may be a convoluted approach to addressing the problem. A very plain approach, the one used generally by similar applications, is to provide a set of static buttons, which are always visible, and which select a particular view within the same window.

This functionality is partially available with the calendar and task list buttons on the toolbar. Integrating the address book into the window, and adding a button for mail, would fully support all the core functions of the application without the need for tabs, or for placing a calendar in a separate window.

In these discussions, I tend to feel that many try to start with some very particular and complicated solution, while leaving unnoticed very clear, basic, and common ones.

Take a look at Evolution or Outlook. If some common work flow is easy in either of these applications, but difficult in Thunderbird, then the gap would seem to represent a shortcoming in the Thunderbird design.

If I were building a metaphor between Thunderbird and a car I might buy, I would describe the feeling of a dealer showing me a sun roof and heated seats, to distract me from the poor ergonomics. Achieving a basic level of usability from simplest principles ought to take highest priority.

[ishikawa]

Maybe I am missing something here.

Although I don't care for tabs very much since I use TB on big screen
desktop computers (one that runs Windows, the other that runs linux) and
saving space is not a priority as on the smartphone or pad device, I can
open a tab in a new window by choosing "Move to new window" menu item that
appears in context menu (the menu that appears when I right-click the tab
heading.)

Yes, the added manual step is necessary, and I wish there is a simpler one
click method to open a message, etc. in a new window. But so far, I don't
find it so inconvenient to do that. But this is me using a big screen and
others may find it very awkward.

Maybe we can provide a user setting that, when enabled, is to open a new
window and place the tab in the new window to display something there
automagically by following the procedural steps that would have taken when a
user moves a newly created tab to a new window immediately after the tab is
created.: i.e., create a tab and display something there, followed by the
procedural steps invoked when the user chooses "Move to new window" in the
context menu. A kludge, but maybe a useful kludge to some portion of the
user population.


Chiaki

[brainchild]

>
> Maybe I am missing something here.
>
> Although I don't care for tabs very much since I use TB on big screen
> desktop computers (one that runs Windows, the other that runs linux) and
> saving space is not a priority as on the smartphone or pad device, I can
> open a tab in a new window by choosing "Move to new window" menu item that
> appears in context menu (the menu that appears when I right-click the tab
> heading.)
>
> Yes, the added manual step is necessary, and I wish there is a simpler one
> click method to open a message, etc. in a new window. But so far, I don't
> find it so inconvenient to do that. But this is me using a big screen and
> others may find it very awkward.
>
> Maybe we can provide a user setting that, when enabled, is to open a new
> window and place the tab in the new window to display something there
> automagically by following the procedural steps that would have taken when a
> user moves a newly created tab to a new window immediately after the tab is
> created.: i.e., create a tab and display something there, followed by the
> procedural steps invoked when the user chooses "Move to new window" in the
> context menu. A kludge, but maybe a useful kludge to some portion of the
> user population.
>
>
> Chiaki

There are many shortcomings with this strategy. When tabs are so deeply integrated into the application design, pretending they do not exist is not feasible.

Consider the following objections:

1. As I indicated in my message from a few hours earlier, not wanting tabs is not the same as wanting separate windows. As I suggested, you might look at the layout of similar applications, such as Evolution. Each function corresponds to a static button, and pressing one of the buttons switches views, without any tabs or extra windows. This design is clean, simple, accessible, and functional.

2. A tab bar consumes space. Having a tab bar with never more than one tab is wasteful and unappealing.

3. Currently, it seems that every window is required to have a tab for the mail view, which must be the first tab and cannot be closed. This constraint assumes that mail is always of central interest to a user. It also makes it impossible for any window to have only one tab, unless that tab happens to be for the mail view.

4. Moving a tab to a new window whenever the a new one is opened manually does not guarantee that each window has only one tab. Other causes are possible for new tabs being created.

5. Views such as preferences and extensions have fundamentally different layouts from the mail and other common views. Even if the user moves tabs with these views into a new window, the result is a window of the same size as the parent. In contrast, when applications normally create dialog boxes, they give the box a size that is appropriate for the content. The user is not required to change the window to an appropriate size manually.

[Mark Banner]

On 16/07/2020 04:37, brainchild wrote:

>> I think you're forgetting that a lot of the protocol layers, and message
>> display (at least for HTML) require significant parts of web browser
>> functionality. Sure you can write them from scratch, but that'll cost
>> you significantly more.
> Is the idea that you're expressing in this comment that it would be impossible for Thunderbird to continue to use the existing mechanisms for acquiring web content from a network source, or for rendering it to a display target, if it did not display a window with a tab bar at the same time?
>
> Note that no one has suggested complete code independence between Firefox and Thunderbird. The immediate discussion is limited to what choices to make about integrating tabs in the user interface.

Will was suggesting that we shouldn't use the web browser parts because
Thunderbird is an email client, and they don't fit together. I was
trying to point out that it is useful to use at least some of the parts
of a web browser.

>> One thing we talked about doing when I was working on Thunderbird was
>> making it so that you could have, for example, a calendar "tab" opened
>> in a separate window without a message "tab" - this would have gone at
>> least part way to allow everything opening in different windows.
>> Unfortunately the size and complexity of the work involved prevented us
>> from doing that at the time - a lot of the code assumes there will be a
>> message tab always available in the window.
> Trying to support separate windows as an alternative to tabs may be a convoluted approach to addressing the problem. A very plain approach, the one used generally by similar applications, is to provide a set of static buttons, which are always visible, and which select a particular view within the same window.

Static buttons wouldn't let you have additional things open and easily
accessible like individual emails, task views, event views, contact views.

> This functionality is partially available with the calendar and task list buttons on the toolbar. Integrating the address book into the window, and adding a button for mail, would fully support all the core functions of the application without the need for tabs, or for placing a calendar in a separate window.

That's a reasonable point, though at what stage does your toolbar then
just become the equivalent of a tab bar with pinned tabs, but with the
limitation of not being able to add / open other things?

> Take a look at Evolution or Outlook. If some common work flow is easy in either of these applications, but difficult in Thunderbird, then the gap would seem to represent a shortcoming in the Thunderbird design.
>
> If I were building a metaphor between Thunderbird and a car I might buy, I would describe the feeling of a dealer showing me a sun roof and heated seats, to distract me from the poor ergonomics. Achieving a basic level of usability from simplest principles ought to take highest priority.

I think this is a matter of opinion. Personally, I'm quite happy with
how it works on the whole, and I know others are happy as well. You
probably know or can find people who aren't. Pleasing everyone is
difficult to do - though we should, of course, try and do our best.

Just a note, I'm going to make sure the Thunderbird UX lead is aware of
this discussion, I'm not sure who exactly monitors this list these days.

Mark

[brainchild]

> Will was suggesting that we shouldn't use the web browser parts because
> Thunderbird is an email client, and they don't fit together. I was
> trying to point out that it is useful to use at least some of the parts
> of a web browser.

I doubt he was expressing a plan to rip out the HTTP network and HTML display layers. I understand his comments to be limited in scope to window layout, which has always been the scope of this discussion.

> Static buttons wouldn't let you have additional things open and easily
> accessible like individual emails, task views, event views, contact views.

Individual messages, as I have said, in my view, is the strongest case for tabs in a mail client. For me, the case still feels not particularly strong, since features such as bookmarking, tagging, refiling, and external windows seem to me to make it possible to achieve the same level of convenience, without the liabilities or overhead of tabs. Nevertheless, I have no need to take away this support if some users benefit from it.

For tasks, events, and contacts, it is hard to see why relying on static buttons imposes a limitation. When the user clicks on a task, the application generates a view of the task. The behavior is the same for events and contacts. One may ask to keep many contacts open at the same time, in separate tabs, but this need seems very limited in practice, and better served by other features, such as the ones mentioned above.

> That's a reasonable point, though at what stage does your toolbar then
> just become the equivalent of a tab bar with pinned tabs, but with the
> limitation of not being able to add / open other things?

A dividing line between two categories may be completely arbitrary. One observation is that I have explained the buttons as sitting on the tool bar only because that approach is least disruptive to the current design. I find no particular reason why the tool bar is the only or best location for them. Also, I think that "not being able to open other things" is not an accurate characterization. The buttons represent a small number of top-level features, such as mail and contacts. From a contacts list, any contact may be opened. A button related to contacts is need only to move to the contacts view, but not to select any particular contact. Pressing the button for contacts opens a list of contacts in the main window pane.

Again, I point to Evolution and Outlook. Neither uses tabs, and yet all the features of mail, contacts, and related components are fully accessible.

> I think this is a matter of opinion. Personally, I'm quite happy with
> how it works on the whole, and I know others are happy as well. You
> probably know or can find people who aren't. Pleasing everyone is
> difficult to do - though we should, of course, try and do our best.

In some sense, perhaps, but I return to the comparison of Evolution and Outlook. I compare this design to a basic five seat sedan. It is what the market has proved to be the baseline concept of a consumer motor vehicle. Some users may have specialized interests, and others may have relaxed needs, but most car owners have a sense that they would not sacrifice the back seat of their car for a sun roof, even if many think that a sun roof is nice to have.

> Just a note, I'm going to make sure the Thunderbird UX lead is aware of
> this discussion, I'm not sure who exactly monitors this list these days.

I think this idea is a good one. I offered my thoughts on Alex's recent talk in an earlier message in this discussion. I'm glad he is working on some of the problems he mentioned. For example, I look at the message list, and feel that the headers are hard to read because they are so tightly spaced. He mentioned that he realizes spacing is worth considering, so hopefully at some time his ideas will lead to improvements in this aspect. Even so, these questions seem trivial compared basic navigation issues. If Alex would postpone resolving the finer display details in favor of developing an overall strategy for application navigation, I think that the effect would be favorable.

[Tanstaafl]

On Thu Jul 16 2020 03:06:09 GMT-0400 (Eastern Standard Time), brainchild
<eric...@gmail.com> wrote:
> Consider the following objections:

>
> 2. A tab bar consumes space. Having a tab bar with never more than one tab is wasteful and unappealing.

Exactly - which is why, if the user has an option to 'Never use tabs',
it would simply eliminate the Tab Bar. Completely, less wasted space for
those of us who do not want to use Tabs.

> 3. Currently, it seems that every window is required to have a tab
> for > the mail view, which must be the first tab and cannot be
> closed. This constraint assumes that mail is always of central
> interest to a user. It also makes it impossible for any window to
> have only one tab, unless that tab happens to be for the mail view.

Exactly - so when the 'No tabs' option is enabled, there is no
requyirement for every window to have a Tab for the mail view. Simple.

> 4. Moving a tab to a new window whenever the a new one is opened
> manually does not guarantee that each window has only one tab. Other
> causes are possible for new tabs being created.

Not if there is an option to disable tabs that is honored by the system.

> 5. Views such as preferences and extensions have fundamentally
> different layouts from the mail and other common views. Even if the
> user moves tabs with these views into a new window, the result is a
> window of the same size as the parent. In contrast, when applications
> normally create dialog boxes, they give the box a size that is
> appropriate for the content. The user is not required to change the
> window to an appropriate size manually.

Solved by programming the different window types to remember their sizes
once the user has resized them to their liking.

This isn't rocket science.

[The Wanderer]

On 2020-07-16 at 12:38, Tanstaafl wrote:

> On Thu Jul 16 2020 03:06:09 GMT-0400 (Eastern Standard Time),
> brainchild <eric...@gmail.com> wrote:
>
>> Consider the following objections:
>>

>> 2. A tab bar consumes space. Having a tab bar with never more than
>> one tab is wasteful and unappealing.
>

> Exactly - which is why, if the user has an option to 'Never use
> tabs', it would simply eliminate the Tab Bar. Completely, less wasted
> space for those of us who do not want to use Tabs.

In the versions I've tried to date, there's already an option (or at
least a pref) to not show the tab bar when only one tab is open. That's
the only reason I've been able to stomach using the tab-supporting
versions in the first place, even as far as I have.

>> 3. Currently, it seems that every window is required to have a tab
>> for > the mail view, which must be the first tab and cannot be
>> closed. This constraint assumes that mail is always of central
>> interest to a user. It also makes it impossible for any window to
>> have only one tab, unless that tab happens to be for the mail
>> view.
>

> Exactly - so when the 'No tabs' option is enabled, there is no
> requyirement for every window to have a Tab for the mail view.
> Simple.

Simple to describe, but IIRC there's been a comment indicating that they
looked at trying to remove this requirement, and so much of the code was
centered around the assumption that "this window includes the elements
of the mail UI" that refactoring to remove that assumption would have
been prohibitively impractical. (Potentially tantamount to rewriting a
large chunk of the program almost from scratch.)

>> 5. Views such as preferences and extensions have fundamentally
>> different layouts from the mail and other common views. Even if
>> the user moves tabs with these views into a new window, the result
>> is a window of the same size as the parent. In contrast, when
>> applications normally create dialog boxes, they give the box a size
>> that is appropriate for the content. The user is not required to
>> change the window to an appropriate size manually.
>

> Solved by programming the different window types to remember their
> sizes once the user has resized them to their liking.

That's not necessarily under the application's control. Window size,
position, et cetera, is a matter for the window manager. I've applied
this "remember window size" behavior in my own WM, but it had to be done
in the WM; even there, it doesn't always behave as desired, because it
tends to treat all windows from a given program as being the same for
"what size do I remember?" purposes.

The whole "tabs" paradigm on Firefox's end has been described as an
evolution towards becoming a window manager in its own right, but it
isn't there yet, and is usually run within a dedicated window manager.
Thunderbird is even less far along that path.

In theory, if the application makes it sufficiently clear that two
sub-windows are distinct entities from one another and requests specific
sizes, in most cases a good WM will respect those. There's no guarantee
about that, however.

[Tanstaafl]

On Thu Jul 16 2020 13:46:35 GMT-0400 (Eastern Standard Time), The

Wanderer <wand...@fastmail.fm> wrote:
> In the versions I've tried to date, there's already an option (or at
> least a pref) to not show the tab bar when only one tab is open. That's
> the only reason I've been able to stomach using the tab-supporting
> versions in the first place, even as far as I have.

Yes, but its far from perfect. It still shows a substantial blank ribbon
across the top of the window basically negating the space savings when
it is not full screen - I'd love to eliminate this wasted space.

> Simple to describe, but IIRC there's been a comment indicating that they
> looked at trying to remove this requirement, and so much of the code was
> centered around the assumption that "this window includes the elements
> of the mail UI" that refactoring to remove that assumption would have
> been prohibitively impractical. (Potentially tantamount to rewriting a
> large chunk of the program almost from scratch.)

Could be true - but is, imnsho, evidence of poor decision making when
designing the feature in the first place.

[WaltS48]

It's nicer and easier to have my most used folders open in a tab when
Thunderbird starts. I can scan the Folder Pane to see if there are any
new messages, select the tab and read the messages in the Message pane.

I also like Chat in a tab.

[The Wanderer]

On 2020-07-16 at 19:49, WaltS48 wrote:

> It's nicer and easier to have my most used folders open in a tab when
> Thunderbird starts. I can scan the Folder Pane to see if there are
> any new messages, select the tab and read the messages in the Message
> pane.

I clearly am not understanding your workflow.

I scan the folder pane to see if there are any new messages, select the
folder, select the messages in the thread pane, and read them in the
message pane.

I find it hard to see what advantage selecting a tab rather than a
folder at step 2 could bring. In fact, it seems worse, because it's
limited to only the folders for which you already have open tabs; if
there are new messages in a different folder, you have to fall back to
the "select a folder" version.

Clearly there is some benefit you're seeing, but I have no idea what.


I do see one context where tabs could be useful: multiple accounts,
particularly if one is mail and another is news. If I could get myself
to accept the loss of screen real estate involved in the tab bar, I
could even see myself using a separate tab per account in that way, just
to have more visible-at-once space in the folder pane for each account's
list of folders.

Then again, I don't really use newsgroups anymore (the last time I did
was with news.mozilla.org, before most of the groups I was using it to
read were apparently going to get shut down in favor of mailing list
equivalents or worse), so it's probably moot in practice.

[WaltS48]

On 7/16/20 8:11 PM, The Wanderer wrote:
> On 2020-07-16 at 19:49, WaltS48 wrote:
>
>> It's nicer and easier to have my most used folders open in a tab when
>> Thunderbird starts. I can scan the Folder Pane to see if there are
>> any new messages, select the tab and read the messages in the Message
>> pane.
>
> I clearly am not understanding your workflow.
>

I'm not understanding the workflow of users that want many windows.

It is a nightmare to go looking for them with separate applications or
even the same application. Like the composition window in Thunderbird.

> I scan the folder pane to see if there are any new messages, select the
> folder, select the messages in the thread pane, and read them in the
> message pane.
>
> I find it hard to see what advantage selecting a tab rather than a
> folder at step 2 could bring. In fact, it seems worse, because it's
> limited to only the folders for which you already have open tabs; if
> there are new messages in a different folder, you have to fall back to
> the "select a folder" version.

No, I see the selected folder in a tab and the Folder pane for all the
other folders in the same tab. Unless I choose View > Layout and disable
the Folder pane.

>
> Clearly there is some benefit you're seeing, but I have no idea what.
>
>
> I do see one context where tabs could be useful: multiple accounts,
> particularly if one is mail and another is news. If I could get myself
> to accept the loss of screen real estate involved in the tab bar, I
> could even see myself using a separate tab per account in that way, just
> to have more visible-at-once space in the folder pane for each account's
> list of folders.
>

A separate account in a tab only shows the account hub for that account
and all other accounts still showing in the Folder pane. You have to
select a folder to view an email.

> Then again, I don't really use newsgroups anymore (the last time I did
> was with news.mozilla.org, before most of the groups I was using it to
> read were apparently going to get shut down in favor of mailing list
> equivalents or worse), so it's probably moot in practice.
>

I'm subscribed to 17 Mozilla newsgroups.

[The Wanderer]

On 2020-07-16 at 21:25, WaltS48 wrote:

> On 7/16/20 8:11 PM, The Wanderer wrote:
>
>> On 2020-07-16 at 19:49, WaltS48 wrote:
>>
>>> It's nicer and easier to have my most used folders open in a tab
>>> when Thunderbird starts. I can scan the Folder Pane to see if
>>> there are any new messages, select the tab and read the messages
>>> in the Message pane.
>>
>> I clearly am not understanding your workflow.
>
> I'm not understanding the workflow of users that want many windows.

It's not so much that I want many windows. Most of the time, I have
exactly one Thunderbird-related window open: the main one.

It's just that when I do want to open something that doesn't have a
dedicated space within that main window, I want it to live in its own
separate window, for the limited duration that it will be around. Things
like the Compose window, the options / account settings / etc. dialogs,
about:config, the advanced search functionality, or - rarest of all - a
specific message.

(That next-to-last is something which I do sometimes want multiple
windows for, one window for each active search, although I think that's
happened maybe once a decade or so. I also do a separate window for each
message in the process of being composed, but it's rare for me to have
more than one going at a time without closing the others out into saved
drafts; that might happen a few times a year.)

I do miss the "quick search" functionality, because I can't get that as
a toolbar widget anymore; unless something has changed since I last
checked new versions, "quick filter" is only available as a separate bar
of its own inside the folder pane, which either takes up vertical space
all the time even when I don't need it or changes the amount of
available space in the folder pane every time it's turned on or off.
Changing the layout of the UI like that (outside of "currently actively
performing customization") is a strict no-no for me, so I haven't
actually been able to bring myself to use this otherwise very nice
functionality in years. Fixing things so that the contents of that
separate bar can live in the toolbar would be one of the necessary
projects if I ever have the resources to dedicate myself to getting
newer Thunderbird versions to work the way I want again.

That "UI elements should not move around under my feet" sensibility is
why having the tab bar appear when I open something that isn't allowed
to go into a separate window anymore is such a major negative for me.
The reason having the tab bar be around all the time, so that it doesn't
appear and disappear like that, is a negative for me is partly a matter
of principle and partly fact that it takes up vertical screen real
estate; in some contexts, such as my 1366x768 laptop, vertical space is
at a very heavy premium.


As far as my actual workflow, in regard to opening windows:

I open the Compose window, write a mail, and save it as a draft, send
it, or cancel it without saving, any of which closes the window.

I open one of the settings dialogs, dig through it, check and/or change
the settings I'm after, and close the dialog.

I open the advanced-search window, run the search (usually in a separate
desktop, so that the window doesn't get in the way of the main one while
the search processes), open a search-result message in a
new window, close that message after determining whether it's the right
one or not, go back to the main window and find the right one in its
proper folder so that I can read it in proper context, and close the
advanced-search window.

I very, very rarely have any reason to open a separate window (or,
potentially, tab) and leave it open while I go on to do something else,
much less something that has any need to open a separate window of its
own. Even the advanced-search workflow is just recursing into one
additional layer of "open window", and the recursion is quickly returned
from. I just don't leave a Thunderbird-related window open unless it's
either the primary focus of the task I'm working on, or an ancestor of
that "focus" window in the recursion tree, which is to become the focus
again as soon as its immediate descendant is closed.

> It is a nightmare to go looking for them with separate applications
> or even the same application. Like the composition window in
> Thunderbird.

Maybe I'm not understanding what the Compose window being a separate tab
in the main window would be like, because at first glance that strikes
me as such a blatantly obviously horrible idea that I'm not sure where
to start describing why it's bad.

"Go looking for" doesn't arise unless you have plenty of windows open at
once, which as I said I basically never do in a Thunderbird context.

(In a Firefox context, where I do use tabs - well, I'm currently sitting
at 700-some open tabs, up from maybe as low as 400-some after having
ground it down from a peak of 5,190. Similar workflows very much do not
apply there.)

>> I scan the folder pane to see if there are any new messages, select
>> the folder, select the messages in the thread pane, and read them
>> in the message pane.
>>
>> I find it hard to see what advantage selecting a tab rather than a
>> folder at step 2 could bring. In fact, it seems worse, because
>> it's limited to only the folders for which you already have open
>> tabs; if there are new messages in a different folder, you have to
>> fall back to the "select a folder" version.
>
> No, I see the selected folder in a tab and the Folder pane for all
> the other folders in the same tab. Unless I choose View > Layout and
> disable the Folder pane.

That's about what I'd expect, yes - and I don't see how bringing tabs
into it offers any advantage, vs. just selecting folders within the
single "tab" which is the original, main window.

>> I do see one context where tabs could be useful: multiple
>> accounts, particularly if one is mail and another is news. If I
>> could get myself to accept the loss of screen real estate involved
>> in the tab bar, I could even see myself using a separate tab per
>> account in that way, just to have more visible-at-once space in the
>> folder pane for each account's list of folders.
>
> A separate account in a tab only shows the account hub for that
> account and all other accounts still showing in the Folder pane. You
> have to select a folder to view an email.

...yes, of course you do.

The point of a separate tab per account would be to keep all the
accounts other than the one the tab is focused on minimized, so that
they take up as little space in the folder pane as possible. (If I were
to go that direction, I'd probably even want to have only one account's
folders visible in any given pane at all. This would almost certainly be
a new feature, not something that's already possible.)

Unless what you're saying is that each tab has the same
expanded/collapsed state for the accounts and folders as all the other
tabs do? In that case the potential advantage disappears again.

[brainchild]

> I'm not understanding the workflow of users that want many windows.

It may be instructive simply to consider the design of modern mail applications generally. In such design, the application presents a list of accounts to the user, and the mail folders of each one. (One of these accounts may be a composite representation of all the real accounts on servers.) Any accounts or folders with unread messages are generally highlighted or otherwise distinguished.

The user may open any folder, whose contents then would populate a message list.

Separate from any benefit that tabs might provide, is the above design in any way inadequate, in terms of what functionality or convenience might be desired from Thunderbird?

[Tanstaafl]

On 7/16/2020, 9:25:13 PM, WaltS48 <sch...@invalid.net> wrote:
> I'm not understanding the workflow of users that want many windows.
>
> It is a nightmare to go looking for them with separate applications or
> even the same application. Like the composition window in Thunderbird.

I would only keep two windows open all the time - the Calendar, and Mail.

All other things opening in separate windows would be temporary - like
messages (at least those will still open in a separate window),
Options/Addons, those are temporary things I work with, and I want them
to open in a separate window, and when I'm done, they're closed/gone.

Also, it is impossible to compare the contents of two different tabs at
the same time, because you can only look at one of t hem at a time.

What you seem to be refusing to understand is, not everyone works the
same way you do.

[Tanstaafl]

On 7/16/2020, 7:49:54 PM, WaltS48 <sch...@invalid.net> wrote:
> It's nicer and easier to have my most used folders open in a tab when
> Thunderbird starts. I can scan the Folder Pane to see if there are any
> new messages, select the tab and read the messages in the Message pane.
>
> I also like Chat in a tab.

You are not everyone. That is the point. Choice is best, whenever
possible, and there is simply no technological reason that tabs must be
forced on everyone.

[Tito]

Hello

I just saw the following page where it is explain how to create a simple
minimal "Hello World" Mail Extension step by step. i.e. from the guide
here:

https://developer.thunderbird.net/add-ons/examples/hello-world-add-on

I decided to directly test already available one i.e.

https://github.com/cleidigh/ThunderStorm/tree/master/examples/MailExtensions/HelloWorld-Popup

I notice that although the extension is being installed correct in TB
version 78.1.0 (64-bit), when i click on the extension i do not get the
expected JavaScript code executed i.e. the JavaScript file popup.js is
not getting executed. That means i am not able to see the console.log
output in the development console.

popup.js :
###############################################################
console.log('Hello, World! - from popup.js');
###############################################################

then after reading the page again i notice the comment:

„
The default content security policy disallows JavaScript placed directly
in <script> tags and inline event handlers like onclick. Place all your
Javascript code into a separate file (like popup.js in this example) and
use addEventListener() instead of inline event handlers.
„



Am i missing something in the extension or is the example out of date
and the addEventListener mnethod is not present there?
It fails to load any JavaScript what so ever.


Tito

[Tito]

apologies , did a reply to all the first time, now this should be in the
correct thread!
#########################################################################

[brainchild]

Now that the activity in this conversation has settled, I would express my hope that all of the various comments, mine and others', receive the attention of the core development team, and that I would be happy if any overall responses were provided through this thread, as otherwise I am unlikely to learn of them. I would also express gratitude to all who have contributed so far to the discussion.

[Dave Royal]

<https://github.com/cleidigh/ThunderStorm/issues/4>
--
(Remove numerics from email address)

[Tito]

thank you Dave,

i saw this and that fixes the problem.
many thanks !

On 10.08.20 17:13, Dave Royal wrote:
> <https://github.com/cleidigh/ThunderStorm/issues/4>

[Will Mische]

I was commenting on the UI, not the fact that you need a html
rendering engine.

You can use the rendering engine without turning the entire application
into a browser, which is all that TB really has become.

Which in turn has meant breaking lots of other thing en route.

TB now is just like an electron app. A web browser specifically built
to read mails with a bit of other functionality.

Hence I said you may just as well use a browser and webmail now.

[Will Mische]

On Thu, 16 Jul 2020 01:56:53 -0700 (PDT)
brainchild <eric...@gmail.com> wrote:

> > Will was suggesting that we shouldn't use the web browser parts
> > because Thunderbird is an email client, and they don't fit
> > together. I was trying to point out that it is useful to use at
> > least some of the parts of a web browser.
>
> I doubt he was expressing a plan to rip out the HTTP network and HTML
> display layers. I understand his comments to be limited in scope to
> window layout, which has always been the scope of this discussion.
>

Precisely.

But we aren't allowed to criticise the UI - and this has been the case
for a long time.

[Will Mische]

On Thu, 16 Jul 2020 09:19:27 +0100
Mark Banner <mba...@mozilla.com> wrote:

> > Note that no one has suggested complete code independence between
> > Firefox and Thunderbird. The immediate discussion is limited to
> > what choices to make about integrating tabs in the user interface.
>

> Will was suggesting that we shouldn't use the web browser parts
> because Thunderbird is an email client, and they don't fit together.

No I wasn't. You misunderstood the comment.

We understand the use of browser technology to render html (yuck -
should be outlawed.. but... users).

That does not need to extend to use of browser *UI design* for
everything.

If you noticed our comment:

> Forcing everyone to use TB like a browser means we may as well just
> use a browser and bin TB

'Use like a browser' - as in UI use.

Since TB has gone browser tabby UI it broke our plugins, and TB didn't
even bother adding the missing API stuff to try and let anyone make
them work. (it wasn't for want of trying on our part - see elsewhere)

Tabs just do not work for this sort of scenario - we have discussed this
with developers and there are just no easy ways around it.

What is ironic is that browsers DO allow the use of popups/separate
windows, when it suits....

Any way, we'll use the old TB 52.x until we have finished migrating
elsewhere but we can't do that in 5 minutes. We'll also donate our cash
to other worthy open source causes instead.

>I never said we had to force people to use tabs

But that is exactly what has happened..................

>> Achieving a basic level of usability from simplest principles ought
>> to take highest priority.

> I think this is a matter of opinion. Personally, I'm quite happy with
> how it works on the whole, and I know others are happy as well

"IMHO..." Indeed it is. But most people had no idea what was coming
because they don't do nightlies and beta builds, and the way TB was
force upgraded and instantly removed all old versions almost over night
meant that no one was every given any real chance to go back, were
they? Job done, no right of reply.

So it is hardly a fair and equitable assessment of peoples thoughts
about it, especially as it is not easy to speak to devs with moderated
and/or restricted access lists etc. Any dissent is usually stamped out
pretty quickly. IME.

Every person who we know that uses it (and over the years we have
introduced a lot of people to it) says they have hated the upgrades,
but "What can we do?". And a lot of complaints from broken add ons etc
etc. "Might as well just use gmail/hotmail/webmail"

So, YMMV.....

Regrettably our experience over quite a few years is that TB devs are
not the most approachable or open to criticism. We are involved in a
number of open source communities, and none of them are as aloof as TB.

Hopefully chat will become more ubiquitous and federated which should
deal the final coup de grace and kill off email.

Hey ho. We move on.

For anyone else wanting an older version of TB based on 52.x this might
be interesting:

https://binaryoutcast.com/projects/interlink/

[Eric Levy]

On Wednesday, September 23, 2020 at 10:22:42 AM UTC, Will Mische wrote:
> > I doubt he was expressing a plan to rip out the HTTP network and HTML
> > display layers. I understand his comments to be limited in scope to
> > window layout, which has always been the scope of this discussion.
> >
> Precisely.
>
> But we aren't allowed to criticise the UI - and this has been the case
> for a long time.

Will,

You and I apparently agree regarding the technical questions.

However, based at least on the current discussion, I would not characterize the attitude from within the organization as closed or rigid. Rather, those in this discussion who have represented the organization replied with cordial attempts to explain the current position. They also expressed at least some interest in passing the comments to an appropriate internal group. I have no experience from the past on this subject, but I so far have found no particular cause for dissatisfaction over what has has occurred.

One unmet hope I would express is more direct and open engagement on this issues. Recently, the discussion has been dominated by two camps separated by a wide field, with little clarity over why one in particular is officially favored.

[Will Mische]

On Wed, 23 Sep 2020 20:03:07 -0700 (PDT)
Eric Levy <con...@ericlevy.name> wrote:

> On Wednesday, September 23, 2020 at 10:22:42 AM UTC, Will Mische
> wrote:
> > > I doubt he was expressing a plan to rip out the HTTP network and
> > > HTML display layers. I understand his comments to be limited in
> > > scope to window layout, which has always been the scope of this
> > > discussion.
> > Precisely.
> >
> > But we aren't allowed to criticise the UI - and this has been the
> > case for a long time.
>
>
> Will,
>
> You and I apparently agree regarding the technical questions.
>

Thanks :-)

> However, based at least on the current discussion, I would not
> characterize the attitude from within the organization as closed or
> rigid. Rather, those in this discussion who have represented the
> organization replied with cordial attempts to explain the current
> position. They also expressed at least some interest in passing the
> comments to an appropriate internal group. I have no experience from
> the past on this subject, but I so far have found no particular cause
> for dissatisfaction over what has has occurred.
>

I think you ought to be subscribed to tb-planning and tb-enterprise
lists, if they will let you (heavily restricted access and
tightly moderated/censored)

That will tell you a story in its own right.

[Wayne]

On 9/24/20 6:15 AM, Will Mische wrote:
> I think you ought to be subscribed to tb-planning and tb-enterprise
> lists, if they will let you (heavily restricted access and
> tightly moderated/censored)

How is it helpful or thoughtful to paint everyone with the same brush?

BTW - you are mistaken, tb-enterprise is not moderated in any way.