10 Keys for 'Easy to Use' Video Management Software
In this report, we examine well established usability principles for software, how they are routinely violated and what can be done. Contrary to common suggestions, the answer is not more training, ignoring it because engineers can use it as is or simply dismissing the need as a matter of opinion.
Training = Failure
If Video Management Software requires experienced security professionals to be formally trained on using it, than it is not easy to use. Easy to use software enables users to quickly experiment and learn the interface as the user explores it. Multi-day training classes should be considered a vice, not a virtue, reflecting software with poor interface design.
Expert Users Do Not Prove A VMS is Easy to Use
It is common to hear experienced engineers talk about how their favorite VMS is 'intuitive'. This certainly is possible but misses the point. Software ease of use is measured by the time and difficulty new users have to learn software, not the ease with which experts who use an application regularly have using it.
Easy to Use is Not Simply A Matter of Opinion
Many people think 'easiness' is just a matter of taste or opinion (Joe's favorite color is blue but Mary's is pink, etc., etc.)
To the contrary, human-machine interaction and user interface design has been developed over the past 50 years. There are broadly agreed upon principles that software developers should follow. Here are a few of the most cited works in the field:
- The Humane Interface
- The Inmates are Running the Asylum
- About Face: The Essentials of Interaction Design
- Designing Interfaces
In this premium report, we examine the most basic principles and demonstrate how they are routinely violated resulting in user experiences that are both frustrating and cumbersome. We analyze and demonstrate issues with two of the largest IP video providers - Mobotix and Milestone.
Here are 4 basic principles to keep in mind:
- Spatial Grouping: Related tasks should be physically close to one another. For example, selecting cameras and controlling PTZs should be very close and physically separated from configuring cameras. It's shocking how often this is violated by VMS systems.
- Visual Cues: There should be some visible symbol (icon, text, combination) that displays the key functions. The more intermediate steps required (click of a pull down, right click on a screen, etc.), the more difficult it will be for a user to find and the more experience and training one will need.
- Make Most Commonly Used Features Easiest to Access: A system can have hundreds of features but the handful used the most (like selecting cameras and searching video) should be far more prominent than most others. We are amazed at how often VMS vendors bury the most frequently used functions in long series of rarely used controls.
- Provide Clear Status and Feedback: The UI should make it easy to understand where the user is at and what is causing any problems. It's absurd that many VMS systems do not clearly show whether the system is in live or playback mode. Similar problems exist with error messages, especially when a VMS cannot connect to an IP camera. The messages are often written in technical terms ("cannot connect to the database") is unhelpful for most integrators and users.
These are not the only principles/issues in UI design but they focus on the most repeatedly violated ones in real world VMS systems.
Below are two case studies of VMS systems in action followed by further analysis and commentary on VMS usability.
Mobotix Case Study
Mobotix is one of the largest IP video companies. Their strategy centers around an all Mobotix solution where customers use Mobotix' cameras and their free VMS systems.
Mobotix offers 2 Video Management clients - MxControlCenter and MxEasy. Both of them violate fundamental principles but MxEasy really stands out because it is designed for smaller deployments with less sophisticated users.
In the video below, we examine numerous issues with MxEasy. We encourage you to download MxEeasy yourself so you can experience it directly.
Milestone Case Study
Milestone is widely acknowledged as one of the top sellers of VMS software globally. It's also one of the oldest/most mature offerings. Despite this, their most well known product offering, XProtect Enterprise suffers from numerous usability issues.
See the 17 minute video below for an analysis and demonstration of issues in live monitoring, investigations and administration.
Examining Usability Principles
The videos above are key in demonstrating the first 3 principles we cited: (1) spatial grouping, (2) making most common features easiest to use and (3) providing clear status and feedback.
Let's examine some more well established guidelines and their utility to VMS software:
- "To software makers, it seems virtually free to add features, so any proposed feature is assumed to be a good investment until proven otherwise." While VMS software providers seem their products as far more sophisticated because of their generally greater feature count than DVRs, a big downside is when there are so many functions, it undermines the ability of users to find and use any of them.
- Design for the probable, provide for the possible: A pithy maxim from Alan Cooper emphasizes that systems can have numerous features but the system must make the most common cases, the easiest to access and use.
- Fitt's law - "predicts that the time required to rapidly move to a target area is a function of the distance and the size of the target." The practical implication of this principle is that to minimize time and effort related features should be close to each other and the most common ones should be the largest.
- Hick's law - "describes the time it takes for a person to make a decision as a result of the possible choices he or she has." Studies show the more options you provide to be people, the more difficult and frustrating it becomes to make a decisions. Many VMS systems offer long rows of icons under the belief that this provides greater power. However, for most users, this creates greater difficulty in determining where the function they want is.
- Beware of Overloading Icons: “Whatever language you know, you have to learn the meaning of an icon anew. There's a reason why humans invented phonetic languages where just a few symbols can be combined to produce any word." It's common for VMS systems to use numerous icons (see MxEasy as the worst/best example of this). It may appear that this saves space but what it likely does for most users is cause them to hover over each icon repeatedly trying to remember what the meaning of the icon is.
- "If an interface forces you to memorize the fact the features exists, that feature is invisible.” When VMS software fails to provide spatial grouping of related features, overuses icons and overloads the screen with icons, it forces users to memorize the location of each feature (again, see MxEasy for a perfect example of this).
- User's perception of response time: Users can become very frustrated and believe an application is broken if it takes more than a few seconds to respond. Developers who become acclimated to such long delays often over look this. However, for a new user, they have no idea that this is normal and routinely assume the system simply does not work. This problem frequently happens in VMS software both during searches and when logging in to user applications. If the developer cannot eliminate this, clear feedback should be provided (e.g., a percent done display that accurately reflects progress). See a note on response time from Jakob Nielsen.
- The problem of designing for 'elastic users', who are accommodating computer literate power users. This identifies the common danger of developers to assume that their users are technically proficient as themselves and willing to spend time and energy figuring things out. Even with integrators, this cannot be assumed as integrators deal with many product lines and have large numbers of technicians they need to train.
- Choose very specific personas and design for them. As an example, a good persona for VMS software is "Joe, a 43 year security guard who enlisted in the Army right out of high school, discharged after 5 years, has worked a series of odd jobs since including construction and retail sales. He has a 2003 PC at home, uses it moderately to play online games." This persona would make it much clearer the type of challenges a 'real' user would face. There are many types of people who use VMS software but almost all have far greater restrictions than the computer literate power user that VMS developers often implicitly design for.
- Design for specific goals and scenarios. Pick a common scenario: "The guard wants to know what happened last night between 3 and 5 in the morning, get the video of any event and send it to the police." I am amazed at how difficult this most basic and often used scenario is in many VMS systems. By focusing and prioritizing usability for common scenarios, systems would be much 'easier' to use.