[chandler-users] Re: chandler-users Digest, Vol 5, Issue 6
Sam Elowitch
sam at elowitch.com
Tue May 15 12:16:16 PDT 2007
Actually, I think a radical rethinking of contacts management needs to
be undertaken. Few, if any, PIMs leverage the true power of a relational
database. I see a very successful model whereby people, places,
phone/fax numbers, e-mail addresses, and the relationships among those
objects are all placed in separate tables will full referential
integrity and generous use of foreign keys. That way, there are flexible
ways to describe families and couples and their various work/home
configurations without being stuck in the old
one-home-address-and-one-work-address-per-person model.
Using this model, for example, my wife and I would each be represented
by a separate "person" record. Our home address would be in a separate
"location" table, and our phone numbers in a third table, and finally
our e-mail addresses in a fourth. The job of Chandler GUI would be to
form queries and display this information on a single "family card".
-Sam
> Send chandler-users mailing list submissions to
> chandler-users at osafoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osafoundation.org/mailman/listinfo/chandler-users
> or, via email, send a message with subject or body 'help' to
> chandler-users-request at osafoundation.org
>
> You can reach the person managing the list at
> chandler-users-owner at osafoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of chandler-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Address Book Implementation (Jeffrey Harris)
> 2. Re: Address Book Implementation (Jerzy Jalocha)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 May 2007 13:58:08 -0700
> From: Jeffrey Harris <jeffrey at osafoundation.org>
> Subject: Re: [chandler-users] Address Book Implementation
> To: chandler-users at osafoundation.org
> Message-ID: <4648CD60.2000702 at osafoundation.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Jerzy,
>
>> But what I see as a major hindrance for adoption is the lack of
>> contacts management. I know, there is a 2006 SoC project which has not
>> been integrated yet because of lack of time. But however crude and
>> restricted, I think basic contacts is a must-have, if feasible.
>>
>> If i know that I am starting to use a system that will grow into an
>> amazing and powerful application, I gladly can wait for the full
>> featureset to be implemented later. I just need to cover my basic
>> needs today.
>>
>> If not, I will just have to wait until a later release.
>
> In our planning about staging features, we realized we weren't going to
> have an email client powerful enough to replace most people's existing
> email client (Thunderbird, Apple Mail, or Outlook) by the time we wanted
> to ship the upcoming release we're calling Preview. Instead, we're
> thinking of Chandler (for now) as a complement to existing mail
> applications.
>
> Our goal for Preview is to have a tight, coherent feature set that we
> can think of as our first usable release. We decided that while
> contacts is an important feature, since we aren't yet an email client
> replacement, we could live without contact management for now.
>
> I'm sorry if that means we won't get to have you as an early user of
> Chandler. I appreciate your feedback that contact management is not
> just important but a basic requirement for you.
>
> It's too late for us to shift our strategy for Preview, but I for one
> would certainly like to see contacts included in our post-Preview
> feature set, I hope you'll give Chandler a try when we get there! Or
> even better, we'd be delighted to hear about what features are "must
> haves" for you when it comes to contact management.
>
> Sincerely,
> Jeffrey
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 May 2007 10:20:25 -0600
> From: "Jerzy Jalocha" <jjalocha at gmail.com>
> Subject: Re: [chandler-users] Address Book Implementation
> To: chandler-users at osafoundation.org
> Message-ID:
> <9b72f9a90705150920r3ab9941dt3d8e61d93663c400 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jeffrey, thank you for your detailed answer.
>
>> It's too late for us to shift our strategy for Preview, but I for one
>> would certainly like to see contacts included in our post-Preview
>> feature set, I hope you'll give Chandler a try when we get there! Or
>> even better, we'd be delighted to hear about what features are "must
>> haves" for you when it comes to contact management.
>
> BASIC FEATURES:
>
> * We need to share contacts cross-platform, with a centralized server.
>
> * It is probably a good idea to have a rich model for names (which
> works for persons, organizations, and families) right from the start.
> It would be a nightmare to have to change manually every entry later,
> when switching to a richer semantic.
>
> * One address, not necessarily with detailed fields. Just one chunk
> with many lines.
>
> * A limited set of phone numbers, which can be with fixed meaning
> (home, work, fax, mobile)
>
> * one email, one website
>
> * maybe role and organization.
>
> * A large field for notes, where I can store everything that doesn't
> have its place, yet.
>
> COMPLETE FEATURE SET:
>
> * Migration of contacts data from old to new versions. (Probably
> requires manual adjustments). But there can't be any data loss.
>
> * Chandler should allow to split contacts into different collections
> (eg. technical, administrative, personal), which are visible/invisible
> for different users. Some of them (personal contacts) stored locally?
>
> * With time, we need a complete set of fields with precise meanings
> (phone numbers, addresses, nicknames, birthdays, etc)
>
> * It should allow a precise handling of different locations (arbitrary
> number of homes, offices, each with address, phones, etc., maybe even
> email and websites.)
>
> * Some kind of grouping. (people that work in the same company, people
> that work or live together). Situations like: A grouped with B. B
> grouped with C. Search for A returns A B only, search for B returns A
> B C.
>
> * Efficient handling of locations. Company A with employees B, C, ...
> Q, moves to a new address. It should be necessary to change the
> address only once (A), and not for each and every employee (B, C, ...
> Q).
>
> I know, many, if not all, of these features are already planned.
> Grouping looks like a key feature for rich functionality.
>
> I haven't found an application with this feature set, so I will have
> to wait patiently until Chandler gets there. I'm sure, it is worth it.
>
>
> ------------------------------
>
> _______________________________________________
> chandler-users mailing list
> chandler-users at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>
>
> End of chandler-users Digest, Vol 5, Issue 6
> ********************************************
More information about the chandler-users
mailing list