[Bug 208719] New: different structure to manage phones/email/IM items

[Marco Menardi]

https://bugs.kde.org/show_bug.cgi?id=208719

           Summary: different structure to manage phones/email/IM items
           Product: kaddressbook
           Version: unspecified
          Platform: Debian testing
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kdepim-bugs at kde.org
        ReportedBy: mmenaz at mail.com
                CC: tokoe at kde.org, tuju at iki.fi


+++ This bug was initially created as a clone of Bug #110350 +++

Version:           KDE 4.x
Installed from:    Debian testing/unstable Packages
OS:                Linux

I propose a different structure for KAddressbook data, that, on my opinion, is
much more flexible and effective in office usage.
The current structure seems be taken from early PIM assistants, with a very
limited capacity, and a rigid structure of data (vCard).
In fact, you have a predefined number of fields where enter phone
numbers/emails and whatever, with only a limited set of description for the
fields (i.e. home, work, work fax, mobile...).
A program in Delphi that I've build time ago and that I find very effective has
a different aproach.
a) you have unlimited number of items (telephones, e-mails, etc.) associated to
a contact (master-detail tables)
b) you have a free description of the item (i.e. "wife's phone", "Rome office
L2" (I use "L2" as mnemonic to indicete "second phone line"), "private e-mail",
etc.
c) you have a list of "types" of item, that currently in my program is: phone,
mobile, fax only, phone and fax, e-mail
d) an "additional info" field, so it can contain the IM protocol, if the item
is of type IM, or the type of switch if the numeber is associated with a
phone+fax (manual/automatic)
e) you can order them at will (so you put on top the more used), thanks to an
"order" field

Very draft screenshot (just to give you an idea)
http://www.ammdomus.it/download/KDE/kontact_addresses_03.png

Advantages:
1) you can manage every situations, with a unlimited numbers of "items" per
contact, as for people with more than one office, or with a lot of people that
can be contacted but have to belong to the same contact (so you have "A.C.M.E.
inc." as contact, and numbers/faxes/e-mails of the director, a pair of
managers, the responsable of marketing, one secretary, an employee that is a
friend of you, etc.)
2) you have separation between the number/e-mail, the description, and the
"type" of technology (phone/fax/e-mail/messanger...). This greately helps when
automatically dialing, or for other automatic management of these information
3) when you want to contact someone, you can filter the important info in a
snap, i..e if you have to make a call, show only the rows of type "phone" or
"phone and fax", if you have to send a mail, just the type "e-mail", etc., or
have them showed in different color/icons
4) these data can be the base of data for a pecific telphony CRM/CTI program,
with call queues, call annotations, etc. (I'm thinking about an integration
with Asterisk or Yate PBX, for instance)

Disadvantages:
when you have to synch with a portable PIM (like iPaq), you don't have a 1:1
correspondence with the fields, since it uses the vCard desigh. To overcome
this, there can be used multiples aproaches (the first that comes me to my mind
is add one more field with "PIM sync vcard kind" that contains the old
classifications, so the transfer can work with those items that have tha field
that matches). In any case, the current situation is already of partial match.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.