Hack the HTML or start from scratch?

I've been trolling on this board for months while I saved to buy/install all the (Insteon) devices I needed to build the system of my dreams and I'm finally ready to build the interface/UI for my control pages. Trouble is that I'm a UI designer and HTML/CSS hacker and I'm not going to be happy with my system unless the UI is a little more polished and fancy than what I've seen from Indigo so far. Specifically, I'm looking for the kind of animations, pop over effects, transitions and expandable containers (etc) that have been standard on the web and in App/UI design and I'm trying to figure out how to get that from a control page.

I'm planning to use a mix of wall mounted iPads and/or Android tablets to control everything I'm thinking that HTML is the solution because:

1. it's device agnostic and easy to build responsive layouts

2. there's already a mature set of Javascript/CSS modules to borrow from for animation

3. there's opportunity to extend the interface easily -- not that I need to, but I could iFrame a Netflix window or include (and style) some widget built for the web with dynamic data

4. I'm already familiar with most of the tool set

What I'm trying to figure out is the best way of accomplishing this. My thoughts are:

Option 1
Compose most of my control panels in the Indigo interface then export/render them to HTML and then tear them apart and hack the rendered HTML back together again with CSS/HTML/JavaScript overrides as needed. I read in a previous post that this is possible, but dicey because server updates will likely break any custom work and require a rebuild/restore of the revisions I've made.

Option 2
Use the REST API and build the HTML from scratch. This sounds like the best solution, but I'm not sure where to start? I found the Indigo RESTful Overview (http://wiki.indigodomo.com/doku.php?id= ... ful_urls&s[]=restful&s[]=api) but I'm stumbling to get out of the gate.

I guess I’m wondering if anyone has attempted either option and can provide any guidance or suggestions about the best approach to take?

Are there any performance issues that stem from using HTML instead of control pages?

Additionally are there any red flags that stand out or reasons that make this idea/plan bad?

[jay (support)]

Control pages are stored in an internal format and are rendered natively in Indigo Touch for iOS and as HTML in Indigo Touch for the Web. The RESTful API is also delivered by the same web server (Indigo Web Server or IWS) that delivers the the web pages.

I wouldn't go with Option 1 at the moment. We will be doing a major rewrite of IWS in the future (after Indigo 7) to move it from an older internal API to the Indigo Object Model (IOM). Any templates that you would modify would likely need fairly significant updates to work, and honestly it might even require a rewrite (it depends on how we decide to deliver the IWS update). In the meantime, any templates you modify would have to be reapplied to your install after an Indigo upgrade.

Option 2 is the safer approach since we will maintain backwards compatibility for the RESTful API even beyond the IWS rewrite (we don't want to break clients that use it for obvious reasons). Assuming you'd be using AJAX to build your web site's communication, you'd need to be able to use HTTP digest authentication from JavaScript to talk to the RESTful API. I'm sure there's a way to do it but not being particularly fluent in JS I don't know what it is.

Compose most of my control panels in the Indigo interface then export/render them to HTML and then tear them apart and hack the rendered HTML back together again

Been there, done that, don't do it. It's a mess to do and breaks easily.

Either way you'll be up for a lot of work. The REST api is pretty good but might still cripple you in certain places and isn't as speedy as using Indigo's built in pages with their integrated web server.

Yeah, I did a little more research after Jay's reply and just the setup and basic build out sounds like a fair amount of work. I was really hoping someone would chime in with some foundational work and offer up some sample HTML so I wouldn't have to invent/research all the back-end pluming and what-not . But it sounds like I'd be on my own for the majority of the build out . Plus, it sounds like the Rest api doesn't offer some of the advanced features or expose features from some of the plugins I was planning to use.

I'd really like to build in some slick animations/effects to enhance the UI/UX but now I'm thinking it may not be worth the effort -- at least not on a first go-around. Guess I'll have to design the hell out of the interface instead of relying on effects to enhance the cool factor for now.

Ok, new idea...

I'm thinking I can get a pretty rich interface with effects and transitions in an HTML shell that loads the web versions of control pages as iFrames. The buttons and controls wouldn't animate, but everything else around them could. In theory, I could publish several small control panels and then display them in multiple iFrames on the shell then hide/display them with Javascript and CSS as needed.

In theory, this would also allow me to mimic a "responsive" design that handles both horizontal and vertical pages because the shell/browser would manage the page layout and my mini-control pages would just display as modules which can be restacked or moved around as needed -- potentially even hiding/displaying different versions of a control page based on the screen orientation (a bit messy, but dooable).

Any thoughts about how the web server built into Indigo would perform with say a dozen control pages being requested every time this shell gets loaded into the browser? Then with 5-8 panels within the house all serving this shell page? Even if they all fired at the same time, that's under 100 requests - which is nothing for a web server (though granted a mac mini isn't typically the first choice for a web server).

[jay (support)]

Probably would be fine - we use CherryPy which is a very minimalist server. You can always do some load testing before you build anything complex just to prove how fast it will be.