We've started the work on designing the next version of the user interface composer. From user functionality and user interface point of view this is going to bring some notable changes to the current 1.x release branch.
Marc described some of the logic driving the changes in his earlier UI composer, next generation post in June. The upcoming changes are mainly driven by the discussions we had last month at our Amsterdam meeting.
Building Modeler vs. UI Designer
To summarize, the user interface of the application is going to change to cater two separate user roles – one for an installer who models the building automation setup and another for a user interface designer who uses this model to create different types of panel and console applications. At times these two roles may be assigned to the same person but it does allow some of the technical details of the installation to be hidden from purely panel UI related work (and vice versa if necessary). A technical end-user for example could be allowed to modify the user interface layout to better suit his or her needs without necessarily exposing them to the technical details of KNX or UPnP protocol configuration used at the building.
Sharing Model Information
In order for the installer, UI designer and end-user to collaborate, we are introducing an account where data can be shared between these users. This account is intended to be used as a private storage of all protocol configuration and device data plus all the user interface layout configuration. Since it is a private account between the collaborating parties, installation specific data such as non-unique KNX addressing may be stored on this account. This ensures all parties involved are in sync with changes to the model and that all parties have equal access to all the model, data, code and UI layouts that belongs into a full home or building automation installation.
Devices and Ease-of-Use
Since the application is logically split between Building Modeler and UI Designer, some additional context is required to pass information that so far was implicit in using the 1.x release UI Composer. We are planning to address this by introducing a "Device" abstraction to the user interface, where both Building Modeler and UI Designer begin from creating/using a device type.
Device naturally associates with the available protocols and commands (available buttons on the UI Designer side). This should help with scaling the user interface to accommodate more protocol implementations – we've already doubled from the expected 3 supported protocols to 6 supported protocols in 1.0 release (thanks to contributions from our community) and are looking to add at least two or three more either in 1.1 or next 2.0 releases. Further, it is the hope to increase the ease-of-use of the user interface by exposing only the available modeled commands in the UI designer interface as opposed to showing all possible protocols and commands that could be modeled for a panel or console.
Easier Integration
Additional goal of the redesign is to allow contributors more easily add their own implementations to the online tool UIs by exposing some UI elements as XML configuration files that can be modified without having to familiarize yourself with the codebase. This should increase the ease-of-use for integration scenarios.
UI Mockups
The following UI mockups illustrate some of the changes mentioned above.
Figure 1: Create a new device in Building Modeler
The application view is logically split to Building Modeler and UI Designer. The views made available are based on user permissions on the account. For example, an end-user logging in with a UI Designer permission would only see how to arrange the UI elements on the preconfigured devices and protocols (created in the Building Modeler).
An installer modeling the house or building configuration would start the work by creating a new device. Device has a logical name, vendor and model. Additional attributes can also be supported for devices (such as device type shown in Figure 1).
Figure 2: Create a new command by inputting the configuration manually or importing from Beehive.
One of the challenges with the existing UI Composer design is the quickly increasing number of protocols and the complexity it adds to the user interface. With the device modeling abstraction shown in the Figure 1, it is natural to add commands and protocols to these specific devices.
Commands can be added in two ways. Either by inputting them directly for cases where there is no shareable data available or looking them up from Beehive database which contains data about devices that can be shared.
For example, creating a KNX command is at the moment a manual process since the addressing is non-unique and specific to each installation. This is also true for many other IP-based protocols that require local IP address or port information, and where discovery is not available. Choosing the protocol type (KNX, X10, etc.) for a command allows these properties to be typed in the dialog.
Where shareable database of device commands are possible, existing command information can be imported from Beehive. Currently this is the case for LIRC infrared data. In that case, all the available commands for a device can be imported directly into the device model.
Figure 3: Working with commands associated to devices.
As the device modeling proceeds, working with macros or creating UI layouts is based on the list of available devices and commands configured for them. On the UI Designer side, a macro will be another command available as a UI widget for the layout. The details of protocols, addresses and protocol commands are hidden when creating or modifying existing panel layouts.
Integration and Contributions
To ease the integration of new protocols into the UI tools, we are externalizing some of the basic UI configuration. For example, a dialog to enter protocol properties could be defined in XML in the following way:
|
|
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="KNX">
<attr name="groupAddress" label="Group Address">
<validations>
<allowBlank>false</allowBlank>
<regexp message="group address should be 1.4.1.4">(\d\.){3}\d</regexp>
</validations>
</attr>
<attr name="command" label="KNX Command">
<validations>
<<allowBlank>false</allowBlank>
<maxLength>10</maxLength>
<regexp>\w*</regexp>
</validations>
</attr>
</protocol>
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="X10">
<attr name="address" label="Address">
<validations>
<allowBlank>false</allowBlank>
</validations>
</attr>
<attr name="command" label="Command">
<validations>
<allowBlank>false</allowBlank>
<maxLength>10</maxLength>
<regexp>\w*</regexp>
</validations>
</attr>
</protocol>
|
There's a large number of details not covered in this quick overview. The most suitable place for further discussion is the Design Forum.
