Opening up permissions on watch faces? Here's why it should be considered.

This has been brought up in the past, both inside the team and by other external developers trying to do something similar. I understand the motivation, but in the short term, we plan to keep watch faces pretty restricted in order to preserve battery life and maintain a consistent user experience. This does't mean we won't ever open up watch faces to additional capabilities down the road--perhaps improvements in hardware and battery technology will make this a more viable option without the need to compromise core product requirements.

A common argument is that even if making things like Position and Comm available to watch faces might lessen battery life or impact user experience, that option should be available to the user should they want it. I agree with that philosophy to a point, but we ultimately we need to defend user experience as much as possible. There are certainly individuals that would knowingly and willingly sacrifice battery life or performance for the sake of desired features, but on the whole, most customers aren't aware of the implications of that kind of trade off. This leads them to a bad experience and causes a loss of confidence in their product. I'm sure you can understand why this is important to us. :)

You've always provided thoughtful suggestions and have been a big contributor in the forums, so I definitely don't want you to feel like you're being dismissed by my response. If anything, I'm hoping you'll see that we've put a lot of thought into these things, too!

Please keep providing us with ideas and examples, because even if my answer is "no" right now, the things you folks discuss and ask for do have influence over the way features and fixes are prioritized.

I agree w/ BRandon on this..
UI - there is a need to provide a relatively as close as possible experience as that is offered by Garmin's native stuffs.
having said that - of course does not preclude people from making even better UIs tat best's Garmin's own.

I don't think it changes the UI - it would just allow something like the current temperature to be displayed on a watchface. I can see his point how it could impact the battery as it could add a makeJsonRequest every 15 minutes or so, and a one-shot GPS every 30 minutes or so, and that could lead to shorter battery life (the user experience).

But the more complex watchfaces probably impact the battery life more than the very simple ones, even today.

Sorry.. I wasnt referring to the watch face (but in general)

I find this a real shame with the limitations. Not sure how you make less aware users understand the implications of reduced battery life before installing apps. But the types of apps that could be added could be a huge bonus. Maybe an in-between solution would be allowing data to flow between different types of apps. So you slide over to a widget that grabs the weather data and stores it in such a way that the related watch face can get it. This, then, has no impact on battery life but can improve user experience. Similarly between widgets and data fields as a way to customize.

In my particular case, I have a widget that turns red if my garage door is open. I have replaced the step count page with this widget as I know before bed I'm going to check my steps. Thus I get an "in my face" ability to see that I have forgotten to close my garage door. The same widget gets my weather stats from my home weather station. Ideally both of these sets of data would show up on my watch face. Querying the data every 10 minutes via a JSON request couldn't be a huge drain on my battery. Maybe have a way for push notifications to do something like this more often. After all, my watch is obviously listening for notifications from my phone. Maybe a watch face could get notified of these. (it can't, can it?)

What I've done since starting this thread is create a couple watch apps that look like watchfaces. (with the screen only updating every minute, like a watchface in low power mode)

One uses a Tempe Sensor, and displays the time and temperature. (it's in the app store - https://apps.garmin.com/en-US/apps/54e90766-dc58-4f42-b898-261a090949c5 )

The second uses makJsonRequest() to get data from the weather underground (my back yard weather station) (I have a widget to do this in the store, but not the app yet)

The app version updates the temp every 20 minutes (user configurable for 10-60 minutes), and every other time it updates the temp, it updates the forecast. (the forecast only changes every couple hours). It also gets sunrise/sunset, but I only do that once a day. (another reason that using an app for this, is that I can have multiple screens!) The user can request a GPS location update, and other than the first time the app is run, is the only time GPS is on..)

Both do burn more battery than a watchface (the Tempe version the most, as it gets sent Temperature data every minute), but the WU version's additional burn is also noticeable.

So this is a solution instead of opening up the watchface permissions, and for me, it works fine.

Watch faces and data fields that drain battery life will self moderate

It is great that Garmin want to provide consistent user experience and keep battery life long.

However, users of app stores should be given a bit of freedom to decide what is important to them, long battery life or information. One of the features of App stores that allow reviews is that if Jim_M_58 or EKutter or I write a watchface or a datafield that drains the battery then we will get punished by poor reviews and few downloads. Or maybe we will have developed something that is more useful to our users than a longer battery life. If you have good developers like Jim_M_58 then he will add configuration features that manage the refresh rate, and he will have more time to add value rather than having to reinvent the wheel again.

Extending the availability of communications will make your development platform even more flexible.

R.

I don't agree they will "self moderate". What will happen is that someone will download a watchface that's heavier in battery usage, and a week or two later, may notice they have to charge the watch every 3 days instead of every 5 days. As that goes on, they forget about the watchface being the impact, but do remember that they aren't getting the 5 days like they grew to expect, and will blame the watch, and not the watchface.

Many thinks is protected but not battery drain: last know position, positions database. Many thinks is not implemented but possible and not need lot of power - like sharing variables between apps/watchfaces. Nobody know why.