design: WAVE Desktop Communicator redesign

So why redesign an application, especially one that's selling pretty well? We had a handful of good reasons for starting from scratch. The original application was developed using an older version of Visual Basic that was becoming difficult to maintain, and we didn't dare add any new major features to the existing codebase. We wanted the application to be easily localizable into other languages, and we wanted to make it accessible via keyboard to disabled people. We wanted the application to be everything the original Desktop Communicator was, plus add a multi-line VoIP softphone interface. We wanted helpful error reporting and correction. We wanted this. We wanted that. Plus we wanted it to look really sharp. Classic recipe for the Version 2.0 Sophmore Jinx, right?

When the project first got underway, I was dedicated to it, but the other team members had different priorities. I was familiar with the original application and with the new high-level requirements, and decided that the best way to get started was to sketch out different possibilities and then ask for comments. I'd hole up for a couple days, then invite everyone into a conference room to "throw fruit". We went through nearly two dozen cycles of this before coming up with an overall shape that included a ribbon control interface at the top of the screen, channels below, and flyout tabs for other components off to the side.

Choosing a ribbon interface was controversial and prompted a great deal of "spirited discussion". Fans of the Office 2007 ribbon-based redesign were few. We could find no examples of real-time communications applications that used a ribbon interface. We'd need to license the UI from Microsoft. And yet, the ribbon solved some big problems for us. We could keep global controls, like the Simulcast Talk button, visible all the time. We could expose complex control sets, like the master audio mixer, from a simple button click. We could use our visual symbol design language effectively. After digging in a little deeper, we discovered the ribbon was keyboard-accessible and could be minimized to show more channels. Our new application just seemed to work better with the ribbon. We eventually ended up with a simple ribbon interface that exposed high-use and global elements, and placed more specialized controls directly on the affected application components.

Here's an example of a specialized control at the detail level: the channel audio panel. Each channel has its own volume and pan controls that look and work just like the ones on the master audio panel. The channel audio controls are in a little popup launched directly from the channel by clicking a menu button. Each channel can have its own volume and pan settings if needed, or you can leave them all alone and control volume at the master level.

Another channel-level detail is the instant replay popup. The waveform shows the last couple minutes of audio on the channel. You can move the slider around to cue playback, save the audio to a local file, pause, restart. Each channel can have its own replay controls, and these are available from both the channel and from the history panel.

The history flyout panel shows recent activity. You can show activity from all channels, which can get pretty busy, or narrow it down to show activity on just the currently highlighted channel. If recent audio activity includes an instant replay buffer, you can replay the audio by clicking on the replay icon. Clicking a text chat activity icon opens the channel's chat panel.

This is a group chat interface, where everyone on the channel can read chat text sent by anyone else on the channel. The chat panel can grow or shrink, or be hidden away. The chat button lights up to notify that a new message is visible. We've learned that text chat is handy for soldiers who must contend with noisy and busy radio environments. Our channels are typically encrypted and routed over secure networks when used by the military. WAVE channels carry audio, text chat and other data, such as user presence.

The user presence panel shows who else is on a channel. I wish I'd taken a more interesting screenshot; this view shows just three people with computers on a channel. One of them is speaking. The presence panel displays different icons for people connecting from two-way radios, people connecting from IP phones, and other non-human entities, like recording gateways. The presence view can show a single highlighted channel, or all channels, and can be sorted by activity, user name, or status. This view helps to answer one of the big questions in radio environments: who else is out there on the channel?

Radio users don't just talk; they also send tones or other signals to announce a change in frequency, the start or end of a transmission, or to directly control a remote piece of equipment. Sometimes the tones are sent automatically, but frequently tone controls must be selected manually. We've tried various radio control designs over the years, but I think we nailed it this time. The remote control panel can accommodate multiple groups of tones which may be either talk-activated or immediate. The talk-activated tones are transmitted whenever you push the channel's talk button, and remain in effect until changed. Immediate tones are sent once only, but right away. It's useful for our customers to tell which tones are selected at a glance, without opening the panel, so we display the currently selected talk-activated tones right on the channel face.

We made a risky decision to develop the project using WPF and XAML. We had two main reasons for this. The first was that we believed it would be very difficult to create some of our more complex control surfaces using Windows Forms or Java, which we've previously used for our desktop applications. The second reason was there were only three of us dedicated to developing the application, and we needed to select a technology that I could dive in and help with. Richard Bogart worked at the lowest level, connecting the application to the WAVE SDK, tuning performance, managing resources, testing for memory leaks, and constructing a framework of real-time data we could bind to. Mike Passinsky created many of the components, touching almost everything but focusing especially on the phone panel. I created the production graphics and merged them into XAML resources, picked the colors, created some of the control surfaces, styled everything, and spent a lot of quality time writing C# and XAML code. We all fixed bugs. Early in the project, we had help from Michael Stacie, who had other WPF projects under his belt. We grappled with WPF issues others have also struggled with: blurry text, real-time performance slowdowns, buggy third-party controls, frustrations trying to debug XAML, and on and on. WPF/XAML (and Silverlight) will get there one day, but they often seemed like wines that hadn't aged quite long enough — a bit raw and harsh now, but with evident potential for the future.

The phone panel was one of the more complex components to develop. This is a multi-line VoIP phone interface that can connect using SIP or H.323 to a variety of different telephone gateways and use capability detection to configure the controls. So if the gateway supports transferring calls, the transfer button is enabled when on an active call. Multiple calls can be made and answered from multiple lines. Add in conferencing and transfer logic, styling, call states, and a log of calls made during the session. What we end up with is a comprehensive real-time communications control panel that lets a low-end Windows laptop substitute for a whole bank of radio gear and VoIP phones, over a WiFi connection in Starbucks if you like. Although you'd probably get a lot of funny looks from the other customers.

So our application is very sleek and silvery and pretty, but that's not all that important in day-to-day use. Many power users minimize the application and communicate over a limited number of channels using system-wide hot keys. An officer following remote units may want to keep a map up on the screen, and use a keyboard accelerator to talk or mute channels. Most application functions can be remapped in this way. One of our big challenges with WPF and XAML was to keep keyboard focus set correctly; I've lost track of all the hours we spent on this. Maintaining keyboard focus is important for both accessibility and also for quick keyboard-centric operations. Alas, our friends at Microsoft made setting keyboard focus in WPF much harder than it should be; unreliable and quirky, this is one of those "sacrifice a chicken" bits of techno-voodoo we all struggle with sometimes.

Another help for power users who keep the app hidden are the popup "toaster" notifications in the taskbar. These are configurable for number, duration, transparency, etc. Basically, when someone speaks or sends a text message, or an inbound phone call is received, a notification appears at the top of the list. Double-clicking an item does something useful; selects a channel, opens a chat panel, or answers the phone call.

Redesigning the WAVE Desktop Communicator was a big project, of the sort that doesn't come around very often. It was a lot of work, complicated by learning how to use WPF and XAML effectively. We had some strong personalities in the room during design sessions, and a lot of passion. Some of our best features got tossed overboard to simplify the project and make our release schedule. Still, I have to say that the whole thing was worth it. The three of us on our development team worked well together, and got a lot done quickly. I learned to love working in Illustrator, which I adopted in order to create vector graphics that could scale using a zoom control. See the related articles on XAML image template-swapping for a deeper look at my Illustrator to XAML workflow. Feedback from customers has been very positive, and our partners use the application to give demonstrations and loosen checkbooks. Hope this bit of year-end reflection was interesting; please contact me if you have any questions.

About Twisted Pair Solutions

Twisted Pair Solutions is a gigantic worldwide firm with 40-some employees scattered across the continents. We create software that uses standard IP networks to solve communications interoperability problems. Our technology partners use our software and SDKs to build great products. I'm the designer on our development team.