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

[Thomas Pfeiffer]

On 16.05.2013 11:47, Björn Balazs wrote:
> Hi Thomas, Michael, all,

> Ok, then I might have been on the wrong track, but as far as I understand the
> pattern you were referring to, multiple columns are the basic idea of it?!?

Multiple columns for the general UI, but not for navigating a folder 
hierarchy, specifically.

> Actually "New" has gotten me on the wrong track.

Yes, maybe that has to be renamed to "unread" (especially since I'm not 
sure if KMail distinguishes between "new" and "unread" like Thunderbird 
does anyway).

> I agree 100% that drag&drop
> is great (not only) for touch devices and would not question that. What I fear
> are inconsistencies in respect of the result after dragging (and hence
> problems with building up the mental model by the user):

> Mails are usually single instance items, so when dragging them to a different
> folder they get moved there. Copying mails is really a rare use-case and
> should be possible, but could be done somehow different. Now when the user is
> in a folder (by the way: How is the currently active folder visualized? -
> missing the mocks) and he drags a mial e.g. to Trash, that mail is moved
> there. If on the other hand she moves it to important only the state and not
> the place of the mail is changed. This could be confusing and is inconsistent.
>
> To suggest a solution: We could somehow visually seperate real and virtual
> folders - that would solve this inconsistency.

Yes. The two virtual folders should be placed before the others and 
either be visually separated from the rest or should look slightly 
different.

>>> 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.
>
> Well, I do have to disagree here a bit. People use mail quite differently.
> There are people that make excessive use of pre-sorting of mail, either using
> Sieve or clients rules. This has nothing to do with a business environment.

Absolutely. Actually, I'm one of those people. However, on a mobile 
device, I would be satisfied with seeing all unread mails in one place, 
have quick access to my most frequently used folders and have a 
not-so-quick way to access the other mails in the rare cases I need to 
have a look at them later.

> Other people just leave everything in the inbox and work with read / unread
> status only and others again use flags like important / unimportant to manage
> their mails.

Yes.

> I think a solution should allow all these ways of working with mails (and also
> those I forgot). But you are right, we need to agree on the use-cases we want
> to cover and if the team decides to leave those other use-cases out, well I
> would not be happy, but I will not do the work, so it would be ok...

> Another aspect is not only reading the mails, but also cleaning up. For this
> the user e.g. has to be able to move the mail to the target destination. Also:
> even if we do not want to have full enterprise (or desktop) complexity - as I
> do not see the

I agree that there has to be some way to access every email that is on 
the server. However, I think that usecases like quickly dealing with 
incoming mails on the go are more frequent on mobile devices than big 
managing tasks and thus we should _optimize_ for those.
Btw: Some part of your text seems to have been eaten at some point, i 
received only the first half of the last sentence of the paragraph above...

> Again, I do not yet understand how this will be achieved with the current
> approach, do we really want to reduce it that much? I do not see any
> contextual options. Example: I go on holiday, but forgot to activate my
> automatic reply. Something which could be handy to be able to do directly on
> the phone. Do want to cover anything like that? Or to be able to start and
> configure spell-checking? - Just go through the contextual features of KMail -
> there are many stupid ones, some I would even like to remove from KMail
> desktop - but cutting them all down on the mobile interface?

Oh, I sincerely hope that these mockups are not supposed to already 
contain all the features KMail Active will have in the end. Maybe that's 
all that can be implemented in a GSoC, but there will definitely more 
features at some point than shown here. There can still be buttons on 
the toolbar for these, though.

>> 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.
>
> This could be an approach to solve some of the above mentioned problems. I am
> curious for the next mocks...

Yes, me too ;) Let's see what ideas Mike will come up with in this area :)

> Do not get me wrong. I am perhaps too fully aware of the complexity of the
> topic, so it is good that you start of with something extremely simple and
> question everything. I just fear that just as the current solution is hitting
> way beyond the target, we might end up with something too simple.

Yes, sure. I hope that we'll end up somewhere between 
"super-minimalistic" and "all that KMail Desktop does" ;)

> Anyway - keep up to good work!

Thanks for your feedback! Unless the two of us get into serious 
disagreements in the future, it looks to me like two specialists giving 
feedback are better than one ;)

> Cheers,
> Björn

Cheers,
Thomas