[Kde-pim] Kontact Touch GSOC Project - mentor needed

[Thomas Pfeiffer]

(re-sending including kde-pim so as not to break "reply to all". active@ 
subscribers: Sorry for the double-post).

On Thursday 11 April 2013 23:36:38 Michael Bohlender wrote:
> It is a bit thin on scope and implementation details.
> 
> > E.g. does this include folder specific settings UI, composer, attachment
> > handling, address book integration/recipient editor, filter/search UI,
> > etc.
> > 
> > Maybe list a couple of example workflows that should be possible with the
> > improved UI.
> 
> I updated my proposal with a concrete mockup and ugly but hopefully
> descriptive kolourpaint drawings.
> It is more like a rewrite than a little update so please give it a second
> look.

Erm... you might have misunderstood Kevin's comment. It didn't seem to me like 
he was asking for UI design details, but rather for a more detailed list of 
planned features. I agree that this is important in order to estimate whether 
your scope is realistic.

> This design proposal constrains me a little as I was hoping to be able to
> experiment with the ideas of a task driven approach that float around the
> Plasma Active project these days. But I can see how "I will do mockups and
> play around with UI ideas. This will be great. Trust me" is not a good
> project proposal.

I think leaving much flexibility for the design phase of the project actually 
was a good idea. What was lacking was more details on the planned feature set. 
I don't think you have to commit yourself to a concrete design before the 
project starts, though putting your design ideas into the proposal may still 
have been a good idea, even though I see them as not binding at all and 
subject to change during the design/mockup phase (and later as well).

> @Thomas
> I am really interested in your feedback on my "initial mockup" it is
> basically a brain dump of what I was imagining so far. Is this something we
> can work with? I have still some time to change it.

Without wanting to go into too much detail (since, as I stated above, I only 
see it as a preliminary idea subject to change anyway): I think the 
combination of column-based design and drawers is worth exploring for Kontact 
Touch. However, your mockup shows the limits of strictly adhering to this 
paradigm in this case: You end up with many steps until you arrive at a common 
task such as writing a new email, forcing users to make many choices in a 
rather mundane task. This does not necessarily mean that the general paradigm 
doesn't work in this case, it may just mean that not everything should be 
chosen each time (for example, the switch between flat or grouped might be done 
in a drawer on demand instead of as a separate step in the main UI.

Creating a new email (not a reply) is where the task-centric UI comes in: If a 
user wants to send an email to someone, she should not have to explicitly open 
Kmail first, but initiate the task directly from the (task) launcher. We don't 
have that task launcher yet, but it is likely to come in PA5, so it would be 
nice to integrate Kmail into it already.

Maybe you could reduce the complexity of the second wireframe and just show 
the steps for a typical workflow (like replying to a thread on a mailing list) 
instead of trying to show all the possibilities? 
You can then use the space you gain from that to elaborate more on the scope, 
in textual form: Which tasks do you plan to support with the version you'll 
have at the end of GSoC (e.g. "Writing a new email and signing it digitally" 
or "Finding a specific email by date")? I think this is what Kevin meant by 
"list a couple of example workflows" as well ;)
 
> "Would it then not be better to have someone from PA be the primary mentor
> for this?"
> 
> Thomas Pfeiffer is form PA but not a developer, so he can't be a Mentor I
> guess. The code I am intending to write will sure look a lot like what we
> have in plasma-mobile and declarative-plasmoids. I hang around in #active
> for some time now and feel comfortable working with the PA guys so I
> wouldn't mind getting mentored by one of them. But having someone with KDE
> PIM knowledge who makes you aware of possible performance problems and can
> help with questions regarding Akonadi is also really useful.
> 
> Any opinion from the PA developers on this?

I thought that code reviews would have to be done by the mentor, that's why I 
thought I couldn't be your main mentor. But since Sebas said that they don't 
necessarily have to be done by the mentor, it's okay for me to be the official 
mentor, with people from the PA team and PIM team (especially Kevin) doing 
code reviews and answering technical questions.
_______________________________________________
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/