Sunday, September 2, 2012

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.

No comments:

Post a Comment