Re: Thunderbird’s future: a modern addressbook

neandr neandr at gmx.de
Wed Mar 14 23:04:08 UTC 2018


Different tb-planning/devmail/etc messages and also personnel statements 
of the Council Candidates spoke about the necessity to re-new the legacy 
TB/Addressbook. But there were not much concepts with functional or 
technical background, the look and feel, not even any activity plan / 
perspective for it.

So glad to see a TB/Addressbook discussion was started with:

On 12.03.18 17:28, TT Mooney wrote:
> The current address book in Thunderbird is barely usable. There are a 
> couple extensions which try to work around the problem, but they’re 
> not 100%. Not that I’m complaining about Cardbook, or anyone else 
> working on solving the problem — it’s the best we have now, and I’m 
> happy to have it. 

Cardbook -- evolved over the last few years (2-3 ?) -- shows how much 
improvement are possible to get a significant enriched addressbook. 
Philippe -- the author -- wrote:

On 14.03.18 14:40, CardBook wrote:
> CardBook starts to be a pretty decent address book but I don't know if 
> it is a modern addressbook : CardBook is written in javascript, xul, 
> css, xml bindings and an indexedDB database, so no "new technologies". 
> It is relatively handy until 10 000 contacts but above writing an 
> email is slow.

And he himself pointed to some important facts for any further work on 
the re-new of the TB/Adressbook (TB/AB).

 1. A new TB/AB was said to be an ideal part to see how modern technique
    can be used
>     It's intended to serve as a technical experiment for a rewrite
>     using web technologies
    Clearly Cardbook doesn't fulfill this point.

 2. TB performance should not be degraded by any subsystem -- or better
    said: the degradation should be a minium. One of the strong points
    of the legacy TB/AB is performance, and the trophy goes to:  the
    (hated) Mork db. So any replacement has a challenge here.
    Cardbook doesn't do well about that. I have seen massive delays at
    TB startup already with 3.000 contacts. Not sure if it's building
    the db at startup or handling the contacts table. Also it's
    interesting to see Cardbook is using XUL for the table and that
    should be fast.
    What happens with a change to using web technologies (JS/HTML/CSS)?
    A concept which could help here is described by Ben Bucksch:
>     "fastlist <https://github.com/benbucksch/trex>" TRex - HTML UI
>     markup language and library to develop GUI apps 

More imporant point for a new-TB/AB:

 3. A modern addressbook (using web technologies) should overcome legacy
    layout ideas. Clearly our legacy TB/AB UI is bound to a desktop
    implementation. If a new-TB/AB project is meant  "to serve as a
    technical experiment" we should experiment also with alternative
    layouts and handling, not only bound to mouse and menu and pulldown
    and such. Do will need a full list/table to show the contacts?
    Categories instead or additionally to Contact Lists (see also next
    point).

 4. Last not least TB/AB functionality: Mike Conley helped for a
    students project in 2016 and he reworked some of his interesting
    aspects it. Worth to take it as a basic also in 2018.
    See here: https://github.com/Thunderbird301/react-addon/wiki


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20180315/b741edb1/attachment.html>


More information about the tb-planning mailing list