On 28.04.2013 14:36, Michael Bohlender wrote:
Thanks for your feedback and your insights.

Sorry for not having replied yet. I'm at a conference with long days and bad internet connection, so I have not found the time to read your updated version
and write proper reply yet.
Since Friday is the deadline, I'll use the last bit of power in my laptop's battery (no power in the Lobby and the WiFi doesn't reach my room) to write a reply now ;)

One thing that should be added to your proposal is deployment: Thomas wont 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).

added to Implementation details.

Thanks, that should work :)

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.

Sounds very reasonable to me.
I divided the work into 5 tasks:
# general layout
# mail list
# display mail
# compose mail
# folder (or whatever way we come up to browse the mail)

We could do 4 of them working 3 weeks on each task with a qml
mockup/prototype followed by the actual implementation.
I can use the idle time (waiting for your feedback) during each
mockup phase to do small tasks like porting a button or things like
that.

Sounds good to me! We just need to make sure that every task is self-contained and could be released together with the rest of the old GUI in case you can't finish all tasks.

I am a little worried that the whole project is too much work for me
in the given time. Like stated before "asking for a full rewrite of a
mail application UI within a single GSOC is asking for a bit much". If
I don't progress as expected we could skip one of the above tasks and
instead focus on polishing the remaining three.

See above: If it doesn't leave us with something unreleasable, this approach should leave us enough flexibility.

Going completely crazy: The whole project looks a lot more achievable
if I pick Tasks or Notes instead of Mail...
But I guess we can't come up with a UX that will work across Kontact
Touch as some problems will only show with complex applications like
Mail ?

Hm, sounds reasonable form the size perspective, but mail is really much more important for us than notes or tasks, so I'd prefer having a partly improved Mail than a fully improved Notes or Tasks. Sebas, Aaron, what do you think? Would it make more sense to do Tasks or Notes instead of Mail?

reworked proposal:
https://docs.google.com/document/d/1qxWHUg-STYimYuqxMyPaD2gHiCDoI_m_YNa5mZkpU1Y/edit?usp=sharing
[1]

It's okay from my perspective, and obviously from Kevin's as well. :) Unless PA developers have any objections, I think it can stay that way.

I think we need to start earlier with the mockups for the general
design as we wont have that much time during the GSoC period as I
hoped. I
will try to come up with some Pencil mockups next weeks so that we
have a head start.

Maybe you could also start with some of the preparation tasks ahead of time, so we can start the mockup phase when GSoC officially starts.

Cheers,
Thomas
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active

Reply via email to