Summer of Code: Draft of Playdar Proposal

[Andy Coder]

On Thu, Mar 25, 2010 at 1:06 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>
> I do think however that in this specific case, the best playdar
> implementation will be a Collection and one that doesn't require
> custom UI's. In general good integration into the app will always be
> higher quality and nicer to use then something that feels hacked in.
>

   The trouble I run into in the service vs. collection discussion is
spelled out in the UI (and I think you mentioned it earlier);
Collections are 'local sources of content' and Services are 'internet
sources of content'.  Where Playdar actually fits here isn't obvious,
since a Playdar track can be either local, on the internet, or remote
on a smaller scale.  Still, if it can be implemented satisfactorily as
only a Collection, then I agree it makes sense to avoid the custom
UIs, would rather avoid them myself (in general), and appreciate that
what I think is a particularly fun design question has sparked this
much debate.

On Thu, Mar 25, 2010 at 9:40 AM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
>
> It is not an either/or decision. One could write a custom GUI for the
> service, and add a simple "Show in collection browser" to enable the
> collection there. One can do the same today manually by overriding the
> CollectionStatus in amarokrc.
>

   This point inspired an analogy that I think does a decent job of
illustrating the merits of a more involved implementation:

   When school's in session, I work at the Dept. of Music library.
All of our recordings are kept behind the circulation desk, and
patrons can check them out only for use in the listening room.  Since
patrons can't just walk through our selection, they search the online
catalog, where they have the option to search only OWU, CONSORT (OWU +
4 other schools), or OhioLink (CONSORT + most other
colleges/universities in Ohio).  If we have the recording, they walk
up to the counter and ask for [LP/CD/DVD]#XYZ, and if it's in another
library, they request it and it shows up at the counter just like any
item we have, (it just takes a bit longer).

   In case it makes the analogy clearer at this point, the patron asks
for a recording (query), we get it by some method (resolver), and
deliver it to them in a consistent manner across all sources (result).

   Finally, patrons can ask for a reserve collection.  This collection
is still listed in every catalog it would be normally, and items in it
may belong to any number of libraries, (some user selected subset of
all available content).   However, each member of the collection is in
a single location so that the patron can see each item by
performer/album name and quickly find the same item again and again.
Any given patron, at any given moment, is only really interested in a
relatively small subset of the recordings that we can obtain, but need
to be able to find any recording through a query.

   When I thought about this, it occurred to me that I really don't
want to see every track available for download or full-length preview
on last.fm, as if it was a local collection, on a regular basis (maybe
just once, it would be cool...), but I would like such a view for
tracks on a local network, and probably a subset of last.fm (artists
connected to the independent dark electronic music group, for
example).  However, If I'm looking for something that may or may not
be a part of that collection, I want to be able to ask if it's
anywhere in the catalog, and probably have the option of keeping in
reserve.

   That is, on top of a common underlying structure, it makes sense to
me to have two separate views of the potentially vast catalog of music
that Playdar may be able to access.  There's the collection view,
which provides the standard method of browsing for a user selected
subset of the catalog, and a service view that allows the user to find
any specific thing in the entire catalog.  I think it might be
possible to do this entirely as a Collection, a fancy config UI, and a
context applet, but I also think this is likely to come off as less
well integrated than a setup with a Collection to hold on to and a
Service to help find things to [not] add to the Collection, (this also
happens to be how I might intuitively want to describe it regardless
of implementation).

 - Andy Coder