Google Summer of Code: Amarok CD Stack Collection View

Mon Mar 24 00:45:18 UTC 2008

Hi,

I've spent some time thinking about the project to digest the feedback
and did some mock ups to get a rough idea how the result could look
like. It would be nice to know what you guys think about the proposal,
what you might want to add and what might be of lesser
importance. Maybe this proposal is a bit lengthy, but if you like it
then I'll cut it down a bit before submission.

The Problem
-----------

Amarok's browsing facilities don't support the user well enough when
exploring his music collection.

While Amarok is one of the leading -- if not /the/ leading -- free
software music players, and its collection view and file view are
tremendously useful, they still leave some features to be desired. The
collection view supports the user when he's looking for certain songs
by searching (mainly) the tags for a given query string. This works
well if the user already has a clear vision of what he's looking for
and if he can clearly phrase it (otherwise the collection view can be
quite overwhelming because of the sheer mass of unfiltered
entries). It doesn't work well if the user just want's to browse his
collection, as he cannot manually group certain artists or
albums. 

Using the file view the user can explore the folder structure of his
music collection. This can be useful in the "aimless browsing" use
case, when the user doesn't have a certain artist or track in mind. He
can limit the displayed files by entering a search string, but this is
only applied to the file names. However, this will only work well for
users with a very tidy folder structure, it doesn't allow searching in
the meta data or subdirectories and fails just like the tree view at the
combined "browse and search" use case.

My Vision
---------

Allow the user to browse his collection as intuitively with Amarok as
he would with real CDs while at the same time augmenting him with
instant searching and context information. (And some eye candy, of
course -- who doesn't like sweets?)

Basically my work would boil down to a different implementation of the
current collection widget: I'd add a folder selection facility and a
different collection view. I've created some mock ups to give you a
rough overview of how this could look like. They are all prototypic,
rough and ugly, so don't think those looks are final ;-)

A basic collection view, no CD is selected:
  http://gentryx.de/~gentryx/slimview_collapsed.png
Upon selection, the CD rotates to show its cover...
  http://gentryx.de/~gentryx/slimview_expanding.png
...tracks and some additional information:
http://gentryx.de/~gentryx/slimview_expanded.png

As an alternative, albums could be directly represented by small cover
icons: (easy implementation thanks to model/view)
  http://gentryx.de/~gentryx/slimview_alternative.png
A drop menu provides access to frequently used folders:
  http://gentryx.de/~gentryx/slimview_pathselector.png

The folder selection would allow the user to make a rough preselection
of what he's looking for, without losing the options of the former
collection view. In the mocks you'll see a view that loosely resembles
photoshop's layer view. I think this is a pretty efficient solution,
but I'd also like to test how this fares with a tree view based
solution (cheap implementation thanks to model/view). The folder
selection could yield some nice synergy with Ryan Zeigler's "Media
Devices as Collection Providers" proposal as it would allow the user
to limit his view to one specific collection.

I did drop the initial idea of a full 3d OpenGL based view because of
three reasons: 
a) Problematic text rendering: could be done via
textures on the (3d) CD boxes (-> poor rendering quality) or via 2d
painting on top of the OpenGL boxes (-> different coordinate systems
cause trouble and fiddling with them creates messy code with poor
maintainability). 
b) It didn't feel as intuitive to use.
c) My prototype did look ugly as all hell ;-)
  http://gentryx.de/~gentryx/gsoc.7.png

Schedule:
---------

I've split the project up into the following packages (start/end dates
and lengths in weeks, some packaged are schedules concurrently over
several weeks as they go hand in hand).

Start/End Length What?
--------- ------ ---------------------------------------------------------------
    0 - 1   1.0  getting to know the code, exploring implementation alternatives
    1 - 4   1.5  folder selection UI
    1 - 3   1.0  very simple initial widget which displays CDs and upon 
                 selection their content (e.g. using QListView or
                 QTreeView), with selection and drag & drop
    3 - 6   1.5  animate CD rotation and track listing (includes testing of
                 different designs to max out usability and eye candy)
    6 - 8   1.0  implement clickable tabs and make levels configurable
                 (e.g. standard artist/album or just album or
                 year/artist/album/younameit) 
    6 - 8   1.0  implement alternative tree view using by reusing available
                 widgets and rendering infrastructure
    8 - 9   1.0  make persistent and options configurable via menu
    9 - 12  3.0  buffer time (polishing, more tests etc.)

This adds up to 11 weeks, one week less than expected because I'll
give a talk at a conference in June (ICCS 2008, anyone there? ^^)

Mid term deliverables would be (as seen in the schedule) a new,
animated collection view with a folder selection ability -- not
necessarily polished, as the buffer time is scheduled for the end of
the term. It would still miss tabs to collapse hierarchies and a
config dialog.

In the summer I'll begin writing down my PhD thesis. This means that
I'll be done with coding and according to my experience from my
diploma thesis, writing fares well with coding for a different
project. It's a good relieve from writer's block. I estimate to put 35
to 40 working hours per week into the project. 

Same as in the last mail:   
> About Me
> --------
> 
> I'm a computer science PhD student and as such I take pride in saying
> that coding is not just my profession, but also my passion (-8 My
> field of work is Cluster & Grid Computing (parallel programming, many,
> many big machines). I'm most proficient in C++, Ruby and Java, but I
> can also write some obscure languages (Object Pascal, x86 assembly,
> Modula 3 ...shudder) if need be. During my studies I specialized in
> software engineering and I have plenty of experience with design
> patterns in general and also Model/View/(Controller) specifically.
> For some of our applications I've created QT based GUIs (both forms
> and widgets), based on Model/View. I enjoy learning new stuff and I
> guess it's fair to say that I'm a quick learner.
> 
> What I'd like to Learn About
> ----------------------------
> 
> - deepen my knowledge of QT (QT4) and the KDE way (code structure,
>   build system etc.)
> - modern graphics programming (most of my knowledge of this is based
>   on my experiences in the early 90s demo scene -- fire and plasma
>   effects, shade bobs etc. :-) )
> - user interface programming (e.g. drag & drop)

I'd be grateful for any feedback and hints.

Happy easter!
-Andreas

-- 
============================================
Andreas Schäfer
Cluster and Metacomputing Working Group
Friedrich-Schiller-Universität Jena, Germany
PGP/GPG key via keyserver
I'm a bright... http://www.the-brights.net
============================================

(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your 
signature to help him gain world domination!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20080324/1ed4d62b/attachment.sig>