[ANSWERED]Noob (Planning migration from HS) - Control Pages

Hi Guys

I'm planning to move from HomeSeer I'm just about to start designing some control pages. I've read all the docs, but have a few questions:

[/list]

1. How often are device statuses (primarily z-wave) updated?
2. I have iPhone5, 5S iPad Mini, iPad 2 and iPad 3 in my house. How do I determine which device gets which control pages? I don't want stuff scaled. In HomeSeer, you make a project (bit of a pain, but allows complete control) for each device type and deploy it to the applicable devices). This way you don;t get any scaling.
3. I found a Wiki Page that explains that touch doesn't handle swapping pages based on rotation:

   Now, you might be thinking to yourself, wouldn't it be cool if I could design landscape and portrait pages and have Indigo Touch switch between them based on the true orientation? And, even better, if I designed one page per device per orientation (4 total currently) so that it automatically picked the right device and orientation page? Yep, that would be pretty cool, and it's something that we'll look into in future versions.

   . Homeseer does this and it's going to be a major sticking point in moving to indigo, unless it's viable to build a fully featured client in HTML (then I can handle all the resolution changes with responsive design). Is this implemented yet? Any planned date/version if not implemented yet?

I'm not sure I know the answer to this (question 2), but are you asking if touch can have a page that auto-scales based on the device type you're using? page1 for tablet, page2 for laptop, page3 for phone?

As far as I know, the only option is to select the proper page from the control page menu in the touch app. I have a 'big' and 'small' page. I don't think there's a way to have it auto-select based on the device you're using.

What have you been able to do with html?

Thanks for reply

To clarify, I don't want it to scale if i can help it (esp from tablet to phone or worse desktop to phone).

Ideally, I'd like to designate which pages are available to which named device (e.g. wife's IPad) or Device Type (e.g. iPad3) or Resolution or aspect ratio (e.g. 1024 x768, or less than 1024 wide or 16:9). There's no way my wife's going to grasp "click this page on the phone and this page on iPad" and I wouldn't want to work like that"

This could be implemented easily in an HTML client with user agent/resolution detection (or better, allow the user to enter the home page for Indigo touch on each device). For example I could serve up the small page to a phone, a medium page to a tablet, and a large page to desktop. Realistically Phone and "Tablet/Desktop" would be the different layout choices (until we have 4K desktops). Even in this case you could design it such that two tablet pages become one big view on the desktop (see below)

With stuff like bootstrap you can hide stuff, move stuff, based on res. Checkout my test page here (was actually fro testing theme swapping), but shows layout changes: http://www.andersonintegrations.com/Boo ... Test.html#

As you make the page narrower, the layout changes, the menu changes. When you get narrow enough, the entire menu becomes one button. (the colored buttons don't wrap well in my test, they're just there to see color themes). So, for example, on my desktop, I could show a news headline and 3 lines of story (or 3 cols of headlines). Then when the page drops below a given res (say 1500px wide), i could hide the 3 line into and just show the headline (or drop to 2 lines or 1 line). I could also drop from 3 cols to 2.

On my desktop layout inHomeSeer, I have both floors of the house floorplan on a single page; on the tablet and phone, each floor gets it's own page. (with retina tables, I could do the whole floorplan on one page.). With responsive design, all that would be required is when res drops below X pixels, hide 2nd floor, center first floor and show button to go to 2nd floor (all just CSS).

It's a bit of work up and planning upfront, but it's a single layout. With my HomeSeer system, its 3 projects, so I have have to make many changes 3 times. It's not bad when you start, but all it does is cause inertia later when you know a 20 minute changes is going to be an hour plus because you have to do it 3 times. Bigger changes and theme changes become much longer.

One of the really nice things in HomeSeer is that you design a landscape and portrait orientation of each page (that's not the good bit ). In the portrait version you link the landscape version (or vice versa) and when I rotate the device it swaps layouts. Of course, I still have to build two layouts.

With HTML I can simply apply CSS styles (or load different page automatically) when res is X*Y and other rules when it becomes Y*X.

Regards

Mark

[matt (support)]

Hi Mark,

Having smart selection of Control Pages based on device orientation is on our Indigo Touch feature wish list (no comment yet if that will make it into the next major release).

Adaptive layouts are really neat and magical when they work correctly (our new site uses bootstrap, BTW), but I'm not sure how well suited that is to a WYSIWYG editor like we have. As you mentioned responsive layout requires some thought into how the layout should change based on the client resolution. Presenting how that works in a graphical editor (versus in HTML/CSS) would be a challenge.

So while I could see us providing functionality for specifying multiple Control Page views based on orientation (and then having the client smartly choose the correct one), I don't know that adaptive smart layout of Control Pages is likely in the near future.

Also keep in mind Indigo Touch does not render HTML. Its rendered is optimized for Indigo's tables and graphical Control Pages. The browser based rendering of Indigo Control Pages are, of course, HTML/CSS based.

Hi Mark,

after reading your post I had to go check my control pages to see how I solved the problem, because each of my control pages work on every device, I wouldn't want it otherwise. In fact they are using the same image background of size of 1024x704 in landscape mode, and the whole family is used to rotate the iDevice to see and interact with the full page: it became so natural that I didn't realize we do it every time until I read your email !

I did it this way because I have an old iPad on the wall in landscape position as our main controller in the living room, you cannot rotate that one so I needed horizontal pages. On the other devices if you see the page in portrait it looks to small and you naturally rotate the device without thinking.

It works for us also because I have simple pages, one per function (one for A/C, one for blinds, one for pool, one for sprinklers, etc..) with big buttons and indications. As it is easy and quick to reach the page you need it works for us, and as the page works on every device it is easy to maintain or change.

Just my 2 cents, I came also from another software and had to re-think how to deal with the interface and found the control page perfect for us, with a different approach than what I used before.

Hi DemoPat

That doesn't sound too bad, but the key for me is to do what HomeSeer does: allow users to link a portrait and landscape pair together. iOS users are used to rotate to get more detail, but it's never implemented as "it's too small to be usable in portrait, so I need to rotate". iOS 7 calendar is a good example. In portrait mode, you get 1 day, in landscape you get 5 days.

Regards

Mark

Hi Mark,

Having smart selection of Control Pages based on device orientation is on our Indigo Touch feature wish list (no comment yet if that will make it into the next major release).

Adaptive layouts are really neat and magical when they work correctly (our new site uses bootstrap, BTW), but I'm not sure how well suited that is to a WYSIWYG editor like we have. As you mentioned responsive layout requires some thought into how the layout should change based on the client resolution. Presenting how that works in a graphical editor (versus in HTML/CSS) would be a challenge.

So while I could see us providing functionality for specifying multiple Control Page views based on orientation (and then having the client smartly choose the correct one), I don't know that adaptive smart layout of Control Pages is likely in the near future.

Also keep in mind Indigo Touch does not render HTML. Its rendered is optimized for Indigo's tables and graphical Control Pages. The browser based rendering of Indigo Control Pages are, of course, HTML/CSS based.

Thanks for the reply Matt. I agree it's not an easy challenge. I'm just working on an HTML mock-up of my screens with responsiveness. I'd like to match the general layout of my existing system (homescreen attached). I'll be reworking the center section quite a bit, but keeping a header and the side buttons.

The header and buttons on both sides are the same on every page. What I'm testing right now is making this scale intelligently. Things that help are and you may be able to implement in Touch are (haven't got started on my control pages yet, so I'm sure some of these are done):

• Templates. My header and left and right button set are same on every page. I don;t want to have to change this on every single page when I update it.
• Snap to edges (headers is a always top, my buttons are always at left and right)
• Auto distribute. For example, my left and right buttons (5) should always be 20% of the screen height (minus heading), so when I go from 500px to 750px they occupy 100px and 150px height each.
• Hide below x-height/width / show above x-height/width. So in my case, if the height changes from 500px to 750px, I may display 2 more buttons on each side instead of leaving a lot of space between buttons
• Change item size based on height/width. For example, if my news items are divs. Only show one line per item up to 500px, 2 lines up to 1000px, 3 lines over 1000px. (This example could also be be done partially if it was a heading a para. (hide the para on small screens)
• Expressions for properties. I use SQL Reporting Services at work and one of the single best features is that virtually every property of a report can be an expression: dimensions, colors, visibility. This gives amazing power. In the news example above I could set no of lines to be int(height / 500), or the news detail invisibility to (height < 600px)

I'm still wrestling with the feasibility of a single layout that bridges the chasm between tablet and phone. Currently it's totally different (see below), and I may have to live with a second set of pages (this is where the ability to restrict pages to specific devices/resolutions would really help.

The real pain is having to make one for my Kindle fire, one for my iPad mini, one for my iPad, one for my laptop. These could easily be the same general design with just levels of details being hidden and spacing changes based on res.

When I'm done with a basic mockup, I'll post.

How good is the scaling in touch, especially at odd multiples (e.g. vertical res changes from 1024 to 1000?

Regards

Mark

[matt (support)]

How good is the scaling in touch, especially at odd multiples (e.g. vertical res changes from 1024 to 1000?

In Indigo Touch? I'd say it is very good. The text/captions should scale perfectly (no chunky pixels), and iOS does a very good job of scaling images.

In Indigo Touch? I'd say it is very good. The text/captions should scale perfectly (no chunky pixels), and iOS does a very good job of scaling images.

In my experience i also find the scaling very good.. the only bits you can really notice is the text (and i assume that’s because the current iPad version isn’t optimised for retina displays)

Ideally, I'd like to designate which pages are available to which device type...

This could be implemented easily in an HTML client with user agent/resolution detection (or better, allow the user to enter the home page for Indigo touch on each device). For example I could serve up the small page to a phone, a medium page to a tablet, and a large page to desktop. Realistically Phone and "Tablet/Desktop" would be the different layout choices (until we have 4K desktops). Even in this case you could design it such that two tablet pages become one big view on the desktop (see below)

Regards

Mark

It would be a pain, but you could achieve the device type distinction by using the inbuilt iOS URL paths (whose proper name I've forgotten). Or if you really wish - and had far too much time on your hands - one per device as well.

You'd make one set of pages for iPhones, one for iPads and optionally a separate one for Desktops. Then add a custom shortcut (aka webclip) on each device that opens up indigo://controlpages/iPhoneHome, indigo://controlpages/iPadHome.... (Again, I can't remember correct syntax). Each page would link to its own set of pages, never knowing the others existed.

I'll update this thread in a moment with link to the thread that discusses this.

[Edit: Link here: viewtopic.php?t=12028]

Peter


Sent from my iPad using Tapatalk

[jay (support)]

In my experience i also find the scaling very good.. the only bits you can really notice is the text (and i assume that’s because the current iPad version isn’t optimised for retina displays)

Point of fact, the text should render perfectly on any iOS device - the OS takes care of that automatically. And, we do actually include retina images so we are optimized for retina.

Interesting, the only reason I made this assumption is on a control page I use the text displays perfectly in Safari but slightly jaggedly on indigo touch. It's not a show stopper at all, but it is noticeable.


Sent from my iPad using Tapatalk

[matt (support)]

Right, I forgot how it worked actually. The text will render well at 100% or scaled out, but when zooming in it does get the jags. I remember experimenting improving it a long time ago, so we'll revisit that -- I got it to render sharply when scaled in but the placement of the text started to change a bit. Note if you design your page at a big enough resolution in the page editor, then it will render sharply until you zoom in such that it is having to scale up the page (text and graphics).

Point of fact, the text should render perfectly on any iOS device - the OS takes care of that automatically. And, we do actually include retina images so we are optimized for retina.

User images won't display in retina-quality in control pages; at least not in terms of selecting the proper from several (ala name.png and name@2X.png). Might could be added to the request list if it is not already on there? I realize that would be slightly tricky to implement, but wouldn't be nearly as bad as some other requests.

I've considered a few options for the Android app along these lines -- pixel density is FAR more disparate on Android devices, from 200 to 500+ DPI now. However, I didn't find an acceptable user-friendly method that didn't require control page editor modifications.

Adam

[quote="matt (support)”]So while I could see us providing functionality for specifying multiple Control Page views based on orientation (and then having the client smartly choose the correct one), I don't know that adaptive smart layout of Control Pages is likely in the near future.[/quote]

Actually thinking about that and rouge’s post above.. if its not going to be viable to have self adapting pages, how about a way of grouping multiple versions of the same page content? EG a control page for controlling the tv. One version is the default landscape, one is the default portrait, both have a version that’s retina which is identical to the standard version but loads the @2x image versions, and so on with different flags for different device types.. each page is separately editable to move things around, but some things can be linked like the functions behind those controls are universal so if i were to modify a script to turn off all the devices on one control page the rest would follow suit. And whichever device you load up in will just auto select the one assigned to it (whether that be device specific or modelled to a particular res, dpi, etc)