The flagship product of MathWorks is MATLAB, a program that scientists and engineers use for computation and data visualization. MATLAB users, like many users, don’t want to spend time learning software—they just want to get their work done. They often have large data sets to analyze, and MATLAB provides many tools to help them. The desktop program includes windows for entering commands interactively, displaying charts, saving previous commands, editing files, viewing files and folders, and more. In response to customer demand, we decided to move this product to a mobile platform, beginning with the Apple iPhone in 2010.
Selecting the UI Elements to Include
Our first challenge was determining how to map the rich feature set of the desktop product to the limited real estate on a phone. To reduce the scope of our project, we asked ourselves, “What do most of our users need in order to perform most of their common tasks?” We identified three windows that corresponded to the majority of our users’ tasks (see Figure 1):
- Command Window, where users enter commands to perform calculations and create graphs.
- Figures, where users view graphs.
- Command History, where users select commands to rerun without having to retype them.
Figure 1. Default view of the desktop program.
Translating Elements to the Smartphone
We organized the three essential features—Command Window, Command History, and Figures—in three tabs (see Figure 2). The most important window for users is the Command Window, which allows them to enter commands and create figures, so this is the tab that users see when they start the app. It provides a clean slate for new computations.
Figure 2. The app’s tabs and Command Window.
Command Tab
Most MATLAB commands use programming conventions that require special symbols. For example, commands like these are common:
- x = 1:.01:100;
- y = sin(x);
- plot(x,y)
In our initial usability tests, users said it was very painful to navigate to more than one secondary keyboard to enter a command. To make typing easier, we added a row of extra keys above the main keyboard, containing the most frequently used special characters. To support even more characters, we added tap-and-hold pop-ups, following standard iOS behavior (see Figure 3).
Figure 3. Additional row and popups with programming keys.
Lesson Learned: Balance the limited real estate between leaving enough room to display content and adding features that make interaction easier.
Unfortunately, usability tests showed that people didn’t discover these pop-ups. We resolved this issue by displaying the pop-up on the initial tap. If the user didn’t select one of the pop-up characters, the app inserted the character corresponding to the original key.
Lesson Learned: Don’t assume that following the OS standards automatically produces a design that works for your app or user.
In the desktop product, the Command Window shows the most recently entered commands. We preserved that behavior in the app. In addition, on the desktop, users can enter a plotting command and see the resulting full-size figure in a separate window at the same time. A smartphone didn’t have room to show them together. To reduce switching between tabs, we added figure thumbnails next to the recent commands (see Figure 4).
Figure 4. Command with a thumbnail of the resulting figure.
Lesson Learned: Provide a glimpse of essential information in context whenever possible.
History Tab
In the desktop product, users can rerun commands by selecting them in the Command History. This feature significantly reduces the amount of typing that users must do, which is a valuable asset in a mobile app (see Figure 5).
Figure 5. History with previous commands and figure thumbnails.
Figure Tab
Our users frequently work with large data sets. They often use graphical figures to find details and irregularities in their data that are otherwise difficult to detect. We originally treated figures like photos: when users zoomed in, the app enlarged everything.
But during usability tests, participants told us this made figures “useless.” They couldn’t see the data values because the axes ended up off-screen. To solve this, we decided to keep the axes on-screen when users zoomed figures (see Figure 6). This was another example of an OS standard that we had to tweak to support our users.
Figure 6. On the left: the original figure. In the middle: the figure after zooming (the axes are off-screen). On the right: improved zooming behavior (the axes remain on the screen).
In the desktop product, users can click on a point in a figure with a mouse to see its data value. On a smartphone, it’s hard for users to pick a point because their fingers cover the area they’re tapping. We made crosshairs that users can move to a desired position on the screen, so their fingers don’t cover it up (see Figure 7).
Figure 7. Data cursor that users “grab” and move.
Lesson Learned: When a user needs to select a specific location, find a way to keep fingers from blocking it.
Because it can be hard to select a specific point with a finger even using crosshairs, sometimes users tapped outside the data and no data values appeared. Users thought this was confusing, so we also added a message saying that no data was found.
Optimizing the App for a Tablet
After we produced the iPhone app and had some success in the App Store, we decided to apply our lessons learned and expand our repertoire to another mobile device. Users asked us to create a version optimized for the iPad, so that seemed like a logical next step. We were eager to address some of the pains caused by the small screen of a smartphone, such as:
- Typing. Adding extra keys helped, but didn’t solve the whole problem. Users still needed to switch between keyboards to type numbers.
- Switching between tabs. Adding figure thumbnails to commands helped, but users still had to switch to the figure tab to get a better look at their plot.
Lesson Learned: Take advantage of the extra real estate on a tablet to address some of the pains of the reduced real estate on a phone.
Our Tablet Design
We used the real estate available on the tablet to add all the numbers to the row of extra keys. Users can access every key they need for programming from the main keyboard and its pop-ups (see Figure 8).
Figure 8. Tablet keyboard with all numbers and programming keys.
We also provided larger figures with the recent commands (see Figure 9) so that users have less need to switch to the full-figure view. When users do need to see more detail, the full-screen figure is larger, so they can see the data more easily.
The tablet interface also includes a toggle so that users can view the Command History at the same time as the Command Window, and they don’t have to switch between the two to rerun commands (see Figure 10).
Figure 9. Tablet with larger figure thumbnails.
Figure 10. Command History on the tablet.
Challenges with Cloud Connections
Users generally expect mobile apps to run locally on their device and to be very responsive. Our app connects to the cloud to access our computing engine, and cannot always provide results immediately. For example, zooming figures or viewing data values requires data transfer that takes longer than users expect. We had to find ways to make the system respond while bringing back computation results from the cloud.
Lesson Learned: Design intermediate feedback so that your app has a chance to complete a command in response to a user’s input.
Zooming Figures
So that the app feels responsive as users pinch open to zoom on a figure, the app zooms in on the local image. This allows users to check that they’re zooming in on the right area of the figure (see Figure 11). When they stop pinching, the app shows a progress indicator while it brings back new data from the cloud. Then, the figure is updated with the additional detail.
Figure 11. On the left: a zoomed local figure with a progress indicator. On the right: the figure updated with new data from the cloud.
Viewing Data Values on Figures
We initially used a tap-and-hold gesture to bring up the crosshairs for selecting a data point on a figure. Unfortunately, users had trouble discovering this interaction. Even when they discovered and moved the crosshairs, nothing happened immediately because the app was retrieving the values from the cloud. Users thought the crosshairs did not have a useful purpose. In our second design, we added a progress indicator, which helped somewhat (see Figure 12).
However, the crosshairs disappeared as soon as the data values appeared. If the user selected the wrong point, then they had to tap and hold again to redisplay the crosshairs. On our third attempt, we kept the crosshairs visible even after the data values appeared, but then we needed a way to make the crosshairs disappear. So, we added an explicit data cursor mode with a button to turn it on and off.
Figure 12. On the left: the app displays a progress message while it gets data values from the cloud. On the right: the app displays the values.
Losing Network Connections
Because devices are mobile, users move around and can lose their network connection. To address this issue, we save users’ information and state between sessions, both on the device and in the cloud. Even when they’re not connected to the cloud, users can continue to view their recent commands and figures. Because the cloud saves the state of the last session, when a device reconnects, users can continue working where they left off instead of starting with a brand new session.
Lesson Learned: Allow users to continue working despite dropped connections by saving session information and data on the device and in the cloud.
Conclusion
When we moved our desktop application to a mobile device, we found that the primary constraints were limited real estate and unreliable connectivity to the computing cloud. Our primary lessons: include only the essential features, balance the display of user content with contextual information, find ways to provide immediate feedback even when connections are slow—and always be willing to iterate on the design.
Retrieved from https://oldmagazine.uxpa.org/mobilize/
