GSoC update from Riccardo - his KMail is b0rked again

Riccardo Iaconelli riccardo at kde.org
Tue Aug 21 13:32:56 UTC 2012


Hi,

On Monday 20 August 2012 14:53:47 Matěj Laitl wrote:
> Such code should live in a branch until it has general feature parity (in
> this  case: functionality of all meaningful applets that work reliably
> currently should be provided by the new CV: wikipedia, labels, lyrics,
> similar artists, tabs, events, photos...), as for example my iPod
> Collection rewrite did.

in theory I'd agree with you, but it's not very easy to use this apporach in 
my case.

The very first objective of my rewrite was to have something clean and usable, 
with elements well thought and defined before the coding part actually 
started, instead of mixing them up in post-production.

Now, this approach requires time, and it's a very hard iterative process 
(since it must be done for almost every UI change introduced), but is IMHO 
something crucial in order to create a great user experience.

I obviously agree that we should try to provide as much functionality as we 
can, but just throwing it in the UI would only ruin all the good work done on 
the rest of Amarok.

Note that we also can't bump it in now (which would be easy) and fix it later, 
this way it's much harder to identify the problems and come up with a creative 
solution.

Additionally, there is not only design involved: I need quite some feedback 
and day-to-day testing when designing the UI, so I'd rather see it merged 
sooner rather than later. On the other hand, I recognize the problems that you 
rise, and the fact that we really don't want to release a dumbed-down version 
of Amarok.

So how to fix this? What we could do is to create a series of levels of 
functionality such as these:

Level 0 (must-have items):
 - Lyrics
 - Wikipedia
 - Current song info
 - Similar artists
 - ...?

This set of items must be implemented before any merge is done.

Level 1 (must-release items):
 - Photos
 - Videos
 - Visualization
 - ...?

These items are blockers for a release, but it's not a big deal if they get in 
during the development.

Level 2 (maybe items):
 - Tabs
 - Labels
 - Events
 - ...?

This set would contain the applets which don't really work well and are 
definitely marginal, which get in the main UI only if a good interaction 
paradigm is found. Nice to have, but nobody will cry if they're missing.

What do you think?

Feel free to ask me if I've been unclear on some parts, re-reading this mail I 
figure out it's not as clear as I'd like it to be. :)

Bye,
-Riccardo



More information about the Amarok-devel mailing list