Premise jQuery Mobile MiniBrowser UI - Preview

Motorola Premise
I'm not sure whether I want to cry, run to the top of a mountain and scream, or simply sit and worship the screen shots.

I am jealous.

I am thrilled. Beautiful work W84!!!!
 
... to cry, run to the top of a mountain and scream, or simply sit and worship the screen shots. ...
I vote for constructive criticism.

How does everyone feel about the proposed Light UI? It no longer displays a numeric Brightness indicator (i.e. 75%). The slider's relative position is the sole indication of Brightness. Is this satisfactory?

I like the numeric indicator but, quite honestly, believe it is useful only when setting the Brightness. Ideally, it would appear only while operating the slider. Once the Brightness has been set, there's no need to display the numeric value. I don't know if the slider widget has this ability to automatically show/hide its magnitude.

PS
W84no1,
What happens when this new UI is displayed on a PC or tablet or anything else with a horizontal resolution of 1024 or greater? Do the widgets:
Stretch horizontally to fill the screen from left to right margins.
Stretch horizontally to a preset maximum width.
Retain their current width and appear in the center of the screen.
 
How about if we compromise and provide some constructive comments? ^_^

There is/was an initiative to move towards a cross-platform UI for jQuery based apps. I'm not sure where that initiative is at, but the industry seems to be picking up on that theme. Although W84's may/may not scale (he'll let us know), I think having the UI building blocks would allow a customized desktop, or tablet, version with the brains of your MB to be developed.

I have a tablet root (case #3) that uses different graphics, menus, etc (thanks to your MB genius of providing extensibility!) - so I would expect to do something of the like if it doesn't scale. I think the additional landscape on a tablet allows more drill down on features ( e.g. on a mobile device, I may only want vol/power/inputs/ for a receiver, where on the tablet, I want surround modes, tuner options, and all of the other gazillion features I have yet to use...)
 
I vote for constructive criticism.

How does everyone feel about the proposed Light UI? It no longer displays a numeric Brightness indicator (i.e. 75%). The slider's relative position is the sole indication of Brightness. Is this satisfactory?

I like the numeric indicator but, quite honestly, believe it is useful only when setting the Brightness. Ideally, it would appear only while operating the slider. Once the Brightness has been set, there's no need to display the numeric value. I don't know if the slider widget has this ability to automatically show/hide its magnitude.

PS
W84no1,
What happens when this new UI is displayed on a PC or tablet or anything else with a horizontal resolution of 1024 or greater? Do the widgets:
Stretch horizontally to fill the screen from left to right margins.
Stretch horizontally to a preset maximum width.
Retain their current width and appear in the center of the screen.

123 et al,

Here's a link to a slider that I've been working on for a custom UI in Indigo - just html5 and CSS3, no Javascript so it'll only work on more recent webkit-based browsers (iDevices, BB Playbook, Android ICS, Chrome, etc.)

It does similar to what you mentioned - a tab slides into view when you start adjusting the slider showing the amount and then hides when you release. It's still a work-in-progress but feel free to dopy the slider.html and style.css files and use then however you want if they're of use. You can most certainly duplicate this with jquery, but I'm shooting for a tiny codebase for fast response on low-power devices.

Terry
 
The UI will need some tweeking for larger displays, the good thing is that it can be done all in css.

I thought the same thing about the slider, I just haven't added it yet.
 
Terry,

Thanks for the example. That's what I had I mind but without the added flourish of the popup tab. Numeric value appears when you need it and quietly slips into the night when you don't. FWIW, it works on my PlayBook but the tab occasionally wants to disappear before I've finished moving the slider.

W84no1,
I was afraid of that. The UI expands to the point of becoming awkward. A button that's a thousand pixels wide is an atypical widget. The thermostat has lost containment and it's parts have spilled out. Is there any way to restrict the maximum horizontal width? Can the widgets sit within a "carrier", or canvas, whose size can expand horizontally by a fixed percentage but no further? Or no expansion at all?

Chuck,
From Wikipedia: Criticism is the practice of judging the merits and faults of something or someone in an intelligible (or articulate) way.
If anyone wants to criticize my criticism, I welcome it. ;)

FWIW
The stock MiniBrowser supported one UI and it was ppc (Pocket PC). Rob Brun made a copy of the MiniBrowser, tweaked it and created xBrowser or simply XB. He did it at a time when Premise was a live product and new versions were being released. Modifying MiniBrowser was a bad idea because a new release would potentially overwrite one's modifications. More recently, Chuck made a second copy of MiniBrowser and customized it for the iPhone.

Three copies of the same code seemed inefficient. Premise was no longer being updated so I set out to integrate XB and iPhone into MiniBrowser. Along the way I cleaned up the code, added support for more objects, cleaned up the UI, and put a touch of extensibility in. The result was a unified codebase that could produce three different appearances. Actually, the three UI's were very similar, it was the same codebase after all, and simply the size of the icon grid varied from one to the other (and icon set).

Today, I'd scrap all three UI's in a heartbeat and trade them in for just one. The focus should be faithful to MiniBrowser's original purpose, namely create a UI for a handheld PC, a mobile device. I feel the focus should be to support smartphone screens. When viewed with a higher-resolution device, it should either retain its original size or increase slightly (a little extra whitespace) but not scale to the limits of available resolution.

I like the idea of an intelligent MiniBrowser that detects the available canvas size and delivers more widgets if suitable. Definitely something to consider for a future version. To allow for this capability in the future, today's MiniBrowser must ensure its widgets don't expand and occupy all available space.
 
Just wantin' to make sure we're not discouraging the new (and talented) new guys...
 
I can't take all the criticism!! I give up!

J/K :rofl:
Here is the road map for the jQuery Mobile UI:
  1. Get everything working so that you can do at least everything you can do with standard MB
  2. Get it to display correctly on mobile devices
  3. Tablet Display
  4. Computer/Big Screen Display
  5. Clean up code so that it is easy to follow and customize
  6. Add bells and whistles
  7. Release code

My goal with this project is to have an interface that I can use to replace Automation Browser. All of my control devices are either Android or iOS devices. I don't have any PC's that have a touch interface.

As for the criticism, it is very useful. I am a Premise/Home Automation noob, I don't have any devices that I currently control with Premise, so I need you guys (that actually use the software) to guide me in the right direction. And if I write the code correctly, then it should be easy for those that want to change the look of it to be able to without much effort ;)
 
I have adjusted the font so that it will display 3 place values, a decimal value and negative values on the smallest screen I have which is the iPhone 3g.
 

Attachments

  • therm.JPG
    therm.JPG
    27.9 KB · Views: 43
Looks good.

Regarding the road map, may I suggest you include a few beta releases. You've indicated that you do not have several of the physical devices needed to fully test the UI. There are many Premise users here who have the devices plus many years of hands-on experience. We can catch any glitches early in the development cycle. For example:

Are you modifying a copy of MiniBrowser's code or the original code? I hope it is the original code and not a copy.
 
You're good.

Every element in a Module (class, methods, properties, etc) has a unique GUID. If you make a copy of a Module, all of the copy's elements get new GUIDs. This is precisely what you want when making a new driver for device Y based on an existing driver for device X. However, if you want to upgrade a driver for device Z, you must work on the driver's original code and not a copy. This is how you are currently handling MiniBrowser and that's perfect.

What I've said may seem obvious but I can assure you it is very easy to forget when creating a a new driver for Y based on X. If you make a copy of a Module within Builder, the copy gets all new GUIDs. If you export the Module, naturally it retains its original GUIDs. Te exported Module should not be used to create a new driver because it does not have its own unique GUIDs. It is the second thing I learned, the hard way, and it is the second post in the School of Hard Knocks thread.
 
Back
Top