Transforming a triple-screen desktop application into a mobile-friendly web dashboard.
PROBLEM: Take a sprawling drag-and-drop application meant to work on three connected screens….
…..and turn parts of it into a mobile-friendly web dashboard.
THE CPOF EXPERIENCE: The Command Post of the Future, originally developed as a DARPA research project in the early 2000s, is the Army's first networked collaborative mapping application. The software lets users navigate a shared data repository and display, create and edit data elements, graphics, text and images on maps, schedules, charts, tables and other visualizations. It ingests and publishes data continuously to and from third-party systems. Users can collaboratively annotate data via flash-lighting, brush-marks, graphical ink-strokes, stickies, and text.
CPOF clients are connected to each other on the Army's tactical cloud network. Users can simultaneously update the same data on the same visualizations in real-time. The system is designed to work on highly disadvantaged tactical networks with up to 1400ms of latency over several satellite hops.
CPOF clients can continue working while disconnected from the network. Individual users or selected enclaves can disconnect entirely from the main network and continue to view and edit all of their locally-available data. To make as much data available to disconnected users as possible, the system continually updates and refreshes entire collections of data in the background while users are connected. When a user reconnects, their changes merge back to the cloud. The system uses a variety of algorithms to pick a single consistent state when there are conflicts on the same attributes of data. The interface informs users of conflicts and gives them a chance to revert changes on selected "critical" attributes (such as the geo-location of a particular piece of data).
CPOF is designed from the ground-up to support collaboration and visualization. Using drag-and-drop, users can fluidly move and share data among visualizations and with each other, ensuring that data-elements retain their identity across visualizations and users without needing to be copied. The system strives to ensure users are seeing "ground truth" at all times rather than a proliferation of copies of data across different visualizations and users.
The Command Post of the Future's typical setup: lots of connected visualizations spread out across lots of screens.
USER CHARACTERISTICS: The CPOF Program's thousands of users operate the system in some of the most intense and dangerous places in the world. Though the system was designed to be accessible to commanders, the users who enter data into CPOF are largely enlisted specialists or operators (you could think of them as more "blue collar" users), while the people who consume data, briefs and reports are predominantly commanders and officers (executive, managerial, white-collar users). The system's designers and product managers are constantly working the balance between serving the different needs and job-roles of these different user categories.
We expected the users of the Dashboard system to be no different from our existing users; however, since the system had never been fielded, we couldn't get feedback directly from users, and the development timeline was too short to include feedback from users in the field.
UI & UX CHARACTERISTICS: The CPOF client application is modeled on a desktop operating system and uses a minimalist design aesthetic with very little chrome around visualizations. The primary mechanism for nearly every interaction is drag-and-drop, sometimes using keyboard commands to modify what happens on the drop. This design helps to eliminate chrome, menus, and buttons in the interface, but it isn't particularly discoverable or usable without training. Data elements in CPOF most closely match the "cards" UI pattern; they can be dragged and shuffled around, viewed as flat data on slide-like pasteboards, or dropped into visualizations that display whatever attributes make sense for the type of visualization being used. Permissions need to be set on every data element and on visualizations. It can take a long time to set everything up and to train users, but once it's up and running, things go really fast. Watching expert users collaborate using CPOF is like watching a high-performing sports team dominate a field of play. Watching inexpert or untrained users is pure pain. The learning curve is very steep, and some have questioned whether the collaborative gain is worth it.
We were translating specific, high-value parts of our existing system to a web dashboard -- specifically, navigating a shared repository, creating and editing data, importing data (KML and SHP files), and visualizing data on a map.
DESIGN CHALLENGES: We knew going into this project that there were going to be some UX problems we couldn't overcome. Specifically, identity and disconnected operations.
Identity. Big CPOF was built from the ground-up to make it easy to retain the identity of a piece of data shared among multiple visualizations and users. Maintaining identity -- and thus ground-truth -- is a high-value capability for our users and their domain. In migrating to an Ozone web dashboard, we knew we would have to give up that guarantee of identity; data couldn't reliably be shared across widgets (especially when those widgets were developed by other contractors and software shops). Maintaining identity across widgets that we had developed ourselves was the best we could do in the short term.
Disconnected Operations. The state-of-the-art for the Ozone web framework hadn't progressed to allowing users to edit and create data while they were disconnected from a web server, so we knew up-front that we would have to lose disconnected ops.
DESIGN GOALS:
Letting go. Since we were designing for an open-source framework that we did not own, and that we couldn't necessarily influence in the short term, we knew intellectually that there was nothing we could do to correctly resolve the problems around identity and disconnected operations. The best we could do, especially for the identity problem, was to let users know they were seeing copies of data. We resolved to acknowledge these problems, document them for future consideration, and let them go. (Easier said than done.)
UI Refresh: We couldn't wait to modernize and streamline parts of CPOF's UI and UX in a modern web idiom.
Mobile First: Although we weren't specifically tasked to design for multiple form-factors, we knew better. We focused on mobile-first, mobile-friendly design patterns as the most efficient path to a modern multi-form-factor UI.
DESIGN PROCESS:
A team of five designers worked with about twenty developers on four scrum teams. When we weren't scrumming with the developers, the designers worked together at a long shared table in a room with a whiteboard, a projector, a ton of Sharpies and sketchbooks, and our laptops. In the mornings, most designers would attend scrum meetings, work with developers on specific problems, and edit their designs based on the previous day's critiques. In the afternoons, designers took turns projecting the day's sketches and getting critiques from the rest of the designers. We would invite developers to participate in these critiques once a week on average.
The first week of design was spent developing high-level navigation patterns and a data hierarchy. We documented requirements for everything the system had to do and mapped them to different regions in the UI (status bar, nav bar, toolbar) and interaction buttons where those actions would take place.
We worked in pen-and-paper or whiteboard sketch as much as possible in the early days. Each designer was assigned a different part of the system.
Mockup Example in Balsamiq showing a detailed design for moving and sharing data.
High-fidelity prototypes. Our entire team worked on the framework and interaction design together; our teammate Ben Joos did the visual design.