Google Summer of Code: Amarok CD Stack Collection View

[Ian Monroe]

On Sun, Mar 23, 2008 at 7:45 PM, Andreas Schäfer <gentryx at gmx.de> wrote:
> 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

Well I'm disappointed that you don't plan on using OpenGL. The
prototype is pretty ugly, but it's also a prototype. I don't know much
about OpenGL though, so perhaps having so much text in opengl isn't
feasible. Decent looking text seems like a pretty basic feature
though...

I don't like the file filter idea. The date filter we have now makes
more sense. If I want to browse by directory, I use the file browser.

Ian