thunderbird design: mail client or web browser?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

WaltS48-12
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?
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

thunderbird design: mail client or web browser?

Jörg Knobloch
In reply to this post by brainchild
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
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

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


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Mark Banner-4
In reply to this post by brainchild
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

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Wayne Mery
In reply to this post by brainchild
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
<https://www.google.com/search?q=netscape+mail&client=firefox-b-1-d&tbm=isch&source=iu&ictx=1&fir=yIPfCV61z1WHaM%252CAFbxHFnCsNkZUM%252C%252Fm%252F02vl33z&vet=1&usg=AI4_-kSMUzDJ1l2YMAp4_qqPJdUD419xEw&sa=X&ved=2ahUKEwjRi7CtnrTqAhUilXIEHf8oB18Q_B16BAgxEA4&biw=1206&bih=721#imgrc=yIPfCV61z1WHaM>. 
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.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Frank-Rainer Grahl-4
In reply to this post by Jörg Knobloch


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

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

brainchild
In reply to this post by 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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Will-2
In reply to this post by The Wanderer
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

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Will-2
In reply to this post by Mark Banner-4
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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Mark Banner-4
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.

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

The Wanderer
On 2020-07-15 at 09:53, Mark Banner wrote:

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

>> 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.
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.

--
   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


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

tanstaafl-2
In reply to this post by Will-2
On Wed Jul 15 2020 09:37:54 GMT-0400 (Eastern Standard Time), Will
<[hidden email]> 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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

tanstaafl-2
In reply to this post by Mark Banner-4
On Wed Jul 15 2020 09:53:54 GMT-0400 (Eastern Standard Time), Mark
Banner <[hidden email]> 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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

brainchild
In reply to this post by Mark Banner-4
> 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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

ISHIKAWA,chiaki
In reply to this post by tanstaafl-2
On 2020/07/16 0:10, Tanstaafl wrote:

> On Wed Jul 15 2020 09:53:54 GMT-0400 (Eastern Standard Time), Mark
> Banner <[hidden email]> 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.
>


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



_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

Mark Banner-4
In reply to this post by brainchild
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


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: thunderbird design: mail client or web browser?

tanstaafl-2
In reply to this post by brainchild
On Thu Jul 16 2020 03:06:09 GMT-0400 (Eastern Standard Time), brainchild
<[hidden email]> 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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
12