New Android Release 2.25.0

We offer so much flexibility. I understand why you are confused and can’t choose the right layout :wink:

  1. make one string on hardware and send to 1 widget (full width)
  2. make 3,2,3, widgets, all with centered labels
  3. make 2,3,2, widgets, all with centered labels
  4. make 4, 4 widgets with centered labels
  5. make 2,2,2 with 1 cell offset
  6. Use LCD

this is planned

perhaps I’m missing something, but with the latest version I got the value display widgets back to a good size. I did have to resize some widgets to make it all fit destroying the symmetry but as you can hide the widget outlines, not too disturbing.

One thing though: the labels do not align with the values making it butt ugly (so align right places the value right, but leaves the label left). Am I overlooking something or is this on your todo list?

it’ll be interesting to center Title too

One thing though: the labels do not align with the values making it butt ugly (so align right places the value right, but leaves the label left).

I believe this is how they’re supposed to work and is what I at least would expect to happen.

you expect it to be butt ugly? I recall you made a good argument for aesthetics, this sounds quite the opposite. Could you elaborate on why you expect labels and values to align differently?

you expect it to be butt ugly? I recall you made a good argument for aesthetics, this sounds quite the opposite. Could you elaborate on why you expect labels and values to align differently?

I don’t find the right alignment at all pleasing and never use it. I’m just saying it works as I would expect. As an example think about an Excel spreadsheet. If I remember correctly it by default aligns text on the left and numeric values on the right. Maybe an example use case would be to have let’s say 4 numeric values on top of each other. Each would have a variable length prefix. Aligning the values right would have all the numeric data on the right and the varying prefixes then unaligned to the left.

I agree having the labels also aligned to the right would probably make the widget more useful to me personally though. Then again having centered values with centered labels (which is how it would logically work) would just be a mess as there’d be no straight line for the eye to follow.

We offer so much flexibility. I understand why you are confused and can’t choose the right layout :wink:

Well I’m not too confused with the layout possibilities although for the given moment I am with some widgets like the Device Tiles (don’t know if it could solve my issue). I’ll go through the workarounds one by one and include a screenshot of some of them implemented so you’ll hopefully see the problem.

make one string on hardware and send to 1 widget (full width)

Since the font is not constant width the values on the right would be shifting left and right around all the time. Not sure who would find this a usable interface?

make 3,2,3, widgets, all with centered labels

This does not help as you can see on the screenshot row 3.

make 2,3,2, widgets, all with centered labels

This does not help either as you can see on the screenshot row 2.

make 4, 4 widgets with centered labels

This will work but even though I know you’re after a more “air” in the layout instead of information density, don’t you think there’s a little bit too much air on the screenshot row 1?

make 2,2,2 with 1 cell offset

This would make no difference as I used 2,2,2,2 previousl and the values did not fit.

Use LCD

I personally find the LCD too geeky in an aesthetic sense. It’s too clunky and has bad contrast with he values (like their real world equivalents of course). It would also be too much work merging values from different sources and trying to make them align on the labels (which would be the first row I assume).

this is planned

If this happens to make 22.5 °C fit in two columns that would certainly help in some of the cases. It also sounds like an improvement besides the cropped values. Good to hear this is on the works!

Below is the promised screenshot. All widgets center aligned with medium font size as small was just too small. There’s some obvious issues with this but I’ll still list them:

  • temperature values are now legible would be cleaner next to each other since there happens to be three of them
  • 2x3x2 with one unused column leaves one value cropped. Of course in this particular case it would make much more sense to make it a 2x3x3 layout and then each of these values would fit.
  • 3x2x3 layout of the small particle (PM) concentrations (all related and would be nice to have on a single line) obviously don’t work that well. Please ignore the illogical ordering, it got mixed up while doing the changes.

With a font option between small and medium with the DPI fix to make the values fit an equivalent area of the widget on bigger screens would/will hopefully make things pleasing to the eye again. :slight_smile:

Besides the complaints for this particular design decision/current execution of it I want to say the Blynk team is doing awesome work. The app has inspired me to do so many cool and useful things for me and my family in the form of shared projects. I am thankful for this and also really appreciate you taking the time to personally reply here on the forum.

@BlynkAndroidDev can take a look?

No need to, false alarm. I just didn’t have enough data on the particular widgets I happened to try this with. Sorry about this!

With the change of the resize I had to resize some widgets to make the data still fit. This resulted in the fact that I had to make the 2nd row widgets bigger and align to the right to make it more symmetric. The label (“DRUK”) however now ‘floats’ making it less pleasing.
I see your point though, different cases, different required layouts

I might just center align all the values in this case but to me the end result looks acceptable, definately not butt ugly although I see the issue. A hacky solution you could try with the label is to add spaces in front of the value and hope the pixels match the alignment on the button above.

nice one! yes that works, not ideal but less painfull to the eye.
And yes ‘butt ugly’ is a bit too strong, but its that kind of stuff that can really annoy me.

Do WE like this ?

@Ze_Pico It looks like this thread is pretty much done. I guess we just have to adapt to this change and hope either the situation with the existing widgets will improve on future refinements and/or there will be some new widgets @Pavel mentioned earlier on the thread that we can use to better fit the purpose.

What I’m 100% sure will get addressed is the minisculous fonts on larger displays like tablets. This should be just a matter for tweaking the algorithms detecting the display size etc.

Have you tried the test build? If next builds would go that way, issue should be pretty much resolved (still not entirely unless we will be able to at least change font size from code with setProperty). I haven’t received answer to that question, so don’t know if that is/will be possible.

I would like to but at least my tablet refused to install it. I just assumed it’s older than the current Play Store version and had some builtin mechanism preventing it from installation. I’ll just need to wait for an update while not using Blynk on my tablet to avoid getting annoyed about this issue all over again.

guys, this fixed text size font is a really bad move:

with the auto text size i never had any issues viewing my projects on different phones / screens: the auto text just worked flawlessly and i always had the right font size, adjusted dynamically based on the screen resolution and widget content length.

with this new fixed font size, i have to tweak my projects every time when i use a different phone: if i set the font size to be ok on one device, on the other one it is just too small or too large and didn’t displays all content.

we use a shared project in the family, and everyone has very different phones. so we can’t find a general font size to be usable for all members. i have read this topic, but i simply do not understand what is the logic behind this new “feature”? if we anyway have the option for different sized fonts on all widgets, at least let them adjust automatically, not manually every time.

why change something which worked indeed very good up to now, and everyone was happy with it?

this is not cool. dislike :frowning:

4 Likes

Had you checked test build with another font scaling model? It will provide same font sizes for almost all text enabled widget and will scale appropriately on any display size. We are almost ready to release it.

Just two questions:

  1. What about font scaling on other widgets (buttons, gauge, text labels…)? Will the same scaling model be applied to them?
  2. Will it be possible to change the font size from code with set property ?? That would really help to substitute the autoscaling up to some degree…
1 Like
  1. Yes, we are making one model for all widgets (with texts), they will be scaled to 100%, 70% and 60% of the available space in the cell (1x1) - it will provide enough unification of this issue for us, and disable issue of a different look on different displays (but yep, maybe for some devices you will need to make a widget wider if you have long texts). Lots of widgets still have no font size parameter and had forced font size (Timer, Button, Sensors, etc) - most of them will use 70% option for now, but I guess we’ll add it to them. Number Input is a small exception here - it will have 70%, 100% and 200% scale options (last one is for the cases when it’s larger in height)

  2. Not in nearest releases, but I’ll ask @Dmitriy for this option.

2 Likes

Regarding the Auto-scaling labels… I may be taken out the back and shot but maybe a Black-market app will appear that merges in the patch for the auto-scaling with each new version. Or maybe we can raise a sufficient bug bounty that @BlynkAndroidDev can maintain it and we can have harmony again. :slight_smile:

Also I haven’t tried yet - is there a way to send a new line escape character to have the two lines of text in the Label?