[Kde-pim] Kontact Touch Mail - Usecases

[Thomas Pfeiffer]

On Saturday 25 May 2013 23:46:08 Heiko Tietze wrote:
> Am Samstag, 25. Mai 2013, 18:17:45 schrieb Thomas Pfeiffer:
> > The list was originally written not in order to prioritize
> > implementation...
> Well, that's a horse of a different color :-).

Yes. We should have clarified that before you reviewed it... On the other hand, 
this misunderstanding brought us your list of prioritized requirements, so 
it's a good thing in the end :)

> > I've written some comments on them.
> |
> |list=mailing list.
> 
> Isn't it rather a feature of the addressbook, if at all? Emails can be sent
> to a list of receivers but this list gets separated first. And when I write
> to active at kde.org for instance then I do not write to all single
> reciepients. Or am I wrong?

One example usage scenario is this:
Someone sends a mail to a mailing list (like active at kde.org) as well as to you 
personally (and maybe other people as well). Now if you reply directly, you 
only reply to the author. You could reply to all, but you might want to keep 
the discussion only on the list. 

Another scenario is a case are mailing lists which do not automatically set 
the mailing list as reply-to address when they send out mails. If you just hit 
"reply" on a mail from such lists, you reply only to the author, not the list.

For these scenarios, e.g. KMail or Thunderbird have a specific "Reply to 
Mailing-List" option, which only sends to the mailing list from which you 
received the mail (in addition to receiving it personally).

This is surely not a must-have, but I've been using it quite a few times.

> |User Experience
> 
> I want to add some kind of soft feature. Mobile devices are used more to
> pleasure than desktop computers. Therefore joy of use becomes relevant.

Yes, no objection to that.

> |(?) Design fancy dialogs Thomas: If by that you mean "Make the UI look
> different to the rest of the system" then I'm against it
> Nope, unless the rest of the UI will be designed as ugly as possible :-). It
> should have a nice appearence. (But UI has to be as well "normal" as stated
> once before)

Ah, okay. It's just that in me, "fancy" triggers the "A designer has done 
something which looks cool, but offers zero consistency with the rest of the 
system"alarm. There surely are cases where deviating from the platform 
standards makes sense (like games or some multimedia apps), but I don't think 
a mail client is one of them.
Maybe we should just replace "fancy" with "Aesthetically pleasing"?
 
> |User Actions
> 
> Common
> +Mark as spam (sadly common)

Depending on the spam filtering system of your email provider, this may indeed 
be a common feature. This should only appear if spam filtering has been 
activated, though. I would not use client-side filtering on my Web.de account, 
for example, because the provider takes care of that for me and if I marked a 
mail as spam locally, that information would not reach Web.de.
I'll add it.

> Uncommon/Rare
> +Format email text (html)
> +Show details, e.g. size of email(s)

Yes. I'll add those.

> +Userdefined tags, favorite, note, task etc. (or is it SLC?) btw: I don't
> know what SLC mean. Perhaps it should get written out somewhere if I'm not
> the only one.

Yes this should be done via SLC. SLC stands for "Share/Like/Connect" and is a 
system-wide system for resource-specific actions. See 
http://community.kde.org/Plasma/Active/Development/ActiveHIG/SLC for details.

Thanks again,
Thomas