Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Room config HTML based app preview
#1
So I've got enough of the new HTML based, room config driven application (which still needs a name because I keep having to type that out) to show off a bit here. So I figured I'd start a thread for ongoing discussion.

It's early days yet, but you can see it shows promise. There's just a few pages, but getting it here means having gotten a lot of infrastructure in place already.

http://www.charmedquark.com/Web2/PostIma...eview1.mp4


It's showing real field data and it updates live and all that. The weather data is just from the simulator so it's not 'real' weather data but it's real data from the driver. I have a field cache scheme so that any incoming field change messages from the server are used to update the cache so that the fields are always available, as with the regular IV.

I'm going for a very neutral look, and simple. There's a common footer at the bottom, with time on the left, connect state on the right, and a room selection drop down in the middle. The time is working it was just midnight when I got to the point of making this video.

I'll keep posting previews here for ongoing discussion.
Dean Roddey
Software Geek Extraordinaire
Reply
#2
So, does the lack of responses mean that everyone is basically happy with what's there so far?
Dean Roddey
Software Geek Extraordinaire
Reply
#3
Not a lot to comment on there but it looks like a good start. How well does it size to a tablet or iphone? Remember that whatever the final layout looks like it needs to be touch friendly.
|Z-Wave|Sonos|Tivo|Hue|Plex|Roku|MyMovies|Echo|
Nest|Harmony|Neeo|LG TV|Smarthings|
Reply
#4
It currently isn't doing anything particular to deal with wide variations in resolution. I'll be using scrollable areas as a means of dealing with varying amounts of content. All of the content should of course readjust, since it's HTML, though how nicely it will do so remains to be seen.

But, the layout and the code are quite separate, so the layout can be improved over time without changing the program itself much at all. We'll see how it does and adjust as needed.
Dean Roddey
Software Geek Extraordinaire
Reply
#5
I haven't been paying much attention to any discussions on the HTML viewer so forgive me if this has been covered...

In my head what's lacking overall is the ability to pick up my Android based tablet and have an experience the same or very similar to the custom templates I have already created. Will the HTML viewer do that eventually, or would we be limited to some auto generated and therefore more basic set of functions?

Would like to understand what to expect for an HTML viewer and might be good to be clear on that upfront to manage peoples expectations on this. Right now, I'm using fairly successfully an RDP connection to a full IV on my Android. It's not really what I want to do, but it is a decent work-around to the Riva issues I had. If this doesn't replace that then to be honest an HTML client won't be of much consequence to me personally (or at least I think that way at the moment without knowing the potential). Not sure if others are there or not. Just want to make sure any hard work you do pays off for most folks and meets expectations/requirements.

Anyways, to answer your question, I'm not sure what to expect overall so tough to comment whether it's awesome so far or falling short. It's a cool concept to interact with CQC via a web browser so that you get the cross platform thing. Just wondering what the trade-offs are going to be to this one size fits all OS's/architecture type approach... for the layman that is.
Reply
#6
The initial phase will be just a room configuration driven client. That's something that will A) serve a lot of folk's needs and B) provide us with a practical chunk to bite off in the process and get a feel for what's involved in creating such a thing. For some folks the IV can serve as the main interface and their need for something on non-Windows for less powerful access from outside the home. And some folks will be happy to use it as is. Some installers may be happy to use it as is to deliver quick but limited solutions to their customers, since they could get the same stuff on both Windows and non-Windows clients easily.

After that is done, or later on in the process of it getting done we'll know more of what's practical and what's not, and can strategize on something more advanced.

One obvious next step would be to take the core bits of the room config app, make it more general purpose, and provide a Typescript interface file for it. This would make it available as an easily accessed tool for creating HTML/javascript based clients. We could then update the room config app to use it, and it would be available for third parties to use via third party HTML design tools, saving them beau coup time, and we could use it as the basis for anything to come.

Creating something for the browser that's really going to rival the power of the IV will be daunting if not outright impossible. The browser environment is just a play toy compared to Windows, and it's pathetic that it's become sort of the only reasonable option for cross platform GUI applications. The IV is enormously complicated and builds on mountains of underlying functionality to do what it does. Even trying to replicate what it does natively on Android and iOS would be very iffy.

And of course all that immediately leads to the issue of how to do you support fully custom user interfaces on the browser platform? We could do a 'convert templates to HTML' type thing, but it would only be able to support the basics, so you couldn't expect to just take your CQC templates and convert them and get all of the functionality.

So, for most folks, they'd still end up doing two different screen sets if they want to support the IV and other clients. So it sort of comes down to, is it more straightforward to come up with a sub-set of the IV functionality that can be supported in HTML, and provide you with a way to limit what you are doing to that subset, or just create a separate HTML oriented editor for HTML based clients. Both of them probably mean two different design phases, unless you were willing (in the first scenario) to limit your real IV stuff to what is portable.

And, creating another, full featured interface editor for HTML would be very daunting as well. It would require essentially a web browser engine to do that. Maybe we could use the embedded IE browser engine and manipulate its DOM to provide a display mechanism for the editor.

OTOH, there's already lots of HTML design tools out there, which could use the generic javascript/typescript engine I mentioned above, and they'd always be more full featured than one we could create, because HTML and CSS and such as become just stupidly complex and crusty after all these years of excremental 'improvement.' They'd require a lot more work to create something useful, but would be open ended (within the constraints of what HTML/javascript is capable of.)

Of course the argument could be made that even if we do a simple HTML editor, that anyone else could still use do their own using third party tools I guess. So we could do a fairly simple HTML editor that knows how to access the underlying CQC stuff, to make it easy to create fairly straightforward stuff. And base it on the same general purpose engine we'd make available for folks to build their own, more complex clients if they want to do it by hand.


Anyhoo, I think that any sane scenario means:

1. You either limit your real IV to a fairly small subset of what it can do, so that you can generate equivalent HTML from the same work.
2. You design two different sets of screens, one for the IV and one for HTML
3. You only use the HTML client and just limit yourself to what's reasonable to do there.

None of those are necessarily optimal. But, unless someone can magically make the browser a vastly less suck-worthy environment, I don't see how it can be anything other than those options.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Preview of new Web based RIVA client Dean Roddey 424 27,624 10-18-2017, 07:37 AM
Last Post: Dean Roddey
  Alexa/Echo: AWS/Lambda config of myCQCHandler test fails KenC 8 602 09-27-2017, 07:55 PM
Last Post: Dean Roddey
  SOLVED: Media System Config Issue agarden 3 760 04-29-2017, 07:25 AM
Last Post: agarden
  HTTP-based Trigger Driver Docs znelbok 5 988 03-11-2017, 09:34 PM
Last Post: Dean Roddey
  Echo Config file issues rbejr 14 2,086 01-16-2017, 10:05 PM
Last Post: rbejr
  Cant find room generator in v5 and looking for v5 templates ghurty 6 1,035 01-08-2017, 07:53 PM
Last Post: ghurty
  Upgrade to 5.0.1: Local config object store Jnetto 2 743 11-20-2016, 06:12 PM
Last Post: Dean Roddey
  5.0 Preview Stuff Dean Roddey 108 7,274 11-01-2016, 11:06 AM
Last Post: Dean Roddey
  Tip o' the Day - Custom HTML clients via Websockets Dean Roddey 9 1,138 08-23-2016, 06:25 PM
Last Post: Dean Roddey
  1-way HTML/CML Macro questions IVB 15 2,280 05-08-2016, 07:49 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)