GNOME Bugzilla – Bug 658946
poor layout of network menu
Last modified: 2012-08-08 22:24:52 UTC
Created attachment 196394 [details] screenshot When I first start the network menu on a new install it isn't a very good experience. It looks like the attached. There are a number of problems here. Should be sorted by strength not name in the main section, should only show those with significant strength or previously used by default. More problems in the more submenu in next shot.
Created attachment 196396 [details] more menu The more menu is unusable. It should include all of the low signal APs that haven't been used before sorted by name. It can't have a scrollbar this small.
(In reply to comment #0) > Created an attachment (id=196394) [details] > screenshot > > When I first start the network menu on a new install it isn't a very good > experience. It looks like the attached. > > There are a number of problems here. Should be sorted by strength not name in > the main section, should only show those with significant strength or > previously used by default. More problems in the more submenu in next shot. Sorting by strength had been explicitly rejected in the previous cycle, when the network menu was designed, as it is unreliable. Strength comes and goes even when the computer and the router are still, so the list would change randomly. Instead we sort by most-recently-used (using NM connection timestamps, which have a sensibility of a few minutes and are not updated immediately when connecting, so it's difficult to test) and then alphabetically. This said, the network menu should only offer 5 networks by default, if you see all those there's definitely a bug somewhere. I would like to know if you see something strange in .xsession-errors and if it persists across shell restarts. I would appreciate also the detailed contents of Main.panel._userMenu.network._devices.wireless.devices[0]._connections Main.panel._userMenu.network._devices.wireless.devices[0]._networks Thanks!
Rejected by whom?
(In reply to comment #3) > Rejected by whom? Sorry, I can't remember who in particular made this decision. I do remember that Dan Williams was strongly against it.
Honestly, it should not have been rejected by someone not doing the design. What we are doing now is just wrong. Just picking the first 5 access points in an alphanumeric sort is stupid. We should follow the design we made for this.
(In reply to comment #5) > Honestly, it should not have been rejected by someone not doing the design. > What we are doing now is just wrong. Just picking the first 5 access points in > an alphanumeric sort is stupid. We should follow the design we made for this. And how does that address the concerns of sorting by strength, which prevented this in the first place?
What concerns? The full list should be sorted by name but the "we think you may be interested in" list of 5 should be sorted by: you've used this, this is strong.
Except that there is just one partially hidden list. The scheme you propose would mean rearranging items when opening the submenu, I guess, and I'm not sure this would be very pleasant to see.
What rearranging?
(In reply to comment #9) > What rearranging? Strength can change on the fly while the menu is open, which would mean that either the menu becomes unsorted if kept open (not a big deal for UI, probably, but pretty complex to code) or that you always keep it sorted by rearranging items, even if it is open and visible to the user. (Yes, the menu is not build on the fly when opened, it is always there, just hidden. I am starting to think that, given all the bugs with the order and the number of visible/hidden items, I could refactor that code. Maybe it would even improve performance.)
Access points can also appear and disappear. Which I think it just as likely as strength changes. The part that should be strength ordered is the suggested part (up to 5 or so). I don't think we really need to change the order of that list after the menu is displayed. Pick the top 5 (current, previously used, and strong in that order) and keep them. Order the More by name and add/remove as they appear/disappear (in a non-jarring way).
Created attachment 208569 [details] all networks shown
Created attachment 208570 [details] random
I attached two screenshots showing the problem. In the first one all networks are shown but, obviously, there are networks that can't be reached, and I can't reach the "More" button or the VPNs either. In the second one, there are four networks, the "More" button (and menu), two networks, and then the VPNs.
I suppose (hope!) these are from 3.2.*. I reworked the menu code since that, and the layout should be stable (5 + more) in 3.3.*.
Yes, they're from 3.2; sorry for not stating it.
(In reply to comment #15) > I suppose (hope!) these are from 3.2.*. I reworked the menu code since that, > and the layout should be stable (5 + more) in 3.3.*. I've regularly see the network menu fail in 3.3.90, but to a different cause: the "More" subsection not having a scrollbar.
(In reply to comment #17) > (In reply to comment #15) > > I suppose (hope!) these are from 3.2.*. I reworked the menu code since that, > > and the layout should be stable (5 + more) in 3.3.*. > > I've regularly see the network menu fail in 3.3.90, but to a different cause: > the "More" subsection not having a scrollbar. Ah! Interesting... Never saw that in the network menu, only in the apps menu extension, but I attributed that to the interaction of multiple submenus. Going to debug this a bit...
OK, found one case where this happens (open another menu, then mouse over or keynav to the network menu or apps extension menu). Not sure if others are affected.
Created attachment 208618 [details] [review] PanelMenuButton: set max-width every time the menu is opened Previously, PanelMenuButton would only set max width if the user explicitly clicked the menu button, resulting in submenus without scrollbars if opened via keyboard navigation or mouse over.
Review of attachment 208618 [details] [review]: What's this about max-width? (Commit message says max-width, but code is about max-height)
Ping, are you going to push this?
Comment on attachment 208618 [details] [review] PanelMenuButton: set max-width every time the menu is opened Attachment 208618 [details] pushed as ff92d96 - PanelMenuButton: set max-width every time the menu is opened Leaving open, as this was a originally a design bug.
Giovanni, is there a way we could test sorting by strength in the shortlist? Could you rustle up a patch?
Created attachment 215212 [details] [review] NetworkMenu: (experimental): sort wifi networks by strength Sorting by strength is what the other OSes do by default, and it provides a better UX (by offering your hotspot and router before the one from your neighbor).
(In reply to comment #25) > Created an attachment (id=215212) [details] [review] > NetworkMenu: (experimental): sort wifi networks by strength > > Sorting by strength is what the other OSes do by default, and it > provides a better UX (by offering your hotspot and router before > the one from your neighbor). Thanks Giovanni, that's fantastic! I'll get a build going so I can test this.
Seems to work fine in my quick testing. We should do the same sorting in the network panel so the two lists appear similar.
Btw, the network panel could do something similar to what other Android does, and instead of using a combobox with visible networks it could show a treeview with both visible and stored networks, possibly with profile (connection) name. This would allow to change settings without connecting (this is a requirement because it could be impossible to connect if settings are wrong) and to "forget" a network that is not actively used.
I would love to have this landed
Review of attachment 215212 [details] [review]: Code looks fine to me if this is the UX we want. ::: js/ui/status/network.js @@ +1113,3 @@ + // place stronger connections first + if (oneStrength != twoStrength) + return oneStrength < twoStrength ? +1 : -1; No unary +. @@ +1310,2 @@ _createAPItem: function(connection, accessPointObj, useConnectionName) { + let item = new NMNetworkMenuItem(accessPointObj.accessPoints[0], useConnectionName ? connection._name : undefined); This needs to be updated.
I've been testing the patch for a while now, including while in Hong Kong (never was there a place with more wi-fi networks). The stability of the list seemed fine to me - there was only one or two occassions where items moved around, and it never felt intrusive.
Pushed then.
Thanks Giovanni!
This was one of the most important Gnome Shell bugs (from a personal point of view), thank you!
I really think this is a case of "But signal strength works in my case so it must be correct!!". But alphabetical sorting *always* works, because you always know the name of the AP you're connecting to. Because either you set it up (your house) or you found out the name from a table placard or the hotel concierge. Two points here, which I've argued before. 1) When I'm in the front of my house, my neighbors WiFi is stronger than mine, which is in the back of the house. It's certainly not a given that any given hotspot will be stronger. Mine: Upstairs: 86% Front porch where I watch TV: - Mine: 37% - usiw_secure: 47% (a wifi hotspot on a lamp-post on the street) - Hawkins Private Network: 44% (I have no idea who's this is) 2) when you're not in your house, how do you find out what hotspot to connect to? At a coffee shop you certainly don't use signal strength, since it's likely that the hotspots of the businesses on either side and upstairs and across the street are visible, and may even be stronger. Plus the people using Android phones with WiFi hotspot are likely stronger than the coffee shop wifi. You see the sign on the wall that says "Starbucks Wifi" and you look for that in the menu. The point being that just because an AP is stronger, that doesn't guarantee that it'll be the one you want. Instead, I'd suggest perhaps sorting by signal strength, and then sorting anything in the top 5 or 10 alphabetically.