Your Own weather app within KLWP.

This may come in handy:

One of the most exciting things out of Kustom apps I find the ability to design Your Own "weather app".

At first glance it seems that You can simply create some weather widgets - but if You take a closer look on it, You'll discover that You could do much more - up to the point in which You can create virtually Your Own "weather app" (within Your - let's say - KLWP preset).

The reason I find it exciting is that it allows You to have weather forecast constructed completely by Your Own way, keeping Your taste and needs in mind at the first place, both visual- and feature-wise. Earlier on I've used several weather apps, but - to no surprise - none of them was perfect. Or in other words: they always lacked something. On the other hand, however, they've helped Me to figure out what I really need and what way (of presenting weather data) would fit Me most.

I felt excited that as a result I wouldn't be in the need of using any standalone weather app anymore. So I've got the show on the road :) .

First: the overall idea.
As I've mentioned, the first thing I needed to do was to prepare an overall "big-picture" in mind, illustrating how I want My "weather app" to be arranged. What information it should present, where and how? I was still amazed that all those things are up to Me :D . This is what I chose:

1. First: a large, nicely-looking weather icon (out of My favorite icon set Komponent Weather Class) along with - also large - current temperature, including "feels like".
2. Second: hourly conditions (in a form of a 16-hour bar graph (8 displayed at once, tap to see the next 8), covering temperature, precipitation and wind speed).
3. Third: 10-day forecast (5 at once, tap to see the next 5), covering the same data as above.
4. Between hourly and daily forecast I decided to put small, discrete info on the current: air quality, wind speed and location.

So as You see, I've resigned from several other pieces usually included in weather forecast - such as the high and low temperature, pressure, wind direction... because I don't need these as much. The thing I still consider to add is pollen count - due to My spontaneous allergy symptoms. Whereas the thing I miss is the way how Today Weather (and probably some other weather apps as well) puts forecast description - which I like very much. It may go as follows: "Today - light rain in the afternoon" or "Mostly cloudy starting in the evening". To achieve this way of presenting data much work is required - but I think it is too tempting to resign, and this is only a matter of time when I'll do that too :) .

Second: new approach to the "feels-like" temperature.
Temperature level is often a pretty elfish thing ;) : You see one value, but feel something different enough for You to loose trust to the numbers. Therefore the "feels-like" temperature exists - and this I consider the most valuable and practical information I can derive out of the forecast, so I've given a different color to it in order to be more readable.

Every time I wanted to find out what the "feels-like" temperature is, what I really wanted to know was the difference between the two: is it warmer or colder than the predicted temperature states? And how much? So, after a second thought, I've decided to take a different approach to the "feels like" numbers: to display only those differences instead of sole values - because in fact this is the real thing I am interested in. So - code-wise - I needed to design a system which will calculate for Me those differences and, moreover, will present them in a comprehensive way, meaning: every time the "feels like" temperature is lower than the predicted one - it will display the difference number preceded by a "-" sign (which stands for "x degrees colder than the predicted value") - while if the "feels like" temperature is higher than the predicted one - the difference number will be preceded by a "+" sign (which stands for "x degrees warmer than the predicted value"). And one more thing: if the "feels like" temperature equals the predicted value - it should display nothing but the predicted number. Code-wise it may look as follows:

$if(wf(temp, 0,15)-wf(flik, 0,15)>0,"-",wf(temp, 0,15)-wf(flik, 0,15)<0,"+")$$if(wf(temp, 0,15)-wf(flik, 0,15)>0|wf(temp, 0,15)-wf(flik, 0,15)<0,mu(round,mu(abs, wf(temp, 0,15)-wf(flik, 0,15))))$

And this is the code for regular (i.e. positive) temperature bar height - in case You'd be interested ("barH" is a global value for custom max. height for all the bars - "maxTemp" is a global value for custom max. temperature level):

$(((wf(temp, 0, 0)*100)/gv(maxTemp))*gv(barH))/100$

Third: flexibility of custom ranges.
This piece of My "weather app" required the most thinking, mainly because it can be handled many ways, and it may be pretty complex, both design- and code-wise. When it comes to hourly and daily forecast, I wanted to present data in a form of bar graphs. Moreover, I wanted to combine several different kinds of information in a form of bars overlaying each other, but being readable enough to easy differentiate one another.

Now, if You consider this topic in the context of the whole weather app layout - You'll stumble upon a real challenge: some parts of it will be dynamically changing (because of the nature of the data they present) - while all the rest should stay fixed in place (otherwise the whole thing may - for example - stop fit Your device's screen). So I needed to figure out how to arrange all the bars in a way that could prevent such a situation, preserving the whole layout in place and intact.

I think there are many ways to achieve that - the one I chose consists of defining the maximum value for each measurement I want to include (temperature, wind and rain). This way I can be sure that there won't be any single bar of too much height - because all of them should always fit the value range set in the beginning.

Going forward with that approach, however, an interesting point arises. Let's think about the temperature (for example): if it used to be pretty low in the winter while being pretty high in the summer - winter temperature bars may be almost tiny, although pretty high in the summer. During the winter, however, it will be much harder to tell the difference between each bar - due to their low height within the overall range.

I wanted those bars to be always readable - so I didn't like this issue. This has inspired Me to "upgrade" the whole mechanism - by adding flexible ranges, or - being more precise - flexible max. values. Now, during the summer I can set (for example) 40℃ as the max. temperature level and everything will be all right - but during the winter I can adjust the maximum level to the more reasonable at the time, let's say, as 10℃. As a result My temperature bars will be still pretty high (as during the summer) - with any differences between each other now easy to notice. The same thing can be done regarding other measurements, like precipitation level or wind speed: You can always adjust them to Your Own liking, making them as readable as You please. Moreover, thanks to various bars overlapping each other, You can decide which measurement You want to be more readable than the others. Regardless of Your decision I tried to compose all kinds of bars the way for them to be readable enough. Speaking of this, I am very content with how I've shaped the wind bars :) - using sole Kustom features I've managed to give them a kind of a "windy" visual style :) .

Fourth: how to handle rain?
At first glance it seems to be simple: just use the proper formula for the chance of rain (in percentage). But then I've discovered that not every weather provider delivers such an information. There are weather providers within Kustom which deliver only the chance of rain (Weather.com) - or only the precipitation level (Open Weather Map, Yr.No). Although the latter I find more attractive (because it seems to refer to the all kinds of precipitation - not only rain per se) - if I'd like to make this KLWP preset public, I should include both variants, depending on what weather provider You prefer. Since I use the one without predicting rain - I've chosen precipitation level as the data source for my "rain bars" - which, therefore, will cover rain, snow, and so on.

Fifth: what about "below the 0℃" temperature?
The next matter for Me to consider was "below the 0℃" temperature: how to present that? First I thought that I could simply copy&paste the already existing bars, giving them the opposite direction (downwards) - but then I've realized that this way My whole layout will be significantly shrunk - which was not acceptable. So I needed to invent some other way to handle it.

Finally I've decided to simplify the whole thing by using relative temperature range for all temperature levels which are below the 0℃ (I suppose using Fahrenheit is much easier because it doesn't incorporate any "minus 0" numbers). What I mean by "relative" is that the negative temperature bars won't be so precise as positive ones: the positive temperature bars' height has been calculated on the basis of precise temperature values - while the negative temperature bars' height is calculated on the basis of a couple of negative temperature ranges - for Me to have more general insight on how cold will be out there ;) . The code looks like this:

$if(
wf(temp, 4)<0 & wf(temp, 4)>-5,50,
wf(temp, 4)<=-5 & wf(temp, 4)>-10,25,
wf(temp, 4)<=-10,0,
75)$

So it includes three negative temperature ranges: 0 - -5℃, -5℃ - -10℃ and -10℃ and lower. All those values have been tailored to the current location I live in.

This approach of relative ranges I didn't use the first time - I've already incorporated it when it comes to chance of rain (or precipitation level) and wind speed. There was yet another reason why this also was an interesting issue: it requires to define My Own custom rain/wind range. For the rain/precipitation I decided to use standardized ranges derived out of Wikipedia ("light, moderate, heavy, violent") - while for the wind speed I've used totally custom levels based on My Own observation on the speed range wind usually blows in My location (this way My wind bars are pretty accurate in terms of how well/readable they render the current wind speed).

This is an example of the code I use for precipitation bar height ("gv(barH)" stands for global value within which I can adjust all bars' maximum height to make My weather forecast more readable):

$if(
wf(rain, 0,7)>0 & wf(rain, 0,7)<2.5,0.25*gv(barH),
wf(rain, 0,7)>2.5 & wf(rain, 0,7)<10,0.5*gv(barH),
wf(rain, 0,7)>10 & wf(rain, 0,7)<50,0.75*gv(barH),
wf(rain, 0,7)>50 ,gv(barH),
0)$

In case of wind speed the code is much simpler due to that this time I use custom progress bar with "100" as its max. value (whereas "maxWind" is the global value I use to adjust custom max. wind speed to My Own liking = max. readability):

$mu(round,(100*wf(wspeed, 0,0))/gv(maxWind))$