Looks wonderful! Can you share any ofthe icons you used for the sprinkler heads?

My sprinkler head is actually a character in a font: On the Mac you can use the "Character Viewer" to bring up alternate fonts, I used the Emoji font and used the "Splashing...At Symbol" character.

Just curious... is there a way to link BACK to the main iOS client page for indigo touch from a control page? I have several control pages with links to other control pages, but sometimes I do want to get back to see what my variables are, or to manually trigger an action or device. Rather than hitting the "back button" to go back through all the control pages I visited, it would be nice to just get back to the main screen on indigo touch. I realise I could make control pages for all of these things as well, but that would require me to update it every time I add a device/variable/action.

Yes and no. Yes - you can enter one of the Indigo Touch URLs into the client action "Link to External URL" which would do it. There is a bug however - when it goes to any of the built-in lists, the tab bar at the bottom will remain hidden and the only way to get it back is to force-quit Indigo Touch and restart it. Not a good thing.

We'll add this request to the feature request list for the next version of Indigo Touch - but it's going to be a while. We're still trying to wrap up the last of the Indigo 5 features.

No problem. I know you guys have a full plate.

I'm not sure if it's more because I'm adding and testing a lot right now or if this is a long-term need. Right now I'm just making sure me or my wife don't click TOO far down to come back out of it. Do you know offhand how many pages it remembers back to?

Unfortunately, I think it will keep a history as deep as you go. Note that if you uncheck the Hide Tabe Bar checkbox inside the Control Page editor for all of your pages then the main tab bar will remain visible. Additionally, when it is visible if you double-tap on the Control Pages icon it will automatically back you all the way to the topmost Control Page list (erasing the browse history).

Thanks for the info... unfortunately I'm losing valuable pixels going that route and back to scrolling. I have a couple of pages I could do that on as a work around, but most pages are already packed to the brim!

I originally had the Hide Tab Bar option checked for all my control pages, because I wanted all the available screen real estate. But I found myself stranded too far down the history path too often, so I ended up turning on the Bar for each page.

Is there an obvious, and "legal", UI gesture that could be used to reveal the Tab Bar at will?

- Like a three- or four-finger swipe from the bottom, for example.

- Or a button in the currently vacant upper-right corner, on the page's title bar, that could be used to either reveal the Bar, or display a menu of the Bar's options.

- Or holding down the Back button to jump all the way back to the Control Page screen.

In other words, some better way out of the history path than the current multiple tap procedure of the back button.

There is nothing that works in the current version of Indigo Touch, but we have navigation improvements on our feature list for the next major rev of Indigo Touch. No promises what exactly will get done, and the next major rev is still pretty far out on our calendars.

We're definitely thinking about ways to make navigation better in the next major Indigo Touch revision - gestures are definitely in the mix.

I'd suggest rethinking the flow of pages. I suspect that if you do it with an eye towards navigation you can avoid having a long trail of breadcrumbs (not exactly your original question but a valid point). What I always try to remember that the back button, unlike on most websites, is actually quite useful as a navigation tool if you design your flows with that in mind. The temptation is to try to put all navigation on the control page itself - I don't think that's necessarily the case. Sometimes, definitely - but not always.

For instance, my pages rarely take you more than 2 levels down - and the back button plays a key role in my navigation scheme. Start with a "landing" control page and make it the hub of what you typically need to do. And sparingly use links betwee sub-pages. Tapping back then something else, particularly on an iPhone where the screen is so small, is rarely so inconvenient that it's annoying. And, if it keeps navigation from becoming an issue, then it's probably worth the extra tap. Make the back button the first thing that the user thinks of tapping when "done" with a page and they'll get in the habit of just tapping that pretty much out of habit.

Just some thoughts after building out my pages multiple times.

Jay, you're sort of reinforcing the point of my wish list. I consider the built in Control Pages screen to be my "hub." I was suggesting an interface refinement to get back there with minimal clicks, regardless of how far down the history path one is. I'll add one more. A three- or four-finger tap to jump back to the Control Pages screen (if that doesn't interfere with Apple's gestures).

I don't think that function should be a link or button within a user's control page. Too hard to find if zoomed in or scrolled to a point where it is no longer visible. I think it should be built into the Touch interface.

So that's:

- some kind of swipe to reveal the tab bar, and

- some kind of tap gesture, or permanent button, to jump right to the Control Pages screen.

Since the Control Pages screen always has the Tab Bar, then a quick way back there would also serve those that want to access Tab Bar functions quickly. A Twofer!

I think it is different mentalities of how the UI should be approached.

1. Just the devices/actions,variables tab, which I used extensively and nearly exclusively for the past two years.

2. Just the control pages.

3. A combination of both.

I think myself and Mark are in boat number three. While I think #2 works GREAT for end users (spousal level of understanding), people who are constantly tweaking/improving their system or wanting to know down to the programming level what is going on with their system are probably the ones who struggle with the app as it is today the most.

I like the idea of having a gesture control as opposed to the button because that adds another area where you may not someone to fall into either deliberately or by accident. I could see this as a major issue in a professional installation where the end user is expected to solely operate within the boundaries of the control pages.

Agree. I, too, would prefer the gestures.

The reasons for considering a button:

- gestures have to be explained and learned separate from the interface. They are handier, cleaner and faster, at least for me, but not always obvious to the "don't read instructions" crowd. A properly labeled button could be simpler for a non-poweruser.

- gestures (1) should follow Apple's UI guidelines, and (2) can't override the gestures Apple has commandeered for their own OS purposes. I don't even have iOS 5 yet, so I'm not sure what Apple is already using. Are there any gestures left that could be applied for these purposes?

Dave Durham wrote:This is one of my control pages, it's just for the sprinklers. I had a lot of specific needs for flexibility in controlling my zones. This does exactly what I wanted and makes sense to me, although it takes a little getting used to for some.

-d

Excellent Control Page! What hardware are you using to control your sprinklers? I am looking for something that will do up to 8 zones with similar "precision control" as you have. I have a mixture of in-ground and potted plants so I need precise timing for the various types. Additionally, I live in AZ and primarily use drip irrigation.

ticotice wrote:...What hardware are you using to control your sprinklers? I am looking for something that will do up to 8 zones with similar "precision control" as you have. I have a mixture of in-ground and potted plants so I need precise timing for the various types. Additionally, I live in AZ and primarily use drip irrigation.

Take a look at the sprinkler plugin. While it can support multiple controllers, it also works well with a single controller. Each virtual sprinkler device represents a specific sprinkler with a specific schedule. The schedule can be period based (every n days) or based on the days of the week. Currently, only one watering period is supported and all watering starts at a pre-set time and continues until all watering for the day is done.

However, this is definitely still a work in progress, and it is quite possible to add new features like additional scheduled times per day.

Taks a look and post or PM me if you are interested in working with it.