Space bar key should always trigger play/pause, like in all other media players

[Olli Savolainen]

Rhythmbox, spotify, vlc, Totem all have the space bar key to make playback go from pause to play and from play to pause mode.

I listen to music while I do other stuff on the PC. Sometimes I listen on spotify, sometimes on Exaile (I love Exaile's UI over Rhythmbox since it is so simple and similar to Spotify). Sometimes I play a speech-only video on Totem or VLC and have Exaile play background music. For all of the above, quick switching between apps using alt+tab and being able to control playback blazingly fast using space bar, is key.

I am so used to this that I keep forgetting that Exaile does not follow this de facto standard behaviour, and instead starts playbaack from the start of the song. This irritates me a lot, since I not only do not get the song paused, but lose the spot where I was in the song.

[Carlos Eduardo Melo (ceduardo-melo)]

Can you elaborate more?

Here, when the focus is in the playlist, pressing the spacebar causes the playback to pause/resume, instead of starting the song from beginning.

[Olli Savolainen (pilpi)]

Ah right, I just upgraded to 0.3.2.1 and can confirm that there is a modality now that allows toggling pause when in playlist. I suggest removing this modality to conform to the de facto standard, and to the above usage scenario: have it play/pause regardless of where the focus is.

At the moment it is up to luck whether or not one can quickly switch to exaile and have it pause. If focus is in the wrong place, a lot of hassle follows.

Also, the fact that the functionality is dependent on this modality has no affordance in the UI, so if the user tries whether this works in exaile and happens to have focus in wrong part of the screen, they will likely learn the assumption that spacebar for play/pause just does not work - they have no reason to assume otherwise.

Also related to the above, I suggest to have play/pause in the application menu - in addition to providing accessibility to disabled users, it provides affordance/discoverability for shortcuts.

[Mathias Brodala (mathbr)]

The thing is that this is a restriction of GTK. Key press events in entries within a window are also triggered on the window itself. So if we try to toggle pause upon Space key press, you will toggle it also every time you try to enter a space in one of the entries.

And due to the event processing order in GTK one cannot prevent the event to reach the window since that’s actually where it starts from, moving down to the lowest piece in the widget tree.

As for the Playback menu: this is surely something to consider but should be moved into a separate report.

[Olli Savolainen (pilpi)]

Yeah, I was just being lazy about playback menu. Sorry.

If GTK does not allow the global shortcut, a workable workaround would then seemingly be to bind space bar press to play/pause in all or most controls that do not accept keyboard input. Of course, you would probably need a good abstraction/OO design pattern for this that would allow not having the binding code all over the place.

At first glance, it seems it would help a lot if space bar would work in any of the list views in the tabs on the left, and when any of the tab titles are active.

[Olli Savolainen (pilpi)]

I find it sad that usability defects are regarded as "opinion", as if they were somehow more subjective than functional bugs.

Please, do get the facts about user expectations, and about existing domain (music player) conventions. What other players do (defining users' expectations) is just as much a circumstance that defines whether people will think your application works, as whether your play button is just functionally broken.

[reacocard (reacocard)]

As mathbr said, this isn't something that's trivial to do in GTK+. Additionally, the space key is used by GTK+ to activate widgets by default, so users who are used to that function might be confused if we start overriding this behavior. Furthermore, since text entries are part the the UI and need to be able to absorb spaces for their own functionality to work, it wouldn't be guaranteed to pause when you switch back anyway! The action of space is ALWAYS going to be context-sensitive to one degree or another.

I do agree that it's a usability issue, and we should at least handle this for the common case where the focus is in the playlist. I'm not certain that it makes sense or is feasible to do it everywhere else, which is why I marked this as Opinion.

[Johannes Sasongko (sjohannes)]

> Please, do get the facts about user expectations

I'd be interested if there is a study regarding this. Here's my
opinion ("expectation"):
- in a list box, space bar shouldn't do anything special other than
for Ctrl-selecting;
- in a *video* player, space bar should toggle playback when the
selection is on the video widget.

The GTK+ list box behaviour of "Space = activate" is not very
uncommon; the Mac file manager does this as well (although I don't
know about iTunes). Maybe users expect this behaviour?

I do think Exaile needs a keyboard shortcut for controling playback.
Whether it should involve the Space key is, at this point, a matter of
opinion.

[Olli Savolainen (pilpi)]

Thank you for your thoughtful comments.

I agree that space needs to have a special functionality in certain places, i.e. in text input boxes. Still, there is a difference between a key functionality of the player being global with some reasonable exceptions, and being so heavily affected by application modality that users have to carefully place the application in a mode required by the application, to get what they want, done.

"Furthermore, since text entries are part the the UI and need to be able to absorb spaces for their own functionality to work, it wouldn't be guaranteed to pause when you switch back anyway!"
This is a difficult question. In spotify, the search text box loses focus when you switch out of the app. Which is more important, rapid and reliable usage of the main function of the whole application, or important but nonetheless less often used search functionality?

The one usage scenario where I would not want search boxes to lose focus when I switch out of the app is where I am confirming the name of an artist/album/song in say, a web browser, to be able to return to the music player to search for it in my collection. Then again, I am not sure if having to mouse back to the search box would be a great price to pay for having the main functionality work reliably. And again, just having to tab once to get the functionality working again (Amarok) is very different than having to tab through dozens of items to get it working.

But if there are buttons in the UI that you can tab through, should not tabbing to them and pressing space on them to activate be possible? In Spotify, the enter key serves this purpose. In Amarok and VLC, this appears impossible.

UI modality is usually a risk I want to avoid, unless I can make very sure that the mode and its consequences on what users can and can not do are clearly visible in the UI. Here, the modality is so strict and so invisible that it effectively renders the shortcut useless.

It seems to me that ctrl-selecting more than one item with a keyboard is a marginal use case that few people except expert users would ever think of doing, whereas pressing space to play/pause is a near-global de facto convention across most music players.

Usability is about usage context - what is reasonable in a file manager may not be reasonable for a music player. So even though there is a platform convention, if it makes little sense in a music player that in my opinion, the burden of proof should be on the person who thinks that the platform convention - not on the one preferring the "this is how music players generally work" design choice. Even GNOME all in all is a very small player in the real world. In my opinion, Jakob's law not only applies to web UIs!

'Jakob's Law of the Web User Experience states that "users spend most of their time on other websites."
This means that they form their expectations for your site based on what's commonly done on most other sites. If you deviate, your site will be harder to use and users will leave. ' http://www.useit.com/alertbox/9605.html (#8 Violating Design Conventions)

It seems that the reasonable way to do this research would be to see which players ar...

[reacocard (reacocard)]

> In spotify, the search text box loses focus when you
> switch out of the app.

Interesting idea. Where does it move the focus to?

> 'Jakob's Law of the Web User Experience states that
> "users spend most of their time on other websites." ...

Right, and desktop app users spend most of their time using other apps on the same platform - NOT other music apps. Thus this argument is just as easily applied to consistency with the platform as with players in general.

> ...see which players are the most popular on the
> market, and...mimic their usual behaviour unless
> there is a sound reasoning not to.

Why not research this then, if this is such an important feature to you?

That's honestly my biggest issue with how your report is going so far - you state your opinion a lot, but have not actually done significant work towards making it happen yet. If you care about it that much, work to make it better - it is open source, after all. Otherwise, shut up and let us work as we see fit - we already know what your opinion is, hearing it yet again without anything new to show isn't going to change our minds.

[Olli Savolainen (pilpi)]

My intention was not to repeat what I already said, but to continue on your thoughts. I am sorry if you found my last post had nothing new to contribute - I earnestly thought I was adding to the conversation, and also giving a little taste on the research at the end of my post - research of competing products is also important in user centered design.

I was not aware you do not welcome critical discussion about reasoning behind design decisions. In my opinion, the kind of discussion I thought we were having is exactly what is needed to make sure the design decisions are based on sound principles. I presented different usage scenarios where what I am proposing might be useful, and where it might be harmful. Usage scenarios are often used in user centered design processes. Nonetheless, I wish to present my apologies if I failed to respect your policy.

I warmly welcome your thoughts about the kind of research you would expect to get done on a question like this.

[reacocard (reacocard)]

> I was not aware you do not welcome critical discussion
> about reasoning behind design decisions.

It didn't sound like a critical discussion to me - it sounded like you pulling more random thoughts about why your opinion is right out of thin air. There was a LOT of text, and not a lot of it was directly relevant to solving the issue at hand. Being concise and to the point is generally more effective than writing a 700 word essay in a comment. :)

Regardless of your intention, my point remains - both parties here have already made it clear what their opinions are, so until something is actually /done/, rehashing these ideas more is unlikely to be helpful.

> I warmly welcome your thoughts about the kind of research
> you would expect to get done on a question like this.

- A list of the 'most popular' music players that would be relevant to this discussion. I think we should concentrate on linux-based ones but it may be worth looking at some examples from windows and mac as well.
- For each of these players, examine:
-- What sort of shortcuts are set for playback controls when the window is focused. i.e. what keys are used, how are they sensitive to context, and how do they deal with interactions with other widgets like textboxes that may already have defined behaviors for them.
-- Whether these bindings override default behaviors or best practices on the platform/toolkit the player utilizes, and how the loss of functionality, if any, is compensated for, if at all.
-- How the player addresses or fails to address any usability/accessibility concerns that arise from such bindings and/or overrides.

That should give us an idea of "usual behavior", as you put it, along with any potential problems that might come up and their solutions.

This still doesn't address the coding side of things - unless there's some way to do this in code without having to manually attach bindings or exceptions to bindings everywhere, then the code maintenance burden would be too great to implement it regardless of common practice. I don't think this is likely to be the case though, since Banshee appears to implement space as play/pause in the manner you prescribe. Maybe I'll take a look at their code and see what they had to do to make it work right.

[Johannes Sasongko (sjohannes)]

I figured I'd start with foobar2000 since I'm on Windows at the moment, but fb2k by default has absolutely no keyboard shortcuts for playback control; so in that sense it's similar to current Exaile.

It does let you set your own shortcuts, though, including redefining important keys like Return or up/down. As far as I can tell, these shortcuts then work on any widget except text boxes.

[drewm1980 (drewm1980)]

+1 for space bar activating play/pause. Unreliable play/pause is a showstopper for me. Rhythmbox fails too.