Under Review
over 1 year ago

Users complain of very small text in simple data fields

Original thread: https://forums.garmin.com/developer/connect-iq/f/discussion/259355/users-complain-of-very-small-text-in-simple-data-fields

Although I can't personally recreate this problem, I am reposting it here for visibility, as multiple users have complained of this issue, for multiple simple data field apps.

Text of original post:

Is this happening to anyone else? At first it was only happening for one of my simple data field apps, so I thought it was an isolated incident.

Now a user of a 2nd simple data field app has made the same complaint. Some users report that they used to see normal-sized text, and one day it suddenly became small. More recently, some new users say that it's always been small.

In one case I'm only displaying characters available in number fonts (for simple data fields *) such as digits, ".", ":", and "-" (verified in the simulator). (* I'm aware that simple data fields may be slightly more restrictive than necessary when it comes to which characters it will display in numerical fonts. i.e. The set of available characters for number fonts may be bigger in some cases than the set of characters that a simple data field will render in a number font). Even in this case, I've asked an affected user to change the settings so that only digits are displayed, and the problem persists.

In the other case I'm only displaying digits.

And I can't recreate this in the simulator or on my real 935 device.

What I see on my watch (normal-sized text):

https://ibb.co/1QC0c5V

What they see on their watch (text that's too small):

https://ibb.co/sFCYvvY

It's not limited to one device as Vivoactive 4 and Edge 530 users have both complained.

The two apps in question are:

https://apps.garmin.com/en-US/apps/fd690281-9c22-4fee-a81e-3b7f39aa67c5

https://apps.garmin.com/en-US/apps/2bc8b0c1-dd83-4679-96f1-0ae2a0925920

The latter (Total Ascent) literally does nothing but convert ActivityInfo.totalAscent to the user's preferred units and round it to a whole number.

using Toybox.WatchUi;

class totalAscentView extends WatchUi.SimpleDataField {

	var elevationUnits;
	function getUnits()
	{
		var settings = System.getDeviceSettings();
		elevationUnits = settings.elevationUnits;
	}

	// m to feet
	private function convertAltitude(value)
	{
		if (value == null)
		{
			return null;
		}
		
		if (elevationUnits == System.UNIT_STATUTE)
		{
			value = value / 0.3048;
		}
		return value;
	}		


    function initialize() {
        SimpleDataField.initialize();
        label = "Ascent";
    }

    function compute(info) {
    	getUnits();
        
        var val = convertAltitude(info.totalAscent);
        if (val == null)
        {
        	return 0;
        }
        
        return Math.round(val).toNumber();
    }
}

FlowState
Parents
  • over 1 year ago

    The text string does not have hyphen/minus/dash symbols that may have triggered smaller font size some years ago

    Yes, but there's additional nuance here, unfortunately. In the past, simple data fields which returned strings would use the larger "numerical" fonts if they only contained numerical characters. Depending on the device, other characters such as hyphen, dash, and blank space would also be considered "numerical characters", for these purposes. One limitation of this behavior was that certain characters which were included in large numerical fonts were apparently not considered "numerical characters" for the purpose of the font selection algorithm. (Fake example: say that for a given device, the large number fonts contained the colon character, but if you returned a string that contained only numbers and the colon character, the simple data field font selection algorithm would use a smaller non-numerical font instead.)

    This behavior seems to have changed in more recent watches so it's only the data type which is considered.

    - If a data field returns a number, the larger numerical font is used

    - If a data field returns a string, the smaller non-numerical font is used, regardless of the contents of the string. (so returning a string with only numerical characters won't result in a larger string.)

    See this comment for anecdotal evidence: https://forums.garmin.com/developer/connect-iq/i/bug-reports/users-complain-of-very-small-text-in-simple-data-fields?CommentId=365ea465-4a3e-4269-9f5f-c3614a4d88ac

    Having said that, your situation may be a different (or may be a combination of issues), since it works differently for different layouts.

    You can validate whether you're seeing the problem that I mentioned above by changing your simple data field app to return a Number, not a String. If it now uses a larger font, then it's the return type issue.

Comment
  • over 1 year ago

    The text string does not have hyphen/minus/dash symbols that may have triggered smaller font size some years ago

    Yes, but there's additional nuance here, unfortunately. In the past, simple data fields which returned strings would use the larger "numerical" fonts if they only contained numerical characters. Depending on the device, other characters such as hyphen, dash, and blank space would also be considered "numerical characters", for these purposes. One limitation of this behavior was that certain characters which were included in large numerical fonts were apparently not considered "numerical characters" for the purpose of the font selection algorithm. (Fake example: say that for a given device, the large number fonts contained the colon character, but if you returned a string that contained only numbers and the colon character, the simple data field font selection algorithm would use a smaller non-numerical font instead.)

    This behavior seems to have changed in more recent watches so it's only the data type which is considered.

    - If a data field returns a number, the larger numerical font is used

    - If a data field returns a string, the smaller non-numerical font is used, regardless of the contents of the string. (so returning a string with only numerical characters won't result in a larger string.)

    See this comment for anecdotal evidence: https://forums.garmin.com/developer/connect-iq/i/bug-reports/users-complain-of-very-small-text-in-simple-data-fields?CommentId=365ea465-4a3e-4269-9f5f-c3614a4d88ac

    Having said that, your situation may be a different (or may be a combination of issues), since it works differently for different layouts.

    You can validate whether you're seeing the problem that I mentioned above by changing your simple data field app to return a Number, not a String. If it now uses a larger font, then it's the return type issue.

Children
  • over 1 year ago in reply to FlowState

    Thanks very much.  Very helpful.  Yes, something like that.  After investigating (in part through your suggestions), I believe there is a bug in the assignment of font size for "Strings" in the large but not small fields in some layouts in the Simple Data Field module/class.  My Simple Data Field app returns a string object that includes some numeric values but also some text characters.  In the smaller fields in some layouts, it is formatted as a string, using a font that is slightly different that the font for used for number objects but roughly the same size.  However, for large fields in some layouts, e.g. 1, 2, some 3, and some 4 field layouts, the string is rendered in a tiny (i.e. really small) font size.  The font style may be the same as for the smaller fields -- it’s too small to see clearly.  The behavior is different in the simulator, where my string object is recognized as a string – as evidenced by the choice of font compared to numeric objects.  In the simulator, the size of the font for string and numeric objects is roughly the same and large enough to nicely fill the field regardless of its size/layout. 

    In the process of the investigation and searching for a work around, I tested the rendering of a series of string objects.  As indicated below, some strings are rendered in the string font, others in the number font.  On my Edge 530, the strings rendered in string font are tiny for the large size fields in some layouts but have sensible size for the smaller size fields.  The size of the strings that are rendered in number font is sensible regardless of the field size across all layouts.  By contrast, there does not seem to be a problem with font size rendering for these strings in the simulator.

    string (formatted as/font used on my Edge 530)

    "--" (number)

    ".." (number)

    “111111” (number)

    "10-11" (number)

    "10-11*" (string)

    "10 - 11" (string)

    "10--11" (number)

    "10 -- 11" (string)

    "10..11" (number)

    "10 .. 11" (string)

    "10_--_11" (string)

    "10_.._11" (string)

    "10^--^11" (string)

    "10^..^11" (string)

    "Test Text" (string)

    "1Test Text" (string)

    "1. Test Text" (string)

    "+Test Text" (string)

    "+1Test Text" (string)

    "+1. Test Text" (string)

    "Test_Text" (string)

    "1Test_Text" (string)

    "1._Test_Text" (string)

    "+Test_Text" (string)

    "+1Test_Text" (string)

    "+1._Test_Text" (string)