| Forum: System Design |
 |
28. Jun 2008, 17:11 CET | Link |
By now it should be obvious that there are a lot of Home Automation platforms out there. We put together a list of like 10 and didn't even scratch the surface. Although I'm not familiar with all of them, the one thing I think openRemote can do that will really differentiate it from all the others is with the user interface.
The iPhone/Touch is the most obvious remote right now and for good reason. It is an exciting new way to interact with technology and everyone wants to interact with all of their technology like they do on the iPhone. It is also a good price point and does enough other cool stuff that makes it a good value.
But I believe the key to taking advantage of the new interface is to forget about how other touch screens work. Putting buttons on a screen that people press is only the beginning and whenever possible it should be questioned. My favorite example is navigating a menu on the TV's screen. If you only had buttons on the iPhone for up/down/right/left/enter, in order to navigate the menu on the TV's screen you'd have to constantly look up to see what you were selecting on the TV screen and then down to make sure you were hitting the UP button with your finger on the iPhone's screen. Traditional touch screen remotes got around this by using hard buttons that could be felt so you didn't have to look down. But with the iPhone we don't have hard buttons, but by using an actual iPhone application instead of a web UI you could take advantage of the swiping feature. So you'd swipe up anywhere on the iPhone when you wanted to go up on the TV's menu, you'd tap the screen anywhere to select.
That is just one example.
But unfortunately a functional interface isn't the only important factor in designing a successful HA user interface. The interface must be attractive. There is so much HA software out there that works great, but is down right ugly. Lets face it, for the most part HA is a toy and most people want their toys to look cool.
I think it is still function before form, but it has to be considered.
Looking forward. No project can be everything to everyone right out of the gate, but if designed properly it can be one day.
As great as the iPhone/Touch is, it isn't for everyone. Maybe you want to use another cell phone, maybe you already have an in wall touch screen that runs Windows CE. Maybe you want an in-wall touch screen because it looks cool and you want to impress your friends when they come over. Maybe you have a Nokia N800 and you are still looking for things to do with it. It doesn't matter the scenario, but if you can imagine a device in the home, someone is going to want to use it to control their HA system.
So while I think the initial focus should be on the iPhone/Touch UI, I think it is very important to implement it in such a way that adding a variety of clients later on down the road is more important for long term success.
The guys I'm talking to about a new design of this website - which by the way we'll roll out next week - are very interested in this aspect as well. They are reading this but are too shy to register so far :) Well, I worked with them in the past at a company that had a good reputation for pretty and functional UI work and I'm sure we'll involve them at some point.
From experience I know that it will be a challenge to get C hackers and Java middleware guys to even care about these kind of issues. I'll just say that there is at least one other person registered here so far who completely agrees with what you said.
I could argue but I'm no good with user interfaces (I don't have a touch screen phone, maybe later). My view on home automation is that a lot of it should be hidden behind the scenes. An example. in my living room are three lamps. One is connected to an Insteon lamp module, the other an X10 module and the third an Insteon appliance module. The appliance module will automatically turn on 15 minutes after sunset and off at 15 minutes before sun sunrise. But the Insteon Lamp module is set such that if you turn on the lamp connected to it the module knows, tells Misterhouse that the lamp was manually turned on and Misterhouse then turns on the X10 module and the Insteon appliance module. The same holds true if you turn it off. I still have the web interface to manually change the setting but the lamp makes a good remote.
Now having said all that, the user interface is extremely important. The end user thinks that is the home automation. If it's bad then the home automation is bad. Now a touch screen is very nice and the IPhone has that nice interface (where you can slide your finger across the screen and thumb through things). I think you might be interested in this interface one user came up with for Misterhouse (but not the iPhone) called TIMO. It's not perfect but the turn table type interface is interesting.
Author: Linux Smart Homes For Dummies
Speaking of, Christian, I think the current wording and presentation doesn't make it to register. We should have EXPLICIT words to say anyone qualified is WELCOME to join. This is why the may help. Explicit words on could be good. If you want me to work on it, i will, but I will come up with something along the lines of ;)
Get your friends to register!!! we need to grow even in stealth!
Ben, I think what you are suggesting is to use gestures. If you move your thumb in a Z pattern do this, S pattern do this, up/down this, left/right this ... Also you want the ease of Tivo or the no deeper than 3 clicks for information on a web site type setup. Of course this is my view on what you are saying, I could be wrong.
There are several other things that are important, one is something that's already been brought up and that the device database. Add a new device, pull down the info from the openRemote web site.
Yet another important feature is the HA language that works inside the HA server. It's got a be a basic if/then/else but it needs the capability to rip strings apart (including binary data, so lets loosely include that with strings). I haven't stared to figure this out yet as I'm not software architect. Basically my thinking is that the HA server needs to manage modules/device IO, handle the HA Language and interface with the user. Where the modules are things like X10 modules, digital/analog IO, or information from the internet and the devices are the specific interfaces to those modules.
Author: Linux Smart Homes For Dummies
Neil, you are absolutely right about the need for a scripting language. It is however a separate discussion from this one if I am not mistaken (and feel free to correct me if I am). The Scenes/macros will be developed on the website (or swing app or whatever) which is what Christian is referring to with his friends, who hopefully will be registering soon.
Model View Controller is what us Java puppies like to talk about as separation of concerns. You are squarely talking about the Controller part.
I like what I am reading Ben, this is the sort of functional thinking that you need to develop to help us succeed. And that is just it... do not leave at but do go through the pain of putting together a UI USE CASE (see what Juha does on that front). I mean it, I am sure you have participated in other OSS efforts, but when you are that close to the core you need to put your thoughts out there. So here is the challenge: DIG INTO THOSE IDEAS! DIP YOUR TOE IN A DESIGN OF SUCH AN INTERFACE. When we go public you will see people starting to comment but if there is nothing it will float. Anchor your flow of ideas with a document that we can share on this site. I love the idea of gestures to command. Maybe think about the UI with a on the screen? so you you use buttons and have a gesture area, I don't know, try to put something more concrete. I believe you are onto something my friend!
Right on! I think Michael Yuan is there with you. He has designed the iPhone interface but has been talking about the cellphone interfaces as well. This is where he works professionally by the way so he knows a bunch about this. I am surprised that he isn't participating more, maybe he doesn't get the reader feeds? BTW the feeds are the best way to keep abreast for me, we should be explicit on the website.
But anyway you have got the steps in the right order, iPhone as a draw, then other interfaces will be supported. My recommendation there is to see what level of interest there is from our community. Sure everyone will ASK for whatever UI device they use to be supported but in true OSS fashion we should wait for the contributors to come out of the wood-work before we take extra work on seriously. If there is enough of an itch to scratch we will definitely provide help.
Keep it coming guys, this is moving at light speed.
We don't need to worry about getting a single UI -- there will be many. Not only for many different devices but multiple alternatives for the same device.
Because you just can't get everyone to agree on a single approach.
And that's a good thing, that's where the power comes from. Innovation from the community and users. And no proprietary vendor is able to match that.
The good stuff will float and the shit will sink. There will be the popular ones and the niche ones. We just need to make it real easy for everyone to contribute and help orchestrate.
Separating client concerns is in our DNA.
Juha Lindfors
Co-Founder OpenRemote
Join OpenRemote Chat
I understand what you mean, but at the same time I believe the UI will symbolize the entire project. Many Engadget readers just look at the pictures and will only click through for something that cool. Yet another iPhone remote UI isn't going to cut it.
The other point I was trying to make you picked up on. The design needs to be done in such a way that makes it easy for others to customzie the look, the functionality, and even the client.
Hello Ben,
I'm not disagreeing on eye-candy :-) Sure things need to look pretty. I'm more making the point on the different UI paradigms, if buttons on the screen, gestures, something else -- these I believe will be fine-tuned by the users turned into designers (or maybe some users are designers).
Once a workable UI paradigm gains traction, adding eye-candy to it is the lesser problem of the two. E.g. once you decide that folders are your UI paradigm then you keep incrementally making those folders look prettier and prettier ;-)
Having said that, for the initial push to gain attention, yes we do need to make a good first effort.
So I believe we are in agreement :-)
PS. reminded me of a demo on how to look at your desktop a little differently
Juha Lindfors
Co-Founder OpenRemote
Join OpenRemote Chat
Excellent.
Ben keeps talking about a programmable PHYSICAL device. I found the idea interesting. If anything at an home infrastructure level. Imagine a reference implementation of a user device like we are doing the specification of a reference implementation on the server. A Physical pod station, can communicate with your remote, maintain it. Point being we control the software stack that is running on it. There is a certain quality to a pod station, attaching hardware devices to it opens up custom programming applications for UI interaction.
Ben you should open this discussion under the section. I don't even think these depend on the the existence of pods, if they can in fact talk IP.
If in fact domotica (home-tech in the US) is looking for physical device to drive this then having profiles programmed on it could be an interesting idea. Once we have separated this concern, if someone can come with a compelling device to drive this, or at least the software infrastructure to achieve these profiles, then it is a valuable contribution, enabling the home-infrastructure field to implement on a Open platform.
The iPhone is an interesting excercise for everyone when you think about it, forcing us to rethink the physical device in my hand as a programmable platform and therefore a programmable remote. All of the sudden the hardware is the platform and its software programming interface is somewhat open (HTML and Cocoa).
Neil is still talking about the PODS as a hardware server that open a tons of possibilities for domotics. Hometech based on wifi pods, the last strech problem is being taken a whack at.