Re: [Usability] Media Controls

[Alan Horkan <horkana maths tcd ie>]

On Sun, 30 Oct 2005, Bastien Nocera wrote:

> > > <snip>
> > > > > Very neat because they don't use "Open..."- or "New.."-items.
> > > > > * Totem uses a firs menu called "Movie" (which is bad, you can also play
> > >
> > > Why is it bad exactly? Totem is a movie player, and can also play audio
> > > files. But it's mainly a movie player.

I would appreciate if you would answer this question in particular as you
rely on us to disprove your case rather than ever having to prove it
yourself.

> > Why is it good?  Surely you had some strong idea to justify not using a
> > File menu like most applications?

It should be easy for your to answer as in your previous message you
wrote:

> I'm not trying to make things different just to be different, but all of
> them for a good reason.

Especially given the precedent set by other media applications such as
Quicktime, Windows Media Player and Real Player your choice looks like
being different for the sake of being different.  Totem seems to be a very
rare case in its choice of this menu layout even among multimedia
application let alone in the wider context of desktop applications.

> > > You've already filed this bug nearly a year ago:
> > > http://bugzilla.gnome.org/show_bug.cgi?id=160274

> The HIG says I'm OK: "If your application does not operate on documents,

You are assuming a very narrow defination of "documents" which excludes
movie files.  Gnome desktop is described as primarily "document based" and
I take documents as a way to distinguish user data files such as office
documents, text files, program data files, and even multimedia files from
configuration files the user does not generally need to know about
(unfortunately the lines are can be blurred).

I do not believe the writers intended the way you are reading that section
and I think the distintion between Task based (GnomeMeeting, AIM,
Calculator) and File or Document based applications (Gedit, Totem, Gimp,
Evince, Eog).

By your logic should Evince use a menu Document instead of File; should
Eog use a menu labelled Image; should gedit use a menu labelled Text?
What makes Totem so special?

I do not know how to make you understand a Movie file is still a file and
a File menu is a good idea.  How confident are you that Apple, Microsoft
and Real are all wrong about this and you are absolutely sure you know
better?

> > The HIG seemed to think it was a good idea and you disagreed. As the
>
> It says absolutely nowhere in the HIG that I should have a Stop button,

I'm pretty sure this was brought up before the last time this issue was
discussed:

"Show separate Stop and Pause buttons. Do not change Play to Pause while
the clip is playing."
http://developer.gnome.org/projects/gup/hig/2.0/toolbars.html

To be fair Totem doesn't actually use a standard toolbar widget so it and
this section was first included in version 2.0 of the HIG so it is easy to
have missed it.

> and if the Stop button does absolutely nothing more than what's possible
> otherwise, what's the point?

There were certainly Accessiblity issues which may have been addressed by
taking the unusual (inconsistent) step of providing a button with two
labels and the various out compromises you have experimented.  While you
were trying to find a better way Totem was left with a system which was
known to be unsuitable for certain users, which is why I said in my
previous message it was a shame the HIG failed and why I think it is
important for developers to do the same as the standards (or defacto
standards) first and then try to find something better later.

(It is tough to remember all the details and I would have to reread all
the old dicussions to give you a more thorough answer.  Help from anyone
who remembers the issues or has more time available to check is very much
appreciated.)

> You seem to be reading a different HIG than I am, because I can't find
> that anywhere in the HIG.

See above.

> Read the archives as well,

I read most of the dicussions at the time but we both see the same things
differently.

> the lack of a Stop button has already been discussed, and all the
> problems people were seeing (like not being able to eject a CD when
> playing a file from it, not releasing the sound device, etc.) were
> fixed. The Stop button is unneeded, that's why there isn't one.

You have diliggently gone out of your way to fix any problems presented
rather than follow the method originally recommended.  Certainly that is
some impressive development work to meet all those requirements the hard
way but a lot more effort than it would be to have followed what the
guidelines recommended (or at least follow them first and come up with
your better solution later).
There is also the fact that despite your more elegent solution users are
already a familiar with the more straightforward and predictable
solution of having a stop button.

It a shame such an important application which chose to be part of the
Gnome Desktop did not choose to follow the Gnome Human Interface
Guidelines and instead decided to set their own standard as if Totem were
being developed in isolation and there was no benefit to being integrated
and consistent with the rest of the Gnome.

> > developer cannot be convinced to follow the standard first and then extend
> > it later after there is evidence to show they really have thought out a
> > better answer than whoever wrote the HIG.
> >
> > I realise I am being arguementative and it is great when developers try
> > out new ideas but I think Gnome would be a lot better if developers
> > embraced first and extended later (embrace the HIG, and embrace the
> > example of the media players in the mass market).
>
> As I've said a number of times, the HIG is only a guide.

Of course the HIG isn't perfect but that means you should have a really
good reason if you are not going to follow it.  Picking at the HIG doesn't
prove your way it is necssarily better and by doing things differently to
the other applications which have followed the Guidelines we end up with
the kinds inconsitencies Tim brought up.

> You can make HIG-compliant applications that will be unusable, and some
> applications that don't completely comply will be usable.

How would using a standard File menu with consitent mnemonics and
predicatable layout users are already familiar with from not just Gnome
but other multimedia applications make Totem any less usable?  You are
asking us to prove the guidelines rather than disproving them yourself. It
is a shame you place so little trust in those who wrote the Guidelines.

How would following the Guidelines and using seperate stop and pause
buttons make Totem any less usable?  It wouldn't but finding a different
way to achieve the same thing just to show have clever you are (and I dont
think anyone ever claimed you weren't brilliant to have brought Totem to
where it is today) doesn't make Totem any more usable either.

> I'm not trying to make things different just to be different, but all of
> them for a good reason.

It honestly doesn't seem that way because relatively speaking it is such a
small change from what other media players are doing.  If you really had
wanted to do something different to be innovative you could have been
really differnt and implement something radical like a media player with
support for Gestures or Pie menus or other ideas so clever I haven't even
of them.

There is an expression in politics "if you are still arguing you have
already lost" and unfortunately I do not think you are someone who is
likely to reconsider no matter how hard I try to convince you.  Thanks for
at least reading what I had to say and although I admit is unlikely you
will change your mind I do hope you will think about these things and
maybe discuss them with people you do respect or maybe ask some real
usability experts to put the different ideas to the test and see if they
really are better.

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/