UX Guide update

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

  • Would it be helpful to have the Graphics.{FONT_ENUM} label in the UX guide? Yes.

    So we agree: the Graphics font name is missing from the Guide.

  • The name might be useful to some, but what I'm pointing out is that there's no mapping between the font name and the Graphics font name in the UX-Guide. 

    Today, for example,I had to try it out to see if FONT_MEDIUM was bigger or smaller than FONT_MILD. They are just not referenced in the UX-Guide. 

    Those are both very valid points. I will also point out that the relative sizes of FONT_MEDIUM and FONT_NUMBER_MILD aren't going to be the same across all devices. Might be smaller on some devices but bigger on others.

    EDIT: I meant FONT_MEDIUM (text font) vs FONT_NUMBER_MILD (number font), since they're different classes of fonts, but the person I'm replying to actually meant FONT_NUMBER_MEDIUM vs FONT_NUMBER_MILD. In the latter case, I would say that FONT_NUMBER_MEDIUM is always bigger than FONT_NUMBER_MILD.

    There's also the somewhat well-known issue that some devices (like VA3/4) have lots of whitespace at the top of fonts, so that if you try to automatically resize your fonts to fit a container, end users will complain that your fonts are too small. Then you have to end up hardcoding some adjustments to ignore the whitespace.

    None of that stuff is in the UX guide.

  • So we agree: the Graphics font name is missing from the Guide.

    Yeah I do agree. I agree with the main point, but not some of the specifics, of your argument.

    In general a lot of this UX stuff is a nightmare.

  • Might be smaller on some devices but bigger on others.

    *#$%! I hope not! There has to be some sense to all of this!

  • Well I assume you mean FONT_MEDIUM vs FONT_NUMBER_MILD (there is no "FONT_MILD").

    As FONT_MEDIUM is a text font and FONT_NUMBER_MILD is, well, a number font, you can't expect there to be any guarantee about the relative sizes between different classes of fonts.

    The docs imply that FONT_MEDIUM is bigger than FONT_SMALL, for example (they're both text fonts), but they say nothing about the relative sizes of number vs text fonts.

    So IIRC, the relative sizes of text vs number fonts can definitely vary between devices, but don't quote me on that.

    Just for context, for anyone else reading this thread:

    developer.garmin.com/.../Graphics.html

    Name Value Since Description
    FONT_XTINY 0

    API Level 1.0.0

    Extra tiny Connect IQ font

    FONT_TINY 1

    API Level 1.0.0

    Tiny Connect IQ font

    FONT_SMALL 2

    API Level 1.0.0

    Small Connect IQ font

    FONT_MEDIUM 3

    API Level 1.0.0

    Medium Connect IQ font

    FONT_LARGE 4

    API Level 1.0.0

    Large Connect IQ font

    FONT_NUMBER_MILD 5

    API Level 1.0.0

    Normal size number only Connect IQ font

    FONT_NUMBER_MEDIUM 6

    API Level 1.0.0

    Medium size number only Connect IQ font

    FONT_NUMBER_HOT 7

    API Level 1.0.0

    Large size number only Connect IQ font

    FONT_NUMBER_THAI_HOT 8

    API Level 1.0.0

    Huge size number only Connect IQ font

    FONT_SYSTEM_XTINY 9

    API Level 1.3.0

    Extra tiny system font

    FONT_SYSTEM_TINY 10

    API Level 1.3.0

    Tiny system font

    FONT_SYSTEM_SMALL 11

    API Level 1.3.0

    Small system font

    FONT_SYSTEM_MEDIUM 12

    API Level 1.3.0

    Medium system font

    FONT_SYSTEM_LARGE 13

    API Level 1.3.0

    Large system font

    FONT_SYSTEM_NUMBER_MILD 14

    API Level 1.3.0

    Normal size number only system font

    FONT_SYSTEM_NUMBER_MEDIUM 15

    API Level 1.3.0

    Medium size number only system font

    FONT_SYSTEM_NUMBER_HOT 16

    API Level 1.3.0

    Large size number only system font

    FONT_SYSTEM_NUMBER_THAI_HOT 17

    API Level 1.3.0

    Huge size number only system font

    FONT_GLANCE 18

    API Level 3.1.8

    Glance text font

    FONT_GLANCE_NUMBER 19

    API Level 3.1.8

    Glance number only font

  • As a matter of fact, I would guess that Garmin chose "fun" names for the number font sizes (like mild and hot), in part to differentiate them from the text fonts, and to avoid meaningless questions like "is mild bigger or smaller than small." Then again, they both have "medium".

    I could be wrong about that, and maybe they just did it for fun.

    Either way, I don't see any implicit or explicit guarantee that the relative sizes of number and text fonts should be consistent or "make sense"

  • Well I assume you mean FONT_MEDIUM vs FONT_NUMBER_MILD (there is no "FONT_MILD").

    That was my typo, but no, I meant FONT_NUMBER_MEDIUM and FONT_NUMBER_MILD.

    Provides no further clarity!

  • That was my typo, but no, I meant FONT_NUMBER_MEDIUM and FONT_NUMBER_MILD.

    Oh in that case I would say that FONT_NUMBER_MEDIUM should always be bigger than FONT_NUMBER_MILD.

  • All I'm saying is that it is not explained in the Guide.

    And my post is simply about some shortcomings in the Guide.

  • Either way, I don't see any implicit or explicit guarantee that the relative sizes of number and text fonts should be consistent or "make sense"

    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....

    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]