This page last changed on Jun 09, 2009 by marcf.

It probably is a little early but I wanted to start a thread on UI composer.

As we release the software, we need to focus on the next generation of the composer.   I personally think that it is one of the most important focus points, because it will be the entry point to most users of OR.

There are 2 roles within the composer

1/ The installer.

Within composer, an installer defines devices. For example the X10 dialog, or the IR Beehive dialog, or the KNX group address dialog allow for definition of devices.The device is associated with a set of buttons.  For example in IR, declaring a remote to the beehive device database returns a panel of buttons.  The programmer will use these buttons.

2/ The programmer. 

The programmer and the installer are usually one and the same.  But the programmer's role is to program panels for the iphone from a palette of buttons. Today, programming in OR means to drag and drop buttons on different panels. We also support macro's as a set of buttons represented by one.


The integration of a device in this framework means to make available a set of buttons representing commands with associated images.  That is the what the programmer will need to assemble panels.  Then for the runtime BOSS support. These commands map to a native bus and the routing is taking care of in the controller. How to integrate is specified today, we focus here on the software side for composer.

From the java world JMX is Java Management Extensions.  Juha and I wrote books and specs on the subject It's main idea is that random components or devices will be deployed and will advertise their functionality.  Think about a device with an IR remote.  Take a picture of the IR remote, image-map it and you have a declaration of buttons, or APIs as it were to the system.  From a programmatic layer, they can be invoked, or called.  Of course these would be the one-way only commands.  A device exports its API through its IR remote. Mapping this to a visual assembly tool for buttons is straightforward. Programmatic self description is the feature we gain. As an industry we are a long way from this goal. The BOSS helps with this goal.

Implementing these ideas in composer depends on previous infrastructure work such as the notion of "accounts" where you can declare your devices.

Panel assembly

On the panel generation side, we already support panel swiping and custom images for background and buttons.  Per Juha this needs to be tightened up before we release something but fairly advanced panels can be created this way (see amsterdam demo).

1/ Get rid of the current grid to allow for absolute positioning.

2/ Support for mask on images.  With transparent zones you can either replace icon or create visual effect on iphone surface like "magnify" which does not require the upload of buttons to signify changed state.  This will allow for graphics designers to do their thing and then for programmers to generate the panels from single images.

3/ advanced navigation.  Navigation right now means panels of x by y that one can swipe through.  This is probably enough for now.  At least we should allow for long panels that we can scroll.  Clicking on a floorplan would require a level of software navigation, for example, click on room, see remotes available, select remote available, then display corresponding panel(s).

To bring an update to this discussion, I wrote a post on how the changes described here will affect the next version of UI Composer design.

UIComposer Design for 2.0

Posted by juha at Jul 13, 2009 13:53

Juha, it is a great read.  I really like how you display the XML next to the dialog.  The integration is simply XML driven.  Love the new mockup software.  Better than pictures of my desk.

An event should be associated with an icon.  The icon is specified by the installer.

First I would do a default palette of icons (switch, rocker, slide, number).  You can select from that for a particular instance.  So stored in the session of the user you have a set of instantiated icons.

Additionally, from XML we should be able to specify icons as a list of jpg and display them in a selection menu so you can select an image for each instance of command.

I hope this makes sense. It is close to what iKNX has in the wheelie with over-ride of icons.

Posted by marcf at Jul 17, 2009 21:26

It does make sense. However, icons probably belong to the UI designer side of things which was not yet displayed in the mockups.

Posted by juha at Jul 22, 2009 18:50

A quick progress update and some eye-candy – some of the upcoming building modeler web UI with the features discussed in the earlier blog post.

Creating a new device Devices listed in the model
Import existing commands for a device from Beehive Select device commands for the current building model
Add new commands manually Enter protocol details
Commands associated to a device Build macros on modeled devices and commands
Posted by juha at Aug 04, 2009 00:41
Document generated by Confluence on Jun 05, 2016 09:32