Re: Proposed Modules, My Take
- From: Havoc Pennington <hp redhat com>
- To: Jürg Billeter <j bitron ch>
- Cc: Jeff Waugh <jdub perkypants org>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>, Murray Cumming <murrayc murrayc com>
- Subject: Re: Proposed Modules, My Take
- Date: Sun, 16 Jan 2005 18:21:11 -0500
On Sun, 2005-01-16 at 23:48 +0100, J�lleter wrote:
>
> Can't we look at the program as "the window representing my audio cd"? I
> can open and copy files within the same nautilus folder window even
> though I often do only one of those tasks at a given time.
Well, sure, we can come up with some abstraction where listening and
ripping have stuff in common, but I think tasks/use-cases/scenarios are
more relevant for deciding how to organize the UI.
> Besides that I can imagine that people, who do not rip all tracks at
> once, may want to listen to some tracks before deciding which ones to
> rip.
But having a "listen to this track" feature in the ripper is different
from "the ripper and the player are the same window"
Don't get me wrong, maybe the ripper and player share 99% of the code,
it just seems to me they would be two somewhat different windows
launched from different menu items.
Where I'm coming from is that I think the usual basic CD player UI is
pretty nice, or maybe something like the Rhythmbox "small display" mode
applied to CDs; and I think sound-juicer UI is really nice, it does
*exactly* what I want. The mockups I've seen of these two merged look
like the merger is worse for each specific task.
I can imagine that having a little "play this track" icon by each track
in sound-juicer, that launched the CD player aimed at that track, would
be handy. But that's just one more button by each track, not any kind of
major change to sound-juicer.
Similarly if the CD player had a single button "rip this CD" then that
would be convenient.
If you wanted to get fancy, then if you start the CD player while
ripping, it just plays what you are currently ripping... but this could
be transparent and doesn't require any UI change.
So it seems to me that you get all the "merger" benefits by adding 1
button to each app, while keeping the nice task-focused dedicated UI for
each task.
If you merge the two, then rather than adding 1 button to each to make
it simple to switch tasks, you get a sort of frankenstein all-in-one
app. I don't think having an integrated/single backend implies we have
to merge the UI windows.
Similarly there's an obvious integration between ripper and rhythmbox
(rhythmbox should find what you just ripped), but this doesn't mean we
have to merge the sound-juicer window into the rhythmbox window.
And there's obvious CD player to rhythmbox integration (e.g. only one of
them plays at a time, if you start one the other stops).
In short definitely start thinking of CD player + music player + ripper
as an integrated suite and codebase, but you can still have multiple
windows and menu items if appropriate.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]