[Kde-pim] New RecipientsPicker in kmail (KDE4)

[Cornelius Schumacher]

On Sunday 18 March 2007 16:15, Christian Schaarschmidt wrote:
> Am Sonntag, 18. März 2007 11:42 schrieb Cornelius Schumacher:
> > On Saturday 17 March 2007 21:52, Christian Schaarschmidt wrote:
> > > sorry for not being precise enough, one should never try to explain a
> > > GUI element without a screenshot ....
> > > the tree is from Bug 131796 and the checkboxes show what I ment in my
> > > previous posting.
> >
> > The problem with this approach is that you need an additional click to
> > add somebody as recipient to a mail compared to the current design.
>
> currently I have to
> open recipientspicker
> select recepient
> press "add as CC"
> open recipientspicker
> select recepient
> press "add as BCC"
>
> with  checkboxes:
> open recipientspicker
> click on the CC box
> click on the BCC box
> press "OK"
>
> am I missing something?

You are missing that the common user doesn't use CC and BCC at all. So the 
most common use case is:

open recipeintspicker
select recipient
press "add as To"

That's what your implementation makes harder.

In addition your implementation exposes the user to CC and BCC much more than 
the previous implementation. As many users don't know about CC or even BCC, 
this is a problem, because it makes the user interface more confusing.

As said before, the goal of the current implementation is to make it simple 
for simple things and make it possible to do more complex stuff, but don't 
expose this in a way confusing to the user.

> > The class is intentionally called picker and not editor because it's
> > purpose is not to edit the recipients list, but to simply pick a
> > recipient that should be added.
> >
> > This addresses the basic use case that somebody wants to write a mail to
> > one recipient in the most efficient way.
>
> that explains why I find it so hard to use.
> from my point of view it was always:
> Use Case "select one recipient"  -> autocompletion
> Use Case "large number or recipients" -> recipientspicker

Autocompletion only works, if you know the part of the name which gets auto 
completed and if you are willing to type in the recipients. That assumption 
is often not true.

The use case "large number of recipients" is a rare and complex case. We 
shouldn't optimize the user interface for that, if this means a regression 
for the common simpler use cases.

> I think we need something for editing large number of recipients, doing it
> directly scrolling up/down the list is too cumbersome. Having mixed set of
> To/Cc/Bcc makes it even more complicated.
> My suggestion addesses these issues.

Yes. It's certainly an improvement for the complex case for the power user. 
But as long as this gets in the way of the simpler use cases it's not an 
improvement in general.

> > More complex uses cases with CC or even BCC are possible, but that's not
> > the primary target.
>
> If not in the recipientspicker, where can we place this functionality?

It's possible to create complex recipients lists directly in the composer. If 
that also can be done in a non-intrusive way in the recipientspicker, that 
would be an improvement. Your current proposal is just not completely there 
yet.

All these issues are hard to discuss without knowing about the behavior of 
actual users. That's why it is so important to get the usability people 
involved.

-- 
Cornelius Schumacher <schumacher at kde.org>
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/