2012-05-09 / The Work Department
With the goal of creating both an intuitive and accessible user experience (UX) across a sampling of devices that will run Commotion, we surveyed and analyzed the current state of the existing interfaces. We deployed a test network using the three software components currently in development phases: Commotion on an Ubiquiti Picostation (router), The Guardian Project’s OLSR Mesh Tether on an Android handset (phone) and Commotion on Linux (laptop). In anticipation of The Serval Project’s forthcoming work around meshing mobile devices with Commotion, we also researched the current release of Serval Mesh. We documented each step with screenshots, which are compiled here. After the initial audit, we compared and contrasted each workflow, documenting any issues that arose during the process and were then able to make recommendations on how to improve each of the interfaces and workflows and make them consistent across platforms. Our process was unique in that our auditors represented a range of skill levels and backgrounds. We seek to represent this diversity when creating user interfaces that are intended for a broad range of users. For example, Auditor 1 is a self-taught web developer with advanced skills in networks and mesh networks specifically. Auditor 2 is a designer with intermediate knowledge of networks and some experience setting up networks. Auditor 3 is a designer with basic network skills and very little experience setting up a network. We feel that these varied levels of experience with networking are important. The advanced user can help guide the process for successful installation and the inexperienced users can communicate what is helpful while illuminating confusing aspects of the process. Commotion Router: Installing on an Ubiquiti Picostation (See a PDF of the process.) The router interface and workflow was the most complex of the three platforms we tested. The welcome screen includes rules for accessing the network and the option to “accept” or “decline” access. Though that seems straightforward, after clicking “accept” we were redirected to an error message, “302 found.” With no explanation of what caused the error or what to do next, we manually typed in the router’s IP address to attempt to access the network. This seemed to work, as we were then taken to the Commotion login page. The default settings do not require a username and password, though this is not noted anywhere, so we clicked the “login” button and were taken to (another) welcome screen. This welcome screen told us that we were now connected to a mesh network and included a description of what Commotion is, with a link to even more information about the project. To configure the settings of the mesh network, we clicked on “Administration,” which was a link in the upper right corner. Once inside the Administration section, the menu links on the left changed. Initially, the left menu had one link: “Overview.” When inside the Administration section, the menu no longer includes “Overview” but changes to include “Commotion, Status, System, Services, Network, Statistics, Logout, and Voice” links. From the “Commotion” menu we selected “Mesh Config (Manual).” Confusingly, when selecting the “Commotion” menu the “Status” menu link changed color as if we were selecting it instead. Also, the link in the menu is called “Mesh Config (Manual),” though when on this page, the title is “Configuration.” From the “Configuration” page we changed the base-name from “commotion_52_51” to our custom network name “meshshaging.” We then clicked “Save & Apply.” A loading wheel spun and read “waiting for router,” however no validation message ever appeared. A line of text at the top of the pages suggested rebooting the node after changing any settings, so we found the link to “Reboot” under the “System” menu. We were taken to another screen where we could select “Perform Reboot.” A message appeared reading “Please wait: Device rebooting…” However, we never saw any validation message. Once the device was rebooted, which we noticed from watching the status lights on the actual device, we verified that the network had been renamed via the airport/wireless window. This process is also documented in the UX flowchart here. OLSR Mesh Tether Phone: Installing on an Android handset (See a PDF of the process.) Once the OLSR Mesh Tether was installed on the Android device, and the program was launched, we were taken to a screen showing a log of activity, a “Traffic” button, a “Clients” button and a large “Start” button. In order to access the settings, we had to push the physical “Settings” button on the handset, not in the interface. This menu was a long list of settings, some with a bit of explanation underneath and some without any explanation. We selected “SSID” which was the first listing in the settings. A pop-up appeared titled “SSID (Network Name)” with a default value of “olsr.org” and an “OK” and “cancel” button. We changed the name to “meshshaging” and selected “OK.” We then were back at the main Settings menu, where we selected “Channel,” which was third in the list of settings. A pop-up appeared with the title “Channel” and a list of channels, from 1-12, to choose from each with a channel number and the corresponding frequency. We selected channel 7 and were taken back to the main settings menu. These steps are the only steps required to set up the mesh, but when we tried to access the network we received an error message titled, “Root Access,” telling us we needed to have root access in order for the software to actually work. So our process with the Android device had to end there. This process is also documented in the UX flowchart here. Serval Mesh Phone: Installing on an Android handset (See a PDF of the process.) We also looked at the Serval Mesh software on the Android device. The current release of Serval Mesh creates a mesh-based self-powered and self-organizing phone network between WiFi-enabled phones that requires no other infrastructure. We chose to evaluate Serval’s interface as well, because it relies on mesh networks and many of the settings might be similar. When Serval Mesh is launched, the first screen is not a welcome message, but a warning titled “HERE BE DRAGONS!” and a long paragraph about the program still being in development and containing various bugs, and that it may interfere with normal use of your phone. There is an “I Agree” and a “Cancel” button. We chose “I Agree” and were taken to the “Setup Instructions.” The instructions told us that we would have to pick a phone number, which cannot start with “11” and must have more than 5 digits. There is an “OK” button that we clicked after thinking about a number. Then we were prompted to enter the number we chose, which we did, and clicked “OK” - phone calls could now be made. This process is also documented in the UX flowchart here. Commotion Laptop: Installation on a laptop running Linux This installation process has no graphic user interface. All commands are via terminal input and only an experienced user could have success navigating this process. The commands are below and the following analysis is limited.
# add guardian's ppa
apt-get update
apt-get install olsrd
# edit /etc/olsrd/olsrd.conf: set DebugLevel to 1, change Interface to your wifi card
sudo service stop network-manager
sudo ifconfig wlan0 up
sudo ifconfig wlan0 5.70.60.60 netmask 255.0.0.0
olsrd -f /etc/olsrd/olsrd.conf
Shared actions: Commotion router, OLSR Mesh Tether phone and Serval Mesh phone The Commotion Router and Serval Mesh processes start with a splash page that includes a welcome/warning, more information, and the choice to either continue or cancel. The OLSR Mesh Tether and Commotion Linux processes don’t have any initial instruction or more information about the software. From this point in the workflow, all of the processes become equally unclear as to what is necessary to configure the network. The Commotion Linux and OLSR Mesh Tether interfaces are the least informative. The OLSR Mesh Tether user interface (UI) offers only a few hints as to what is optional and rarely defines terminology. The Linux application, as it is run from the terminal, offers no hints or help at all. The Commotion Router UI has the most information - because it is accessed from a laptop and not a handheld device, there is plenty of “space” to feature this much detail. But while there is more detail and are more options, there is no guidance and the process far from intuitive. As auditors, we conclude that without programming or mesh-networking experience, the chances for users to successfully configure a network are slim. See the flowcharts side-by-side here. Shared language Each of the interfaces has a unique way of communicating the purpose of the software when it is first launched. The Commotion Router welcome screen never says the word “mesh” but instead calls the project a “community wireless network.” The OLSR Mesh Tether interface has the title “OLSR Mesh Tether” but no other mention of “mesh” or “network[ing].” The Serval Mesh interface’s warning/welcome screen has both the words “mesh” and “networking,” but they are buried deep in the warning. The Linux language includes native terminal cues and the word “network” but not “mesh.” On both the Serval Mesh and Commotion Router interfaces, there is a button on the welcome screen that allows you to cancel or move further into the process but the language used here is different as well. The Serval Mesh UI buttons are labeled “I agree” and “Cancel.” The Commotion Router UI buttons are labeled “Decline” and “Accept.” The OLSR Mesh Tether and Linux interfaces do not include these buttons at all. The Serval Mesh software seems to automatically configure the settings and the other applications do not. Though the same settings need to be configured, the language referring to some of the settings is not the same. The OLSR Mesh Tether interface refers to the SSID as “SSID (Network Name)” while the router interface refers to it as “Mesh SSID.” In addition, the essential settings are in menus labeled in two different ways: the OLSR Mesh Tether menu is labeled ”Wireless LAN” and the router interface menu is labeled “Configuration.” The language surrounding choosing a channel is the same in both interfaces, though it is not a required step in the router interface. Initial recommendations Among the audited software, we discovered that there is a lack of an shared language. In order to create the foundation for a seamless, connected, and accessible platform, a Commotion set of themes, actions and icons are essential. After this discovery phase, we conclude that these are four focus areas that will drastically improve the overall user experience. These focus areas are in addition to applying the new Commotion brand identity.
1. Common Language
Shared language is essential in order to make Commotion accessible to the general public. In addition to using a common set of themes, actions and icons, we recommend adding hints or tooltips as much as possible. For example, a hint could be added to the SSID field that tells the user “The SSID should be a unique name for your community network and can be up to xx characters.” This would make it clearer to a beginner user what is expected in each field. Moreover, we recommend that the language on buttons, menus and messages be replaced with more action-oriented and explanatory language. The first buttons the user is faced with in the Serval, router and Android interfaces are “I Agree/Cancel,” “Accept/Decline” and “Start,” respectively. The action the user is agreeing to would be more evident if the buttons were named, for example, “Link Up” and “Not Now."
2. Workflow Hierarchy
Designing a way to designate required fields and optional fields would be helpful for new users. If this were done, a beginner would know that only two clear steps (hypothetically) are needed to configure the network and that not all settings are needed to simply link to the mesh network. Beyond this, we recommend that two groups of settings, required and optional, be separated hierarchically to make it even more clear to a new user what is needed and to an advanced user where more changes can be made. The interface should also include a link to more information about the settings and how to choose a channel or SSID, for the user who would like to self-educate.
3. Join an existing network or build a new network?
Throughout all of the UI, it is never clear what actions should be taken by a user when they are either joining an existing network or building a new network. It may be useful to create initial prompts that clarify whether the device is detecting and, thus, linking to an existing network or not. It may be important to note whether the device, or node, is acting as the first node in a new network. It may also be useful to show whether or not a network is connected to the global Internet. In the future, icons can be created that communicate how nodes are connected and how traffic is flowing across the network. This may be similar to a visualization/mapping tool, like Open Mesh’s cloudtrax.com network management tool.
4. Connectivity and configuration validation
Finally, we recommend a positive message, sound or validation feature when the network has been successfully configured and instructions on what to do next. As of now, the user is just left to assume (or not) that the settings they have entered are valid. A progress wheel, or something similar, is also recommended where appropriate, as it gives the user a sense of progress when going through the installation and configuration process. An example can be found with the OLSR Mesh Tether device error message. The message told us that the device needed to be rooted in order to proceed, but with little experience in development for handheld devices, a user will not be familiar with what the term “root” means and will be left with no pathway to move forward.