Why our User Interfaces must be come Model Driven?

I referred to “Model Driven “ navigation last week, and got some reaction that we are already there with ArchestrA Graphics. This made me step and re read what I in the last blog, and realise that I had assumed some understanding.

Yes today ArchestrA Graphics are built into the model in the objects etc, this is a significant step from the classic InTouch like window which the graphics are independent of the model, just linked, but many applications do not build in navigation to the model. My actually intention was not just these graphics in the model but take the whole operational experience to  level, that the model and views into this model for operational control etc, can be independent of the device and layout. Also, the model must be able to change freely and not a characteristic of what device or who will engage with it.

Similar to the web browser if you look at the web page content, it is design unaware of the device, the real estate etc that is available. The location which a page is displayed, or accessed is up to the browser consumer.

If we now take a look at the range of User Interfaces below, these likely will be all in one solution on the one namespace, with all users being able to access the same state and data of the plant. Interacting with plant and interface relative to their role’s actions. So in the example below you would have 5 plus user interface type experiences, different laoyouts due to device and role etc.

Now add to this the roaming user, with the increasing policy of “get out from behind the desk/screen”, where the available real estate on a mobile device calls for a different layout.

How can we design user interfaces the way we did in the 90s? Where we designed a HMI application for a role/ location, with a fixed layout and navigation experience.

Today engineers will continue to evolve the model of the plant, developing say a new process unit, including in this required interfaces (windows) that enable control, analysis etc. These windows, forms, specialized clients will be accessible to all users through their own user interface.

Avoiding people having to reengineer each user interface, each time the model changes. So to avoid this, the navigation of which windows are available at this level in the model, needs to be built into the model. Today some applications are doing this with ArchestrA Graphics in the application, but to go with this is need for each user to be setup their user interface layout.

This means each user/role can define their own layout, with panes as to where certain information is displayed. Where navigation come up, etc.

I saw a very good example of this two weeks ago, where navigation through the model could be through a tree, through the mimic drill, etc, and the model provides the context. As Invensys evolves the operational experience tools so that engineering and lifecycle costs reduce as the solution complexity increases, the above situation is a real one which we are making natural.

Consider your user interface designs to day, do not think narrowly to one role, one layout, it is time to move the user interface screens to the model, away from the role/ display etc, providing the freedom to have my own experience.

Navigation needs to be a Natural Act!!!!

Last week I visited some sites and engineering houses as they developed new systems. What struck me was the amount of time, and effort we put into designing a forced navigation between screens and windows. Even though, I knew this in my mind, I asked Why?.

In designing navigational buttons,  thereby enforcing a method of navigating through the application, which then now needs to trained to the people. Why cannot the system has Natural navigation built from the application model.

So what is this about?

Simple in today’s environment we have a couple of areas effecting the operational environment:

• Rotating people are in locations, role shorter times
• Increase in responsibility and decision making requirements, requiring a significant increase in data and information the operator must absorb or react over.

Last week I discussed Advanced Process Graphics, and how the new coloring scheme where only exception is shown is key to a person’s day, not the pretty pictures, providing a practical way to address the second point of more information. This starts not just in the screen design but down in the data and information source so the system is managing by exception.

The top point I raised is the rotating staff, discussing this last week with a couple of customers, this is a huge issue, I have spoken before about Operator Training Systems, but along with that must come a “natural” navigation. The users need intuitive navigation around screens, accessing the information they need, to make the decision, and take the required action. The interface may not be the desktop or control room experience it may start there, but it may also be at home, on the web, or roaming.

Consider screens and navigation designed for the desktop, now consider the Ipad, where the real estate is smaller, experience is “touch not click”, the desktop design will probably not be practical. Does this mean as a designer you have design different windows, and especially different navigation experiences or has the paradigm changed that this one window must be able to hosted in both environments, and the navigation/ layout for the experience changes. Yes the day of the HMI Application is over, it’s layout and windows been specific to location/ device and experience.

Layouts need to define where windows appear, layouts will be associated with the device and person. Example: I may have my desktop control experience, but I will have my Ipad control experience, and a different one for industrial, mobile device experience. Each with their own layout, and associated navigation, yet the same windows and information can be accessed.

Model driven navigation is required, so as you drill through the experience, to different levels of the model, the navigational experience must evolve driven from  the model. This allows the evolution of the model to happen, with no change required to operational experience as the new model extensions will be naturally available.

People often ask me why cannot the classic InTouch application work for the modern HMI, well the HMI products like InTouch, Citect, Ifix etc were built for local, one experience, one device, that is why we are evolving the InTouch experience to modern requirement. Next week I want continue the discussion on the "Intutive" navigation concept.