User expectations and standards-based application platforms -

User expectations and standards-based application platforms

Imagine trying to develop and market a film camera today. No matter how well it is built,  how good it looks, or how well it performs, the likelihood that you’ll make money selling it is approximately zero.

The reason is obvious: Digital cameras have transformed consumer expectations. Why buy a camera that makes you wait (and pay) for your pictures, when you can get something that displays your pictures instantly — and that makes it easy to share those pictures online with friends and family?

The moral is simple: When developing a product, you must always anticipate what your customers will compare it to. The question is, what exactly will they use for comparison?

Naturally, they will compare it to similar products in the market. But if your system has any kind of user interface, they will also compare it to the smart phone — or smart pad — sitting in their hand. And they’ll make this comparison even if your system has nothing to do with texting, messaging, emailing, or Facebooking.

Surprising? Not really. Every time one of your customers picks up a smart phone (which could be dozens or hundreds of times a day), they become more conditioned to the user experience it delivers. And the more conditioned they become, they more they expect a similar experience in other systems — and the more they miss that experience when a system doesn’t provide it.

An anecdote is in order. Recently, a colleague of mine saw an engineer attempt to use a pinch-and-spread finger gesture on the display of an oscilloscope. The engineer was so conditioned by the multi-touch interface of his smart phone that he unconsciously expected his o scilloscope to support the same form of interaction.

So is adding a spiffy user interface to your system the solution? Only partially. Smart phones and smart pads also allow users to download new apps and new themes on demand. Every time a smart phone user downloads a new app, they are again being rewired with new expectations — even for systems that look or feel nothing like a smart phone.

You don’t have to look far to find evidence for this. For instance, I’ve spoken to customers in the industrial automation market who are interested in adapting app store technology to what, in the past, were isolated, fixed-function systems.

All this signals a sea change for embedded system manufacturers. On the user interface front, it was often acceptable to let programmers design the user interface. But now, customers expect eye candy, such as screens that employ alpha-blended transparent regions and that transition from one view to another using swishes, swirls, and other effects.

To implement these types of effects while ensuring the high level of usability established by smart phones, manufacturers are well advised to lean on experts in user interface design.

Graphics are one thing, but the demand for systems that can support new apps or services is another. At one time, an embedded systems manufacturer either developed, or was in control of, all the software running on its products. But now, much or even most of that software may come from third-party developers — developers that the manufacturer can’t completely control, but must somehow enable.

Naturally, these new expectations will impact some markets more than others. In the automotive market, for example, there is little doubt that downloadable apps will become a common feature of car infotainment systems. It’s still unclear whether most automakers will allow users to download any apps they wish or whether they will implement walled gardens. But either way, don’t be surprised if, when shopping for your next car, the automaker’s app store becomes one of your purchasing criteria.

Other markets will also be affected, though not so conspicuously. Imagine a bedside monitor that allows doctors and nurses to access a patient’s critical information, but that doubles as an entertainment portal for the patient when medical personnel are absent. Even something like a programmable automation controller (PAC) can provide a form of app store interface that lets the customer add modules for flowcharts, ladder logic, or Pseudo C.

If you think these demands sound a death knell for home grown real time kernels, you’re right. Manufacturers must move to standards-based application platforms that can support both the compelling graphics and the rich choice of applications that users have come to expect.

We’ve already seen the phenomenal success of this platform approach in the smart phone market. To succeed in other markets, including automotive, medical, and industrial, application platforms must embody a number of qualities. They must cleanly partition applications and services to protect core functions from untrusted programs and content.

They must support secure and reliable in-field upgrades. They must be hardware agnostic. They must, in markets such as automotive, integrate easily with users’ smart phones and other mobile devices.

And they must provide graphics frameworks based on de facto or de jure standards such as HTML5, Adobe AIR, and OpenGL. That way, the manufacturer can not only create compelling user interfaces, but also leverage the talents of a large development community.

In the end, who will profit from “platform enabled” embedded systems? Embedded system manufacturers? Third-party application developers? Service providers? End users? The more manufacturers embrace the platform approach, the more the answer will be, quite simply, all of the above.

Sebastien Marineau-Mes is the vice president of engineering at QNX Software Systems .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.