Or why and how the new XMMS2 GUI client should be extensible (and what I mean by extensible anyway).
Quizz: What do Winamp, Foobar2000, Emacs, Eclipse and Firefox have in common?
(Vim users, we love you too, but shut up for now please.)
They are very popular and they highly promote extensibility.
Now, we all know that correlation != causation. What is certain, however, is that all those projects boast many fan(boy)s, some of whom even get quite religious about it.
This enthusiasm reflects itself in the emergence of strong communities: people who share content, tips, modules, extensions, themes, configurations, scripts, etc. And those people usually aren’t even core developers of the software, sometimes not developers at all; just users or hobbyists who like the project.
Paradoxically, most of what they share is aimed at personalizing the software, i.e. making it the user’s own, fitting the user’s wishes and needs. This creates a feeling of ownership and satisfaction, because the user can bend it the way she likes and master it like a pro.
In essence, the idea here is give power to people to shape the software the way they want, and they will extend it in creative ways and get together to share these extensions. And I think that encouraging this creative freedom is one of the many factors which contribute to popularity.
Obviously, each of the projects mentioned above have their own way of allowing user extensions.
- Classic Winamp 2.* had (lots of) theme and some plugins (mostly effects, visualization), but remained otherwise quite static in terms of interaction or features.
- foobar2000 goes much further with theming and interface customization, allowing varied usage and user experience.
- Eclipse focuses mainly on extension modules (to interact with the VCS, manage project workflow, etc) and a jungle of configuration options.
- Firefox boasts rich installable extensions which add powerful new features, two levels of configurability (standard Preferences and advanced about:config), and recently themes (Personas).
- emacs allows essentially everything through scripting: altering and extending looks, interaction, features, as long as you have a high enough Elisp-fu (or enough curiosity to install other people’s modes).
More to the point, extensions can be mapped along three mostly orthogonal axes:
- Themeable appearance (look)
- Configurable interaction (feel)
- Scriptable features (personal usage)
Let’s take each of them and see what it means for our beloved imaginary music player.
Themeable appearance
Not an easy one, especially when one wants to rely on advanced features and widgets from a toolkit, which doesn’t necessarily allow for heavy reskinning.
There are more and more ways to draw fancy stuff in a window (vectorial canvas, HTML view, etc) but those often come at the price of limited interactivity with the rest of the interface (drag and drop, event handling, interoperability with the MVC architecture).
Using Qt StyleSheets (possibly with the help of QtScript) to style native widgets might be a better option, though I haven’t yet investigated in depth how much can be achieved with them.
Anyone with a better clue is welcome to step up.
While the whole layout of the player could benefit from imaginative and beautiful theming, one of the oft talked about use of styling was for the rendering of the playlist (usually out of jealousy for gorgeous foobar2000 screenshots), with album grouping, sexy styling of information instead of boring columns, etc.
Viewing and browsing the medialib could definitely benefit from a rich, themeable design, which would ideally (and optionally?) smoothen navigation with animations (see a hastily put together demo I made with jQuery, a while ago).
Customizable interaction
Power-users get easily nervous about GUIs, as they fear that their personal preferences might not be respected:
Will there be a STOP button, or only PAUSE?
The best way to approach such religious questions is to set a default reasonable with regards to the rest of the default settings (i.e. coherent with the “default experience”), and let the user change it if she wants to.
Note that I put as much emphasis here on configurability as on picking a sensible default. In parallel, fine-grained options should be hidden away from the main configuration panel to keep it usable — a standard configuration pane similar to Mozilla’s
about:config
can do the trick.
Will it require me to reach for the mouse?
I believe that a complete GUI player should be usable either exclusively with the mouse, exclusively with the keyboard, or with a combination of both.
The keyboard access is often assimilated to keyboard shortcuts, and indeed advanced users often rely on shortcuts to work quickly with an interface. They should even be able to define their own shortcuts bound to arbitrary actions (jump to the playing song, enqueue the album for the track I’m viewing, etc).
However, another underused keyboard-based interface has been making a comeback into GUIs lately. You might have heard of it, it’s called the command-line.
Apart from the venerable emacs and vim, command-lines have been creeping more or less discretely into various Mozilla projects. Bespin, the web-based text editor has attempted at allowing users to run smart commands directly in the editor. And of course, the Firefox 3 Awesome Bar is just a step away from a command-line; a step taken by the TaskFox (see demo), which brings Ubiquity into the browser address bar.
I had experimented with the idea of a CLI-based GUI (sounds strange doesn’t it?) with my unfinished lindalë prototype, and I think it could bring a lot of interesting power to our new graphical player.
More on this idea in a future post.
Scriptable features
As usual, the level of scriptability is a trade-off decision, somewhere between the horror of Excel inline formulas (a sad ad-hoc hack most of the time) and the universal meta-ness of emacs (which allows the editor to rewrite itself when you’re not looking). The latter is naturally attractive to us geeks, but it’s probably excessive in terms of work required.
On the other hand, if we pursue our idea of using a high-level
language for the GUI (possibly QtScript, which is being worked on), it should be relatively easier to import self-contained extensions into the player.
In terms of design, it would be preferable to think of such “extensions” as features of the player, rather than external add-ons bolted onto it. The player itself would therefore be nothing more than a platform hosting extensions/features, and even the default interface would be implemented as extensions, indistinguishable from third-party ones.
This would for instance allow anyone to tweak the widget that displays search results, or replace it with something completely different. Even better, entirely new features could be imported, e.g. a rich interface exposing a bookmarking system (managing a generic bookmarking service client under the scene), or new widgets to explore one’s music library.
Possibilities are endless, and our time to work on them isn’t.
I have been discussing some of those ideas with greafine, our student working on this project for this year’s Summer of Code, and we’ll work together to determine what is feasible technically and temporally. In any case, I hope this post hints at various ways we shall explore to achieve high extensibility!
