[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KMail and contacts - RMB behavior
From:       "Eric Ellsworth" <whalesuit () softhome ! net>
Date:       2002-05-30 17:05:13
[Download RAW message or body]

> this data.  In my opinion, the lowest common denominator out there is the
> Palm address book.  Its the simplest set of data, and perhaps the single
most
> popular electronic address book going.  Its a very proven user interface
for
> even very demanding users of contact lists.  Pretty much every sales
person
> in my company (with the exception of a couple CE users) manage all their
> contacts with one.
>
> In my mind, interactivity with other applications and appliances should
take a
> very high priority over additional functionality.


I think we're reinventing the wheel here, there are well established
standard both for addresses and groupware scheduling: vCard and iCalendar.
Here's some stuff about the standards, inclduing the RFC:
http://www.imc.org/pdi/, http://www.oasis-open.org/cover/vcard.html .  If we
want data exchange we should base it on vCard, which I believe KMail either
does or is working on.  From what I see, vCard supports multiple email
addresses.  If you think we shouldn't aways show all the available vCard
fields, let's definitely discuss that, as the number of fields appearing
initally on one of those cards is indeed dauting.


> > This is part of it. My KMail/OE addressbooks are the only addressbook I
> > own, so I'm a heavy user.  Since I also store my contacts' phone
numbers,
> > and snail mail addresses in my addressbook, it's really annoying having
6
> > entries for Jared Yang, one for each email address or From name he's
chosen
> > to use:
> >     J. Yang jyang@nowhere.net
> >     Jaredon jyang@fun.net
> >     Jared Yang jyang@school.edu
> >     Jared Yang jyang@nowhere.net
> >     etc
> > Presently when I want to find someone's phone, I have to look through
all
> > 6. This is why I'm so nuts about making it easy to put multiple email
> > addresses into one contact.
>
> I understand what you're getting at here, and why.  Unfortunately I
believe
> this to be a dangerous road to go down.  Even as annoying as it may be to
> file away Mr. Yang there.  I too have similar kinds of entries going on.

I'm not sure I understand what's dangerous about combining email addresses,
if the user does it manually.  Now, if KMail automatically condensed
multiple email addresses into one contact, and/or KPilot didn't make sure
all the email addresses made into onto the Palm, that is indeed a source of
concern.  So perhaps let's talk about those questions separately.  Right
now, I'm just talking about a shortcut for manually condensing email
addresses into one contact.  Presently what keeps me from doing this is
having to copy and paste every one, rather than a right click - i.e.,
laziness. :)


Now, to some of the very reasonable concerns you raise:
    1) Autocondensing - I think this is generally a bad idea, as there's a
myriad of ways a user could want to aggregate info into contacts.  So I'd
see a Collected Addresses section, almost exactly like Mozilla's, and right
click behavior that lets you add new contacts
    2) Inadequate Palm syncing.  I have not used a Palm Pilot, but it sounds
from what you're saying like some models don't support vCard, or all the
info is not getting in there.  Here we'd have to resort to trickery, and it
sounds like Reinhold is just the man to do that.  :)
    3) Don't always show all the fields vCard offers.  Yes!  Less is indeed
more.  The question becomes providing an easy way to add the fields, and one
that's not annoying for power users...

> >  I want simple ways to:
> > 2) Search my emails by contact for something they wrote
>
> This already exists in KMail.  Try the "S" key.

Will do.  Thanks!


Kind Regards,

Eric

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]