Month: May 2010

Complexity Revisited

How come NVR’s (or VMS’s) have to be so (damn) complex?

Back when NVR’s were considered a programmers pipe dream, I would often visit end-users (usually with the integrator) to troubleshoot particularly tricky systems. I vividly remember a particularly irritated user who looked at me and my colleague with disdain, and asked:

Why can’t you just put a big red [Record] button on the screen?

It’s a fair question; a large group of users really don’t need all the features that modern NVRs offer, to them all the options are just distractions, and if the system doesn’t perform as expected the many bewildering knobs and settings just add to the frustration.

Record!

A fair amount of settings can be found in two main areas; image quality and recording conditions. As developers we often feel that we should be completely in charge – we value fine grained control and detailed accuracy, we feel that we need to know the pixel resolution, the H.264 bitrate and GOP size and that a mere “low, medium or high” quality would be a dull and blunt setting.

Why is it important to know that the image is 640 by 480 pixels, and that compression rate is 50%? To most users “medium quality” would be enough. If the “medium” setting is accompanied with a preview and an estimate of how many hours of video they can record, they will probably be better off than stabbing in the darkness.

Not from an NVR, but you get the idea

Recording conditions is a tricky area; the worst part is that if the user makes a configuration mistake, they most likely will not realize until it is too late. Programming is programming, even if the input method is dragging and dropping cute looking boxes, or entering via a “wizard”. And programming requires testing and debugging, something that can be extremely difficult to implement and very difficult to master for an end user (who just wants a “big red button”!).

I feel that Apple and Google has shown that technology doesn’t have to be complex and nerdy, and that regular non-techies can, and SHOULD, demand that the technology makes their lives easier. It doesn’t imply that the technology is inferior (the nerds can access OS-X’s free-bsd console, and google has some cool API’s for the nerds too).

The Real Purpose of R&D

“Is to make the support department obsolete, likewise the purpose of marketing is to make the sales department obsolete.”

The perfect product requires no support whatsoever. It installs and performs flawlessly, people who call support will not be worthwhile supporting, so the entire department can be replaced by an automated response system explaining the client how to get a refund.

Similarly, if the marketing department creates “the perfect campaign”, the sales dept. can be replaced by an online shop – no need for the sales people to elaborate on the wonderful features – people already “get it” and just want to know how to place an order.

These are the goals.

In between, there will be situations where support will perform clarification on features because some parts of the application are not well documented, or there are rare fringe situations that require a little tweaking and troubleshooting. In terms of marketing, the sales people will be met by people who “get it” but need justification to make the actual purchase. The same way we fall in love with a car, but need a salesperson to confirm our (sometimes made-up, irrational) justification.

Table Displays

In the last couple of years, a lot of vendors have started using the giant projector based touch-screens at trade shows. We’ve been using one for a while, but I am sure we’ll get something like this at some point in time.

It remains to be seen if this sort of interface will be commercially viable. I can imagine a lot of coffee and cake spills once they become mainstream.