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).
About this entry
You’re currently reading “Refresh in reactive displays,” an entry on Bryan Clark
- Published:
- 10.16.07 / 9am
- Category:
- Design, NetworkManager
17 Comments
Jump to comment form | comments rss [?] | trackback uri [?]