At Fri, 24 Aug 2007 00:59:56 +0800, Sham Chukoury wrote:
> Music players have been done to death over the past decade - most
> hardcore coders aren't really interested in this anymore.
I don't think it's true that "music players have been done to death
over the past decade". And I don't think that's the reason why
hardcore coders don't code music players. In fact I wonder if they
ever did, except perhaps to write omg-optimized decoders.
It's trivial to write a music player, now that decoders lib are
available. The difficulty lies in designing the abstraction (think:
playlists, tags, collections) and the interface for accessing it. It's
still an open challenge that I don't see properly addressed in any
existing player; but it's an HCI or HII ("human information
interaction") or usability challenge; not a coding, technical
challenge (or only after the abstraction has been formalized, e.g. s4
derives significantly from the information organization, and
collections).
I believe that we have the potential to experiment new ideas in that
direction, more so than players with "hardcoded abstraction". It would
be interesting to encourage people to focus on this challenge; I am
certainly interested by it, and while usability people aren't always
easy to come by, we should make sure our developer website emphasizes
how favourable an environment XMMS2 is for them. So that sounds like a
good point from you, to try to characterize the typical xmms2 dev and
the "needed" xmms2 dev. (note that of course, we still need genius
bearded hardcore coders)
> I think the challenge would be in structuring the information in
> such a way as to minimise duplication between the user facing side
> and the developer facing side
I don't think there is so much overlap. Clearly we're talking about
the same concepts, but in different terms, so the content will have to
be different. It will probably get clearer after we refine the other
part of this thread, namely what the user facing side should say.
But I think the user side should remain rather small and static, since
the general orientation and concepts do not change much. Only new
features can be added when they are introduced with every
release. It's still good to have some dynamic and changes to show the
project is now dead, but that would mainly be through news (project
news, new clients, new release), not changes in the content of
pages. In fact if we separate things clearly, it might be easier to
know what and when to post new exciting news. :-)
The developer side is clearly more dynamic, with SoC pages, updates
about the new cool stuff happening (genipc, s4, collections 1.1,
nycli, xform improvements). I still believe we can do a better job at
organizing those dynamic pages (e.g. using "Proposal" pages, and
"Concept Documentation" pages, etc), but there it's more okay if
people come and dump content less formally than on the user side.
So yes, I think the styling and editing features should reflect that
too.
--
Sébastien Cevey - http://inso.cc/
--
_______________________________________________
Xmms2-devel mailing list
[email protected]
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
