CD burning with Nautilus, was: Why xcdroast and not gcombust?

[Nils Philippsen]

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
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20030909/114f6e4f/attachment.sig>