Thunderbird is getting good again

I used to be a fan of Mozilla’s email application, Thunderbird, for a long time – even going back to Netscape Communicator days and through the first Mozilla release. Unfortunately, at some point, Mozilla focused on Firefox to the neglect of everything else, and then directed their energies into what at the time felt like sideshows (like Pocket, Mozilla VPN, etc.). What ultimately made me switch away from Thunderbird, aside from growing performance issues, was the lack of a space-efficient three-column view (Bug 213945):

Screenshot of Thunderbird bug 213945 about better three-column layout – opened 20 years(!) ago, and finally closed in March 2023.

However, recently (-ish, 2017), Thunderbird was “spun out” of Mozilla proper and started to reorganize themselves, with a clear roadmap, a plan for funding including donations, new design directions, and a general re-architecture and cleanup of the Thunderbird code base.

For a while, I’ve been trying Betterbird, a Thunderbird fork that prioritized merging UI/UX improvements for end users (see the Betterbird FAQ for a few examples) over endlessly discussing technical concerns. However, many of the core issues remained, so I did not fully commit to Betterbird either.

Now, with the new Thunderbird “Supernova” design landing in Beta, I’ve been back on Thunderbird again for a bit longer and the difference is night and day. There are still some improvements to be made, especially around performance in large mailboxes and virtual views including them, but the current Thunderbird Beta looks and feels much more like a modern mail client: Performance is much improved, the UX looks fresh, there is an option to use Unified Folders, groupware (calendaring, contacts, tasks and chat) have been integrated instead of being relegated to extensions, encryption has been integrated in the core (again, from extensions), and even one of the most useful features for me – dynamically managing email identities, i.e. sender addresses – is now part of Thunderbird core (which I needed a while to realize, and which also triggered me writing this blog post, as I feel that function is not documented well).

So, what’s good?

There was a bug in a few betas that made Unified Folders unusable for me, but that appears to be fixed now as well – I may be staying on Thunderbird for the foreseeable future now! 🎉

Try it out for yourself with the Thunderbird Beta (installs alongside the stable version), or wait until the changes land in the next release – and if you want to support FOSS email, donate to the Thunderbird project!

Ordering options by frequency with hysteresis

(Skip to the horizontal divider for the idea if you don’t care about the context.)

With the continued Twitter chaos (popcorn worthy, in a way), the ActivityPub/Mastodon ecosystem has received a ton of additional attention lately. This includes UI/UX work on both the official Mastodon web UI as well as multiple alternative clients on several platforms. I am currently using Tusky on Android, Ivory on iOS, and both the Mastodon “Advanced” UI as well as [Elk]( on the web.

One of the features Mastodon exposes prominently is tagging posts with metadata such as the posting language. Unfortunately, the multilingual use case is rarely well served with the current state these features are implemented in: Most clients let the user set exactly one default language for posting, and offer a long, usually alphabetically sorted, list to pick another option. At least there is usually type-ahead search, but it is still far from a great user experience.

Mastodon itself lets users choose several “content languages”, as in “show me content in these languages”. This setting could conceivably double as a list of languages to pin to the top of the language selector widget, but having a separate setting would be better for flexibility. It also stands to reason that most people will be able to read and understand more languages than they are fluent writing in.

Already, there is a bit of a heuristic in Mastodon mainline, namely that it will set the post language of replies to the language of the parent post, which makes sense for threads. Additionally, English is always pinned to near the top of the list, right after the user’s chosen default posting language (which makes some sense, given the widespread use of English as an international communication language, but then we should also ask about why not Mandarin, or Spanish, etc.).

One UI paradigm that is often employed in similar contexts, and one that has also come up in discussions about evolving the language selector feature, is remembering recently used languages. There are more or less sophisticated algorithms here, for example:

  • Strict ordering by recency – the currently selected language will move to the top of the list and push everything else down one slot. Simple, predictable, but a bit annoying if the user frequently posts in different languages.
  • Static ordering from a selection – Of the many languages supported in the standard, the user gets to choose a subset (e.g. with checkboxes) and those get shown first in the widget, in whatever “natural” order they are normally in (e.g. alphabetically, or by database ID) and that order does not change. The advantage is that the user never needs to scan the list visually – click positions remain the same. The disadvantage is, obviously, that the “natural” ordering may not align with the user’s language use frequency at all.
  • Static, user-defined ordering – Same as above, but the user has a way to define the order explicitly. All the advantages as above, with none of the disadvantages, but the UI is necessarily more complex, both for the users to use and the developers to build and maintain, which makes this less accessible.
  • Simple ordering by frequency – usage is counted for each option, and the options ordered by the frequency of their use, e.g. if I post in English 50% of the time, 45% in German, and occasionally in Dutch, then the list would show English, German, and Dutch, in that order. While this has many advantages, it can take a while for the ordering to settle if the different options don’t have clearly different preferences. There is also a pathological case where people might use several options almost equally, and statistical noise will lead to frequent re-ordering of the options, and the case where at different times of the day (or one’s life) one interacts with different communities more or less, in different languages (one simple example could be moving to a new country).
  • Order by frecency. Wikipedia says “In computing, frecency is any heuristic that combines the frequency and recency into a single measure.” The most popular example is probably most browsers’ URL input boxes – I know for a fact that Firefox uses a sophisticated frecency algorithm, but I would assume that other browsers do as well. Basically, this algorithm weighs recently used items higher than they would be looking purely at the frequency of their use. A good compromise for most use cases, but for simple items like languages (versus suggested web URLs after a partially typed query), the ordering will likely be unpredictable and opaque for most users, which would be frustrating.

Now, what originally prompted this post was an idea I had while proposing changes to the language selector in Elk: Currently the default post language is the UI display language (not a good choice, they should really be decoupled) and there is no way to configure post language separately. Additionally, the language chooser widget does not show the currently selected option without clicking. All in all, not a great user experience (but one that is common in lots of software, especially when it is developed by a primarily English-speaking group). However, I wanted to make sure that they wouldn’t switch to a simple frequency-based model, because I post almost equally in English and German and I hate nothing more than drop-down menus that rearrange themselves seemingly randomly.

After considering the options outlined above, I thought that maybe another sorting method would be useful, which I admittedly haven’t completely thought through yet, but that I’d like to call “frequency (or frecency) with hysteresis“.

The idea is simple: Instead of looking only at frequency or frecency of items, add a hysteresis threshold.

Hysteresis, in this context, is at its core a “lagging change”, an approach commonly used for e.g. temperature control: Instead of stopping heating exactly at reaching 21.0 degrees C and restarting heating immediately when the temperature falls to 20.9 degrees C, there is a certain window the measurement has to clear first, so the heating would only start at e.g. 20.0 C and then heat up to 21.5 C, instead of constantly flip-flopping between on and off around 21.0 C.

In the context of ordering items in a menu, that would mean that the items do not get re-ordered immediately when their frequency or recency ranking changes, but only after it has changed by a certain amount (or amount of times).

An example: Of my last 10 posts, 5 were in English, and 5 in German. The languages drop-down shows English, German, and then all other languages, because I used English last. Now I post once in English and once in German, and now the ordering would be German, English, others, if going by frequency with last-used-wins. Annoying, because chances are good that the next post would be in English, which is now option #2.

If there was a hysteresis to the ordering, it would not change until I’ve posted significantly more in one language recently, let’s say at least a third more than the previous top spot = German gets the new top spot only once I posted 2 more times (in the above example) in German than English (6/3=2, 6+2=8). The exact thresholds should be determined based on some actual usage data, but this could nicely work around the challenge of people using multiple items with near equal frequency, and avoid the flip-flopping of a simple recency-based approach.