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
