maemo.org Bugzilla – Bug 2564
No consistency on scrolling/scrollbars in bundled OS2008 applications
Last modified: 2008-10-27 08:12:25 UTC
You need to log in before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM: * Compare scrolling the content area in: o RSS reader o Media Player o Control Panel o Browser o File Manager o RSS applet o Maps POI configuration dialogue box EXPECTED OUTCOME: * OS has a consistent, easy-to-use mechanism for scrolling content areas using fingers or stylus. * Dragging content area with finger or stylus causes the content area to scroll. * Optionally with inertial/kinetic scrolling (though this is a different enhancement request). This bug is focused on the UI breakage and confusing interface caused by having at least 4 different scroll mechanisms in the bundled applications. ACTUAL OUTCOME: Each of the applications named above has a different scrolling method. The following table summarises: ==== Scrollbar type ==== Drag to scroll Up/down buttons Thin Normal Fat --------------+--------------------------------------------------------------- RSS Reader | x x Media Player | x Browser | x x Control Panel | x File Manager | x RSS applet | x x REPRODUCIBILITY: always OTHER COMMENTS: The benefits of "drag to scroll" have been recognised in the browser and the RSS reader, but should be standard throughout the device. The RSS applet's up/down buttons should be scrapped in favour of this (no rearranging of the desktop by dragging over its content area, but this is fine). The consistent use of "drag to scroll" would also mean that precious screen estate could be freed up by using a mobile phone-style scrollbar, showing only the position (similar to that used in the RSS applet). Third party applications like Canola, Maiku, UKMP and Kagu all use "drag to scroll" very effectively. As do the browser (although it's a little tricky finding a non-active piece of the content area, with the Gecko engine) and RSS Reader in OS2008.
BTW, I forgot to say: comments of the form "CLOSED - WONTFIX: This is what the UI specification says" will cause this bug to be re-opened. If that's what the UI specification says, it's a bug in *THAT*, not the implementation. The implementation of all these different scrolling mechanisms seems, on the whole, to be fine. It's the fact there *are* all these different scrolling mechanisms which is the bug: 1) Copying the desktop metaphors and then just making stuff bigger is not a suitable approach to having a usable finger-friendly device. 2) Many different mechanisms for scrolling, with little to no consistency within the *bundled* applications is not a suitable approach to having a usable, consumer-friendly device.
Yes, we are aware of this and actively working on this issue.
Hm. The table seems to have a slight error, everything *else* except RSS applet have up/down arrows in the scrollbar. The reason why it doesn't have arrows, is that it's not a scrollbar, it's just a position indicator. Another difference in the RSS applet is that its list focus/selection wraps around at top&bottom whereas in all others it doesn't. And when talking about lists, menus could also be thought as lists. Too long Task Navigator menus have both scroll arrows at the bottom (similarly to RSS applet), but normal Gtk menus have separate arrow in both ends of the menu. It would be good to have also a proposal how all these would be harmonized. Surely you don't want thumbable scrollbars like the one in mediaplayer everywhere? :-)
By "arrows" I meant separate arrows for scrolling, rather than the usual header/footer of scrollbars. This would be the two buttons from the right on the toolbar of the RSS applet. Your point about even more inconsistency when it comes to considering menus is acknowledged, and gratefully received (it adds even more weight to the bug report). My preference for resolving this, after careful consideration and comparison with EPOC R5; desktop OSes and the variety of mechanisms in use in Maemo and its applications would be the combination of: 1) A thin scrollbar similar to that used in the RSS home applet to indicate position and size of viewport. 2) Drag to scroll, with an inertial element, as implemented in the third party application MediaBox. (1) would free up more screen real estate in both full and non-full screen modes. I would imagine this to be implemented at the Gtk container/widget level so that all current scrollable widgets would implement the same behaviour (and the "fat scrollbar" option removed). The OpenMoko project has implemented a drag-to-scroll Gtk widget, designed for finger use. This deserves further investigation. Drag-to-scroll may introduce problems with dragging to select multiple items. Various options are possible here: 1) Have different portions of the list act differently (i.e. two columns overlaid on the list: one which selects when dragged, one which scrolls). 2) Have a double-tap drag mean select, rather than scroll. This is the expected behaviour in the Web browser and my own personal preference at the moment. 3) Have some other modifier or switch temporarily activate selection, rather than scrolling. For example, holding down KP_Enter (the centre of the d-pad) and then dragging could work well. However, IMHO multiple selection is a much less primary use-case than scrolling, and so scrolling should have the easiest and most consistent interface.
Some information from the moblin mailing list on how application developers there can take advantage of OpenMoko's scroll widget without having to hack their glade files: http://www.moblin.org/pipermail/dev/2008-January/001291.html Even there they haven't got the option of getting it for free, so automatically turning all GtkScrolledWindows into OpenMoko-style finger scrollers would give maemo developers an edge, and ensure that ported applications are consistent with the built-in software on ITOS (hopefully).
Moving to better location. I believe Diablo improves the situation a bit. However is in Fremantle where all the UI is required to be fully consisten and ready for finger use.
This will be fixed in Fremantle. We can't discuss much details at this stage but if you trust the statement above we can resolve this bug as Fixed - Target milestone Fremantle. And make room for another bug in the ranking of most popular bugs. :)
Assigning bug, not sure I want to resolve it until a "fix is committed to the tree and tested". If there are Fremantle builds internally which do fix this, please feel free to resolve. Until the plan item is developed, I'd say it should stay open - it could drop off the plan and yet still be resolved, otherwise.
Let's close this when the code fixing this has been checked in. This may take a while but is more correct IMO.
Yes, there will be major fixes to this issue in Fremantle. As with any bug that is so general, the definition of a 100% fix is very hard. But it is certainly one of the key improvement areas.
(In reply to comment #9) > Let's close this when the code fixing this has been checked in. This may take a > while but is more correct IMO. After a second thought I disagree. This is a UI Spec bug and we are saying that the UI Spec in Fremantle is clear about providing consistency on scrolling. This alone fixes the bug with a Fremantle target milestone. If then you find specific cases where this spec is infringed, please file bugs against those cases.