support of imagemaps in the UI

[GoogleCodeExporter]

1. Feature Description
Currently the UIs of openhab are mostly widget based (switches, sliders,etc.)
It would be nice to have some imagemap based UI, where you can upload your home 
photos and put on it some switches/sliders. In that case it is more visual and 
user-friendly to use.
2. Example Use Case
there is an example using openRemote
http://www.youtube.com/watch?v=vuDgwJD9_Js&list=UUlErAxhISL9V9AGedA2pGqg&index=5
&feature=plcp-UI-Demo_showcase.jpg

Original issue reported on code.google.com by ramazany...@gmail.com on 8 Apr 2013 at 8:30

[GoogleCodeExporter]

I would say that this is probably not a feature to add in the existing UIs, but 
a whole new UI in itself. Using the openHAB REST API it should be feasible to 
do. 

Does the UI already exist for OpenRemote? Maybe we could could also implement 
an adapter for it instead of rewriting it on our own?

Original comment by kai.openhab on 8 Apr 2013 at 8:50

[GoogleCodeExporter]

openremote has an visual designer 
http://composer.openremote.org/demo/Modeler.jsp which allows you to draw 
complete UI view.  

Original comment by ramazany...@gmail.com on 9 Apr 2013 at 5:53

[GoogleCodeExporter]

As for the REST interface. Wouldn't it be enough to extend the widget object 
with coordinates? And extend the designer so that we have graphical mode to 
determine these coordinates?

Original comment by till.klo...@gmail.com on 15 Apr 2013 at 12:10

[GoogleCodeExporter]

"extend the designer" - you mean the openHAB or OpenRemote designer?
The current sitemaps are using the hierarchy as a strong concept. Mixing this 
with coordinates is probably not a good idea. But it should be easy to add a 
new model type for this purpose - but if we could simply parse the OpenRemote 
XML files that fall out of their designer, that could be fine as well.

Original comment by kai.openhab on 15 Apr 2013 at 6:16

[GoogleCodeExporter]

I don't know the architecture of openHAB well enough, so Idon't know which is 
more desirable: Create a new REST interface for image based UIs or extend the 
current interface. From the top of my head and from my current experiences with 
the REST interface you have always a current page with widgets. Sometimes 
widgets can be grouped in frames inside such a page. Except from cases where 
frames are inside frames I don't see a big problem with enriching the Widget 
object with coordinates inside a page. Every page would then have a 
"background" images with a virtual coordinate system and every widget would 
have coordinates except for widgets inside a frame which are grouped inside the 
frame.
But that is my perspective as a user of the REST interface.
But I will also have look at OpenRemote. Generally I would prefer to use JSON 
(as option) instead of XML, since parsing of JSON is more efficient on most 
mobile devices (allthough, generally I also prefer XML).

Original comment by till.klo...@gmail.com on 16 Apr 2013 at 7:40

[GoogleCodeExporter]

Original comment by kai.openhab on 22 May 2013 at 8:19

[GoogleCodeExporter]

Interesting discussion. 

Even if the imagemaps would be defined separately from the sitemap, I suggest 
they still could be linked from the sitemaps and be included as widgets in the 
current user interfaces as well (it would naturally require them to be extended 
to support them)? 

Original comment by kristian...@gmail.com on 27 Sep 2013 at 5:55

[GoogleCodeExporter]

OK, guys. I would like to make several suggestions that would enrich and better 
the client UX.

1. "ImageMap" widget. So, here comes the idea:

Imagine the ImageMap widget as a container. It is placed as a regular openHAB 
widget and can have children. It has only two attributes - "background" and 
"ratio". Background attribute is used for color or image set for background. 
Ratio attribute is used to set the width/height ratio. We don't use pixels here 
like in OpenRemote, instead we use ratio. Everything we do, must be responsive 
in order to avoid designing different sitemaps for different devices (the case 
of OpenRemote). So, for example a ratio value of "0.75" will set the height of 
the ImageMap widget 75% of the it's width. The width is always auto calculated 
like it's the case of all openHAB widgets.

Every widget can be a child of the ImageMap widget and thus it's rendered 
inside of it. Every widget should have X and Y attributes when it's a child of 
ImageMap. Every Image widget should have width and height attributes too (see 
paragraph 2.). This way every widget can be precisely positioned inside 
ImageMap container. If label="none", not show the label even there is a label 
set in the item configuration. If icon="none", not show the icon even there is 
an icon set in the item configuration.

If there is a Image widget that have children, don't show the children 
initially. Show them only on image tap.

2. Enrich the Image widget with a "mappings" attribute, "width" attribute and 
"height" attribute:
Image [item="<itemname>"] [icon="<iconname>"] url="<url of image>" 
[label="<labelname>"] [refresh=xxxx] [mappings="<mapping definition>"] 
[width=33%] [height=17%]

This way image widget could be hooked with Switch, Contact, Number and String 
items and could represent their values with images. For example:

mappings=[ON="switch_on.png", OFF="switch_off.png"]

3. Tab Bar configuration. The idea is to define a tab bar. I suggest in every 
sitemap file to be a tab bar area, as a root node. Also, it would be nice if 
there is a "position" attribute with "top" and "bottom" options. For example:

tabbar position="bottom"
{
    Group item=gFF label="First Floor" icon="firstfloor"
    Group item=gGF label="Ground Floor" icon="groundfloor"
    Group item=gC label="Cellar" icon="cellar"
    Group item=Outdoor icon="garden"
}
sitemap demo label="Main Menu"
{
....

4. Is there really a need to have the sitemap name after "sitemap"? It would be 
cleaner without it. For example "sitemap demo label="Main Menu"" -> "sitemap 
label="Main Menu"".

Original comment by mishoboss on 27 Sep 2013 at 9:09

[GoogleCodeExporter]

Sounds nice. 

I agree, I also think imagemaps should be scalable (for different devices and 
use cases), which I guess  makes support for vector formats like svg important. 
Same thing with labels, I think they should scale and have configurable 
relative font size when used at imagemaps. 

Even though I think the widget approach is perfect, I think it would be great 
to support imagemaps in full screen mode as well. 

Regarding whether to show child widgets by default or after a tap: I think that 
should be a configurable property for every child widget.

Original comment by kristian...@gmail.com on 27 Sep 2013 at 9:59

[GoogleCodeExporter]

@mishoboss - nice :)
One comment -:

3. Tab Bar configuration. The idea is to define a tab bar. I suggest in every 
sitemap file to be a tab bar area, as a root node. Also, it would be nice if 
there is a "position" attribute with "top" and "bottom" options. For example:

>tabbar position="bottom"
>{
>   Group item=gFF label="First Floor" icon="firstfloor"
>   Group item=gGF label="Ground Floor" icon="groundfloor"
>   Group item=gC label="Cellar" icon="cellar"
>   Group item=Outdoor icon="garden"
>}
>sitemap demo label="Main Menu"
>{
>....

I think I would move the tabbar INSIDE the sitemap declaration. There are 2 
reasons for this -:
1) I think the sitemap should be the top level object. This means it can be 
treated just like any other widget that is defined in the sitemap.
2) Having the tabbar inside could allow different tabbars to be defined for 
different pages. This may not be quite your intention, but it would make it 
more flexible. A tabbar would then be applicable to the page in which it's 
defined, and all children unless another tabbar is defined.

Original comment by ch...@cd-jackson.com on 27 Sep 2013 at 10:27

[GoogleCodeExporter]

> Even though I think the widget approach is perfect, I think it would be great 
to support imagemaps in full screen mode as well. 

Nothing stops you to do that. Just make sure the ImageMap widget is the only 
widget on a page and it will take the whole page. Or at least it will take the 
whole width and will respect the "ratio" attribute for the height. Or maybe 
there should be an option to take the whole page, but then what happens with 
the background picture and the precisely positioned widgets?

Chris, I'm not really sure if tabbar should be treated as any other widget. 
Though I like your idea of "per page tabbar". I don't know, maybe we have to 
think more deeply about this.

Original comment by mishoboss on 27 Sep 2013 at 10:40

[GoogleCodeExporter]

>>Chris, I'm not really sure if tabbar should be treated as any other widget. 
Though I like your idea of "per page tabbar". I don't know, maybe we have to 
think more deeply about this.
I don't necessarily mean that it's treated the same within the UI - clearly it 
needs to be different. I was really thinking about it from the HABmin sitemap 
editor perspective. and the way the trees are parsed within the sitemap model 
in openHAB.

Original comment by ch...@cd-jackson.com on 27 Sep 2013 at 10:51

[GoogleCodeExporter]

>> Regarding whether to show child widgets by default or after a tap: I think 
that should be a configurable property for every child widget.

I think that's not necessary. Imagine you want a Switch widget inside ImageMap. 

1. If you want it always visible, just place the Switch widget with X and Y.
2. If you want it to show on tap on some area, you create an Image widget with 
X, Y, Width and Height. As a child of the image you put the Switch widget. You 
can have some value mappings on the Image widget and show different images 
representing the Switch value. Now imagine you put a Slider too, a label, a 
Setpoint widget. Yep, you have now a full Thermostat interface on a click on 
your wall thermostat :)

Original comment by mishoboss on 27 Sep 2013 at 10:53

[GoogleCodeExporter]

Sounds convincing, you're probably right! :)

Don't you think some properties (like font size of labels for example) need to 
be set on every child widget that is placed on the imagemap, regardless of 
whether it's hidden before tapped or not? I probably missed something.. 

Original comment by kristian...@gmail.com on 27 Sep 2013 at 11:52

[GoogleCodeExporter]

> Don't you think some properties (like font size of labels for example) need 
to be set on every child widget that is placed on the imagemap, regardless of 
whether it's hidden before tapped or not? I probably missed something..

I'm not so sure about the font size thing. Please, give a use case when this 
would be needed. I think there should be a reasonable line between 
customization and out of the box UI creation, which is the initial idea of 
openHAB Sitemaps. But lets discuss. I would like to see Kai's opinion too :-)

Original comment by mishoboss on 27 Sep 2013 at 12:06

[GoogleCodeExporter]

I understand your fear, the easy way to get going with openHAB have to be 
maintained. The imagemap should not require a more complicated configuration of 
openhab, unless the user is using new more advanced features.

I think this imagemap together with customizable look of other widgets could 
solve the things that at the moment are restricted in the current user 
interfaces. 

When looking at my Samsung Android phone which has default weather widget for 
example, the clock and outdoor temperature are quite large, while city and 
additional weather forecast labels are small. I think that's a very user 
friendly solution... also found in the Smartvisu screenshots.

Let's say I would like to have a sketch of my building as an imagemap for the 
heating system control page. I've got a lot of temperature information 
available, but I guess the most relevant is the measured average temperature. I 
think it could be rendered with larger font than the other temperatures.

Original comment by kristian...@gmail.com on 27 Sep 2013 at 12:55

[GoogleCodeExporter]

> I would like to see Kai's opinion too :-)
Sorry for being so unresponsive. I am still in SF an have hardly time for 
e-mails.
One remark: I would like to split the tabpane discussion from the imagemap 
discussion. I think these are two different features as tabs are usefule 
regardless of imagemaps and I actually had them in mind from the start (and 
just didn't introduce them as the web-app.net framework didn't support it).
Regarding image maps: I am not sure if I have understood how the nested widgets 
should be (responsively) rendered (and which widget types should be supported). 
I somehow still fear that this will mean a lot of effort to implement and that 
we won't achieve this in most of our UIs. So I wonder, if it might not be 
easier to implement a dedicated (web) UI for this and include it as a webview 
in the other UIs. Could this be an option?

Original comment by kai.openhab on 28 Sep 2013 at 4:15

[GoogleCodeExporter]

You have a lot more knowledge about the technical feasibility than I have, your 
fear is probably justified. In that case the dedicated web UI solution you 
described is probably the best way to go. 

Original comment by kristian...@gmail.com on 28 Sep 2013 at 7:33

[GoogleCodeExporter]

I would really like to see this functionality to show an image and add items 
etc on it.

I could have in heating a picture of heatingssystem with temperatures and flows
same for ventilation system with temperatures and ariflow

floorplan floor 1 with windows / doors/ lamps etc showing their state and 
possible to click to hange state.  Also floor plan could show which part of 
alarm zone that is armed etc

There is a lot of possibilities for this.

Original comment by janannons on 5 Dec 2013 at 2:18

[GoogleCodeExporter]

Original comment by kai.openhab on 5 Dec 2013 at 10:37

• Added labels: To-Github

[GoogleCodeExporter]

has been migrated to https://github.com/openhab/openhab/issues/636

Original comment by teichsta on 10 Dec 2013 at 10:15

• Changed state: Invalid
• Added labels: Migrated-to-Github