Bug 2564 - No consistency on scrolling/scrollbars in bundled OS2008 applications
: No consistency on scrolling/scrollbars in bundled OS2008 applications
Status: RESOLVED FIXED
Product: UI Specification
General
: 4.0
: ARM Linux
: Low normal with 12 votes (vote)
: 5.0 (1.2009.41-10)
Assigned To: Mikko Nurmi
: ui-specification-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2007-12-15 16:14 UTC by Andrew Flegg
Modified: 2008-10-27 08:12 UTC (History)
5 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Andrew Flegg (reporter) maemo.org 2007-12-15 16:14:59 UTC
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.
Comment 1 Andrew Flegg (reporter) maemo.org 2007-12-15 16:54:21 UTC
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.
Comment 2 Roope Rainisto nokia 2007-12-17 12:10:29 UTC
Yes, we are aware of this and actively working on this issue.
Comment 3 Eero Tamminen nokia 2008-01-08 14:32:43 UTC
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?  :-)
Comment 4 Andrew Flegg (reporter) maemo.org 2008-01-08 15:20:06 UTC
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.
Comment 5 Andrew Flegg (reporter) maemo.org 2008-01-27 11:32:12 UTC
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).
Comment 6 Quim Gil nokia 2008-06-19 11:43:54 UTC
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.
Comment 7 Quim Gil nokia 2008-07-03 10:58:06 UTC
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.  :)
Comment 8 Andrew Flegg (reporter) maemo.org 2008-07-09 15:00:02 UTC
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.
Comment 9 Andre Klapper maemo.org 2008-07-14 13:45:19 UTC
Let's close this when the code fixing this has been checked in. This may take a
while but is more correct IMO.
Comment 10 Roope Rainisto nokia 2008-08-26 14:14:18 UTC
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.
Comment 11 Quim Gil nokia 2008-10-27 08:12:25 UTC
(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.