

Contacts considered crappy - barry-cotter
http://yorksranter.wordpress.com/2009/04/03/contacts-considered-crappy/

======
lucumo
Also, family handling completely sucks. If you have both a husband and his
wife in your contacts and they move, you have to change both their contact
details. Even worse when you decide you want to keep track of the birthdays of
their three kids. This really needs to be refactored out to a family group
with persons in it (who have individual details like birthdays and mobile
phone numbers).

And then there is this whole American centeredness in contact management. My
girlfriend has two first names, while a friend of mine has two last names.
Neither fits the American model of "first name middle name last name".
Shortening the second part of their name to an initial would be completely
wrong.

But hey, it can never be worse than Evolution (an open source Outlook clone).
Evolution had the interesting property of not being able to handle birthdates
before 1970 properly. Cause, you know, who would know anyone born before
1970...

~~~
harpastum
One way to handle the family groupings can be achieved in Apple's Address Book
using Smart Folders.

Smart folders allow you to create auto-updating groups based on rules.
Therefore you could create groups based on last name (families). If there are
several families (i.e. extended family), you can add other rules to
differentiate them, like State, ZIP code, or a custom tag in their 'notes'
field.

------
harpastum
I think a decent counterexample is Apple's 'Address Book.' To go down his list
of complaints:

-Accepts Multiple vCards at once (and export vCards)

-Local copy (also syncs to iPods and iPhones), LDAP syncing, and 'cloud' copies for MobileMe customers (anyone can 'subscribe' to public contact lists)

-No hierarchy--there's a main database, and separate 'groups' that are similar to iTunes playlists (i.e. contacts not exclusive)

-Smart groups for even better control (rule-based groups)

-Good UI (obviously subjective)

The only thing that Address Book doesn't have is a "Visual Directory",
although personally I don't see the need for it (the idea seems akin to tag
clouds to me--it sounds cool in theory, but it's implementation would probably
be more flashy than functional).

I'm not saying Address Book is the end-all and be-all of contact management,
but it seems to satisfy all of his complaints.

~~~
unalone
Address Book isn't necessarily great, but you're right: it absolutely doesn't
suck. Combined with its Mail/iChat integration, it makes for a pretty awesome
communications suite.

That said, there's still almost certainly room for improvement. Contacts are
still seen as a task rather than a pleasure.

~~~
harpastum
Your comment about 'task rather than pleasure' reminds me of the story about
TapBot's new iPhone unit conversion app. [1]

They took an idea that had been done and re-done ad nauseam, but focused on
the enjoyment of the process rather than simple efficiency. I like the way the
developer describes it:

"Our goal was to make unit conversions fun and enjoyable. I wanted to separate
the conversion steps into little tasks that need to be completed. It gives a
sense of satisfaction when you’ve completed a unit selection sequence or shock
if you press the wrong button, almost like a game. Regardless of whether the
feedback is positive or negative, it brings out emotion in the user and that
was my goal. Once you get used to it, there’s a sense of satisfaction and
rhythm to the process. It’s very subliminal, but it’s there."

[1]<http://news.ycombinator.com/item?id=543934>

------
jodrellblank
I was thinking about this on the way to work earlier regarding calendars, and
how I don't want to choose a particular service to grace with my data, and
then try to hack 'sync' to other services and devices.

I came up with...

Make the data the important part. Carry the data structure around with me on
my device(s) of choice.

Have the data accessible in a standard format - i.e. I can keep it in
vCal/vCard format - or, in any format I choose as long as it has an included
vCal/vCard interpretive layer.

Anywhere I want to use it, it would be up to the program to read/write the
appropriate format. That is, instead of a proprietary data store with
export/import as afterthoughts, it would be fundamental - or so key that it
would cease to exist in its own right. You don't import wood into a chisel in
order to shape the wood, why must we import all of our calendar into a program
in order to add an appointment?

The model I was thinking of would be more like the wood carving example -
you'd present a slice of your calendar to a program, which would carve it and
give it back.

Still plenty of details that would need working out, though.

