AppType-Suggestion: Activity Plugin

Have you ever done a device app that records an activity?  They are often more complex than a data field, but also, much more flexible.

"You could implement a "full-screen" CIQ data field (which only works in a 1 field layout), which could then display several variables."

We are aware of this feature but i have several issues with this concept:
Many people (including myself) love to decide by themself what they want to see in a datafield.
Somelike to see the pace, some the average speed of the current lap, some want to see in which HR area they are,,...
There is an almost infinite number of possible combinations and deciding for the user what quantities are
1) relevant enought to be shown and 2) in what size everything is displayed
is a huge drawback.

I guess 1) could be resolved by having a giant setting list for each displayed variable?
If so it would still be clunky as the user would need to open an extra app on the smartphone to change a field which in other cases can easily be changed from the watch.(On device-settings are not allowed for datafields)

Sharing Data between DataFields is not the only issue i wanted to adress with my Discussion-Suggestion. 

First of all it would enforce the intended role of DataFields as pure visualization-addons, whereas the ActivityPlugin i envision is for data-calculation. This in itself is good Softwaredesign.

On the other hand, to fullfill that somewhat new role of a data-calculation/creation-addon, such a plugin could e.g. communicate with the internet (over the smartphone) and load data. provide life information from other sources. Do complex calculations on Sensor-Data and so on. 

In my books this is not a complicated copy of a DataField, but rather a design that allows DataFields to stick to their role and not beeing hacked to do any kinds of stuff they are not realy intended to do.

jim_m_58 said:

Have you ever done a device app that records an activity?  They are often more complex than a data field, but also, much more flexible.

Uhhhh yes, I have. I actually found a bug where a device would crash if you stopped and started a recording too quickly. What I love about CIQ is basically anything any given dev looks at for the first time is almost guaranteed to have major bugs.

I love the way I've been here for years but you always talk to me like it's my first post whenever I say anything you disagree with.

And I already gave you props for your Hike apps which are a great example of how device apps can be very useful to the end user.

My point still stands - personally as a runner, using an app to completely replace the native running activity defeats the purpose of using a Garmin in the first place (which is that I like the features of the built-in running activity). I own a Forerunner 955, and I bought it primarily for its running features.

I'm aware of the flexibility of device apps, but did you read the part about reinventing the wheel? Have you ever used a running or cycling device app which comes close to providing the native functionality that comes with the built-in running/cycling activities on a FR255/265/955/965?

Just a few examples in case you can't imagine what I'm talking about:

- With a 3rd-party device app, you can't use native navigation to follow a course

- With a 3rd-party device app, you can't use a 3rd party CIQ field (which I already mentioned). So for example, anyone who uses the Stryd Zones data field for running will not want to use a 3rd-party app for running

- With a 3rd-party device app, you're probably not going to have good support for programmed workouts unless the developer decides to reinvent the wheel

In a hypothetical world where CIQ running device apps are common and popular (they're not), do you think every dev is gonna take the time to add navigation and workout support (for example) to their apps, especially when their implementation will never be as good as the real thing? It makes sense if their app is dedicated to navigation or workouts, but not if they're just making a generic running app which focuses on their proprietary sensor or whatever.

If I wanted to switch to a paradigm where a 3rd party app does almost everything, again it would make more sense to simply switch to Apple Watch, where it's normal to use a fully-fledged 3rd party app instead of native functionality.

I don't know any runners who regularly run with a 3rd party device app on their Garmin. Most runners are not even aware of CIQ. At best they have Spotify and maybe a custom watchface. Very rarely do they use CIQ data fields, and they're even less likely to use a device app which replaces the running activity.

The limitations with the access rights of DataFields make them feel more like mostly visualization-apps. Offcours i have little hopes for anything to change, but talking about it and suggesting solutions might help in the long run

Maybe. One Day. In a few years or so... ;) 

9787675 said:

We are aware of this feature but i have several issues with this concept:
Many people (including myself) love to decide by themself what they want to see in a datafield.
Somelike to see the pace, some the average speed of the current lap, some want to see in which HR area they are,,...
There is an almost infinite number of possible combinations and deciding for the user what quantities are
1) relevant enought to be shown and 2) in what size everything is displayed
is a huge drawback.

Yes, I agree. Once you implement a full-screen data field, you have a new problem where users want to see all their favorite metrics on the same screen.

Giving the user a huge list of of metrics to choose from is very clunky (it could be a drop-down with dozens or hundreds of metrics, given that Garmin's app settings - in the Connect IQ phone app - don't really support any kind of searchable or nested lists)

For two of my full-screen data fields, I actually tried to mitigate this problem with a somewhat novel approach that I haven't seen anywhere else in the CIQ store - instead of giving the user a single flat dropdown list to choose from for each field, I give them 3 lists (2 modifiers + 1 metric)

- 1st modifier: Overall (current/total), Lap, Last Lap

- 2nd modifier: Average, Minimum, Maximum, or none of the above ("---")

- metrics: Distance, Pace, Elevation, HR, Cadence, etc.

For example:

- "Lap", "Average" / "---", "Pace" (lap pace)

- "Overall", "Maximum", "Heart Rate" (max HR)

- "Overall", "---", "Cadence" (current cadence)

In this way my apps can support 100s of combos of modifiers and metrics without requiring the user to select from a single drop down that has 100s of options. I can even support very obscure permutations of metrics that Garmin itself doesn't support, such as Last Lap Max HR or (overall) Min HR.

Ofc none of that helps if the list of actual metrics (not modifiers) becomes too large.

But again, if you are going to limit yourself to one value per field, then the 2 CIQ data field limit (for watches) is insurmountable. Even if Garmin allowed communication between data fields, you would be able to provide the user with 2 whole metrics, and that's assuming they are willing to use both slots.

Again, there is a reason that Garmin support tells user to set the page layout to 1 field when they install a CIQ data field - they know that most of the popular fields are full-screen fields, for the current and historical reasons I mentioned above.

As far as deciding what size everything is displayed in, you can support a fixed number of layouts (e.g. 1 field and 6 fields), and simply display every metric at the max size possible. (Yeah I say "simply", but actually some devices have an issue where there's a lot of white space padding in numerical fonts, so you might have to take that into account when you auto-size your fonts if you want to make the best possible use of space.)

9787675 said:

(On device-settings are not allowed for datafields)

As previously mentioned, yes they are. (For all modern devices supporting CIQ >= 3.2.0, anyway)

[https://developer.garmin.com/connect-iq/core-topics/properties-and-app-settings/#ondevicewatchfaceanddatafieldsettings]

It would still be clunky for the user to change complex settings on the device (as this would require many button presses and swipes, and you're limited in the amount of information you can display at once), but at least you'd be able to implement nested menus for selecting metrics. However, the fact that Garmin somewhat recently introduced "Live Device Settings" where you change your device settings in the Connect app instead of on the device kinda shows that some users don't like changing settings on the watch itself. Even though the live settings are kind of slow, they are still superior in some ways to setting stuff directly on the watch (especially when configuring activity data pages.)

Personally I would prefer for the Connect IQ phone app settings to be a lot more flexible and usable, but as it stands, it's not even possible to have simple text as separators or to render newlines within a label, and advanced features such as groups and arrays don't work.

I once toyed with having an external website to configure one of my apps to reduce complexity and improve usability, but the problem is the act of actually getting the settings to and from the site adds too much complexity for the end user, and that I'd still have to support normal app settings anyway.

deSHalb said:

talking about it and suggesting solutions might help in the long run

I don't have a problem with this, but I also want to be realistic.

Once you've been in the CIQ ecosystem for a while, you'll see that things change very slowly, and many things never get fixed.

I don't see a huge chance that Garmin will radically redesign its app ecosystem to make it more complex.

They have actually gone in the opposite direction a few years ago, when they merged the "device app" and "widget" app type in order to simplify things. This was actually a very good thing (except for one use case that I won't go into which I felt was badly handled), but it's funny that bloggers and end users don't actually realize Garmin did this. They think that "widget" CIQ apps are a still a thing.

Thanks a lot for the informed discussion!

We will probably give the full screen datafield a shot.

I find your arguments against a full app very compelling. I once programmed such an app to have acces to the sensor data and it works fine, but the look and feel is just not the same. No programmable intervalls, no navigation, ..
As you said, it cant compete.

A full datafield has its own drawbacks but they might be worth the effort. One last question:
How would you realize if the datafield is currently beeing displayed in full screen or in a single slot?

9787675 said:

the look and feel is just not the same. No programmable intervalls, no navigation, ..
As you said, it cant compete.

Yeah exactly. I really think there's a very good reason that there are no popular, fully-fledged running or cycling device apps for CIQ, unlike WorkOutDoors for Apple Watch (which is touted as a Garmin killer).

CIQ device apps can't compete with the "flagship" native activities (running, cycling and swimming) by design. Why would a user pay extra $$$ for 265/965 over 165 if they could simply get a $5 CIQ device app which does all the same stuff and more?

9787675 said:

How would you realize if the datafield is currently beeing displayed in full screen or in a single slot?

In onLayout(), you could compare the size (width/height) of the data field's DC to the size of the device display. If the data field's DC is significantly smaller, then you can't be in full screen mode.

(There might be some cases where a data field's DC is just a *little bit* smaller than the device DC. I do know that Venu SQ has a reserved "scrollbar-ish" area on the side of the data page which shows up as a blue line in the simulator. I think that blue area is not part of the field in a 1-field layout, but you can double check the device reference linked below.)

For the exact dimensions of various data field layouts, you can check the device reference guide:

https://developer.garmin.com/connect-iq/reference-guides/devices-reference/

Note that some of the newer layouts (like 8 fields) are missing for some devices. But the 1-field layout should be there for every device that supports it (I forget if there's some obscure device which doesn't)

So in the worst case, in order to handle some of those edge cases with the reserved areas, you could hardcode some of the checks.

You can also see similar information in simulator.json for each device, in the layouts.datafields.datafields array.

e.g. fr965/simulator.json:layouts.datafields.datafields[0]:

{
    "drawBorders": true,
    "fields": [
        {
            "data": {
                "font": "numberThaiHot",
                "justification": "center",
                "width": 425,
                "x": 227,
                "y": 276
            },
            "label": {
                "font": "simExtNumber2",
                "justification": "center",
                "x": 227,
                "y": 126
            },
            "labelDisabled": false,
            "location": {
                "height": 454,
                "width": 454,
                "x": 0,
                "y": 0
            },
            "obscurity": [
                "left",
                "top",
                "right",
                "bottom"
            ]
        }
    ],
    "name": "1 Field"
},

Also I confirmed that for venusq (for example), the device display resolution is 240x240, but the 1-field layout is 220x240.