2013-12-06, 15:34
tab on a keyboard - on your remote depends on what button has been mapped
2013-12-06, 17:10
Allow me to suggest a set of good practices for the 10ft UI in XBMC skins:
1) Can you use it with a remote control?
2) Can your family members (*) use it with a remote control?
3) If your family members call you for help, can you guide them through the UI over the telephone?
Sadly for me, with XBMC's default skin, the answer isn't "yes" for any of these three questions. In case of the third questions, I'd struggle to tell my mum what to do when she describes to me what she sees on the screen. It's just not obvious enough how the navigation is supposed to work at each state of the UI.
(*) e.g. your semi-computer-literate significant other, but also your young kids or your computer-illiterate parents
Two other things that I find frustrating about using XBMC with an MCE remote control:
There's an "OK"-Button on my remote control. Yet in some cases, pressing it does something else than highlighting and clicking an "OK"-UI-Button on the screen with a mouse.
There's a "Back"-Button on the remote. Yet in some cases, it's doing something else than "Backspace" or "ESC" on the PC keyboard with the same XBMC machine.
These should be unified:
"OK" on the remote = "OK" on the screen.
"Back" on the remote = "Cancel" on the screen = "ESC" on the keyboard = "Backspace" on the keyboard (exception for the latter while editing text).
1) Can you use it with a remote control?
2) Can your family members (*) use it with a remote control?
3) If your family members call you for help, can you guide them through the UI over the telephone?
Sadly for me, with XBMC's default skin, the answer isn't "yes" for any of these three questions. In case of the third questions, I'd struggle to tell my mum what to do when she describes to me what she sees on the screen. It's just not obvious enough how the navigation is supposed to work at each state of the UI.
(*) e.g. your semi-computer-literate significant other, but also your young kids or your computer-illiterate parents
Two other things that I find frustrating about using XBMC with an MCE remote control:
There's an "OK"-Button on my remote control. Yet in some cases, pressing it does something else than highlighting and clicking an "OK"-UI-Button on the screen with a mouse.
There's a "Back"-Button on the remote. Yet in some cases, it's doing something else than "Backspace" or "ESC" on the PC keyboard with the same XBMC machine.
These should be unified:
"OK" on the remote = "OK" on the screen.
"Back" on the remote = "Cancel" on the screen = "ESC" on the keyboard = "Backspace" on the keyboard (exception for the latter while editing text).
2013-12-06, 19:24
My opinion for significantly improving the usability of confluence:
1. Eliminate the left slider, finding appropriate homes for its contents. In some cases items can go to the contextual menu. In others an 'options' menu item or tab will be a more intuitive replacement;
2. If it isn't contextual, it shouldn't be in a contextual menu (delete, play and the like make sense for a file. Update does not belong in a contextual menu unless you are updating the thing you are selecting).
3. Provide a visible indicator for items with contextual menus. If possible, pressing and holding the select button would be a good way to access contextual menus;
4. Eliminate the right slider and favourites star. Replace with a menu item. Preferred favourites (favourite favourites!) can be on the shelf via home screen customization;
5. Navigating to buttons, menu items, etc. with the direction buttons should accord to universal human experience - i.e. if a button is below the current focus, pressing the down button should take you there.
1. Eliminate the left slider, finding appropriate homes for its contents. In some cases items can go to the contextual menu. In others an 'options' menu item or tab will be a more intuitive replacement;
2. If it isn't contextual, it shouldn't be in a contextual menu (delete, play and the like make sense for a file. Update does not belong in a contextual menu unless you are updating the thing you are selecting).
3. Provide a visible indicator for items with contextual menus. If possible, pressing and holding the select button would be a good way to access contextual menus;
4. Eliminate the right slider and favourites star. Replace with a menu item. Preferred favourites (favourite favourites!) can be on the shelf via home screen customization;
5. Navigating to buttons, menu items, etc. with the direction buttons should accord to universal human experience - i.e. if a button is below the current focus, pressing the down button should take you there.
2013-12-06, 20:09
Its useful having bksp and esc doing different things, eg in a library list bksp goes up one level, esc goes back to main menu.
2013-12-07, 09:33
Also ok on a remote is like Enter - it shouldn't Hit a "ok" Button - the behavior of the ok Button on a Remote perfectly fits what tv's are Doing (entering subdirs/submenus and so on). At least that one is correct in xbmc 
2013-12-07, 13:58
2013-12-08, 02:20
Great post - thanks very much for taking the time to write it all up - it's most appreciated!
See ronie's solution, on the way, here: http://forum.xbmc.org/showthread.php?tid...pid1568049
This is a bit tricky, as you need to both be able to highlight a folder to "select" it, or navigate into the folder to find a subfolder. Thus, we have a balance between these, but perhaps that balance isn't good enough? As it is, if you go into a folder via Select, then go immediately to Ok (left unfortunately - see above!) then you'll select the folder as default focus will be on the ".." item. Perhaps it could be changed so that we ignore the currently highlighted folder and instead just use the folder you're currently browsing? I'm not sure. Suggestions welcome, noting that we need to also support mouse (and more importantly touch).
Back should absolutely do this according to the code. The "Back" action is specifically overridden to act as "Parent Folder" in the filebrowser dialog:
https://github.com/xbmc/xbmc/blob/master...r.cpp#L118
Can you please grab a Debug Log of you doing this from a subfolder in that dialog? That will allow me to see what your remote is being mapped as. According to the default keymap, it should I think be doing Back, which should end up in this code.
If a control is on-screen within the 'window' you're browsing, then you can get to it via left/up/down/right. This applies everywhere (though the first tasks above, it may not be obvious which of these will do the trick, depending on skin layout).
Back should work there as well. If not, likely a keymapping issue. Again, a Debug Log might highlight where that keymapping issue is.
Yup, we've known about this one for a long time. It was somewhat waiting on the recent re-work of the settings stuff that Montellese bravely undertook. Now that that's done, it will be easier to incorporate the per-video settings to have defaults listed in the main settings screen. It won't make Gotham, however.
That's the goal. The problem is making it look pretty at the same time, and allowing skins as much flexibility as we do. When combined with many input devices which are all remappable, it's sometimes not always achieved.
Thanks again for taking the time to clearly describe the issues you found - it's extremely important, as us old-timers are used to the quirks and often don't see them (or aren't annoyed by them as much as a new user would be).
If you can get those Debug Log's we'll see if we can fix some of the easier ones up.
Cheers,
Jonathan
Quote:Task: You're in the skin list chooser. Move to the "Get More..."-UI-button.
See ronie's solution, on the way, here: http://forum.xbmc.org/showthread.php?tid...pid1568049
Quote:Task: Choose a folder from the list
This is a bit tricky, as you need to both be able to highlight a folder to "select" it, or navigate into the folder to find a subfolder. Thus, we have a balance between these, but perhaps that balance isn't good enough? As it is, if you go into a folder via Select, then go immediately to Ok (left unfortunately - see above!) then you'll select the folder as default focus will be on the ".." item. Perhaps it could be changed so that we ignore the currently highlighted folder and instead just use the folder you're currently browsing? I'm not sure. Suggestions welcome, noting that we need to also support mouse (and more importantly touch).
Quote:Task: While browsing a nested structure, return to the parent item (e.g. the parent folder)
Back should absolutely do this according to the code. The "Back" action is specifically overridden to act as "Parent Folder" in the filebrowser dialog:
https://github.com/xbmc/xbmc/blob/master...r.cpp#L118
Can you please grab a Debug Log of you doing this from a subfolder in that dialog? That will allow me to see what your remote is being mapped as. According to the default keymap, it should I think be doing Back, which should end up in this code.
Quote:Task: Leave the "Skin" settings, go to "Screensaver" settings.
If a control is on-screen within the 'window' you're browsing, then you can get to it via left/up/down/right. This applies everywhere (though the first tasks above, it may not be obvious which of these will do the trick, depending on skin layout).
Quote:Task: You were watching TV, now play a file from the local harddisk
Back should work there as well. If not, likely a keymapping issue. Again, a Debug Log might highlight where that keymapping issue is.
Quote:Task: Turn on de-interlacing for live TV
Yup, we've known about this one for a long time. It was somewhat waiting on the recent re-work of the settings stuff that Montellese bravely undertook. Now that that's done, it will be easier to incorporate the per-video settings to have defaults listed in the main settings screen. It won't make Gotham, however.
Quote:It would be cool to have a simple, standardized path to walk through nested menu or directory hierarchies. So that browsing via buttons is consistent among different UI elements throughout the application. I'd like to see arrow buttons for browsing, "OK" to enter the next level down the hierarchy and "back" to go up to the parent element of the hierarchy, but that's just one possible way to do it.
That's the goal. The problem is making it look pretty at the same time, and allowing skins as much flexibility as we do. When combined with many input devices which are all remappable, it's sometimes not always achieved.
Thanks again for taking the time to clearly describe the issues you found - it's extremely important, as us old-timers are used to the quirks and often don't see them (or aren't annoyed by them as much as a new user would be).
If you can get those Debug Log's we'll see if we can fix some of the easier ones up.
Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
2013-12-09, 11:53
(2013-12-07, 09:33)Memphiz Wrote: Also ok on a remote is like Enter - it shouldn't Hit a "ok" Button - the behavior of the ok Button on a Remote perfectly fits what tv's are Doing (entering subdirs/submenus and so on). At least that one is correct in xbmc
I disagree. If there's "OK" on the screen, the "OK" button on the remote should do just that. Otherwise, the button on the screen should be renamed.
(2013-12-06, 19:24)allan87 Wrote: My opinion for significantly improving the usability of confluence:
I agree on all five points.
2013-12-09, 12:21
(2013-12-09, 11:53)hhzz Wrote:(2013-12-07, 09:33)Memphiz Wrote: Also ok on a remote is like Enter - it shouldn't Hit a "ok" Button - the behavior of the ok Button on a Remote perfectly fits what tv's are Doing (entering subdirs/submenus and so on). At least that one is correct in xbmc
I disagree. If there's "OK" on the screen, the "OK" button on the remote should do just that. Otherwise, the button on the screen should be renamed.
Actually I think it means the button on the remote should be renamed.
2013-12-09, 12:24
2013-12-09, 14:12
(2013-12-09, 11:53)hhzz Wrote:Pressing a remote OK button in my experience never causes an OK gui button to be selected if you've not already navigated to it on the gui, as generally the the remote OK button has the action of selecting the currently highlighted item, at least this is the way it works on all devices I've used including TV's & PVR's.(2013-12-07, 09:33)Memphiz Wrote: Also ok on a remote is like Enter - it shouldn't Hit a "ok" Button - the behavior of the ok Button on a Remote perfectly fits what tv's are Doing (entering subdirs/submenus and so on). At least that one is correct in xbmc
I disagree. If there's "OK" on the screen, the "OK" button on the remote should do just that. Otherwise, the button on the screen should be renamed.
2013-12-09, 14:25
Here's another weird UI thing: That "close" button in a dialog "window".
Compare these two:
vs.
What is the rule for the [X] in the upper right corner?
In one screen, there's no "cancel" UI-button on the screen, so ok, the [x] is used for that if you use mouse or touch.
In the other screen, there is a "cancel" UI-button, yet there is also an [x], which is redundant.
So what's the rule? When is there a [x], when is there a [cancel]?
(My suggestion would be to remove the [x] on any screen. It's an artefact from window-based UIs that doesn't really apply to XBMC's full screen usage.)
Compare these two:
vs.
What is the rule for the [X] in the upper right corner?
In one screen, there's no "cancel" UI-button on the screen, so ok, the [x] is used for that if you use mouse or touch.
In the other screen, there is a "cancel" UI-button, yet there is also an [x], which is redundant.
So what's the rule? When is there a [x], when is there a [cancel]?
(My suggestion would be to remove the [x] on any screen. It's an artefact from window-based UIs that doesn't really apply to XBMC's full screen usage.)
2013-12-09, 18:07
You can remove the "x" on all dialogs by disabling the "mouse and touch" support in XBMC settigngs.
2013-12-09, 20:52
(2013-12-09, 12:24)hhzz Wrote:Kinda kidding, but perhaps you need to change your expectations?(2013-12-09, 12:21)nickr Wrote: Actually I think it means the button on the remote should be renamed.
Well, it's kinda easier to do in software than to scrub the label of the remote. But I see that you're kidding. (Right?)
2013-12-09, 23:55
I experienced similar bewilderment when I started using XBMC but, as has been said, you do get used to it. XBMC, for me, falls into the category of software which you use frequently (compared to say, a website you may be visiting for the first and only time) and so you do learn the interface 'tricks'. I'd compare it to your office software where you eventually pick up the shortcut keys which make life easier but themselves make little sense (paste = ctrl v?).
Having said that, I guess any UI should be as easy to use as it possibly can be. XBMC (like any 10ft UI) is limited by four-direction navigation. A skinner has to fit a lot of functionality somewhere on the screen. Say you have a vertical list of movies titles. That leaves you left and right (or a keyboard press) to bring up other menus. Now switch to a view which has horizontally scrolling movie posters. To bring up those self same menus now means an up or down click. The skinner is often caught between a rock and a hard place through the constraints of the remote.
Which is not to say that some things couldn't be improved in some skins
Having said that, I guess any UI should be as easy to use as it possibly can be. XBMC (like any 10ft UI) is limited by four-direction navigation. A skinner has to fit a lot of functionality somewhere on the screen. Say you have a vertical list of movies titles. That leaves you left and right (or a keyboard press) to bring up other menus. Now switch to a view which has horizontally scrolling movie posters. To bring up those self same menus now means an up or down click. The skinner is often caught between a rock and a hard place through the constraints of the remote.
Which is not to say that some things couldn't be improved in some skins
