XBMC "BACK" verses the "ESCAPE" button?

Here's my keymap with some tweaks:

http://www.mediafire.com/file/nmulyiozwz...ap.xml.zip

Tweaks are:
• Pressing "a" during video playback will toggle the Audio/Subtitles osd. I liked this better than the current "AudioNextLanguage" since it gives visual feedback.

• Pressing "c" toggles the contextual menu (before it'd only open it, now it can also close it), and also brings up the video OSD, and music OSD. I think of this as the "universal options" button. I like it better than having another key "m".

• Pressing Esc in the home screen will toggle fullscreen if there is something playing.

Edit: Also the "Home" key now works in a Mac keyboard.

d4rk I completely agree that it'd better to be able to map to something other than the keyboard mappings. However, the issue isn't just when mapping remotes, I think the issue also applies to users that use the keyboard exclusively. Think of users of the Logitech Dinovo mini, or Apple's wireless aluminum keyboard for example. Personally I use a remote (PS3) but I still use the keyboard from time to time and it'd be nice to have a streamlined set of keys for easy navigation.

Also, think of new users who are trying out XBMC and find that to do simple navigation they are required to use multiple keys. It's not too user-friendly. I think it makes more sense to have Esc act as a "Back" button, have the "Home" button act as a shortcut to the home screen.

Many users are used to the iPod-like navigation, where one moves forward or backward one step. I think this implementation would feel more familiar to most users. And it's not just the iPod, there is also Media Portal and Apple TV which come to mind, that feature this implementation.

While the "Home" button makes sense for many skins, there's nothing inherent in the XBMC codebase that requires it to be this way. Indeed, some skins (mc360 for instance) work quite differently with respect to this, so a home button makes little sense for them, so we have to be a little careful about how things tie in.

If we have a back button on the UI for mouse users, then mouse users have 2 actions available separately: They can go up a directory or can go back a screen. This is no different than allowing this through the keyboard mapping as we do now.

What we really need to think about, though, is whether or not we allow something like "backspace" which is the current "up directory" action to also function as a "previous menu" in some areas. I have no real issue with doing so - indeed, it's already done for the B button on the xbox gamepad. The next issue is whether or not "backspace" is the key to use for this, or whether or not "escape" or some other key is more useful. Backspace is the default mapping on a windows machine for going up the heirachy in explorer for instance - I'm not sure whether this is the same on linux or os x machines (os x machines generally not having separate backspace and delete keys.)

To address your other changes:

1. I agree that "C" should close the context menu.
2. "A" to toggle audio settings is fine - does "V" then toggle video settings? The visual feedback of "AudioNextLanguage" is a separate issue - mind trac'ing that one - it applies to all button presses in fullscreen that have no visual feedback currently.
3. "C" to bring up the OSD's is inconsistent with in-UI OSD's. This is why we use "M" in this case - it always brings up the OSD if something is playing, no matter where you are, so I'm in two minds about this one.
4. I disagree about "escape" from home. The problem is that users may "overrun" and get back to fullscreen when they were wanting to get to home. It also defeats the "previous screen" notion as you can actually get in to a loop toggling between home and fullscreen.

Cheers,
Jonathan

jmarshall Wrote:What we really need to think about, though, is whether or not we allow something like "backspace" which is the current "up directory" action to also function as a "previous menu" in some areas. I have no real issue with doing so - indeed, it's already done for the B button on the xbox gamepad. The next issue is whether or not "backspace" is the key to use for this, or whether or not "escape" or some other key is more useful. Backspace is the default mapping on a windows machine for going up the heirachy in explorer for instance - I'm not sure whether this is the same on linux or os x machines (os x machines generally not having separate backspace and delete keys.)

This is the biggest change I hope for. I am often in context menus or some other dialog and escape closes some of them and backspace closes others. I'll make a list if it is helpful.

jmarshall Wrote:While the "Home" button makes sense for many skins, there's nothing inherent in the XBMC codebase that requires it to be this way. Indeed, some skins (mc360 for instance) work quite differently with respect to this, so a home button makes little sense for them, so we have to be a little careful about how things tie in.

Ok, makes sense.

jmarshall Wrote:If we have a back button on the UI for mouse users, then mouse users have 2 actions available separately: They can go up a directory or can go back a screen. This is no different than allowing this through the keyboard mapping as we do now.

Agh, I don't know man, I think there's just something wrong with the design. As a user I don't see why there needs to be a differentiation between screens and directories... When I navigate I really don't think of it that way. Personally, I'm used to the notion of going forward one screen, going back one screen regardless of type, as in the iPod, Apple Tv, Media portal.

This to me is more evident in Library mode, especially when navigating TV Shows. When you select a show, it shows you the seasons, then when you select a season it shows you the shows. If I want to select another TV show I go back a couple of "screens". As a user I just see them as screens, I don't think of them as directories.

By forcing the user to have Esc and Backspace for navigation, he's forced to think about which of the screens are screens and which are directories. I think this is just confusing and completely unnecessary.

What if we were to have users familiarize with the concept of a "home" which most already are? And then have everything being a "screen"? Then the navigation would be much easier. I think most if not all skins can accommodate to this.

I don't know.. you probably have more ideas than I do; how can this be made such that there is only 1 back button? Media Portal does this, Esc does bring you back 1 level, whether it's files or screens. And media portal also has a home button. I think it works really well.

jmarshall Wrote:What we really need to think about, though, is whether or not we allow something like "backspace" which is the current "up directory" action to also function as a "previous menu" in some areas. I have no real issue with doing so - indeed, it's already done for the B button on the xbox gamepad. The next issue is whether or not "backspace" is the key to use for this, or whether or not "escape" or some other key is more useful. Backspace is the default mapping on a windows machine for going up the heirachy in explorer for instance - I'm not sure whether this is the same on linux or os x machines (os x machines generally not having separate backspace and delete keys.)

Right, on OSX the key is ⌘↑ (command up), it's not too popular though. Backspace on OSX is just reserved for deletion.

As for backspace vs esc vs other button, I see a couple of issues on choosing backspace over esc for a back button. Currently backspace does not close context menus or OSDs, nor does it stop playback. In fact during playback it's mapped to SmallStepBack (really hate that one lol). Also it doesn't "go back" in the settings page. Even if we were able to change this, there might be a problem in cases where text is being input with the keyboard. In such cases backspace obviously acts as a deletion key. This would conflict with the notion that the back button should work everywhere since in this case it wouldn't. Ideally the user should always be able to get back to something by pressing the back button.

jmarshall Wrote:To address your other changes:

1. I agree that "C" should close the context menu.
2. "A" to toggle audio settings is fine - does "V" then toggle video settings? The visual feedback of "AudioNextLanguage" is a separate issue - mind trac'ing that one - it applies to all button presses in fullscreen that have no visual feedback currently.
3. "C" to bring up the OSD's is inconsistent with in-UI OSD's. This is why we use "M" in this case - it always brings up the OSD if something is playing, no matter where you are, so I'm in two minds about this one.
4. I disagree about "escape" from home. The problem is that users may "overrun" and get back to fullscreen when they were wanting to get to home. It also defeats the "previous screen" notion as you can actually get in to a loop toggling between home and fullscreen.

Visual feedback is indeed a separate issue. It'd be really nice to have visual feedback when a subtitles or AudioNextLanguage key is pressed for example.

V toggle for video.. definitely good idea.

"C" to bring up the OSD's is inconsistent with in-UI OSD's, what do mean?

About esc going to fullscreen in home, I agree, this is just a personal preference. Some users might like esc to bring up the shutdown menu. I don't think there is any perfect mapping in this case, I just didn't like it not doing anything, and I found it useful to be a fullscreen toggle. Also it's not "harmful", ie, if there is nothing playing then it won't do anything. But yea, this is just a personal preference.

kricker Wrote:This is the biggest change I hope for. I am often in context menus or some other dialog and escape closes some of them and backspace closes others. I'll make a list if it is helpful.

I don't recall cases where Esc doesn't close context menus, osds, etc.. could you cite some examples? Also which skins are you using? Thanks

Agreed that "backspace" has difficulties due to the editcontrol problems. In this case, using "escape" is indeed probably the best option if we decide to go for a single key does everything type approach. Whether or not the majority of the users wish to sacrifice the screen-only behaviour of the escape key as it is currently is to be decided - I shall start asking around.

A "Home" action breaks in the case of dialogs being on screen (should we cancel them - in some cases, such as progress dialogs, this is tricky programatically), so that's not necessarily a good option.

As for "C". It's inconsistent as you'd have to press "C" to bring up the OSD while in fullscreen (music or video) yet if you weren't in fullscreen, pressing "C" does NOT bring up the OSD, rather it brings up the context menu for an item that may be completely unrelated to what is playing. Thus, we use a different key "M" that is mapped globally to show and close the OSD's no matter where you are.

Cheers,
Jonathan

Cool, I appreciate your time and efforts on this.

jmarshall Wrote:As for "C". It's inconsistent as you'd have to press "C" to bring up the OSD while in fullscreen (music or video) yet if you weren't in fullscreen, pressing "C" does NOT bring up the OSD, rather it brings up the context menu for an item that may be completely unrelated to what is playing. Thus, we use a different key "M" that is mapped globally to show and close the OSD's no matter where you are.

Got it, I didn't know the osd could be displayed outside fullscreen.

Actually, one place that would not function well with a "universal back" thing (or at least it wouldn't be as obvious as in other places) is the filemanager.

Admittedly, not a high priority if you're on a box that already has decent filemanagement tools, but if you aren't (apple tv, xbox, in front of the telly on the couch and don't want to bring up a desktop) then it may well be a problem. ESCAPE if mapped to "parentdir" would be contextual (i.e. based on which list you were in) and you'd have to navigate up to the root in one of the lists (but not both) in order to exit from the screen.

Cheers,
Jonathan

migueld Wrote:I don't recall cases where Esc doesn't close context menus, osds, etc.. could you cite some examples? Also which skins are you using? Thanks

Actually you are correct. I was speaking in reverse. It is "backspace" that does not close context menus and info menus "esc" closes those. But, and this is what I think spurs my confusion, "backspace" does close the Filemanger. Filemanager in PM3.HD is accessed from the settings menu. All of the sub menu settings are exited using "esc" and not "backspace". Filemanager on the other hand can be exited with "esc" and "backspace" provided your at a root level of the selected drive. Being someone used to an overall "back" button, as soon as I close the Filemanager (For some reason I am in there quite a bit) my brain switches to that mode. I forgot to think about what is a directory and what is a menu.

migueld Wrote:As a user I don't see why there needs to be a differentiation between screens and directories... When I navigate I really don't think of it that way. Personally, I'm used to the notion of going forward one screen, going back one screen regardless of type, as in the iPod, Apple Tv, Media portal.

This to me is more evident in Library mode, especially when navigating TV Shows. When you select a show, it shows you the seasons, then when you select a season it shows you the shows. If I want to select another TV show I go back a couple of "screens". As a user I just see them as screens, I don't think of them as directories.

By forcing the user to have Esc and Backspace for navigation, he's forced to think about which of the screens are screens and which are directories. I think this is just confusing and completely unnecessary.

My sentiments exactly

I did notice that the "menu" button opens a context menu and closes it as well. Sage has a similar behavior which I have grown accustom to. The button that opens an option dialog also closes that same dialog. This does happen in XBMC in FullScreen video mode. "m" opens and closes the player controls, "i" opens and closes the OSD info, "o" opens and closes the codec info. If this were universal throughout the GUI, I think most of my control issues would go away. I have also always disliked the "backspace" as smallstepback and have always changed it to stop.