I know this is a crazy request and will probably never happen, but there are currently many issues with the GC mobile app settings implementation, including:
1) Cosmetic issues (long settings titles cut off, newlines not rendered)
2) Too easy to accidentally discard changes by swiping right or hitting back
3) No real settings validation (numeric vs. non-numeric). Instead of displaying error message and forcing user to fix settings, instead, bad settings are silently changed to null. At worst, this causes app crashes; at best, the user doesn't know what settings are actually in effect now. Which is why some devs tell users to send settings twice in case the first time "didn't take".
4) Settings page just randomly exits for no reason, causing you to lose changes. (Actually, this happens when GC syncs with watch over bluetooth, but to most users it just looks random)
5) Very difficult to deal with large numbers of settings, because of 2), 3) and 4), and also because there are no sections and you can't selectively hide irrelevant settings
My preference to deal with most of these would be:
- Render newlines and don't cut off long settings titles
- Get rid of the back button and add Cancel/Save at the top of the page, so it's like a classic "dialog", just like iOS email account settings.
- Do NOT let the user swipe right to go back (thus accidentally losing changes)
- If there are errors (i.e. non-numeric value in numeric field), do NOT let the user save changes. Force them to either fix their settings or press Cancel to discard changes. Alternatively, implement a control (e.g. masked input) that prevents user from entering bad values (e.g. non-numeric value in numeric field)
- The Cancel button could have a confirm prompt, although this might be a bit annoying
- Stop randomly exiting the settings page
However, I'm pragmatic enough to realize that maybe none of these things will ever happen.
So here's my crazy alternative, which will also never happen:
Allow devs to add a "settings provider" URL to one or more (probably hidden) properties on the settings page.
e.g.
"my.app.settings/
The user might see a button that looks like "More Settings..." which would open a web app in their browser that could populate settings based on the passed in property string(s). Since I believe all the GC platforms support 1024 chars for string settings, these could actually be quite comprehensive.
When the user is done editing settings in the web app, they could press a button in the web app which could launch a Garmin Connect App URI that would automatically sync the changed settings strings back to the CIQ app (possibly with a confirmation prompt).
Advantages:
- Save a ton of memory in the app by not having to include settings strings and complex settings dictionary
(I wish apps didn't have to waste memory by having settings strings they won't use in the resource table, but I feel like this is never going to change.)
- Allows for a richer settings UX, if the developer so chooses. Complex apps can implement simplified settings to avoid overwhelming users
Disadvantages:
- External dependency that's not under Garmin's control
- Internet connection necessary (then again, currently GC is the same)
- Potential to alienate/confuse users
- When external app goes away, app is useless
I'm pragmatic enough to see a bunch of logistical, technical, and political reasons this will probably never even be considered, but I figure it couldn't hurt to ask.
(I also wanted one last chance to bring up some of the UX issues in the GC settings.)
