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

List:       kde-usability
Subject:    Re: KMail and addressing
From:       Andreas Mair <Andreas.Mair () linogate ! com>
Date:       2002-05-28 8:17:36
[Download RAW message or body]

On Dienstag, 28. Mai 2002 00:50, Michael W. Collette wrote:
> On Monday 27 May 2002 07:16 am, Andreas Mair wrote:
> > > "Remove" may be a bit too strong a word for what the intended function
> > > is. Perhaps more of a toolbar editing screen kind of implementation
> > > would be more clear.  Like a simple "<--" button.
> >
> > I understand your oppinion, but I think a "<--" button should only be
> > used if the "-->" buttons "move" the address from the left listview to
> > the right one. Do others think "Remove" is too strong, too?
>
> Good point, and I agree.  My only real concern was the possibility that a
> user might connect "Remove" with removal from the address book itself,
> rather than just the list.  Especially since both "New" and "Edit" are
> functions that do edit the address book.
>
> Most likely this isn't a critical point, and as a friend of mine likes to
> say, "they'll get the joke".

I think it should be clear the "New" and "Edit" act on the above (left) 
listview and "Remove" on the listview above it (right one).

> > I thought a search field too. I only hadn't the time to include it yet.
> > Choosing between addressbooks/LDAP will be thought of in detail, when
> > they are integrated in KMail. At the moment I see two possiblities: a)
> > integrating a drop-down list like Mozilla to let the user choose the
> > addressbook or b) integrate other address sources as new trees in the
> > left listview.
>
> Could do a little of both.  A drop down box that can select a specific data
> source, with one of the options being "All".  In the case of "All", provide
> a tree view like the one in your example.
>
> This would also address a possible issue with entries running off the edge
> of the list.  Long names with long addresses would have a tougher time
> fitting on screen when indented under a tree.

Sounds great!

> Along those same lines, I rather like the notion that someone with multiple
> addresses would have them show up as a sub-tree.  In cases like this, it
> probably isn't necessary to show their name next to each address on the
> left hand listing.

You're right, but for the first shot I wanted to change KMail as little as 
possible, and that was the easiest way to implement.
On the other hand I like the current display not very much. KMail always reads 
all 5 name details and sorts them. So if you enter "Mr." or "Mrs." etc. in 
the title field like I do, you have all "Mr."s and then all "Mrs."s  :-(  If 
you leave the title field free, KMail sorts by the firstname - not a better 
way.
I'm thinking of a two column listview: the first column shows the tree with 
the names sorted by "surname, firstname" (maybe using the "file as" field 
would be best, if it once works ok) and the second column showing the email 
address like it is showed today.

_______________________________________________
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]