RMapp

Next generation of the RMapp code named “Allegro”. A post production audio toolkit that would allow users to render, master, and monitor Dolby Atmos files.

About RMapp

Mid life cycle product that supports the Pro Tools workflow. Previously a web based application that connected to a “side-car” computer device. Initially RMApp was a product suite housing the RMU, Pro Tools plug-in panner, and Monitor app.

Customer profile

Isolated three customer profiles

  1. The student audio producer: simplified workflow with a freemium option.
  2. Audio professional needs access to all prior features before migration to native Mac OS.
  3. Dolby maintenance technician: grant easy way to receive logs in case of errors.

UI/UX agenda for release

Based on user feedback simplifying prior user flows and bring back all features from prior versions of the RMapp, while allowing for enough time to transition from a web application to native Mac OS.

User pain points

Gathered through survey, user research, and user interviews.

  1. To many applications need to be open at one time just to render an Atmos file. Combine software suite into one application.
  2. File management is unintuitive and does not leverage native file browser.
  3. RMapp settings are scattered and not centrally located overall information architecture needs to be improved.
  4. Ui look and feel was inconsistent between product suite.

Web to Native

Transition from web to native generated a new opportunity to update legacy user flows and establish new UI patterns for the application. Which was ideal for our new persona the student audio producer who needed a simplified UX.

Combine software suite into one application.

Allow for less applications to be synced for more efficient user flow. Identified the RMU and Monitor app should merge into one application.

Hiearchy

Through user interviews and observing user behavior identified two distinct areas of application interaction.

  1. Setup: These are UI components that the user will interact with only during setup and usually only a one time process
  2. Monitor: Active while recording and during playback, this section gives the user an understanding what’s going on in their Atmos file. Currently read-only.

Rapid prototyping

Generated multiple designs until we settled on appropriate hierarchy by bringing the monitoring aspect to the forefront and the setup to the back. The monitor read-only aspect would be dealt with in a later release.

File management

Simplify overly complex file management system due to legacy web based application workflow.

Leverage existing user flow paradigms

Leveraged pre-existing patterns from popular tools from our user base along with leveraged native browser of Mac OS to design a simple and elegant user flow.

Settings

Reorganize the placement of settings to create a more intuitive information architecture. Prior version of RMapp, the whole application was a glorified settings page. Settings were scattered and unorganized. Reorganize setting placement for optimum user flow.

Architecture breakdown

Discovered four distinct sections after reorganizing the information architecture.

  1. General system settings: A general and global localized settings page.
  2. Room setup: An area designed to manage and tweak your physical speakers in a room.
  3. Re-renders: An area for setting your inputs and outputs for rendering atmos content
  4. Logs: Where a user can get detailed technical information about the state of a process.

Updated UI

UI look and feel was inconsistent throughout the production suite. Update the UI for more consistency throughout the production suite and through Dolby product line.

Extending style guide

By designing out wireframes and patterns we were able to extend out corporate UI/UX style guide which could be leveraged by the rest of the organization.

 
Back to top