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/ _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
