I have a request for a specific type of Labelled Value Widget, which we did have but when recognised was deemed a mistake and removed.
The requested features are:
*Supports Multiline label
*Auto scaling of Content font
My very plain and open goal is to be able to have Blynk working in the flexible way it has since I bought my 20000 energy and started building something very useful. Iām now stuck on an older version and would like to resume being in the current app version - and even better, the code base for it has already been completed. I am happy to contribute some money towards having these two features restored to the current version of the app, please.
I know I am notā¦ I just loaded Blynk up on a newer, high DPI tablet (mostly for use away from home), and sure enoughā¦ there where displays, across my projects, that crapped out and are unable to show the full value, even on the smallest font.
So much for āstandardisationāā¦ more like a standard guaranty that something will look bad on some device somewhere.
Ehh, I will never understand this step āforwardā, just like you and few othersā¦ But what else can we do? We need to forget what was good and get used to what we haveā¦
I have had an interesting parallel situation in work this week, which is in the space of Data Integrations and Reporting within a company. We inherited a lot of reporting that was historically built largely organically over years by one non-technical business user, who is very strong in business knowledge. The team we since grew is in the process of replacing all this legacy world to meet the needs of our growing business and to be enterprise grade.
The data structure side was largely an easy conversation, but it has been a little journey to shift the thinking around the front-end reporting, Multi-dimensional CUBE design, etc. to incorporate scalable design techniques. Some issues disappeared over time through discussion, slight changes to the design and just time to use the new design. However on Friday I made one small change I would have otherwise not wished to, as this person felt it was much more aesthetic (read: familiar) even though there was no net change in functionality. Why? Relationships.
@marvin7 Iām certainly not giving up. This is how I learn new technologies; Iām looking at the decompiler output for both app versions currently to see how to re-implement it.
But I hope it wonāt be necessary as it appears to me that there is no conflict in this case with the technical implementation and progression of Blynk, but something that can be added as an optional App side visual formatting option. For me this is different than changing server ports or a breaking change in a library version to progress the platform, where there is a path forward, itās about the customer having the confidence and reliability in the maturity of the eco-system and functionality.
Itās one of those interesting customer relationship scenarios, the development team and @Dmitriy have every right to move forward in the direction that they see fit. And in the warmest way I can say that they have done a great job with the platform to date. Have a nice Sunday everyone!
Iām with you, although I will not go that way. Simply not enough knowledge and time to learn for that.
I have a feeling it will beā¦ I was wondering, what was the reason, why the āAā (for Auto) cannot be put next to the āLargeā, āMediumā and āSmallā icons. Especially having ready and working code. Just one more option for the user. But it looks it has not been considered, and the whole discussion has been just cut by facts we met.
I am happy to contribute some money towards having these two features restored to the current version of the app, please.
. Nobody likes changes.
