Re: [Rhythmbox-devel] GUI mockup... let's get this sorted once and for all

[William Jon McCann <mccann jhu edu>]

Hi Jakub,

Jakub Steiner wrote:
> On Wed, 2006-03-22 at 22:48 +0000, Bastien Nocera wrote:
>
> > On Wed, 2006-03-22 at 17:39 -0500, William Jon McCann wrote:
> >
> > > Bastien Nocera wrote:
> >
> > <snip>
> >
> > > I'm not sure this is right.  Check out the example here:
> > > http://www.makezine.com/blog/archive/2005/07/how_to_make_enh.html
> > >
> > > I don't think a tiny thumbnail next to the song title is going to cut it.
> > >
> > > I should say that I used to think the same way you do until two weeks 
> > > ago when I saw Apple demo iTunesU here at JHU.  The level of integration 
> > > between audio, video, etc. is amazing - we have some catching up to do. 
> > >  I'm not sure just handing off to totem is going to work.
> >
> > I didn't know you could do all that in a Podcast. But at the same time,
> > it's not anything that Totem wouldn't be able to handle with better SMIL
> > (or simili-SMIL) support. In this particular case it's just MPEG-4 audio
> > bookmarks and images being displayed.
> >
> > Would it be that hard to offload?
>
> Howdy musiclovers.
> I think the only reason to have podcasts in a music jukebox app is
> because of the synchronisation to the portable devices. I personally
> prefer having a set of limited scope applications that cooperate well. 

I don't agree that the only reason to have podcasts in something like 
iTunes is for sync'ing.  Why do you think that?

As for design philosophy: applications, services, or objects it doesn't 
really matter which as long as they are well integrated, the maintenance 
overhead is kept low, and performance is adequate.

> I prefer my file manager to help me manage files, not browse the web. I
> would totally prefer a separate podcast client (penguintv is quite
> cool). And that should actually only deal with finding, subscribing and
> managin the sources, for playback a generic media player such as totem
> sounds ideal. I would prefer a device synchronisation application that
> wouldn't do anything but sync data onto a device. Podcasts, music,
> calendars, e-mail... I don't need my email client to care about that, I
> don't need my music jukebox to care about that either. It's the data
> that matters. Things get to end up a lot easier to understand in terms
> of interface. Cramming podcasting into a jukebox app is a little nasty.

So I don't think I agree with your characterization that podcasts are 
somehow orthogonal to listening to other kinds of audio.  I think your 
argument would be much more relevant to say splitting up the evolution 
components.

I also completely disagree with your assertion that using three separate 
programs to be able to listen to a single podcast is a better 
experience.  Being able to focus the interface is not really relevant 
when the interface and action is essentially the same - listening.


Let's look at this another way.  I think it is perfectly clear that 
adding cd burning and cd ripping to rhythmbox were the right things to 
do.  If we used your logic this would never have happened.  The 
application boundary is artificial.


Jon