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

[Björn Balazs]

Am Donnerstag, 16. Mai 2013, 16:56:10 schrieb 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.

I think I need a mock to understand this :)
 
> > 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).

Agree

> > 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.

Again, this depends on the use cases in mind. I would have suggested to put 
the virtual folders below, but that does not make much of a difference.

> >>> 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.

This is how we solved it in the current solution. So picking up the idea of 
favorite folders the users can somehow bookmark sound fine.

> > 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.

It depends. If this pad-type-of-devices actually keeps gaining market shares, 
people will expect to be able to do everything on them (as they might not even 
have a stationary computer anymore). So optimizing for those users would to my 
mind include also the more complex use cases. Debatable. Best argument on your 
side is probably "what can be done during GSOC"... But I think we should keep 
the extention in mind and provide an interface that will be extendable in 
later GSOCs...

> 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...

You got the point anyhow  ;)

> > 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.

I would always say: Let's think those things through, we can cut it down for 
GSOC anytime. And I absolutely agree: better to have something than nothing, 
because things are getting too big ;)

> >> 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, 

I would not see any reason for that

> it looks to me like two specialists giving
> feedback are better than one ;)

+1

Cheers,
Björn

-- 
Dipl.-Psych. Björn Balazs
Business Management & Research
T +49 30 6098548-21 | M +49 179 4541949

User Prompt GmbH | Psychologic IT Expertise 
Grünberger Str. 49, 10245 Berlin | www.user-prompt.com 
HRB 142277 | AG Berlin Charlottenburg | Geschäftsführer Björn Balazs