[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Kontact Touch GSOC Project
From:       Thomas Pfeiffer <colomar () autistici ! org>
Date:       2013-04-26 19:16:03
Message-ID: 12315911.9T9knyAjHH () linux ! fritz ! box
[Download RAW message or body]

On Friday 26 April 2013 12:34:35 Sebastian K=FCgler 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 achie=
ves
> > 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 inv=
est
> > 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 produc=
e 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 codeba=
se
> > 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 o=
f =

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 dan=
ger =

that the code in the prototype just sits there, unused, because nobody find=
s =

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 rando=
m,
> for me, design takes much *actual* sitting down than coding, but needs mo=
re
> "letting ideas simmer and become clear". For both parts, pick the ones
> first that are relatively independent from each other, then get the worki=
ng
> 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 make=
s =

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 b=
e =

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 wa=
nt
> 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 w=
ith =

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 par=
t =

of the UI with dummy data engines, implement it for real when it's good, th=
en =

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 a=
void =

ending up with a prototype which never gets implemented just as much as seb=
as =

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 create=
d.

I think we'll have to strike a good balance between getting actually workin=
g =

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 a=
s =

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 lea=
st =

have _something_ working in the end, come what may.
Maybe you can chop your work into different UI parts which each get a desig=
n =

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 fi=
les, =

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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]