[Kde-pim] Kontact Touch GSOC Project

[Thomas Pfeiffer]

On Friday 26 April 2013 12:34:35 Sebastian Kügler wrote:
> Hi Michael,
> 
> On Thursday, April 25, 2013 19:59:18 Michael Bohlender wrote:
> > Considering your feedback I tried to find a project approach that achieves
> > two things: 1. Lots of experimentation on the UX side as Thomas (and I)
> > want to use this project to evaluate current Plasma Active UI/UX
> > possibilities. 2. A stable/fast application because I don't want to invest
> > a summer just to produce something that can/will not be used by anybody.
> > 
> > So my idea is to use the first half of my time to experiment and produce a
> > prototype that can serve as a bases for further UI/UX development for
> > Kontact Touch. And use the second half to work on Kontact Touchs codebase
> > doing cleanup and gradually port things of the prototype over.This way,
> > the
> > results of the second half could be gradually reviewed and merged like it
> > was suggested.
> > I think this is a good tradeoff. What do you think?
> 
> I don't think this will work very well. You'll just notice you'll run out of
> time towards the end, you might be able to get some useful stuff in, but
> you likely won't be able to finish this way. It's just another way of
> postponing the hard work.

I agree with both of you here: Interaction design should to be a big part of 
this project, but on the other hand if at the end of the project we have a 
nice prototype but zero changes to the actual Kmail Touch, there is the danger 
that the code in the prototype just sits there, unused, because nobody finds 
the time to get it into the actual application.
 
> Better: Do design mockups and "getting dirty in the code" simultaneously,
> SoC gives you 40 hours a week, split this up, do 10 hours of design and 30
> hours of coding / merging each week. (The 10 / 30 split is somewhat random,
> for me, design takes much *actual* sitting down than coding, but needs more
> "letting ideas simmer and become clear". For both parts, pick the ones
> first that are relatively independent from each other, then get the working
> areas closer together / move to bigger pieces. There are enough of the
> smaller "port the use of this item to PlasmaComponents"-style tasks.

I agree that getting to a know the internals of Kontact Touch early on makes 
sense because it allows you to get a feeling for the technical feasibility of 
ideas. We want to avoid having great ideas which turn out to just not be 
technically feasible in the end.
Maybe 10:30 isn't the ideal proportion for this project, but I guess you'll 
find your ideal proportion after week or two (though it may still need to be 
adjusted as the project progresses).

> This setup also prevents you from going overboard with design, but makes
> sure you're actually working on something achievable. Moreover, you'll want
> to see your design in action, and you want to iterate over it a few times.
> Pure waterfall sucks in that regard.

Well, iterations are of course key, but UI iterations are preferably done with 
mockups/prototypes and not with fully implemented applications, because the 
more "finished" an application is, the more work is needed to make changes to 
the UI.
There is a big space in between "pure waterfall" and "fully implement 
everything immediately". However, a "Iterate on the design of a certain part 
of the UI with dummy data engines, implement it for real when it's good, then 
move on to the next part" may work, especially since with QML we don't need to 
create throw-away prototype code.

> So, instead of doing en entirely new UI for Kontact Touch, which might be
> well beyond what's possible, try to concentrate on smaller pieces: Do a
> design session on the left-hand-side flap, investigate the mail list, etc,
> and then implement fixes for those. Your current proposal is I think too
> ambitious and bears the risk of never being finished.
> 
> In short: Don't redesign, but improve bit by bit, both in design and in
> code.

Hm, I see we have a conflict of interest here: On the one hand, I want to avoid 
ending up with a prototype which never gets implemented just as much as sebas 
does. On the other hand, I don't want a largely unaltered port from the 
current Kontact Touch QML to Plasma Components, either. Not using Plasma 
Components is not the only problem the current Kontact Touch has within PA. To 
really "Activate" Kontact Touch, many of its UI concepts have to be adapted to 
PA's UI patterns as well, and probably some new ones will have to be created.

I think we'll have to strike a good balance between getting actually working 
code and improving the UI. GSoC is generally more about coding than design, so 
I guess working code is a must-have, but for me, UX improvement is a must as 
well.

I do like sebas' idea of mixing the two main tasks you outlined instead of 
doing them strictly one after another. in order to make sure that we at least 
have _something_ working in the end, come what may.
Maybe you can chop your work into different UI parts which each get a design 
and an implementation cycle, instead of one big design cycle folowed by one 
big implementation cycle.

> One thing that should be added to your proposal is deployment: Thomas won't
> be able to even have a look at your work if you don't update packages on
> Mer OBS. That doesn't have to be a lot of work, but should definitely be
> part of your proposal.

It's briefly mentioned in "set up dev environment (obs)", but I agree that it 
makes sense to write somewhere that there will be regular package updates. As 
sebas said: I can't compile stuff for the tablet myself, so I need packages on 
OBS whenever I'm supposed to try something out (maybe I can swap out QML files, 
but everything which is compiled needs to come to me in compiled form).

Sorry that this your current draft won't be the final one yet, but I'm sure 
we'll have something we agree on soon :)

Cheers,
Thomas

_______________________________________________
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/