• Replies 25 replies
  • Subscribers 19 subscribers
  • Views 3422 views
  • Users 0 members are here
Options
Related

UX Guide update

Alan.raceQs
over 2 years ago

In a recent SDK release, it was a welcome sight to see that Garmin has restored the section on font descriptions that disappeared a while back.

But it's still desperately in need of housekeeping.

The fonts are described and examples are shown but they reference the fonts by an arcane naming convention like "Roboto Condensed 10 pt" which mean absolutely nothing to the developer who has to access it by its Graphics font name, "Graphics.FONT_TINY" (and I've probably got that wrong!)

Secondly, although it presents examples of the font: 

  1. they include characters that are not supported in the font: e.g the number fonts include examples of text.
  2. More importantly, they do not include all the characters available in that font: e.g, some number fonts don't include "+" 

There's a similar issue with the colours, which are presented with their hex values, but again, we developers usually refer to them by their Graphics names, e.g. Graphics.COLOR_YELLOW.

It's just a pity they didn't beta test the new stuff with developers, the only group that would need it!



Top Replies

All Replies

  • over 2 years ago in reply to peterdedecker

    Let's not get sidetracked.

    There are plenty of other issues.

    I'm just talking about what is missing from the Guide.

  • over 2 years ago in reply to peterdedecker
    peterdedecker said:

    to be honest imho the whole font naming system should be re-evaluated, now not all fonts available on the device are made available to the developer, for instance if you have a data field and try to match the size of the value field with what's available natively you have though luck....

    With the limited naming set available now there's no good way of solving it, especially since one device has more than others probably....

    Do you think the only reason they don't make all the fonts available is because of the limited naming system?

    That sounds plausible, but then again there's a lot of spare numbers for additional font size enums... You could have FONT_NUMBER_MILD_MEDIUM (jk...ish)

    This kind of thing sort of points to lack of foresight in design tho, which is a common theme in CIQ.

    peterdedecker said:
    Not sure what would be the best approach but some kind of array system  containing refernces to the font would be a better approach imho... eg use something as Graphics.FONT[0] or ala limite have 2 arrays such as Graphics.FONT[0] and Graphics.FONT_NUMBER[0]

    But wouldn't you lose the one redeeming feature of the current system, which is where at least a font size enum has a fairly common meaning across devices?

  • over 2 years ago in reply to FlowState
    FlowState said:
    But wouldn't you lose the one redeeming feature of the current system, which is where at least a font size enum has a fairly common meaning across devices?

    Does it? Have you seen the FONT_XTINY on a fenix 6.... shivers....

  • over 2 years ago in reply to peterdedecker
    peterdedecker said:
    Does it? Have you seen the FONT_XTINY on a fenix 6.... shivers....

    Lol. Yeah I've already gotten complaints from some users that my tiny fonts are too tiny on Fenix 6.

    Sorry I should've said "in theory (but not in practice)" (which applies to a lot of CIQ stuff)

    But seriously, I don't think the intent of the CIQ architects was ever for developers to have to fine-tune their font choices for every single device. We were supposed to be able to pick FONT_SIZE_X and call it a day.

    Best laid plans...

  • over 2 years ago in reply to FlowState

    Please don't hijack my post.