Make the rain chart tidier and easier to understand

[benji1000]

Hello,

one of my principal concern when using a weather forecast app is the ability to see rain forecast. Forecastie is pretty good for that, as it displays a chart with rain forecast for the next 5 days. However some things bother me with this feature. Here is a screenshot so we can talk about it more easily (pardon my French!).

• The Y-axis is not precise: we do not know if the units are in mm or in inches, and the 1 is not aligned with any dotted line. To be clear: I don't require knowing exactly if it's going to rain 1mm or 1,3mm (as it would be pretty useless and inaccurate anyway), but I think it just looks bad that way.
• The X-axis is also not very precise: we can't really see precisely when does a day start or ends. So we do not know if it's more likely to rain in the morning or in the evening.
• This feature is not "easily" accessible: one has to open the app (this data is not showed in widgets), open the top-right menu, select "Charts" and scroll down the page.

One app that I've been using for the last few months is "La Chaine Meteo", which can display rain forecast hour-by-hour. You can see it on their website, if you click on "Heure par heure +" next to "DE 9H À 12H" or "CET APRÈS-MIDI" or "CE SOIR" or "CETTE NUIT" (scroll past the video).

I eventually stopped using that app because it contains trackers, advertisements, is cluttered with too many menus and views, and a lot of BS. Very different from Forecastie :) but I do think that some of their ideas could be implemented in Forecastie. I know OpenWeatherApp has this data, if you go for example here, then "Chart" and then "Precipitation".

So anyway, what I'm saying is, I would like to be able to access rain forecast more easily (integrated in some way in existing or new widgets for instance, and/or within its own menu) and more precisely (maybe adding textual table data below the graph).

Thank you for the great work on this app anyway :)

[robinpaulson]

The Y-axis is not precise: we do not know if the units are in mm or in inches, and the 1 is not aligned with any dotted line. To be clear: I don't require knowing exactly if it's going to rain 1mm or 1,3mm (as it would be pretty useless and inaccurate anyway), but I think it just looks bad that way.

Yes, it is a little clunky, it could look a bit more elegant. The numbers are not very well controlled, neither are the lines. We should probably coordinate their existence in some meaningful way

The X-axis is also not very precise: we can't really see precisely when does a day start or ends. So we do not know if it's more likely to rain in the morning or in the evening.

True, perhaps we use a vertical band of pale foreground colour for the theme to differentiate the day from night?

This feature is not "easily" accessible: one has to open the app (this data is not showed in widgets), open the top-right menu, select "Charts" and scroll down the page.

You can now click the weather icon (rain, clouds, sunny, etc.) at the top of the screen to get to the charts.

As for the scrolling, at some point we will put all charts on one set of axes. See #297 for more.

[benji1000]

Than you for your answer and for considering my feedback, @robinpaulson!

True, perhaps we use a vertical band of pale foreground color for the theme to differentiate the day from night?

That would be pretty good to separate days/nights or days. But then it should be clear what constitutes night: is it between random hours (like 8 PM through 8 AM) or is between sunset and sunrise? Whatever the choices is, it should be indicated close to the charts...

I actually tried to test that idea, but I had trouble identifying whet constitutes the start of the day (0:01 AM) on the existing chart: is it when the name of the day is written on the X-axis (that's what I considered) or is it in between two days? Also, I was wondering if the amount of rain is an information worth mentioning. Maybe, maybe not, I don't have a strong opinion on that one. I removed it for the test.

Now we can see clearly that it's raining in the middle of the day on Saturday ("sam."), it won't rain at all on Sunday ("dim."), it will rain early morning on Monday ("lun."), and rain heavily on Monday evening. I believe this is a feature that could be greatly appreciated by all users because who doesn't want to know if it's necessary to take an umbrella or not before leaving the house? :)

I'll let you adapt this idea in some way or another from your developer point of view.

You can now click the weather icon (rain, clouds, sunny, etc.) at the top of the screen to get to the charts.

I tried it on my phone but it didn't work. Then I realized that I didn't have the latest version of the app as I thought (I installed it for the first time this week), I only have version 1.6.2 that was last updated on November 23rd 2018, as per its Google Play page. But when I go to the Releases page of the project on GitHub I can see that the latest version 1.10.1 is from 5 days ago... Did you know that Google Play doesn't provide the latest version? How can I use it?

Regardless of this version problem, would it be possible to add a setting that would allow a user to change the behavior of the widget when the user taps on it? For example, one could set it to point directly at the charts, so they are only one tap away from the widget.

[robinpaulson]

That would be pretty good to separate days/nights or days. But then it should be clear what constitutes night: is it between random hours (like 8 PM through 8 AM) or is between sunset and sunrise? Whatever the choices is, it should be indicated close to the charts...

True, perhaps we only separate one day from the next then? Monday, Wednesday, Friday, Sunday dark. Tuesday, Thursday, Saturday light.

I actually tried to test that idea, but I had trouble identifying whet constitutes the start of the day (0:01 AM) on the existing chart: is it when the name of the day is written on the X-axis (that's what I

Yes, this is completely valid.

considered) or is it in between two days? Also, I was wondering if the amount of rain is an information worth mentioning. Maybe, maybe not, I don't have a strong opinion on that one. I removed it for the test.

I think it's important to have some information on amount, be it wordy (small, moderate, heavy, etc.) or numerical. Why do you think it may not be important?

I tried it on my phone but it didn't work. Then I realized that I didn't have the latest version of the app as I thought (I installed it for the first time this week), I only have version 1.6.2 that was last updated on November 23rd 2018, as per its Google Play page. But when I go to the Releases page of the project on GitHub I can see that the latest version 1.10.1 is from 5 days ago... Did you know that Google Play doesn't provide the latest version? How can I use it?

Via the f-droid app and repository, available at https://f-droid.org. I only push updates to that repo. I don't have access to Google Play and anyway Google are utterly bankrupt morally, so I'm not interested in helping them.

Regardless of this version problem, would it be possible to add a setting that would allow a user to change the behavior of the widget when the user taps on it? For example, one could set it to point directly at the charts, so they are only one tap away from the widget.

Possibly; this or something like it has been suggested in another issue: #249.

[benji1000]

True, perhaps we only separate one day from the next then? Monday, Wednesday, Friday, Sunday dark. Tuesday, Thursday, Saturday light.

Yes, that could work! And that would avoid adding more information to the page.

I think it's important to have some information on amount, be it wordy (small, moderate, heavy, etc.) or numerical. Why do you think it may not be important?

I don't have a precise explanation on that one. Maybe because I don't require knowing the "exact" amount of rain, I just need to know if it's going to rain at all or not. But maybe people in general do care about this indication, so it's probably best to leave it as it is (fixing the alignment problem at least). As you suggested, maybe a more wordy information would also be appropriate.

Via the f-droid app and repository, available at https://f-droid.org. I only push updates to that repo. I don't have access to Google Play and anyway Google are utterly bankrupt morally, so I'm not interested in helping them.

Ok, thank you for pointing me to F-Droid. That's a whole other debate so I won't respond to it here.

Possibly; this or something like it has been suggested in another issue: #249.

That was not the point of my suggestion. The tap on the weather icon (rain, clouds, sunny, etc.) at the top of the screen is a cool idea, I was suggesting to add this possibility on the widget.

[robinpaulson]

Yes, that could work! And that would avoid adding more information to the page.

Good, excellent. That would also be similar to how we currently differentiate days from each other in the "Main" weather view.

I don't have a precise explanation on that one. Maybe because I don't require knowing the "exact" amount of rain, I just need to know if it's going to rain at all or not. But maybe people in general do care about this indication, so it's probably best to leave it as it is (fixing the alignment problem at least). As you suggested, maybe a more wordy information would also be appropriate.

Yep, understood. To a certain extent, "15mm" (in 3 hours) is very abstract, but some people will understand that's very heavy rain.

That was not the point of my suggestion. The tap on the weather icon (rain, clouds, sunny, etc.) at the top of the screen is a cool idea, I was suggesting to add this possibility on the widget.

Yes, I wasn't concentrating. I'm sure someone has suggested it but can't find it now. If I recall correctly, the full suggestion was "Provide an option to make charts the default view", which would of course apply to opening the app from the homescreen/app list as well as from the widget.

[robinpaulson]

@benji1000 Do you code, would you be prepared to add any of these ideas?

[benji1000]

Unfortunately, I'm not much of a Java coder myself :\

[robinpaulson]

I'll take a look at the android graphing library, see if I can work out how to add the bands.

[robinpaulson]

After a bit of research into the charting library (William Chart, here: https://github.com/diogobernardino/WilliamChart/ ), I'm unsure if it's possible to either control the horizontal grid lines or add in arbitrary pale strips. It's possible I am completely wrong, of course. We could do so by drawing lines and blocks with another library, or switch entirely, but that's a bit more effort than I have the time and inclination for at the moment. I'll leave this open, perhaps others will take a go at it.

[FridoDeluxe]

... perhaps others will take a go at it.

Let's go :grin: I took a look at the charts and I started with the temperature, because most things you discussed so far is valid for all graphs.

Concerning the alignment of the labels at the Y-axis and the vertical grid lines: Currently always the default of 6 grid lines is used. Independent from that the labels have a fixed interval of 2 (for rain it's 1), that's why for example the pressure's labels are so densely packed. I added some calculation to align both:

(Details are up for discussion: How many grid lines? Maybe twice as much labels as grid lines?)

Concerning the week day labels on the X-axis: They are not always on the first value of the day (1:00) but may be shifted up to 3 places (10:00). This is confusing, but I guess the idea behind it is to keep some distance between the first two labels.

I've found no way to include the unit into the Y-axis using WilliamChart. Still this can be achieved by extending the surrounding layout (adding a Text left to the chart). But as far as I can see there is no feasible way to add vertical bars to separate days from each other (which is an excellent idea by the way).

[robinpaulson]

The graph you linked to is a big improvement, nice work.

It does appear William Chart is a limitation to improvements here, perhaps we investigate something more powerful, or ask the WC dev to include the features we need?

The latter of those will take time, if it happens at all, so what do you say to doing some research into replacements?

[FridoDeluxe]

I had an idea using WilliamChart and tried to overlay a bar chart for the days with a line chart for the actual temperature. It's two separate chart views stacked on each other via a RelativeLayout:

Looks promising in the first place. But first of all it's more an ugly hack to draw two charts over each other. And secondly I didn't manage yet to move the Y-axis labels correctly left to the graph while keeping the horizontal alignment.

The current version of WilliamChart was rewritten in Kotlin, aims for simplicity and seems to have not all features of the (four years old) Java version Forecastie is using. I'll do some research for alternatives ...

[FridoDeluxe]

By the way, do you also think a bar chart would be more suitable for the rain/precipitation forcast? I have the feeling it's a more common way of visualizing rain.

It would remove the "zero line" at the X-axis for periods with no rain and thus highlight the actual rain. On the other hand, if there is no precipitation at all in the upcoming five days, the chart will be completely empty without even a zero line.

[robinpaulson]

By the way, do you also think a bar chart would be more suitable for the rain/precipitation forcast? I have the feeling it's a more common way of visualizing rain.

It would remove the "zero line" at the X-axis for periods with no rain and thus highlight the actual rain. On the other hand, if there is no precipitation at all in the upcoming five days, the chart will be completely empty without even a zero line.

Yes to the bar chart, absolutely, it's a cumulative measure, not an instantaneous snapshot. It is also more common.

As to your latter point: that's fine, if there's no rain, we show nothing. That said, I'd like to see a mockup with fake data first, in case there are any gotchas we can't predict.

[FridoDeluxe]

There are other charting libraries, but it was hard for me to find something that is actively maintained, open source, lightweight and allows combined charts. MPAndroidChart and AnyChart are promising and powerful. But nothing convinced me right away during my (admittedly short) research. Because I've already played around with WilliamChart and I like the clean look of these charts I continued and achieved a quite satisfying result (no mockups, but real code and data):

I managed to align both charts now pixel-perfect over each other (the vertical background bars are generated automatically exactly for the data of the actual chart on top). Stacking both charts onto each other is still not a perfect solution, but with comments the respective source code should be understandable/maintainable.

The Y-axis unit is now included in the heading (easy to code, adds less visual clutter to the layout). Y-axis values are always itegers and aligned with the grid lines. The day label is centered (13:00) below the day (except for first and last day in case it's not possible). The border between night and day is exactly at the value of 1:00 for line graphs. For the rain chart every bar belongs to the right day.

• Temperature:
  • grid lines: always 5
  • range: from min to max value (each rounded down/up)
• Rain:
  • grid lines: maximum 7
  • range: from 0 to max value (rounded up)
  • inch as a unit is now supported (only integer values are possible with WilliamChart, this looks weird for normal/low precipitation values)
• Pressure:
  • grid lines: always 5
  • range: from min to max value (each rounded down/up)
• Wind Speed:
  • grid lines: maximum 7
  • range: 0 to max value

The code is working but needs to be revised. I could prepare a PR or still change something. What do you think? Has @benji1000 as the issue initiator any thoughts?

[robinpaulson]

This looks excellent. Yes, it's not ideal, but given what we have I tihnk it's a big improvement. I agree with your point on good commenting.

One thing I'm not sure of: "The border between night and day is exactly at the value of 1:00 for line graphs". Shouldn't the border be at some arbitrary point (say 6am/6pm), or calculated precisely (as we did in #373)? Or have I misunderstood?

Great work, please prepare a PR and I'll accept it.

[FridoDeluxe]

One thing I'm not sure of: "The border between night and day is exactly at the value of 1:00 for line graphs". Shouldn't the border be at some arbitrary point (say 6am/6pm), or calculated precisely (as we did in #373)? Or have I misunderstood?

Sorry, my fault. What I meant was that the border between two days is exactly at 1:00. The background bars do not visualize night and day, but differentiate the days from each other. I'm not sure if that gets clear from looking at the graphs without any explanation?

To align background and graph was a bit tricky. But I guess it will be also not that easy using a different library that provides combined graphs, because a bar graph is not automatically suitable for producing background bars.

I'll check everything again and will prepare a PR in the next days.

[robinpaulson]

Ah, that helps, I understand now.

Could you adjust the border so it's at 00:00/24:00? That's generally accepted as the break between one day and the next.

But I guess it will be also not that easy using a different library that provides combined graphs, because a bar graph is not automatically suitable for producing background bars.

I think this is a good point. Any library which does offer arbitrary blocks in its API is likely to require similar info and coding. We're not going that far into weirdness by doing this, I'm quite OK with it.

I'll check everything again and will prepare a PR in the next days.

Great stuff. I'm looking forward to this change, it will improve the graphs significantly.

[FridoDeluxe]

The background bars are a bar chart actually for the same data. The bars have either 0% or 100% height and no spacing between each other (so that it looks like a coherent block). The height alternates depending on the day, but there are as much bars as there are values for the foreground chart. That's why the border between the days is currently exactly at 1:00.

Now when I think about it I might be possible to move the day border to 0:00/24:00 by just having 24 instead of 8 bars per day. I'll give it a try in the next days.

Does anybody know if the hours of the 5 day forecast are always 1, 4, 7, 10, 13, 16, 19, 22? For me it's the case even with dayligth saving time. This information is relevant for the code. It's easier to code if you know that the last hour per day of the forecast is always 22. But I couldn't find any documentation yet.

[robinpaulson]

The background bars are a bar chart actually for the same data. The bars have either 0% or 100% height and no spacing between each other (so that it looks like a coherent block). The height alternates depending on the day, but there are as much bars as there are values for the foreground chart. That's why the border between the days is currently exactly at 1:00.

Now when I think about it I might be possible to move the day border to 0:00/24:00 by just having 24 instead of 8 bars per day. I'll give it a try in the next days.

it would be nice to do if you can.

Does anybody know if the hours of the 5 day forecast are always 1, 4, 7, 10, 13, 16, 19, 22? For me it's the case even with dayligth saving time. This information is relevant for the code. It's easier to code if you know that the last hour per day of the forecast is always 22. But I couldn't find any documentation yet.

the other forecasters i use (windguru.net, metservice.com) change the hours at each change of clocks.

i just remembered, owm changes with the clocks too.

[robinpaulson]

According to this page, times form OWM are always in UTC, so yes the hour timestamps will shift when the clocks change in spring/autumn: https://openweathermap.org/forecast5#JSON

To find it, do a search on that page for: list.dt_txt

Thinking about it more, having a forecast for 1am and not midnight would be a bit odd.

[FridoDeluxe]

Yes, you are right, UTC and midnight makes sense. Still I'm not sure if Forecastie really changed the hours at the change of clocks ...

I merged the new humidity graph (#392) into my branch, which is available here if anybody is interested: https://github.com/FridoDeluxe/forecastie/tree/improve-charts. Moving the borders between days to midnight is hopefully finished by the end of the week.

[FridoDeluxe]

Just a few changes and hopefully the last update for this issue:

• the border between days is now at midnight (exactly 0:00)
• line color of humidity graph changed from red to blue (which fits better the actual content in my opinion)
• vertical space between graph cards is a bit reduced (which looks better in my opinion)

[robinpaulson]

This looks marvellous, good work.

[robinpaulson]

OK, it looks like we've covered everything which was in the original request. Closing now, the changes have been merged. I made a new release, that will be out in the usual 1-4 days. @benji1000 Please let us know what you think of the new version. Cheers

[benji1000]

Hi everyone! I really like the new visuals for the graphs. It answers perfectly to what I was saying when opening the issue. The graphs are easier to understand. I can't wait to use the new version of the app! Thank you @robinpaulson @FridoDeluxe for your great work 😃

[robinpaulson]

That's great to hear @benji1000

[robinpaulson]

Apparently there was a bug in the Swedish translation, which was causing the build to fail. I didn't notice until today. I've fixed it and released v1.12, along with the other changes we made in the interim. According to CircleCI it builds OK, so it should work this time.

I've also set up CI builds on github, there is an error I don't understand, it appears to be from a piece of code introduced 4 years ago, so I'm not sure of the significance.

https://github.com/martykan/forecastie/runs/325268528#step:4:131

[robinpaulson]

I got the update today, it looks great.

There is one minor niggle though: when i select one of the dark themes, it is very difficult to see the difference between one day and the next. I realise this is the point of the dark/low contrast themes, but I wonder if it's a bit too subtle. What do you all think?

[robinpaulson]

I wonder if we need 6 themes. Perhaps two or at most three is enough. It's certainly easier to maintain, particularly as we add new features, having to check them for every theme.

[benji1000]

when i select one of the dark themes, it is very difficult to see the difference between one day and the next.

Totally agree: the color difference between day and night is too subtle. Also, the last title, "Humidity", is the only one that is black instead of white, making it hard to read as well.

Although it is a different issue, the title "Wind Speed" was not converted to French.

I wonder if we need 6 themes. Perhaps two or at most three is enough. It's certainly easier to maintain, particularly as we add new features, having to check them for every theme.

From the user perspective, I certainly enjoy having multiple themes I can chose from :) but I agree that it complicates maintenance for developers. So if you want to reduce the list, I suggest to keep at least a light theme and a dark theme.

[FridoDeluxe]

Also, the last title, "Humidity", is the only one that is black instead of white, making it hard to read as well.

That was forgotton in the respective commit and I missed that while I was merging it with my branch, but it was easy to fix.

Although it is a different issue, the title "Wind Speed" was not converted to French.

Unfortunately it's missing in the french strings.xml. Another reason to improve the translation process (#364) to spot such problems faster.

when i select one of the dark themes, it is very difficult to see the difference between one day and the next.

Totally agree: the color difference between day and night is too subtle.

Yes, for the dark themes the bars should be brighter instead of darker. I now switched it to transparent white bars, what do you think:

I can provide a PR that fixes both things (brighter background bars and white headings) when my suggestions are okay for you.

[FridoDeluxe]

I wonder if we need 6 themes. Perhaps two or at most three is enough. It's certainly easier to maintain, particularly as we add new features, having to check them for every theme.

Six themes sounds logical if we combine both themes (fresh and classic) with three brightness levels (bright, dark, and black OLED). I am also unhappy with the current state of themes, mainly because of two reasons:

1. Especially the dark themes don't look really good in my opinion (e.g., the colors in the screenshot above don't match nicely).
2. The themes could be better organized by the code. Currently it feels like theming is distributed across all places ...

I think with a more tidier and centralized theme code everything would be easier to maintain. But I have no quick fix in mind and I guess it's quite a bit of work (and deserves its own issue).

[robinpaulson]

@FridoDeluxe The graphs are much improved, that's excellent. Yes to the white text and brighter bars. I agree on everything you say about the themes, I'll create a separate issue and link to this. Then I'll close it.

[robinpaulson]

I've accepted a couple of pulls from Igor and removed the jQuery references. Once you make the changes above, I'll do another release, v1.12.1 (the additions are mostly minor big fixes).

[Korb]

Six themes sounds logical if we combine both themes (fresh and classic) with three brightness levels (bright, dark, and black OLED).

This is currently the "black" theme for AMOLED. Compared to the rest of the screens in the application, this screen is too light, and this is striking:

When "theme for AMOLED" is activated, the user expects to see the screen in predominantly #000-color.