[Kde-pim] Kontact Touch Mail - Initial Mockup + Git Workflow

[Thomas Pfeiffer]

On Wednesday 15 May 2013 20:35:41 Björn Balazs wrote:

> I would like question whether using the column-based-navigation is actually
> a good decision. Remember that a lot of people have deep hierarchies of
> mail folders. As navigating actually is not the main focus when using mail,
> the navigation area might get too much weight in comparison to the actual
> list of mails within a selected folder, when the pattern is used (at least
> as far as I understand it, you can end up with e.g. 4 columns visible).

I agree that deep folder hierarchies should not lead to having to go through 
multiple columns to get to your mail list, but that doesn't necessarily mean 
we have to abandon the whole approach, especially since tree views are not 
very touch-friendly either.
Suggestions for this follow at the end of this email (because I have to make 
something clear in a reply to your summary beforehand).

> In the same category of problem falls the fact that dragging mails to trash
> will only work as long as the trash folder is visible (which cannot be
> assured using the column-based-navigation). Again, having trash as a
> drop-target while the other elements are for navigation only seems to be
> inconsistent and difficult to understand for the user.

The trash folder would always be visible if we don't navigate through a folder 
hierarchy using the columns (and I agree with you that we shouldn't).

Let's see dropping to which folder would not be possible:
- Inbox: Works
- New: Works (would mark a message as unread)
- Important: Works (would mark as important)
- Outbox: Works (at least Desktop KMail allows that)
- Sent-mail: Works
- Trash: Works
- Template: Should work
- Drafts: Should work

All of these items except for New and Important are just normal folders, and 
so it should be possible to drag emails to them just like in Desktop Kmail. 
The two folders which are "virtual" - New and Important, are both cases where 
dragging mails into them to change their status makes perfect sense to me. So 
where do you perceive an inconsistency?
Files has shown that drag & drop is a much more intuitive interaction on a 
touch device than selecting and pressing a button on a toolbar.

> Summing it up - as far as I understand the mockup, it oversimplifies a bit
> too much. The matter is complex. Unfortunately.

What I take from this is that we first need to define the usecase of KMail Touch 
/ Active / Whateveritwillbecalled:
Kontact Touch had the goal to be full-featured Kontact, just with a touch-
optimized GUI. I know where that goal came from, but I don't think it was an 
ideal goal, and thus I don't think it should be the goal for our new approach.
I do not believe it's possible to create a GUI that allows you to manage every 
aspect of enterprise-grade PIM comfortably on a mobile device, no matter how 
smart the interaction designers are.
And I think that's why the current Kontact Touch - despite having been 
designed by smart people such as yourself - doesn't live up to its potential.

This is an opinion which Mike obviously shares, and form previous discussions 
it seems to me that many others from the Plasma Active team share as well.

What I see as typical usecases for mobile mail is reading up on important 
mails and replying to them, or writing new mails from scratch of course. Mike 
seems to have thought something similar, as he oriented his approach towards 
Lionmail, which is optimized for a pretty similar usecase (reading up on new 
emails and deciding what to do with them quickly).

So I don't think the current approach is oversimplifying things, but instead 
is focusing on the usecases that are likely to be done on a mobile device, and 
that's why I like it.
Surely it has to be possible to access all emails on your huge IMAP account 
with dozens of deeply nested folders from your mobile device as well, but this 
is probably a rather rare usecase which does not have to be offered prominently 
in the main UI.

About the navigation through the folder hierarchy: I don't assume this is a 
common usecase for a mobile device. What I'd envision is users selecting a few 
favorite folders which are than shown in the list. 
Maybe add an entry "Select folder" to the list for selecting a folder anywhere 
in the hierarchy which then stays there until another one is selected for the 
case where a user has to deal with old mails somehwere deep in the hierarchy.
New mails are all shown in "new" anyways, no matter where there are in the 
hierarchy.

Cheers,
Thomas