Thread: [Kaffeine-user] A first cut of a new full screen interface for Kaffeine.
Brought to you by:
hftom,
lasselindqvist
From: John M. <jw...@es...> - 2004-05-25 14:23:40
|
The interface consists of a tool bar for the standard media play controls, and a menu bar to access any controls not on the tool bar, various interactive configuration items that can't be shoehorned into the tool bar, and various in-stream options like particular video and audio sub-streams (DVD camera angles, audio commentaries and languages) and subtitles. The tool bar and menu bar will be placed at the edges of the screen, which places them as far out of the way of the action as possible (exploiting the black bands of one aspect ratio displayed on another), and allows the access to the buttons and menus to be accelerated due to the pinning effect of the edges of the screen on the pointer. The specific edges used should be user configurable to some extent. The menu bar can only readily be placed at the top or bottom of the screen, while the tool bar can be placed against any side. When placed against the left or right side, the menu bar's first or last menu should be displaced along so they don't overlap the tool bar. The obvious standard setup would be to put the menu bar at the top and the tool bar at the bottom, but for 16:9 displays, it may make more sense to place the tool bar on the left or right hand side to exploit the black band created by 4:3 material. The tool bar and menu should be hidden during playback and made visible by either clicking the left mouse button, or action key for cursor based navigation, or by pinning the mouse pointer to any corner. (We use the mouse click/action button option mainly so cursor input can pop the controls up, but, if the pause/resume button is on one corner of the tool bar, move-pointer-to-corner, click is faster than click, move-pointer-to-corner, click. And making the right mouse button the pause/resume hot key is fastest of all. We also avoid activating the controls on moving to any side, as this leaves users with no edge that they can just chuck the pointer to when finished.) The controls should use the same visibility mechanic as the pointer to decide when to hide again, subject to two additional rules - if the pointer is overing over the menu or tool bar, increase the timeout to something like 30 seconds (configurable?), and when the pointer is hovering over an open menu, stop the timer until the menu is closed again. Fonts used for all elements - the menu bar, the tool bar with text switched on, tool tips, etc - should be increased in size by some full screen specific font adjustment. A factor of about 150% to 200% would make a good default, but this should be configurable. The tool bar should contain the standard control buttons; pause/resume/play, stop, back one play-list item, forward one play-list item, fast forward and rewind. It should be configurable so that the order and contents can be changed by the user, and certain media specific options can go there. For example, save stream, a full screen/windowed toggle, cycling through DVD camera angles, cycling through subtitles and audio streams (commentary, languages) could all be tool bar buttons. The size of the bar should be the length of the side it's on, and a height (width) based on the size of the blacked out strips of the display when displaying the opposite kind of aspect ratio - ie if using a 4:3 monitor, the height of the bar ought to be about 95% of the black bar displayed when displaying 16:9 content. Buttons should expand to evenly fill the length of the bar. They should have the out of focus buffer around the edge adjacent to the edge of the screen removed so that they can be clicked on when the pointer is pinned to the edge. They'll need to have some visual indication of being in focus for both the cursor and pointer inputs. The menu bar is just a straightforward top of the window affair, except the text is set to the full screen scale factor size, and the tops (or bottoms) of the menu buttons should extend to the edge of the screen. As the menu buttons are larger, due to the increased font size, the amount of menus that can hang off the menu bar is decreased, and due to the titles of the buttons varying by locale, it's wise to have one or two less menus that might otherwise fill the bar. The contents of the menus should be limited to things that are of use during playback, and ought to avoid sub-menus if possible, as they tend to be hard access and they complicate the cursor base navigation model (more below). Candidates for menus might include: - the contents of the play-list, to enable fast access to specific songs, chapters, whatever. - 'Camera angles', or whatever you might call alternative video sub-streams. Greyed out if their are none. - 'Audio channels', like audio commentaries or alternative languages. - Subtitles and subtitles for the deaf. - Interactive configuration options, like toggling audio profiles, filtering options, aspect ratios, etc - Bookmarks. Just like the play-list, really. Most of the settings related to putting things into and generally manipulating the play-list should happen in the play-list, rather than via menus accessed in full screen mode. Cursor navigation should work as follows. The initial action button will bring up the controls. Initial focus should go to the left/top most tool bar item, which will probably be the pause/resume/play button, but it could be configured to start on the left most menu item, or a particular tool bar button, regardless of where it appears. Use left and right, or up and down, depending on the orientation of the tool bar to move to different buttons, and the action key activates them, as you'd expect. Traversal of the bar shouldn't wrap around; you should be able to hold a cursor key down to zip to the end of the bar and be pinned there. Moving along the axis perpendicular to the tool bar, and away from the edge of the screen should move you to the menu bar, and vice versa. If the menu bar and tool bar are at opposite ends of the screen (ie top and bottom), then moving from the nth from the left item on one should place the focus on the nth from left of the other. The case where the menu is at the top or bottom but the tool bar is left or right is a bit trickier; I think moving left(right) from any point on the tool bar should take you to the left(right) most menu item, while moving back from the menu should return you to the focus point you left. But this case needs usability testing. For the menu bar itself, you should hit the action key to pop up a given menu, at which point the menu stays open until you move left or right to another menu button, or you move down(up) the menu and back up to the button. Moving down(up) from the last menu item shouldn't send you to the tool bar!. Which leaves hot keys. For the mouse, pause/resume on right click, and full screen on the middle are good, but the mouse wheel ought to do something less disruptive than fast forward/reverse, such as control the volume (using a gradient that will require a few turns to take it from silent to ear splitting). The rest of the desktop oriented hot keys should require a modifier, like shift, to avoid having them triggered by an accidental brush of the keyboard in the dark. This will also make cursor navigation work at all. Ok. I'd like to implement this, but I have to get to grips with the mysteries of C++ and KDE/Qt from a C/perl/python background, with a little tinkering in X and with tk and wxWindows. And I expect some of the things I've specified fall off the beaten path of standard widgets, so I expect someone who knows their way around some KDE programming will be able to get something up and running months before I could. I'd probably try to build the interface in this order: - drop the pop up menu and create a top menu and bottom tool bar with standard widgets (ktoolbar, etc). Populate the menu with the things I've discussed and drop the rest for the play-list or desktop to handle. Have it unhide on left click and hide when the mouse does. - Add a configuration dialog to control the positioning and populating of the menu and tool bars. - Figure out how to make tool bar buttons expand to full the bar. Calculate the bar height(width) based on the screen size and aspect ratio, so it's a bit smaller than the black band you get playing 16:9 on 4:3 or vice versa. - Figure out how to apply a scale factor to the fonts of all the relevant widgets and place it in the configuration dialog. - Figure out how to pop up on pinning to the corners. - Figure out how to extend the focus areas around menu and tool buttons so you can click on them while pinned to a corner or edge. - Set up the cursor based focus navigation. Allow the menu or a button on the tool bar to take first focus. - Everything else - Test, test, test - various input devices, usability. Comments? John |
From: Mikolaj M. <mi...@wp...> - 2004-05-25 17:42:18
|
Dnia wtorek, 25 maja 2004 16:23, John Morton napisał: > The interface consists of a tool bar for the standard media play > controls, and a menu bar to access any controls not on the tool bar, > various interactive configuration items that can't be shoehorned into the > tool bar, and various in-stream options like particular video and audio > sub-streams (DVD camera angles, audio commentaries and languages) and > subtitles. > > The tool bar and menu bar will be placed at the edges of the screen, > which places them as far out of the way of the action as possible > (exploiting the black bands of one aspect ratio displayed on another), > and allows the access to the buttons and menus to be accelerated due to > the pinning effect of the edges of the screen on the pointer. Note pressing pointer to edge (bottom especially) may trigger unhiding of kicker. Should Kaffeine stole that effect? If so why show this menu only by pressing pointer in corner? When it will be activated by whole width of edge user will be able to place pointer closer to desired action. > The tool bar and menu should be hidden during playback and made > visible > by either clicking the left mouse button, or action key for cursor based > navigation, or by pinning the mouse pointer to any corner. (We use the > mouse click/action button option mainly so cursor input can pop the > controls up, but, if the pause/resume button is on one corner of the tool > bar, move-pointer-to-corner, click is faster than click, > move-pointer-to-corner, click. And making the right mouse button the > pause/resume hot key is fastest of all. We also avoid activating the > controls on moving to any side, as this leaves users with no edge that > they can just chuck the pointer to when finished.) Maybe activating of menus through left mouse click should move cursor to desired corner? That would be only click,click to activate default button. > The controls should use the same visibility mechanic as the pointer to > decide when to hide again, subject to two additional rules - if the > pointer is overing over the menu or tool bar, increase the timeout to > something like 30 seconds (configurable?), and when the pointer is > hovering over an open menu, stop the timer until the menu is closed > again. IMO when pointer is over menu timer should be hold. Configurable is the best :) > Fonts used for all elements - the menu bar, the tool bar with text > switched on, tool tips, etc - should be increased in size by some full > screen specific font adjustment. A factor of about 150% to 200% would > make a good default, but this should be configurable. Agree. > Cursor navigation should work as follows. The initial action button > will > bring up the controls. Initial focus should go to the left/top most tool > bar item, which will probably be the pause/resume/play button, but it > could be configured to start on the left most menu item, or a particular > tool bar button, regardless of where it appears. Use left and right, or > up and down, depending on the orientation of the tool bar to move to > different buttons, and the action key activates them, as you'd > expect. Traversal of the bar shouldn't wrap around; you should be able to > hold a cursor key down to zip to the end of the bar and be pinned there. Not sure here. Maybe treat last element as ten elements. If cursor key will be pressed down for some time it will jump to first/last element? > Moving along the axis perpendicular to the tool bar, and away from the > edge of the screen should move you to the menu bar, and vice versa. If > the menu bar and tool bar are at opposite ends of the screen (ie top and > bottom), then moving from the nth from the left item on one should place > the focus on the nth from left of the other. The case where the menu is > at the top or bottom but the tool bar is left or right is a bit trickier; > I think moving left(right) from any point on the tool bar should take you > to the left(right) most menu item, while moving back from the menu should > return you to the focus point you left. But this case needs usability > testing. I think this reason to not allow placing anything on neighbouring edges. > > - Figure out how to pop up on pinning to the corners. > > - Figure out how to extend the focus areas around menu and tool buttons > so you can click on them while pinned to a corner or edge. Look at kasbar, kicker m. |
From: John M. <jw...@es...> - 2004-05-26 02:08:12
|
On Wed, 26 May 2004 05:41, Mikolaj Machowski wrote: > Dnia wtorek, 25 maja 2004 16:23, John Morton napisa=B3: > > The interface consists of a tool bar for the standard media play > > controls, and a menu bar to access any controls not on the tool bar, > > various interactive configuration items that can't be shoehorned into > > the tool bar, and various in-stream options like particular video and > > audio sub-streams (DVD camera angles, audio commentaries and languages) > > and subtitles. > > > > The tool bar and menu bar will be placed at the edges of the screen, > > which places them as far out of the way of the action as possible > > (exploiting the black bands of one aspect ratio displayed on another), > > and allows the access to the buttons and menus to be accelerated due to > > the pinning effect of the edges of the screen on the pointer. > > Note pressing pointer to edge (bottom especially) may trigger unhiding > of kicker. Should Kaffeine stole that effect? Yes, but only in full screen mode. If you want to bring up kicker, switch b= ack=20 to the desktop and pin. I don't think there's an easy way to steal the=20 corners and sides form a window manager who's using it to switch desktops,= =20 but a user will have had to go to some trouble to set that up, so that's=20 their problem :-) > If so why show this menu=20 > only by pressing pointer in corner? When it will be activated by whole > width of edge user will be able to place pointer closer to desired > action. The corners are both the second largest set of targets and easily avoidable= =20 targets, while the sides are easy to run into. I've watched users use full= =20 screen mode, and they tend to flick the pointer off to an edge to get it ou= t=20 of the middle of the screen - even knowing it will disappear if they leave = it=20 for a couple of seconds. If the edge of the screen brings the controls, use= rs=20 will have to slow down in order to move the pointer to the area between=20 the edge and the video stream, if one exists, which would distract them for= a=20 second or two. > > The tool bar and menu should be hidden during playback and made > > visible > > by either clicking the left mouse button, or action key for cursor bas= ed > > navigation, or by pinning the mouse pointer to any corner. (We use the > > mouse click/action button option mainly so cursor input can pop the > > controls up, but, if the pause/resume button is on one corner of the > > tool bar, move-pointer-to-corner, click is faster than click, > > move-pointer-to-corner, click. And making the right mouse button the > > pause/resume hot key is fastest of all. We also avoid activating the > > controls on moving to any side, as this leaves users with no edge that > > they can just chuck the pointer to when finished.) > > Maybe activating of menus through left mouse click should move cursor to > desired corner? That would be only click,click to activate default > button. Ew! Teleporting mouse pointers! That's definitely in the category of behavi= our=20 that the user won't expect. I'd far rather load the pause/resume function=20 onto the right mouse button so they can click that, then do what they need,= =20 wth the presure taken off because they don't need to split their=20 concerntration between watching the stream and controlling the player.=20 It's probably a good idea to have the controls appear when the pause hotkey= is=20 clicked, too.=20 > > The controls should use the same visibility mechanic as the pointer to > > decide when to hide again, subject to two additional rules - if the > > pointer is overing over the menu or tool bar, increase the timeout to > > something like 30 seconds (configurable?), and when the pointer is > > hovering over an open menu, stop the timer until the menu is closed > > again. > > IMO when pointer is over menu timer should be hold. Configurable is the > best :) But do usabililty testing for the default :-) > > Cursor navigation should work as follows. The initial action button > > will > > bring up the controls. Initial focus should go to the left/top most to= ol > > bar item, which will probably be the pause/resume/play button, but it > > could be configured to start on the left most menu item, or a particul= ar > > tool bar button, regardless of where it appears. Use left and right, or > > up and down, depending on the orientation of the tool bar to move to > > different buttons, and the action key activates them, as you'd > > expect. Traversal of the bar shouldn't wrap around; you should be able > > to hold a cursor key down to zip to the end of the bar and be pinned > > there. > > Not sure here. Maybe treat last element as ten elements. If cursor key > will be pressed down for some time it will jump to first/last element? Possibly, but I expect that holding the opposite key down will get you back= =20 just as fast, but without the unexpected behaviour of holding the key down= a=20 bit too long suddenly sending you to the other side.=20 > > Moving along the axis perpendicular to the tool bar, and away from the > > edge of the screen should move you to the menu bar, and vice versa. If > > the menu bar and tool bar are at opposite ends of the screen (ie top a= nd > > bottom), then moving from the nth from the left item on one should pla= ce > > the focus on the nth from left of the other. The case where the menu is > > at the top or bottom but the tool bar is left or right is a bit > > trickier; I think moving left(right) from any point on the tool bar > > should take you to the left(right) most menu item, while moving back > > from the menu should return you to the focus point you left. But this > > case needs usability testing. > > I think this reason to not allow placing anything on neighbouring edges. Could be. We could just demote the implementation of it for a while. > > - Figure out how to pop up on pinning to the corners. > > > > - Figure out how to extend the focus areas around menu and tool butto= ns > > so you can click on them while pinned to a corner or edge. > > Look at kasbar, kicker Yes - I'm glad it's a solved problem. Hopefully they have a DCOP interface = for=20 toggling the behaviour, as well. John |
From: Mikolaj M. <mi...@wp...> - 2004-05-26 12:41:09
|
Dnia środa, 26 maja 2004 04:08, John Morton napisał: > > If so why show this menu > > only by pressing pointer in corner? When it will be activated by whole > > width of edge user will be able to place pointer closer to desired > > action. > > The corners are both the second largest set of targets and easily > avoidable targets, while the sides are easy to run into. I've watched > users use full screen mode, and they tend to flick the pointer off to an > edge to get it out of the middle of the screen - even knowing it will > disappear if they leave it for a couple of seconds. If the edge of the > screen brings the controls, users will have to slow down in order to move > the pointer to the area between the edge and the video stream, if one > exists, which would distract them for a second or two. But it will trigger only where menu/taskbar is. Users will move pointer to the side. Also triggering by corner isn't very intuitive. Most hidden controls in desktops are turned on by moving to the side. > > Maybe activating of menus through left mouse click should move > > cursor > > to desired corner? That would be only click,click to activate default > > button. > > Ew! Teleporting mouse pointers! That's definitely in the category of > behaviour that the user won't expect. I'd far rather load the > pause/resume function onto the right mouse button so they can click that, > then do what they need, wth the presure taken off because they don't need > to split their concerntration between watching the stream and controlling > the player. Teleporting is also done when Alt-Tabbing through windows. This is not so uncommon. With good feedback indicating cursor was moved it shouldn't be problem. > It's probably a good idea to have the controls appear when the pause > hotkey is clicked, too. Depends on hotkey. > > IMO when pointer is over menu timer should be hold. Configurable is > > the best :) > > But do usabililty testing for the default :-) > Behaviour should default to other elements of desktop. Kicker is IMO the best to follow: Keep visible when pointer is on it, hide after timeout, when not. > > Not sure here. Maybe treat last element as ten elements. If cursor > > key > > will be pressed down for some time it will jump to first/last element? > > Possibly, but I expect that holding the opposite key down will get you > back just as fast, but without the unexpected behaviour of holding the > key down a bit too long suddenly sending you to the other side. After few times it will be known. OTOH I knew some completely untrainable users :/. OK, maybe without wrap is good solution. m. |
From: John M. <jw...@es...> - 2004-05-26 14:55:44
|
On Thu, 27 May 2004 00:45, Mikolaj Machowski wrote: > Dnia =B6roda, 26 maja 2004 04:08, John Morton napisa=B3: > But it will trigger only where menu/taskbar is.=20 That's good. That's where you'll be. And if the most frequently used button= is=20 on the corner of the toolbar, that's the corner people will usually aim for= =2E=20 > Users will move pointer to the side. Also triggering by corner isn't ve= ry > intuitive. It's not unfortunately, though kicker uses it, which means KDE desktop user= s=20 will understand that it exists as a target. But it's ok, as it's not the on= ly=20 means to pop up the controls, as you can use the left mouse button, enter, = or=20 some other action key, which is the first thing they're likely to try. But = if=20 they bother to read the tool tips (and I think I can say everything that=20 needs to be said about basic full screen interface usage in one tool tip),= =20 then they'll know that the corners work, too, and that kicker won't pop up = if=20 they go there. > Most hidden =20 > controls in desktops are turned on by moving to the side. But this is not the desktop, it's full screen mode in a media player,=20 therefore users want to look at the whole screen and not look at the pointe= r,=20 or have it cluttered with controls - hence they'll tend to flick the pointe= r=20 to the edge. If the controls appear on the edge most likely to contain blac= k=20 bands, then there's nowhere to go but leave the pointer in the middle of th= e=20 picture - especially if the controls don't time out and disappear if the=20 pointer is over them! > Teleporting is also done when Alt-Tabbing through windows. This is not > so uncommon. With good feedback indicating cursor was moved it shouldn't > be problem. Perhaps, but a moot point if we have right mouse do pause. Then there's no= =20 rush to move the pointer about.=20 > > It's probably a good idea to have the controls appear when the pause > > hotkey is clicked, too. > > Depends on hotkey. Right mouse button, space or some second action button, in this case. Popin= g=20 up controls for pause is good, because your next action is probably to togg= le=20 some setting or move about in the stream, or you're off doing something awa= y=20 from the screen and don't care. I wouldn't pop up the controls for most oth= er=20 actions - especially not mouse wheel controled volume :-) > > But do usabililty testing for the default :-) > > Behaviour should default to other elements of desktop. Kicker is IMO the > best to follow: Keep visible when pointer is on it, hide after timeout, > when not. Possibly, but full screen isn't the desktop. On the desktop, it's ok to lea= ve=20 kicker up indefinitely when the pointer is over it because it's the natural= =20 thing to do to move the pointer to somewhere else when you've finished usin= g=20 it, and at that point you're off doing something else in some other=20 application. In a full screen mode, there's nowhere else you want to move t= he=20 pointer to except away from the controls and out of the way of the picture.= =20 Now, whether we go for 'controls are always up when the pointer is over the= m',=20 or 'controls disappear after a long timer, when the pointer is stationary=20 over them' in part depends on whether we go for 'edge of screen pixels pop = up=20 the controls'.=20 If we go for both of your preferences, the consequences are that the user= =20 must move the pointer away from the controls to make them disappear, but th= ey=20 can't move it to the remaining edge, as that will cause it to pop up again,= =20 so they're stuck with moving to the middle to have it hover over the pictur= e=20 like a fly on the screen for three or four seconds. And the moment the mous= e=20 registers enough movement to move the pointer by a single pixel, up it=20 appears again. We could make the edges that don't have controls adjacent to= =20 them not activate the popup, but they will tend to be the edges with pictur= e,=20 as the controls will tend to be on the edges with black bands.=20 Conversely, the only reason not to have a long timeout on the controls is t= hat=20 the user manages to hover the pointer, dead stationary, over the controls f= or=20 longer than the timeout when they still wanted to do something. If we can=20 find a timeout period long enough that 95% of the users never experience=20 that, because they've managed to get on with it and do their thing in time= =20 without feeling any presure to keep moving, it's going to be a win.=20 > > > Not sure here. Maybe treat last element as ten elements. If cursor > > > key > > > will be pressed down for some time it will jump to first/last > > > element? > > > > Possibly, but I expect that holding the opposite key down will get you > > back just as fast, but without the unexpected behaviour of holding the > > key down a bit too long suddenly sending you to the other side. > > After few times it will be known. OTOH I knew some completely > untrainable users :/. OK, maybe without wrap is good solution. Ha! That's exactly what I've just said about corner targets :-) In this case, we're talking about five to ten items on the tool bar, and le= ss=20 on the menu bar, so having a 10 step 'punch through' to the other side woul= d=20 actually be a bit slower than just holding down the other key, but it would= =20 surprise someone who wasn't expecting it, and that would cause them to slow= =20 down their button navigation, which is not something we want to discourage.= =20 But the same effect on a playlist, or some other listing that can have tens= to=20 hundreds of entries - that would be a win. John |
From: Mikolaj M. <mi...@wp...> - 2004-05-27 16:40:31
|
Dnia środa, 26 maja 2004 16:55, John Morton napisał: > On Thu, 27 May 2004 00:45, Mikolaj Machowski wrote: > > Dnia środa, 26 maja 2004 04:08, John Morton napisał: > > > > But it will trigger only where menu/taskbar is. > > That's good. That's where you'll be. And if the most frequently used > button is on the corner of the toolbar, that's the corner people will > usually aim for. Are aiming because there is the most used button. But on taskbar are other, also used functions. BTW I am using hiding kicker and usually, even when 'going' to K-Menu I am hitting edge of screen, then go to the corner when I see the target. > > Users will move pointer to the side. Also triggering by corner isn't > > very intuitive. > > It's not unfortunately, though kicker uses it, Kicker uses triggering by edge. > which means KDE desktop > users will understand that it exists as a target. But it's ok, as it's > not the only means to pop up the controls, as you can use the left mouse > button, enter, or some other action key, which is the first thing they're > likely to try. But if they bother to read the tool tips (and I think I > can say everything that needs to be said about basic full screen > interface usage in one tool tip), then they'll know that the corners > work, too, and that kicker won't pop up if they go there. It assumes user _will_ read tooltip... > > Most hidden > > controls in desktops are turned on by moving to the side. > > But this is not the desktop, it's full screen mode in a media player, > therefore users want to look at the whole screen and not look at the > pointer, or have it cluttered with controls - hence they'll tend to flick > the pointer to the edge. If the controls appear on the edge most likely > to contain black bands, then there's nowhere to go but leave the pointer > in the middle of the picture - especially if the controls don't time out > and disappear if the pointer is over them! OK > > Teleporting is also done when Alt-Tabbing through windows. This is not > > so uncommon. With good feedback indicating cursor was moved it > > shouldn't be problem. > > Perhaps, but a moot point if we have right mouse do pause. Then there's > no rush to move the pointer about. And you want to show controls when pause? > > > It's probably a good idea to have the controls appear when the pause > > > hotkey is clicked, too. > > > > Depends on hotkey. > > Right mouse button, space or some second action button, in this case. > Poping up controls for pause is good, because your next action is > probably to toggle some setting or move about in the stream, or you're > off doing something away from the screen and don't care. I wouldn't pop > up the controls for most other actions - especially not mouse wheel > controled volume :-) Here should be some OSD. > > > But do usabililty testing for the default :-) > > > > Behaviour should default to other elements of desktop. Kicker is IMO > > the best to follow: Keep visible when pointer is on it, hide after > > timeout, when not. > > Possibly, but full screen isn't the desktop. On the desktop, it's ok to > leave kicker up indefinitely when the pointer is over it because it's the > natural thing to do to move the pointer to somewhere else when you've > finished using it, and at that point you're off doing something else in > some other application. In a full screen mode, there's nowhere else you > want to move the pointer to except away from the controls and out of the > way of the picture. OK > Now, whether we go for 'controls are always up when the pointer is over > them', or 'controls disappear after a long timer, when the pointer is > stationary over them' in part depends on whether we go for 'edge of > screen pixels pop up the controls'. > > If we go for both of your preferences, the consequences are that the > user must move the pointer away from the controls to make them disappear, > but they can't move it to the remaining edge, as that will cause it to > pop up again, so they're stuck with moving to the middle to have it hover > over the picture like a fly on the screen for three or four seconds. And > the moment the mouse registers enough movement to move the pointer by a > single pixel, up it appears again. We could make the edges that don't > have controls adjacent to them not activate the popup, but they will tend > to be the edges with picture, as the controls will tend to be on the > edges with black bands. In my scenario only two out of four edges are occupied. > Conversely, the only reason not to have a long timeout on the controls is > that the user manages to hover the pointer, dead stationary, over the > controls for longer than the timeout when they still wanted to do > something. If we can find a timeout period long enough that 95% of the > users never experience that, because they've managed to get on with it > and do their thing in time without feeling any presure to keep moving, > it's going to be a win. 5-10s ? m. |
From: <jue...@ch...> - 2004-05-30 13:40:29
|
Hi John, > On Thu, 27 May 2004 00:45, Mikolaj Machowski wrote: > > Dnia =B6roda, 26 maja 2004 04:08, John Morton napisa=B3: > > > > But it will trigger only where menu/taskbar is. > > That's good. That's where you'll be. And if the most frequently used butt= on > is on the corner of the toolbar, that's the corner people will usually aim > for. > > > Users will move pointer to the side. Also triggering by corner isn't > > very intuitive. > > It's not unfortunately, though kicker uses it, which means KDE desktop > users will understand that it exists as a target. But it's ok, as it's not > the only means to pop up the controls, as you can use the left mouse > button, enter, or some other action key, which is the first thing they're > likely to try. But if they bother to read the tool tips (and I think I can > say everything that needs to be said about basic full screen interface > usage in one tool tip), then they'll know that the corners work, too, and > that kicker won't pop up if they go there. > > > Most hidden > > controls in desktops are turned on by moving to the side. > > But this is not the desktop, it's full screen mode in a media player, > therefore users want to look at the whole screen and not look at the > pointer, or have it cluttered with controls - hence they'll tend to flick > the pointer to the edge. If the controls appear on the edge most likely to > contain black bands, then there's nowhere to go but leave the pointer in > the middle of the picture - especially if the controls don't time out and > disappear if the pointer is over them! > > > Teleporting is also done when Alt-Tabbing through windows. This is not > > so uncommon. With good feedback indicating cursor was moved it shouldn= 't > > be problem. > > Perhaps, but a moot point if we have right mouse do pause. Then there's no > rush to move the pointer about. > > > > It's probably a good idea to have the controls appear when the pause > > > hotkey is clicked, too. > > > > Depends on hotkey. > > Right mouse button, space or some second action button, in this case. > Poping up controls for pause is good, because your next action is probably > to toggle some setting or move about in the stream, or you're off doing > something away from the screen and don't care. I wouldn't pop up the > controls for most other actions - especially not mouse wheel controled > volume :-) > > > > But do usabililty testing for the default :-) > > > > Behaviour should default to other elements of desktop. Kicker is IMO t= he > > best to follow: Keep visible when pointer is on it, hide after timeout, > > when not. > > Possibly, but full screen isn't the desktop. On the desktop, it's ok to > leave kicker up indefinitely when the pointer is over it because it's the > natural thing to do to move the pointer to somewhere else when you've > finished using it, and at that point you're off doing something else in > some other application. In a full screen mode, there's nowhere else you > want to move the pointer to except away from the controls and out of the > way of the picture. > > Now, whether we go for 'controls are always up when the pointer is over > them', or 'controls disappear after a long timer, when the pointer is > stationary over them' in part depends on whether we go for 'edge of screen > pixels pop up the controls'. > > If we go for both of your preferences, the consequences are that the user > must move the pointer away from the controls to make them disappear, but > they can't move it to the remaining edge, as that will cause it to pop up > again, so they're stuck with moving to the middle to have it hover over t= he > picture like a fly on the screen for three or four seconds. And the moment > the mouse registers enough movement to move the pointer by a single pixel, > up it appears again. We could make the edges that don't have controls > adjacent to them not activate the popup, but they will tend to be the edg= es > with picture, as the controls will tend to be on the edges with black > bands. > > Conversely, the only reason not to have a long timeout on the controls is > that the user manages to hover the pointer, dead stationary, over the > controls for longer than the timeout when they still wanted to do > something. If we can find a timeout period long enough that 95% of the > users never experience that, because they've managed to get on with it and > do their thing in time without feeling any presure to keep moving, it's > going to be a win. > > > > > Not sure here. Maybe treat last element as ten elements. If cursor > > > > key > > > > will be pressed down for some time it will jump to first/last > > > > element? > > > > > > Possibly, but I expect that holding the opposite key down will get y= ou > > > back just as fast, but without the unexpected behaviour of holding > > > the key down a bit too long suddenly sending you to the other side. > > > > After few times it will be known. OTOH I knew some completely > > untrainable users :/. OK, maybe without wrap is good solution. > > Ha! That's exactly what I've just said about corner targets :-) > > In this case, we're talking about five to ten items on the tool bar, and > less on the menu bar, so having a 10 step 'punch through' to the other si= de > would actually be a bit slower than just holding down the other key, but = it > would surprise someone who wasn't expecting it, and that would cause them > to slow down their button navigation, which is not something we want to > discourage. > > But the same effect on a playlist, or some other listing that can have te= ns > to hundreds of entries - that would be a win. I had no time to follow the whole discussion but sounds all good. I rarely = use=20 the fullscreen mode, because i always watch my DVDs with my hardware player= =20 (lying on my couch in front of the the tv-set and drinking some beer :-).=20 I'm looking forward for a patch ;-) regards J=FCrgen |
From: John M. <jw...@es...> - 2004-06-02 08:30:24
|
On Fri, 28 May 2004 02:09, Mikolaj Machowski wrote: [Edge versus corner popup activation of controls] I think we could go back and forth over the pros and cons of both, but I think this is something where usability testing is really in order to solve the problem. Fortunately, deciding on which of corner or side, and how long the control hiding timeout should be are details, so once we've coded up the implementation that makes both happen, it should be straight forward to test different profiles out on people. John |
From: John M. <jw...@es...> - 2004-06-02 08:45:56
|
On Mon, 31 May 2004 01:40, J=FCrgen Kofler wrote: > I had no time to follow the whole discussion but sounds all good. I rare= ly > use the fullscreen mode, because i always watch my DVDs with my hardware > player (lying on my couch in front of the the tv-set and drinking some be= er > :-). I'm looking forward for a patch ;-) Unfortunately I'm lacking in both C++/KDE-fu and time at the moment - that'= s=20 why I decided to post a design, in the hopes that someone else would make a= =20 start :-) Maybe you can give me some pointers to get going, though - a look at the co= de=20 for the FullScreenPanel class shows there's some sort of toolbar set up, bu= t=20 I have no idea where the keyboard event connected to it happens, nor where= =20 the mouse event connected to the popup menu happens. If you could provide=20 some illumination I might be able to get a start. John |