Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic...
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff...
But probably I'm the wrong person to ask -- getting ACL support into Nautilus wasn't as easy as I thought either ;-). If it'd be doable, I'd try my luck though (if time permits).
Nils
On Sun, 2003-09-07 at 23:04, Nils Philippsen wrote:
Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic...
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff...
It is hard to get the ordering data from a audio-specific burn: view, and the view would be both hard to find, and quite a lot of work to write.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a world-famous moralistic jungle king with a passion for fast cars. She's a psychotic African-American queen of the dead with a song in her heart and a spring in her step. They fight crime!
Hi Alexander
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
I agree with you. The best way to burn Audio is from the Music player but...
It is hard to get the ordering data from a audio-specific burn: view, and the view would be both hard to find, and quite a lot of work to write.
but... in some occasions, it could be useful to have a simple and easy way to burn audio from Nautilus. We already have a dialog asking for the desired burning speed and the device. Why not add a simple list of tracks to this dialog with "up" and "down" buttons ? And if people really want need more stuff, they still can use Rhythmbox for example.
On Mon, 8 Sep 2003, Alexander Larsson wrote:
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
The major Windows cd burning applications burn audio CDs, and they do all the "this many minutes left", "preview track", etc. stuff.
I really would NOT expect to find that functionality in a music player. I'd expect it in a CD burning application. What I'm doing is burning a CD. The contents of that CD should be irrelevant.
later, chris
On Mon, 2003-09-08 at 10:47, Chris Ricker wrote:
On Mon, 8 Sep 2003, Alexander Larsson wrote:
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
The major Windows cd burning applications burn audio CDs, and they do all the "this many minutes left", "preview track", etc. stuff.
I really would NOT expect to find that functionality in a music player. I'd expect it in a CD burning application. What I'm doing is burning a CD. The contents of that CD should be irrelevant.
One thing to keep in mind is that "the major Windows cd burning applications" are competing with each other to have more features, even if the feature really doesn't belong there, it helps you look more impressive in the magazine review checklist.
We have a certain freedom to do things in the right place that someone writing a CD burning application for Windows doesn't have.
Regards, Owen
On Mon, 8 Sep 2003, Owen Taylor wrote:
One thing to keep in mind is that "the major Windows cd burning applications" are competing with each other to have more features, even if the feature really doesn't belong there, it helps you look more impressive in the magazine review checklist.
But of course that cuts both ways. One can just as easily say the same thing about music players as an explanation for why, say, iTunes can burn CDs but shouldn't....
We have a certain freedom to do things in the right place that someone writing a CD burning application for Windows doesn't have.
Sure, but why is a music player the right place to burn audio CDs? Why isn't a CD burning application the right place? To me, the data content is irrelevant, and it's very counter-intuitive to think that I would use an audio player to burn CDs. Otherwise, by the same logic I should use my email program to archive my emails to CD, and my IM client to archive my messages, and vi to archive my text files, and my....
later, chris
On Mon, 2003-09-08 at 12:44, Chris Ricker wrote:
On Mon, 8 Sep 2003, Owen Taylor wrote:
One thing to keep in mind is that "the major Windows cd burning applications" are competing with each other to have more features, even if the feature really doesn't belong there, it helps you look more impressive in the magazine review checklist.
But of course that cuts both ways. One can just as easily say the same thing about music players as an explanation for why, say, iTunes can burn CDs but shouldn't....
Windows Media Player also burns music CDs, and I've seen people use it for that. But sure, the only point here is that simply copying what exists isn't the way to get a firm answer to the question of what's best. ;-)
We have a certain freedom to do things in the right place that someone writing a CD burning application for Windows doesn't have.
Sure, but why is a music player the right place to burn audio CDs? Why isn't a CD burning application the right place? To me, the data content is irrelevant, and it's very counter-intuitive to think that I would use an audio player to burn CDs. Otherwise, by the same logic I should use my email program to archive my emails to CD, and my IM client to archive my messages, and vi to archive my text files, and my....
If you really want to answer this question in a methodical way, there is a whole discipline you can get a degree in. My favorite book I like to suggest is called "Designing From Both Sides of the Screen"
If you follow the well-thought-out process there for answering the questions "who will use this?" "what do they want to do?" "how should the UI facilitate that?" then you can come to some kind of serious answer to the question.
Otherwise we're all just speculating on a mailing list and not addressing tradeoffs or dealing with empirical data. We wouldn't try to write software without having a background in software design and following a methodology, and we shouldn't try to design UIs that way either.
Not that I'm above speculating on mailing lists ;-) fwiw I think it makes a ton of sense that if I have a playlist I should be able to say "put this playlist on a CD" - keep in mind that iTunes is primarily a playlist/music-library manager, not just a player in the xmms mold.
Havoc
Am Mon, 2003-09-08 um 20.59 schrieb Havoc Pennington:
Not that I'm above speculating on mailing lists ;-) fwiw I think it makes a ton of sense that if I have a playlist I should be able to say "put this playlist on a CD" - keep in mind that iTunes is primarily a playlist/music-library manager, not just a player in the xmms mold.
In my opinion this is the right way. Let me show you one nice example how this is done in the KDE World (or better in the world of software based upon KDE components).
There is a nice music-mixing application which is called yammi (http://yammi.sf.net). It is designed as an music manager with two players (uses xmms or noatun) and some really good playlist capabilities. It has menu entry which allows you to burn your playlist via k3b (look at my other mail in this thread for more information). This is the right way to integrate those functinalities. You have the possibility to burn your playlist, but the application itself does not have this functinality, it uses another (IMHO really good) application to do this. This is how interaction and integration should be.
André
On Mon, 2003-09-08 at 21:40, André Kelpe wrote:
Am Mon, 2003-09-08 um 20.59 schrieb Havoc Pennington:
Not that I'm above speculating on mailing lists ;-) fwiw I think it makes a ton of sense that if I have a playlist I should be able to say "put this playlist on a CD" - keep in mind that iTunes is primarily a playlist/music-library manager, not just a player in the xmms mold.
In my opinion this is the right way. Let me show you one nice example how this is done in the KDE World (or better in the world of software based upon KDE components).
There is a nice music-mixing application which is called yammi (http://yammi.sf.net). It is designed as an music manager with two players (uses xmms or noatun) and some really good playlist capabilities. It has menu entry which allows you to burn your playlist via k3b (look at my other mail in this thread for more information). This is the right way to integrate those functinalities. You have the possibility to burn your playlist, but the application itself does not have this functinality, it uses another (IMHO really good) application to do this. This is how interaction and integration should be.
Yes. You wrote exactly what I think (and wrote as well, but with more fluff).
Nils
On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote:
On Mon, 2003-09-08 at 12:44, Chris Ricker wrote:
On Mon, 8 Sep 2003, Owen Taylor wrote:
One thing to keep in mind is that "the major Windows cd burning applications" are competing with each other to have more features, even if the feature really doesn't belong there, it helps you look more impressive in the magazine review checklist.
But of course that cuts both ways. One can just as easily say the same thing about music players as an explanation for why, say, iTunes can burn CDs but shouldn't....
Windows Media Player also burns music CDs, and I've seen people use it for that. But sure, the only point here is that simply copying what exists isn't the way to get a firm answer to the question of what's best. ;-)
We have a certain freedom to do things in the right place that someone writing a CD burning application for Windows doesn't have.
Sure, but why is a music player the right place to burn audio CDs? Why isn't a CD burning application the right place? To me, the data content is irrelevant, and it's very counter-intuitive to think that I would use an audio player to burn CDs. Otherwise, by the same logic I should use my email program to archive my emails to CD, and my IM client to archive my messages, and vi to archive my text files, and my....
If you really want to answer this question in a methodical way, there is a whole discipline you can get a degree in. My favorite book I like to suggest is called "Designing From Both Sides of the Screen"
If you follow the well-thought-out process there for answering the questions "who will use this?" "what do they want to do?" "how should the UI facilitate that?" then you can come to some kind of serious answer to the question.
This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people.
Another thing I learned from my GUI lecture was that you don't need a thousand answers, the 10 or 20 we might get here by asking personally are just enough in our case.
Nils
On Tue, 09 Sep 2003 09:41:18 +0200, Nils Philippsen nphilipp@redhat.com wrote:
[...]
This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people.
Another thing I learned from my GUI lecture was that you don't need a thousand answers, the 10 or 20 we might get here by asking personally are just enough in our case.
[...]
But desktop concepts are always changing. Notice that both iTunes and Windows Media Players now are offering a "burn this stuff" directly from the same user interface which plays the media. Maybe *now* ordinary users did not expect these, but "updated users" of both Windows and Macs have this option now, so I would expect Linux users will expect this too.
regards
On Tue, 2003-09-09 at 08:53, Marco Ermini wrote:
On Tue, 09 Sep 2003 09:41:18 +0200, Nils Philippsen nphilipp@redhat.com wrote:
[...]
This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people.
Another thing I learned from my GUI lecture was that you don't need a thousand answers, the 10 or 20 we might get here by asking personally are just enough in our case.
[...]
But desktop concepts are always changing. Notice that both iTunes and Windows Media Players now are offering a "burn this stuff" directly from the same user interface which plays the media. Maybe *now* ordinary users did not expect these, but "updated users" of both Windows and Macs have this option now, so I would expect Linux users will expect this too.
Yes, and why wouldn't it be the case on GNOME too ? I mean, let's add audio burning to Nautilus, to Coaster (or whatever will be GNOME's _advanced_ CD burner app) and to Rhythmbox. It shouldn't be that hard to share the burning itself using a CD burning library, is it ?
regards
On Tue, 2003-09-09 at 09:41, Nils Philippsen wrote:
On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote:
On Mon, 2003-09-08 at 12:44, Chris Ricker wrote:
We have a certain freedom to do things in the right place that someone writing a CD burning application for Windows doesn't have.
Sure, but why is a music player the right place to burn audio CDs? Why isn't a CD burning application the right place? To me, the data content is irrelevant, and it's very counter-intuitive to think that I would use an audio player to burn CDs. Otherwise, by the same logic I should use my email program to archive my emails to CD, and my IM client to archive my messages, and vi to archive my text files, and my....
If you really want to answer this question in a methodical way, there is a whole discipline you can get a degree in. My favorite book I like to suggest is called "Designing From Both Sides of the Screen"
If you follow the well-thought-out process there for answering the questions "who will use this?" "what do they want to do?" "how should the UI facilitate that?" then you can come to some kind of serious answer to the question.
This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people.
If you ask a user "how would you burn an audio CD" you will probably get the answer "use the cd burning application", yes. In other words, not a file manager window (like Nautilus). Furthermore I think this question is very skewed. In practice if you even have any audio tracks on the computer to burn and you ever listened to them you would have used the media player and noticed the "burn to CD" button in it. So using that functionallity would be very natural.
Its like asking a user "how would you burn files to a cd". Many would probably answer "use a cd burning app". But I thought it would be far better if you just inserted a blank CD, copied the files like you normally copy files (using the *file* manager, Nautilus) and then press the burn button. Thats why I implemented nautilus-cd-burner, and this is the kind of integration I want in the desktop.
If your wife really wants to use an feature-packed do-everything cd burner app like the ones common on windows we're not stopping her, there are several and we ship some. However, the cd burning facilities in nautilus are meant to be an easy-to-use extension of the file manager facilities, not a featurefull application. Audio burning just doesn't match the file manager user model and standard interfaces that well. It does match the model of some media players though, so I think it makes more sense there.
Of course, none of the cd burning code is in nautilus, and it won't be in the media player either. The code will all be shared in a separate package (currently called nautilus-cd-burner, which mostly uses cdrecord to do its thing).
So, basically what I'm saying is: Nautilus is not a CD burning application, it is a file manager that lets you copy files to CDs. Technically it *could* be extended with all sorts of UI gadgets to allow it to burn audio cds, video dvds or do whatever you want, but I think that will make Nautilus a worse UI for file management since it complicates the user model, and in my opinion it wouldn't be the best way to burn audio cds or video dvds anyway.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a scarfaced small-town cop on the edge. She's a virginal cigar-chomping doctor with an evil twin sister. They fight crime!
On Tue, 2003-09-09 at 03:41, Nils Philippsen wrote:
On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote:
If you really want to answer this question in a methodical way, there is a whole discipline you can get a degree in. My favorite book I like to suggest is called "Designing From Both Sides of the Screen"
If you follow the well-thought-out process there for answering the questions "who will use this?" "what do they want to do?" "how should the UI facilitate that?" then you can come to some kind of serious answer to the question.
This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people.
Taking a poll isn't the whole answer though; it can't address tradeoffs, and you won't ever get new ideas or solutions that way. If someone has used a CD burning app then they'll expect a CD burning app and won't think of doing it a different way. But that doesn't mean the iTunes way wouldn't be welcome once they saw it. It certainly also depends on the user; e.g. your wife doesn't use music apps, but millions of people do.
So the design process is a way to try to work through these issues methodically.
Havoc
On Tue, 2003-09-09 at 15:07, Havoc Pennington wrote:
On Tue, 2003-09-09 at 03:41, Nils Philippsen wrote:
On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote:
If you really want to answer this question in a methodical way, there is a whole discipline you can get a degree in. My favorite book I like to suggest is called "Designing From Both Sides of the Screen"
If you follow the well-thought-out process there for answering the questions "who will use this?" "what do they want to do?" "how should the UI facilitate that?" then you can come to some kind of serious answer to the question.
This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people.
Taking a poll isn't the whole answer though; it can't address tradeoffs, and you won't ever get new ideas or solutions that way. If someone has used a CD burning app then they'll expect a CD burning app and won't think of doing it a different way. But that doesn't mean the iTunes way wouldn't be welcome once they saw it. It certainly also depends on the user; e.g. your wife doesn't use music apps, but millions of people do.
Heh, she mightn't use music apps, but she doesn't use CD burning apps either. Therefore I think it is legitimate to ask persons like her (completely unpolluted by previous experience in that area) about what they would think is intuitive.
So the design process is a way to try to work through these issues methodically.
I don't think we have the resources for "real" (formal) UI tests, e.g. coding all scenarios and let loose a huge number of ordinary people on them to see which scenario pleases most of them. Asking people what they think is the next best thing to it, as long as you ask the right people ("Programmers are not users. Vice presidents are not users." and all that).
Let me be more precise re what I meant: I guess we agree from a devel standpoint that we need one "piece of code" to handle the actual burning, this is to be largely independent of file managers or music apps.
There are three approaches for the interface I can distinguish:
a) Everything is done from within a special CD burning app b) File managers, music apps and the like offer interfaces to burn files, music, etc. c) a hybrid of a) and b) where both frontend apps (file manager, music app) and backend app (CD burning program) have their share in the process
Of course I'm a fan of c), partly because it resembles the metaphor of two specialists doing what they're best at (i.e. managing music <-> burning CDs) to produce a result together. Partly because more complicated stuff would be hairy otherwise, for example with mixed mode CDs.
You need code knowing about all the coloured books stuff (e.g. to produce mixed mode CDs) and you need code that knows about music files to display their properties/length and of course code that is aware that a music file can be burned as a "literal" ogg/vorbis file or as a CD audio track and asking the user what shall be done with it. I know where to put the first (CD burning app/lib/component) and the second one (end user app), but I'm not quite sure where I'd want to put this "glue code".
Any ideas?
Nils
On Tue, 2003-09-09 at 16:31, Nils Philippsen wrote:
On Tue, 2003-09-09 at 15:07, Havoc Pennington wrote:
So the design process is a way to try to work through these issues methodically.
I don't think we have the resources for "real" (formal) UI tests, e.g. coding all scenarios and let loose a huge number of ordinary people on them to see which scenario pleases most of them. Asking people what they think is the next best thing to it, as long as you ask the right people ("Programmers are not users. Vice presidents are not users." and all that).
User testing is something you do once you have a design to try out. What I'm talking about is a process for developing the design in the first place. ;-) This isn't just a matter of guessing, it's a matter of identifying users, identifying goals and tasks, prioritizing/categorizing those, developing a user model for the app, laying out your widgets in a way that reflects the user model and the priority of the tasks they facilitate, and so forth.
Discussed in "Inmates are Running the Asylum," "Designing From Both Sides of the Screen", etc.
You need code knowing about all the coloured books stuff (e.g. to produce mixed mode CDs) and you need code that knows about music files to display their properties/length and of course code that is aware that a music file can be burned as a "literal" ogg/vorbis file or as a CD audio track and asking the user what shall be done with it. I know where to put the first (CD burning app/lib/component) and the second one (end user app), but I'm not quite sure where I'd want to put this "glue code".
Any ideas?
I think it's probably just a little app that gets run for the ogg MIME handler. Maybe that wouldn't work though.
Havoc
Am Mon, 2003-09-08 um 16.47 schrieb Chris Ricker:
On Mon, 8 Sep 2003, Alexander Larsson wrote:
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
The major Windows cd burning applications burn audio CDs, and they do all the "this many minutes left", "preview track", etc. stuff.
I really would NOT expect to find that functionality in a music player. I'd expect it in a CD burning application. What I'm doing is burning a CD. The contents of that CD should be irrelevant.
Full ACK! If I want an Audio CD, I want do use the same application, as I use for my data- or video-CD's etc. No one wants to use more than one application to burn things (from an desktop users point of view, not an unix users point of view :-)).
I think k3b (http://www.k3b.org/) is an good example what a burning application has to be (please do not kill me for giving KDE tools as an good example ;-)). It is very powerfull, easy to use and it can play the music your are burning, if you want, but overall it is a burning application not a music player. People want it IMHO that way, not the other way round.
André
On Mon, 2003-09-08 at 11:21, Alexander Larsson wrote:
On Sun, 2003-09-07 at 23:04, Nils Philippsen wrote:
Sorry for stepping up so late (I've been on vacation).
On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote:
One comment about the current music cd burning abilities. This is very limiting and will in the future be removed in favour of a "burn playlist" button in the media player (rhythmbox for instance).
Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic...
A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it.
Point re iTunes taken. I don't know what to make with your other arguments -- you seem to be talking about a monolithic standalone app like xcdroast, gcombust. I want to see this in the context of a shell (what Nautilus seems to me -- it's way beyond being a mere "file manager"). It already can "preview" music tracks, id3 (or ogg metadata) would be just another set of object properties and aggregated properties (like "duration of current selection" in this case or in a more file-centric way "chmod of 200 files at once") is a feature missing which is long overdue (IMO).
There just isn't any sane way to handle ordering of the songs in the nautilus UI. Plus you want to know things like total play time and have easy preview of the songs.
Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff...
It is hard to get the ordering data from a audio-specific burn: view, and the view would be both hard to find, and quite a lot of work to write.
I think we (both/all) have been overseeing a possibility how this could be done without the need to extend every application (and their aunt) that copes with data that possibly could be written to a CD (attention: proposal ahead):
- we already have a "CD burning view" (burn:///) as part of the "shell" (Nautilus), it would be best if it were easy to reach per icon on desktop and/or menu entry - we have applications that handle multimedia files (rhythmbox, xmms, xine, totem, mplayer, ...) - let the CD burning interface accept drops from the aforementioned applications (apps would need to be extend to send drag/drop events eventually, but this would be a generic extension, not specific to cd-burning) - hardest part: extend CD burning view to sensibly handle all the possible types of data, DnD wise ("Burn as files or CD-Audio tracks?") as well as on the presentation side (how to list what gets burned).
Offtopic: Bonus points for hiding URL-protocols behind something like "Burn on CD:", "Filesystem:", "World Wide Web:", "Secure World Wide Web" with nice icons in the URL line for great power ;-).
Finally: I think it would be better to pull the strings between the various views on the problem (files/CD burning/media) together in the shell than in the applications themselves -- I'd like to keep CD-burning specific code in them to a minimum -- perhaps just DnD as described and (where sensible) a "Burn this" button which only knows how to call the program that "burns this" on CD.
What do you think?
Nils
-
Alexander Larsson -
André Kelpe -
Chris Ricker -
Havoc Pennington -
Julien Olivier -
Marco Ermini -
Nils Philippsen -
Owen Taylor