maemo.org Bugzilla – Bug 5496
HildonTouchSelector: No hint that there are more items
Last modified: 2010-03-15 20:53:45 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: (Control Panel > General > About product) 5.0 (1.2009.41-10) STEPS TO REPRODUCE THE PROBLEM: 1. Open Settings -> Profiles It seems there are only "two options": Silent and General EXPECTED OUTCOME: - scrollable dialogs are shown as such, like by a anytime visible scrollbar ACTUAL OUTCOME: - scroll-bar appears only for a short moment REPRODUCIBILITY: always in certain circumstances (depend on UI size). It occurs, when all without scrolling visible elements fit perfect to the panel area and no widget is "cropped/cut". OTHER COMMENTS: I understand that you want keep the design clean and beautiful and might had big discussions internally about showing or not showing the scrollbar permanent. I would recommend to able a small animation, if you open a dialog with scrollable area. the list opens with the top element hidden and scrolls up until bounce against the border. this animation should of course only take a short time, maybe 0.25s. Only to make visible for the user, that you can scroll it. Maybe this is hard to implement. In such case I would suggest to show the scrollbar a little bit longer. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.0.14) Gecko/20080528 Epiphany/2.22 Firefox/3.0
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.
Also see bug 5789 for ideas by Kees how to display "scrollability".
*** 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?
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.
*** 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.
(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.
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
*** 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
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/
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).