GSoC update from Riccardo

[Matěj Laitl]

On 21. 8. 2012 Riccardo Iaconelli wrote:
> 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 totally agree and I appreciate your work.

> 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.

Okay...

> 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.

I think you over-estimate importance of the master branch here. Building the 
qml branch is only one command harder than building the master, plus I think 
most of us (Amarok devs) aren't really usability experts... (thus we may even 
misguide you on what good UI is)

Plus I think that merging too early could be even harmful - the constructive 
criticism could be suppressed by negative emotions such as "OMG YOU REMOVED 
90% FEATURES DONT MAKE AMAROK ANOTHER GNOME PLZ." :-D

> 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?

Hey, this is actually a good (and constructive) proposal! From my PoV I would:
 * Move Labels to Level 0 (I use the applet often, plus people are more & more 
getting used to using tags for example in Dolphin IMO) - but feel free to 
introduce different creative way to show them, perhaps in "current track"?
 * Move Tabs to Level 1 (guitar fans would hate us if we dropped it for 2.7)
 * Move Videos and Visualization to Level 2 - these don't work reliably even 
now.

Then I think a good compromise could be to merge qml branch into master as 
soon as Level 0 is reasonably completed and with confidence that completing 
Level 1 wouldn't block the release for unacceptably long.

There are some other considerations for merging:
 a) code quality: I've seen commented-out code in qml branch - we try to avoid 
this in master
 b) The changes create a lot of dead code. We should try (yep, not just you) 
to remove all the code made dead by CV QMLification. Do you see how current 
info applet adapts to currently selected media sources view? There's a lot of 
code associated spread across code-base and it seems that it's going to be 
dead. (or do you plan to preserve some form of this functionality? Sometimes 
it gives nice info, but it seems hard to present it in a sensible (UI-wise) 
way)

Cheers,
			Matěj