October 16
Refresh in reactive displays
In the web world every browser needs a refresh button because the main protocol (http) doesn’t allow for the web browser client to know if there were changes made on the remote end. Lots of MacGyver like fixes using AJAX are built to accommodate the fact that the web is stateless and yet we use it for almost everything even though it’s probably not the best protocol out there, just the most pervasive. The lack of state change events coming from the remote http server makes the system non-reactive and the user interface becomes a static copy of what we asked the server for, thus we have to refresh and poll the server for changes.
When the system behind the user interfaces are reactive the user interface should be a dynamic representation of the system and thus a refresh/reload system doesn’t actually make much sense, and in fact it can be a bad thing. Take the mockup below as an example, it’s the NetworkManager applet with a refresh button packed tightly into the menu. (this is not a good thing)
bad idea
A refresh button like this is tempting for people to add to the interface because it might help work around some of the networking bugs current Linux systems have. However a button like this is not helpful for everyone, it actually erodes away at the experience of NetworkManager (NM).
Reactive Back end
Network Manager is controlling the wireless card in your computer to scan for new networks when most appropriate, finding new networks as they become available. Both types of scanning, passively and actively, are governed by Network Manager in order to be friendly to the access points and wireless networks around you as well as give you the most up to date list of available networks. So NM effectively acts as the proxy to the polling system that happens in your wireless card, delivering a stateful display.
Because NM is providing this kind of reactive back end to wireless networking our display interface (nm-applet) can be fairly simple since everything is just a dynamic representation of what’s out there. Assuming NM is working as it should be the list of networks shown in the applet is always going to be the full list of available networks. Using a refresh button on this kind of dynamic display starts to change that view.
Putting You to work
Since our interface is assuming that NM is always presenting us with all the available networks there is no need for a refresh button. It’s actually just making you work a little more when that work should be inside of NM itself. The one-two step interaction of clicking on the applet to view the wireless networks and then choosing from the available networks becomes a two-three(-repeat) step system where you have to open the applet and click refresh (because you can’t be certain anymore that the applet is showing the correct list), then opening the applet again to see what changes.
Why is it a bad thing to have a refresh button in a reactive display? Because it creates an unneeded inconsistency in the interface. When you look at the mockup above you can’t know if those networks are all that are available… until you hit the refresh button. The refresh button creates an inconsistency by making you think there’s extra work to be done before you can assume there are no other wireless networks. Without the refresh button you have to assume there are no more networks available, of course there’s no way of knowing if NM is looking for more networks or not (more on that below).
Where things go wrong…
Most of the issues in this area of wireless networking on Linux come from systems not telling NM to suspend, sadly your distro is somewhat responsible for making this happen. There are lots of other possible problems through the whole stack from wireless tools to driver support that can make things not work well. 
But in the end the fixes need to go down into the networking stack to instead of up in the user interface.
Aren’t we still missing something?
So where did we go wrong? Feedback. (often the right answer in interaction design)
The Network Manager applet does lack in user visible feedback during an active scan. When you don’t have a network, either after booting up or resuming, you don’t know if network manager is scanning for new networks. I’m usually left wondering what it’s doing until it connects to something. It would make sense to have some kind of feedback in the applet that indicates it’s currently scanning for wireless networks while you don’t have one (scanning while you are connected to a network isn’t that interesting).
Can we tell how old the data is? Can we just say “20 seconds old” or “2 minutes old” or something? That might lead to someone asking for a refresh button, though.
A refresh button is actually the single thing I miss the most from networkmanager. It’s really annoying that you can’t see networks on other channels when it’s logged onto a wlan.
The list of networks on the _current_ channel is useless.
An alternative to the refresh button could be an entry such as “More …” at the end of the list of networks.
That entry would open a dialog window with some advanced features such as :
– a refresh button.
– hide/show the networks in the applet list and prevent/allow automatic login. I once logged by mistake on my neighbor’s unprotected network and after that NM would automatically choose it by default. I think that I had to manually remove the keys in gconf. Annoying!
– prioritize the available networks (e.g. chose my high speed private network instead of my low speed guest hotspot).
– manage the stored password (clear, show, …).
– show the encryption protocol and the channel for each network.
Blizzard: There’s an issue if you’re actively looking for a new network that you might want to know if NM is still scanning or has scanned everything and what it shows is all that’s available. A little feedback about if it’s scanning or not should relate how old the information is.
Anders: That sounds like a driver issue, it really has nothing to do with NM. Network Manager would send a request for a passive scan while you’re associated to a wlan, however if your driver is broken it won’t honor that request and you’ll have to un-associate.
Stephane: I have some mockups of how to not always connect to networks like that. I was planning on posting them soon. http://www.gnome.org/~clarkbw/designs/network-manager/
Bryan: How does the hardware do that? How does the card do a passive scan on another channel, than the one it’s currently tuned in at? I have two problems with it:
1) I have never seen a Linux-laptop show networks on other channels while attached to a network – but maybe I’m just unlucky.
2) I can’t wrap my head around how a single-radio card can listen on two channels simultaneously – which must be needed for uninterrupted wlan on one channel and a passive scan on another channel.
Sigh… I was going to make a feature request for a Refresh button. I thought it’d be better to have it there until NM works 99,99% of time. Which, sadly, isn’t the case for me (and for many other people) currently. Please please add it – maybe not a button, but some other control that would allow me to tell NM “please do scan the available networks now”. Otherwise the users for whom NM doesn’t work are effectively punished
A quick and dirty alternative to the refresh button would be to start the refresh process when one click the NM icon(?)
Anders: Dan explained this to me this morning because I had never understood it before. A wireless card will send a sleep packet to the AP it’s associated with which causes the AP to buffer incoming packets for the card. The card then buffers any out going packets while it switches channels and listens for activity on other channels; each channel requiring about 100ms. Once the passive scan is completed the card sends a ‘wake’ packet to the AP and they both push through any buffering they’ve been doing. I guess it’s a pretty standard system.
Artem: I know people want it because it would gloss over most of the bugs in NM, but that just leaves the bugs unfixed. As Dan pointed out in his post, we complained early on and stuck to our guns of what we wanted to do with Linux wireless networking and we’re almost there. Just a little further to go.
Bryan: Ahh, thanks for explaining. A very interesting read. I’ll shut up for now
Brian said: “I know people want it because it would gloss over most of the bugs in NM, but that just leaves the bugs unfixed.”
Sure, I can understand this motivation. But maybe some trade-off is possible? Like, for example, include the Refresh button in the UI, but every time a user clicks it, NM would log all relevant aspects of its state and then send the log to the developers for analysis when the connection is up. That way, users would get the control they want, and developers would receive the feedback they need to fix the remaining bugs. What do you think about it?
What if in the same place as the “Refresh” button in the mockup you posted, there was an animated spinner image?
http://www.napyfab.com/ajax-indicators/images/indicator.gif
On OSX, it is very common to see people constantly opening/closing/reopening the AirPort menu, waiting for networks to show up, because the menu does not automatically refresh. The Wireless Networks dialog in Windows XP also does not automatically refresh.
Letting users know that the NetworkManager list menu does automatically update and does not need to be manually closed/re-opened could make them very happy.
I’m wondering if changing the NM icon for that of a radar (maybe animated) when it’s scanning would be something informative and not too much annoying.
By the way, what is the head icon at the right of the NM one?
Bryan,
Thanks for the explanation of UI design. I think sometimes (especially in Linux land) it seems like either black magic, or that someone just threw it together.
I agree with you that some type of “scanning” feedback would be helpful. I like how the bars build as it starts to authenticate (dhcp, etc..) but often I’m left tail -f /var/log/messages to see if it’s going to work, or if my network card’s hung or stuck in an endless cycle.
The lack of a ‘refresh’ has hit me too, when I want to connect to a network that I know’s there but NM hasn’t picked up on it… I’ve often resorted to simply redefining it…. I’m sure that breaks the 1-2 step into something worse then 1-2-3… So there are definitely other ways that people are obscuring the bugs…
[...] Manager could export a signal when it is actively searching for networks. As I mentioned in the previous post and many people pointed out in the comments that we need some feedback when the wireless card is [...]
Hmm, did I understand that correctly — when the users needs CURRENT data she/he cannot get it right away but actually she/he has to wait until next auto-refresh. Oh boy…
Auto-refresh is useful thing to have but refresh on demand also because of time — user can have things to do and don’t want to waste 2 minutes (?) to see the refreshed list.
Current design is another example of this shameful attitude “our program knows better (than user) what and when the user needs”.
Maciej: I think you’ve misunderstood. In the situation where you’re coming out of suspend there isn’t anyway to make the wireless card refresh faster. You have to understand the types of refresh, lets call it soft and hard. During use of the wireless network your card is constantly doing a soft refresh to check for new networks. see my above comments on how this works. When you’re coming out of suspend or first booting up the card is doing a hard refresh of the wireless networks.
You have to really take a much better look at the technology and how it works, perhaps it’s my fault that I didn’t explain what’s going on underneath enough to back up these decisions, but it’s pretty complicated and likely why you don’t understand what’s happening.
So here’s an situation where this refresh button easily fails. You have the button pictured above which causes a hard refresh of all the wireless networks, the system is not smart as you say because the user is smart so it will always go into a refresh when you hit this button.
If your card is attempting to connect to a wireless network as you press the refresh button you will break the connection and cause the card to go into a full scan mode. If your card has scanned 1/2 of all the frequencies in your band and your desired AP is in the other half the card will dump it’s scan cache and start from the beginning after the button is hit.
So you can see that already you have to be somewhat smart so the user doesn’t shoot themselves in the foot; I can tell you’re thinking already that we’re trying to be too smart. But we can both agree that you need to give enough feedback so people know when the card is doing something. Then once there is enough feedback to feel like NM isn’t just silent you probably won’t want to use the refresh button because you’ll see that it’s always about to do the right thing.
Eric: I think that’s a great idea! I thought that putting it in the tray might get a little annoying and I’m not certain of that yet but it seems that way. What you’re proposing sounds really good, you should send it to the NM list.
Daniel: The reason why the animated scan icon could be annoying in the tray is because at times when you’re out of wireless range NM will keep running scans on it’s own. Assuming you didn’t want to connect to a wireless network or knew there were none available to connect to, having an icon that every 5 minutes turns into this animation for the next minute would get annoying.
Oh and the head icon is mugshot running, see http://mugshot.org/
[...] Bryan Clark: Refresh in reactive displays [...]