Comment 1 Andre Klapper 2009-10-16 18:53:29 UTC

You're not the first to complain.
What about showing the scrollbar all of the time?

This is a duplicate of bug 5426, isn't it ?

I agree that the fact that the pane is scrollable is not always clear. Maybe
increase the length of time that the scrollbar appears. I disagree with the
suggested animation, because dialogue boxes currently animate onto the screen
already, so the two animations at once might look messy and unclear to the
user.

One solution could be to have a style guide suggestion to lay things out so
that UI widgets are cropped at the bottom of the screen when the pane is
scrolled to the top, so that the user thinks "what are those things?" and
starts scrolling.

Comment 4 Andre Klapper 2009-10-26 15:19:51 UTC

Also see bug 5789 for ideas by Kees how to display "scrollability".

Comment 5 Andre Klapper 2009-10-26 15:20:12 UTC

*** Bug 5789 has been marked as a duplicate of this bug. ***

In #5789 I propose to use some gradients at the bottom and/or top of a list to
inform the user that more data is available without losing space.

Mox, any comments about this?

Comment 8 Mox 2009-11-23 18:32:25 UTC

the initial visible pan indicator is the hint we use for this in Fremantle and
that's all there is to it.

Makes no sense to overload this with additional hints.

Comment 9 Andre Klapper 2009-12-06 08:39:38 UTC

*** Bug 6607 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> the initial visible pan indicator is the hint we use for this in Fremantle and
> that's all there is to it.
> 
> Makes no sense to overload this with additional hints.
> 

This is really unhelpful. The scrollbar should always be visible if content
goes beyond screen. This is a convention people are very used to from almost
any PC application: web browsers, office applications etc.

It's very easy to miss the hint since it coincides with the dialog opening
animation and can easily be mistaken as part of it, especially in an
environment with bright lights. Like, almost everywhere where you'd use a
telephone.

Comment 12 Ryan Abel 2009-12-20 23:31:25 UTC

(In reply to comment #10)
> (In reply to comment #8)
> > the initial visible pan indicator is the hint we use for this in Fremantle and
> > that's all there is to it.
> > 
> > Makes no sense to overload this with additional hints.
> > 
> 
> This is really unhelpful. The scrollbar should always be visible if content
> goes beyond screen. This is a convention people are very used to from almost
> any PC application: web browsers, office applications etc. 
> 

PC applications require the scrollbar to scroll, we do not as the whole area is
scrollable. Different UI paradigms different UIs.

If we want to look at platforms with similar UI paradigms then look at Mobile
OS X where the indicator appears momentarily when a scrollable element first
comes up and when scrolling (i.e., exactly how Maemo does it).

So, we have a problem, the cues telling a user that the element they're looking
at is scrollable are not visible enough, causing many users to miss additional
elements off the page. What can we do to make it more apparent to users that
there is additional content to view?

My own opinion is that the least disruptive change is to increase the time the
scroll indicator remains on screen when an element appears to 2 seconds or so.
Alternatively the theming could altered to make the indicator more visible.

It appears that this bug is an unhappy coincidence of the scroll window being
exactly 2 selections high. As with comment #3 what if the UI default behavior
always shows some fraction of the next or preceding option in the scroll? This
happens for the time setting selection and some of the other dialog boxes, but
not in the profile setting.

We are not searching for the least disruptive change but for the proper, good
looking fix.

Are there any idea's(mine's?) that are good enough to "accept" as acceptable
solution?

I don't buy into the "mobile UI, different paradigm" excuse because even the
mobile UI paradigm is one where the user actually needs to see easily what can
and can not be done with the elements that are displayed. Even though the
scroll bar is not needed for scrolling, it is still quite useful to see which
part of a larger display is visible on screen at any given time. Having to
actually scroll to get access to this information is a step back, and unlike on
a desktop computer, it will actually obscure part of the screen on a mobile
touch screen device.


Mobile OS X has two main ways of indicating scrolling. The one that is used in
the web browser and the settings is similar to Maemo's as mentioned above, but
there are two small but important differences:

- In Maemo, you open a panel with a scrolling list. Opening the panel is
animated. The scroll bar is visible from the start and then quickly disappears.
The bar is rectangular and appears at the top right of the panel directly at
the panel's border.

- In Mobile OS X, you open a panel with a scrolling list. Opening the panel is
animated. Once the panel is open, the display becomes calm briefly. *Then*, the
scroll bar appears, and then quickly disappears. This makes it easier to see it
as a separate element instead of part of the opening animation. The bar is
rounded and offset from the border of the screen, so it is more distinctly
drawn as a UI element. It can also overlap text or other graphics due to its
position so it is more disturbing, and thus easier to notice.

The other way that Mobile OS X uses is a gradient over the top or bottom of the
list, or both, according to which directions it can be scrolled in. IMHO this
is a generally good way because it looks sleek, visually resembles a familiar
concept of a rotating dial, and uses no screen space at all. However, Mobile OS
X only uses this for a small subset of the lists it displays. It would be
interesting to see it used generally.


The Android scroll bar is more pronounced and even has a separate distinct
background. As such, it serves very well as an indicator of which part of the
document is visible, because you can quickly grasp how much of the document is
above or below (or to the left or the right of) the visible area.


I agree that with regard to the profile settings, this is probably an
unfortunate coincidence with panels that don't look like they continue below
the screen. I couldn't find one in Mobile OS X that did. However Mobile OS X
draws lists and groups in their own rounded frames and things like that, so it
is easier to avoid the problem on that platform due to the added fluff. At any
rate IMHO it would be an improvement to not hide the scroll bar. My ideal
scroll bar would be visible at all times and have its own distinct background,
but this is probably going a bit farther than Nokia would want to implement?

The scrollbar is briefly visible when the screen is first shown and then
flashes up again every tie you touch the screen - surely it wouldn't be too
difficult to change this behaviour so that the scrollbar is there permanently
if the content is bigger than one screen. That would be the most practical and
elegant solution.

Comment 17 Neil MacLeod 2009-12-21 13:56:34 UTC

Personally speaking, as a right-handed user I think the scrollbar would be much
easier to spot if it were shown on the left side of a dialog.

Almost all dialogs have their content on the left so that's where my vision is
focused, while the right hand side of the dialog is mostly obscured by my
finger or hand which wouldn't be an issue if the dialog contained only the
commit/cancel/action buttons, but when my hand also obscures the thin and
momentarily visible scrollbar it often means I miss it completely so I have to
position my hand unnaturally in order that I can see the scrollbar when it
briefly appears.

Obviously this situation may have to be reversed for left handed users, and it
may also seem "odd" to have a scrollbar on the left when most people are used
to having a scrollbar on the right.

I wonder if people who use their left hand to touch the screen suffer from the
same scrollbar problems as right handed users?

Very confusing especially in configuration settings. There are lots of
questions on Talk  Maemo related to email configuration as people have not
scrolled down to see all of the options, and then complain that such and such a
feature is missing.

We have agreed to make the indicator visible for a longer time and to make it
slightly more obvious. Will be fixed in some form or manner in pr1.2.

Working on it now

Comment 21 Andre Klapper 2010-01-15 18:49:34 UTC

*** Bug 8019 has been marked as a duplicate of this bug. ***

I've just fixed this in the hildon-widgets repository (master and hildon-2-2
branches).

http://maemo.gitorious.org/hildon/hildon/commits/8f4f39dbdefe5d5e422c569ec5a09aad94e209b6

This will be available in libhildon 2.2.12

Comment 23 Andre Klapper 2010-02-17 21:15:56 UTC

This has been fixed in package
libhildon 2.2.12-1+0m5
which is part of the internal build version
10.2010.06-14
(Note: 2009/2010 is the year, and the number after is the week.)

The panning indicator now is visible for a bit longer duration as compared to
previous releases.

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 24 Andre Klapper 2010-03-15 20:53:45 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).