Bug 2948

Summary: Wifi AP list scrolls too fast
Product: [Maemo Official Platform] Connectivity Reporter: maemo
Component: WiFiAssignee: unassigned <nobody>
Status: RESOLVED FIXED QA Contact: wifi-bugs
Severity: enhancement    
Priority: High CC: andre_klapper, bugzilla770, maemo, quim.gil
Version: 4.1.3 (5.2008.43-7)   
Target Milestone: 5.0 (1.2009.41-10)   
Hardware: All   
OS: Linux   

Description maemo (reporter) 2008-02-15 08:55:19 UTC
SOFTWARE VERSION:
2-2007-50-2

STEPS TO REPRODUCE THE PROBLEM:
View a large (8+) list of available access points from the "Select connection"
window.

EXPECTED OUTCOME:

The list of access points should be static, or update slowly, allowing the user
to select their access point.

SUGGESTED ENHANCEMENT:

As soon as the user begins scrolling within the window that displays discovered
access points, the window contents & order should be frozen--this will
eliminate the problem of having the order and listing of access points change
while the user is trying to select a "moving target" from the list. The tablet
should continue to scan for access points, and the window can be refreshed
manually via the addition of a "refresh" button at the bottom of the window.
The refresh button should remain greyed out unless the order or number of
access points has changed.


ACTUAL OUTCOME:
Depending on the number of access points and the connection strengths (as well
as the overall CPU load on the tablet), the list will update--and change
order-- faster than the user can select the desired access point.

REPRODUCIBILITY:
always (subject to the number of access points available)

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.10)
Gecko/20071128 Microsoft/1.5.2 Firefox/1.5.2
Comment 1 Jake Kunnari 2008-02-15 13:18:16 UTC
Changed to Enhancement and Quim added to CC
Comment 2 Quim Gil nokia 2008-12-31 03:07:26 UTC
I can't recall whether this was an issue in the past. However, currently
testing in the described conditions provides a refresh every 5 seconds or so,
giving time enough to select a network.
Comment 3 maemo (reporter) 2008-12-31 03:26:58 UTC
I believe that the refresh time (about every 5 seconds) is unchanged from when
I first reported the bug to now (I'm running IABLO_4.2008.23-14). I still claim
that the issue still exists. It is most noticible in an environment with a
large number of networks, particularly when some have low signal strengths and
are not present in every refresh. Since the sort order of the networks in the
list is unstable, the user often must view the entire list to find the desired
network. The problem is that the list may refresh after the user begins
scrolling, and the refreshed list will be in a different order, forcing the
user to scroll again, leading to a loop.

Clearly, this isn't a high priority problem, and it usually only takes 2 or 3
refresh cycles to select a network. However, just because it "worksforyou"
doesn't mean that the minor enhancement of freezing the displayed list once the
user begins scrolling is unnecessary for your customers.
Comment 4 Quim Gil nokia 2008-12-31 13:04:11 UTC
(In reply to comment #3)
> just because it "worksforyou"
> doesn't mean that the minor enhancement of freezing the displayed list once
> the user begins scrolling is unnecessary for your customers.

WORKSFORME is a status defined in bugzilla and I set it thinking that it would
work also for others. I'm not claiming it would work for everybody or for you,
but we have priorities and it is healthy to try to cut the line of things you
won't chase, to concentrate on the things you want to chase.

Nevertheless let's reopen this request and let's set HIGH visibility to gather
more feedack. 

One reason to support the WORKSFORME is that the list is perhaps unstable, but
with clear rules: first the saved connections, then the strong signal
connections, then the open connections... Those on top are always those most
likely to work for you, even if you see plenty more underneath. Tjose 5 secs
(or so) for refresh help you seeing always quite updated information. Again, no
matter what is dancing underneath those connectios are probably not for you.

About the options to improve:

a) Keep refresh rate but freeze once the user starts scrolling down. You
suggest an extra Refresh button to unfreeze, but this is probably a NoGo since
we want to keep the UI simple. Probably a longer refresh rate (15-20 secs)
would probably do. 

b) Simply delaying the refresh rate would also help users since 15-20 seconds
is probably all the time you need to scroll down. I guess this would be much
easier to implement.

DRAWBACK: a network with mild connection might be not available at all after
that longer time, increasing the possibility of frustrated connections. You
have more time to select a network in the bottom of the list but by doing this
you also get more chances to fall in long and unsuccessful attempts to connect.
Comment 5 Neil MacLeod maemo.org 2008-12-31 16:47:25 UTC
Why not update the list in a "non-destructive" way? Currently the list is
repopulated from scratch each time it is refreshed which resets the scroll
position and sort order. Why not see if it's possible to load the list once on
the first scan and then just add new items (networks) into the list as they
appear?

Networks that are not present in subsequent scans can either be left in the
list - after all, it might still be possible to connect to them - or removed
from the list by deleting the relevant entry.

Add a "Reset" button to initiate a scan with a new, empty, list (or just have
the user close the scan dialog and start again).

If the user scrolls up or down the list their position would be retained during
each scan, with new networks added/removed. Essentially a much "smoother"
experience than the current and jarring "reset list and start again with each
scan".
Comment 6 Quim Gil nokia 2008-12-31 22:44:40 UTC
(In reply to comment #4)
> One reason to support the WORKSFORME is that the list is perhaps unstable, but
> with clear rules:

Er, actually yesterday when I got a funny/fatal coincidence. The sorting rule
seems to be much simpler: saved on top and then the rest, sorted
alphabetically. Which doesn't help getting the strongest connections on top.

Checking my S60 phone the rule seems to be the same, but they seem to offer
more time between refreshes, resulting in a more 'stable' feeling.
Comment 7 Andre Klapper maemo.org 2009-06-05 22:07:09 UTC
I cannot reproduce this issue in Fremantle anymore - it seems to me that it
does not change that fast anymore. At least I have no problems here to click
the wifi that I want to use.

This is a WONTFIX for Diablo as Diablo is in maintenance mode and Nokia will
only provide bugfixes for critical issues if at all.
For your interest the Mer project aims to provide a community backport of
Fremantle for N8x0 devices. See http://wiki.maemo.org/Mer for more information.