Address Book - where are we going?
mozilla.org at zindus.com
Fri Feb 11 02:50:17 UTC 2011
On 9/02/2011 8:26 AM, Mark Banner wrote:
> At the recentall-hands, we had several discussions touching on the
> address book. We've been struggling with what to do with the address
> book - whilst it feels that it needs some significant rework,
> especially in the back-end, there's a big question of what to
> rework it in to and how.
I'd like to explore some of the bigger picture questions around
addressbook. Here are some (pretty raw) observations and assertions:
1. the present strategy looks like a continuation of the policy
since tb2. Summarised as: few new fields and churn in the api.
2. by way of feedback on that - perhaps other people found the tb3
api useful but for me:
a) the tb3 interfaces required a lot of new development work
b) extended spike in support burden because of instability,
that lasted maybe 6-12 months.
3. the policy of 'lets innovate around the UX before deciding
about the back end' seems intuitively right but
the experience of the past several years suggests that it
leads nowhere. Have any significant learnings emerged?
Basic problem is that there are too few people able to
utter the necessary incantations and the few wizards prefer
to do other things.
4. In any case, how is the success or failure of different UX
experiments going to inform or clarify the key strategic
5. The addressbook API represents 15 years of technical debt -
a massive dead weight around the neck of developers who
6. The debt has to either be paid or written off
before there is significant progress.
7. The basic idea of the TB addressbook api - a uniform interface
to a diversity of addressbook stores is flawed in conception
and impossible to implement in practice.
It's an experiment that has lived on far beyond it's time.
Thoughts around a roadmap out of the current hole:
8. concentrate on Thunderbird's internal contacts store for a while.
Forget about integration with external stores for a bit.
9. bolt on a 21st century access model that "competes"
with the current API. You can't instantly deprecate the current
API and everything that depends on it. But you might be able to
bolt on a new API that is simple and extensible.
- REST api modelled on Google Contacts API or Windows contacts API
which are both very well done. Particularly google.
10. schema and representation. It really doesn't matter so long
as it is extensible and there's a mechanism for determining
11. TB addressbook desperately needs a notion of "group" to subsume
both mailing lists and directories and support better
12. innovate the UX using this new API.
13. circle back to explore integration with external contact stores.
There's no easy answer. Personally I think sync offers the best
UX - rather than real-time interaction via API.
Either way, the reality to be faced here is that there's
a significant spike in maintenance costs as you integrate with
interfaces that are beyond your control. Do you have the
resources to take that on?
More information about the tb-planning