News from March, 2009

Working on forums today – not the implementation but the style and layout.

Couple of people (Marc Fleury and Neil Cherry) already pointed out that they couldn't tell the difference between what is a forum page and what is a wiki page. There's a reason for that – they are actually one and the same.

It makes sense if you think about it – you have wiki pages with comments on them and forum posts with replies to them. As a software engineer it is pretty trivial to recognize the common model there. So a forum post becomes a very short wiki page (usually with a lot of comment activity). Or perhaps a wiki page is an elaborate forum posting?

Doesn't make a difference really. What we have are root (or parent) documents and child documents.

This is actually a design I spent thinking about a couple of years back when I last time checked community collaboration software. Why do we need a separate wiki and forum softwares? Or even a separate blog or issue tracker software for that matter? They all work on the same document model.

Anyway, the Confluence forum plugin we are using is still very new – a bit raw. And the initial raw look gives a very little feeling of a traditional forum functionality. Hence the attempt to enforce that with some styling, to give people the look and feel they expect. We will see how that works out in the end.

I have to admit though that the forum part of the software we chose was my biggest concern when we started. It won't be a match for established forum software that is already out there. I like however the fact that I get search index and single sign-on integration for "free" with this solution so I hope in the end, as the software matures, the forums will also be "good enough".

Going through a process of discovery here.

I remember going through the CSS2 specification a couple of years back. Liked what I saw, there were a lot of elements there that I felt were missing in CSS1. All in all looked good, a worthy addition.

Then I went and tried it on web browsers. Not much of it worked. Slightly dismayed, decided to forget the CSS2 spec for some time. The browsers needed to catch up.

So last couple of weeks I've been forced to go through the paces with CSS1 again (the website you're staring at). Things seem to work reasonably well. However, some things still feel clumsy when restricted to CSS1 alone (like the lack of min-max widths). So I decided to take a peek at that CSS2 thing again. Well defined, complete, a nicely written specification from W3C.

Then picked up one random CSS2 element and tried it. Of course it happened to be the ill-fated (more on that in a bit) text-shadow property. And of course it did not work on either IE7 or Firefox.

After cursing a while about the lack of CSS2 support, I decided to investigate a bit more. I wasn't surprised IE7 wasn't supporting this property but was surprised Firefox ignored it as well. Despite few bugs here and there, Firefox in general attempts to make some effort to be specification compliant.

So it turns out that the Revision 1 of CSS 2 (a.k.a CSS2.1) dropped the text-shadow property completely due to lack of browser support. Bummer. However, it looks like text shadow is now making a comeback with CSS3! Found some information and samples on how Firefox is implementing it, along with some interesting info about other shadow effect extensions (the shadow-box looks much more interesting than shadow-text, in my opinion).

Of course very soon the realization hit that it will take another couple of years for all major browsers to get to CSS3 level. But I am ever the optimist!

Couple of interesting quotes from this article that highlights a lot of the recent discussions we've had on chat.

Especially when entering a new market, the question of what functionality to include in a product and what to leave out is critical to a timely and successful product launch. Leave out too much and the product flops. Put in more than is necessary and costs and schedule balloon.

The second sin can in fact be worse than the first because you delay engaging real customers with a real product by bloating the requirements and hence learn more slowly what is really important.

I think we are right on track with iPhone app driven development. Just to update everyone since we've been quiet for so long these will be iPhone apps for KNX and infrared control. We can quickly gauge user interest on the product and create IP based integration without additional setup. The requirements from panels and integration (and some high end functionality) will drive the controller requirements.

So we will have a layered product release strategy:

1) Panel software

Simple integration over IP to HA systems that have proven, stable, documented IP gateways.

2) Controller

Following #1, introducing integration to other I/O (serial, USB), leverage existing software like LIRC, serving generic web console interfaces, simple scheduling with a low end controller hardware.

3) Full Integration

Controller bridge between control protocols (X10, KNX, INSTEON, et al), 24x7 high availability with clustering and replication, remotely managed and dynamic software updates, diagnostics and monitoring.

We are working on #1 at the moment.

As the site migration progresses, we've reached a stage where it's ok to let visitors to take a peek. A lot of things remain to be done but certain base functionality is already in place.

The DNS records have been mostly updated to point to the new site. This means new visitors should land to the new site instead of the old one. Some old links will no longer work (we haven't redirected any of the old links). There are certain DNS lookups that still point to the old site, mostly for backup.

On the DNS side, I would still love to have some redundancy set up for the DNS servers but that will have to wait for now.

A guest member popped in on our chat the other day and asked screenshots of the software. While we haven't released anything yet, we are fast approaching our v1.0 prototypes (or should we call them betas?) and can share some shots of them. Admittedly, with all the work going on updating the website we haven't done a good job of updating the community with all the other work that has been going on in software side. We are slowly working to get back up to speed on keeping the community up to date (and getting the code to a shareable state) and will work on getting more complete status updates on the site. The shots of today are from the iPhone user interface composer. While the software hasn't been released yet these are shots from a functional application (with Beehive integration) and not merely mockups.

Screenshot of X10 macro composition in UI Composer (click for larger image)

What is User Interface Composer?

UI Composer allows you to place user interface components and create layouts for your remote panels.

While eventually we plan to support different types of panel hardware (with a generic web console interface) the first iteration of the UI composer is solely focused on creating layouts that are suitable for iPhone and iPod Touch consumption.

The UI composer at the moment allows you to select your infrared remotes from Beehive database, pulling the remote control button information from a LIRC configuration file and allowing you to place the buttons into your iPhone layout. You can either place the infrared buttons directly or compose them into a simple macro which you can place on the user interface instead. The benefit of using LIRC here (via Beehive) is that there's a good chance somebody from the community has already "learned" the buttons of your remote, you can choose your remote model and be instantly ready to go.

We've also added a simple mechanism to enter X10 and KNX commands as buttons in the UI composer. Initially the use of KNX or X10 will require you to have somewhat intimate knowledge of device addressing of each system but we don't anticipate this to be a big issue for our early adopters. Importantly, this step will let us get the required scaffolding in place to start developing more detailed modeling tools for home and building automation. While the first iteration only uses direct user input (X10 or KNX) or infrared configuration from Beehive as input, later iterations of UI Composer are likely to get information of available devices from a modeler tool that may contain full floor plans, lights, HVAC, A/V device information of the building you want to control.

The Shots

iPhone console layout, UI for infrared, KNX, X10, and basic macro composition (click for larger image)	Selecting remote control vendor and model for infrared UI (click for larger image)	Simple X10 UI creation (click for larger image)
Basic macro composition (click for larger image)	X10 button input definition, macro composition and UI layout (click for larger image)

Next blog will describe the OpenRemote design in a bit more detail – how Beehive, UI Composer, iPhone console all work together.