Premise jQuery Mobile MiniBrowser UI - Preview

[123]

Good to know; I was going to ask you if it scales well.

AutomationBrowser has two important architectural advantages over MiniBrowser:

Plugins
Each Premise object's appearance is defined separately, as a Plugin, and not within AutomationBrowser's code. Being independent, Changes can be made in one without affecting the other. I tried to mimic this concept in MiniBrowser, and it works more or less, but is not as modular as AutomationBrowser's Plugins. For example, a custom object must call the mbRenderHeader and mdRenderFooter globalscripts otherwise the resulting page is incomplete. This is housekeeping stuff that should not be handled by a custom object. The other thing that MiniBrowser lacks is the ability to render all standard Premise objects. It renders the 'usual suspects' and skips the rest. I added an enumeration to 'register' the objects it handles in an attempt to prevent overlap when MiniBrowser is enhanced by multiple developers but, again, not as flexible and slick as Plugins.

SysConnector
AutomationBrowser does not have to continuously poll the server to get updated status. SysConnector, albeit limited to use with IE, is a clever technique to deliver status updates only when status changes. The backend has far fewer requests to handle when the frontend is using SysConnector. This is more important that one may think. All Modules execute in a single thread. When servicing the frontend via AutomationBrowser or MiniBrowser, no other Module is being executed. Judicious use of "on error resume next" helps prevent buggy code from causing the interpreter to pause and suspend all Module execution. Similarly, a MiniBrowser that is busy as heck servicing polling requests, will cause other Modules to 'wait their turn' and seem slow. Premise is quite fast on modern PC's but it important to understand its limitations. There is no profiler available to give visibility into what is consuming Premise's time so that's why I like to test my apps on a slow PC. If it makes it suffer then I know I need to optimize it. I think polling a single object isn't going to cause problems but you should be aware of the potential problems it can cause if, for example, a UI page attempts to display and poll all lights in a home. The existing Status page, something I introduced to both AutomationBrowser and MiniBrowser, comes darn close to this scenario except it currently does not poll the objects in MiniBrowser (Sysconnector takes care of efficiently updating the status in AutomationBrowser).

 

[w84no1]

That was my main concern when I started using polling to get the system status. I will make sure that I set the polling interval higher for the status page or maybe not poll at all. I have a pretty slow laptop that I can use as a test. I guess it pays to have some very old machines laying around, I wish I could convince my wife of that

 

[etc6849]

Awesome! It looks like I'll have a use for my HP Touchpad, that is assuming you're kind enough to publish your work

 

[Timoh]

I'm hoping to make polling a thing of the past...
The foundation of my project is a serverside javascript engine... Actually it's the Chrome v8 js engine. There is an open source project that has a rather nice implementation.... nodejs. Nodejs makes the v8 js engine extensible. There are ton of modules written for nodejs... Everything from logging, to db access, to css engines, to email, ftp, json, + + +

Nodejs comes built in with a messaging bus, subscriptions, notifications, websockets, and http server.

My plan, which I should be able to validate in the next few days... Is to wrap the Premise COM objects/MiniBroker in a C++ nodejs module, and expose them to nodejs. WHat does this mean? Serverside javascripting for Premise. ANd more importantly making Premise available to all the features of nodejs including a new webserver, websockets, subscribe/notify of changes (instead of polling).

Disclaimer...
Keep in mind though... I am not a Premise user yet... And I really don't want to generate hype at this point... I'm just tinkering.

Tim

 

[123]

..
Disclaimer...
Keep in mind though... I am not a Premise user yet... And I really don't want to generate hype at this point... I'm just tinkering.

Tim

No worries, Tim. I can point you to at least three other threads on this forum where someone displayed a new UI that was either never completed or not shared with the community. We're Premise users; we've heard it all before and won't be surprised if nothing materializes.

Having said that, I like your vision and sincerely hope you pursue it. Off-loading "User-Interface Management" to a separate system, based on progressive and evolving web-standards, is a good strategic move. It allows Premise to do what it does best, automation logic, and move UI rendering to rapidly-evolving web technologies (well beyond the capabilities of Premise's internal web-server).

I believe it will take a fair bit of time and effort to achieve your goal but it is worthwhile. In the interim, w84no1's work on MiniBrowser provides a near-term solution for providing an attractive, modern UI based on open standards.

Good luck and let us know if you need our assistance; we're rooting for you!

 

[Timoh]

Progress...

I just connected to the MiniBroker COM server with a javascript call. Sweeeeeeet
OK... Actually a c++ call wrapped in javascript.


Next up... write the next wrapper to connect to the Premise SYS server. (servername, user, password)
That will be the final step in my proof of concept. if it works, I'll go into "production" and should be able to bang out wrappers for the entire minibroker COM pretty fast. (Whatever "fast" is). We'll see.

Tim

 

[w84no1]

Good to hear. At that rate you will be finished before I will

 

[w84no1]

The thermostat is finished.

 

[Waynedb]

Great job on the UI, I moved on from Premise but I am glad to see all the new developments.
In my opinion Premise just lacked two things a decent GUI and some more driver support for
newer hardware, Premise is still an excellent H/A program even compared to the much newer
software out there.

 

[123]

I like it.

And I have a few suggestions.

All just my opinion; take it or leave it. I made a mockup (attached) incorporating my suggestions.

• The widgets are nicely balanced in your version except for "80°F SetPoint". It seems like a phrase out of place rather than an integral part of a widget; neither fish nor fowl. I suggest moving the setpoint value in between the Up and Down buttons. I believe it doesn't need to have a title to be understood that it is controlled by the Up/Down buttons and represents a desired temperature. The area needs to be wide enough to handle Celsius values (like 21.5°C; always incremented by 0.5).
• The right-hand side of the three rows of buttons ought to be aligned (see mockup) and not ragged.
• I assume the large "79.7°F" represents the interior temperature. I'm not entirely happy with my suggestion (looks busy) but it clearly indicates Interior/Exterior temperatures.

 

[etc6849]

Nice work on the UI! I had a few non web developer dummy questions now that you're almost complete.

With Minibrowser, I went as far as to make my own Android app to display it to avoid having to pinch and zoom, force caching etc... However, using fast 3G, the page still takes a second to load and using a slow connection maybe 5-10 seconds!?! This always puzzled me as I enabled caching when I built the webview app and I would have thought the Android SDK would automatically cache images as the Android SDK claimed...

So I have to ask in anticipation: how fast do your pages to load on 3G? How much of this beautiful interface is made up of images? I'm hoping not much?!?

Also, with Minibrowser, based on its programmatic flow, it would always reload the page after I did something. This made the 5-10 second load time even more annoying on my cell phone. It appears you are using javascript, or more precisely jQuery, to do most things, so I'm guessing this means that the entire page does not need to load following an action?

I originally tried making an alarm keypad (before 123's latest minibrowser was out), but quickly learned that having the page refresh after each button press wasn't going to hack it on a 3G connection. I ended up banging my head against the wall until I force taught myself enough javascript to make a basic keypad.

Also, how modular is your jQuery code? Will there be a way to add jQuery functionality for a new device without also creating a new version of your jQuery module?

 

[w84no1]

The 3G load time is very fast and the only images I have used are the icons for the locations and devices. None of the controls are images, they are all built-in jQuery Mobile controls. There is no need for the pages to refresh as they use ajax to send and receive data from premise.

Right now the code is pretty rough. After I have everything working I will go back and clean up the code. To add my UI, I added my code to all the

if sysevent.ClientSession.UIAdvanced then

blocks on the mbRenderPage for each class. So to add a new device you would just add the jquery to the mbRenderPage of the new device.

 

[w84no1]

I like it.

And I have a few suggestions.

All just my opinion; take it or leave it. I made a mockup (attached) incorporating my suggestions.

• The widgets are nicely balanced in your version except for "80°F SetPoint". It seems like a phrase out of place rather than an integral part of a widget; neither fish nor fowl. I suggest moving the setpoint value in between the Up and Down buttons. I believe it doesn't need to have a title to be understood that it is controlled by the Up/Down buttons and represents a desired temperature. The area needs to be wide enough to handle Celsius values (like 21.5°C; always incremented by 0.5).
• The right-hand side of the three rows of buttons ought to be aligned (see mockup) and not ragged.
• I assume the large "79.7°F" represents the interior temperature. I'm not entirely happy with my suggestion (looks busy) but it clearly indicates Interior/Exterior temperatures.

I like your changes and I will try to incorporate them. I have ran into a problem as I have been doing all my testing on my chrome browser on my PC. I loaded the thermostat on my Android phone and the buttons wrap. I might have to re-do the entire layout again.

 

[etc6849]

Sounds like a job for notepad++ I'm sure you've used this method already, but just in case...

You can export the minibrowser module as an xdo file using Premise Builder, then rename the file extension to xml. Next open the xml file in notepad++. When you're done, delete minibrowser from Premise Builder and re-import the xml file.

 

[samgreco]

Actually, if you installed Notepad++ with Explorer extensions, just right-click the file (nearly any file) and select "Open in Notepad++. I do it constantly