The math we went through to come up with $25 for a month (this is where having that historical data would have been a big help) – if we knew how many visiting pilots were out-of-towners (perhaps coming into town to fly for a long weekend) and how many are SoCal locals who might come up once a month, we could make a better guess on who this would impact the most. $25 for a month means that out-of-towners (or students) would end up saving a little money (as long as they fly for 3 days or more); SoCal pilots who might just pop in for a day here and there would be paying a bit more. $20 seemed too low (you could fly for 4 months and the club would lose out) and $30 seemed a bit high (didn’t want to scare off SoCal locals).

Tried to “shoot for the middle” as much as possible to minimize impact for everyone and still maintain revenues for the club. Having all of the other multiples of months just seemed unnecessary/impractical and probably targeted at fringe cases of what people might want.

Yep – understood.

Here’s a quick and dirty sample that’s one potential solution (this one still does it all in the browser rather than on the server, kind of like the current solution), but some bandwidth is saved (this is showing 10 frames – looks like one frame per minute) – this one doesn’t work on mobile, so definitely not “it”:

https://crestlinesoaring.org/gifshot-test/

For the storage issue (to keep things simple), could also consider keeping only the last 24-48 hours of imagery. That keeps space requirements down, but still gives everyone a chance to grab an image if they want one for posterity. May need to put together a simple tool for flipping through the images to make that practical for pilot use.

Page Layout

This likely will generate the most debate, as most pilots that I’ve met all look at weather very differently and have very different workflows. This first attempt was aimed at balancing the following:

• Organized: since each location has its own weather station readings and forecast tools, it made sense to organize the page at a top level by location (Crestline, Marshall, AJX). Each location is then divided into “real” data on the left (weather station readings that are actual) and forecast data on the right (weather models or predicted conditions).
• Mobile usability: I think most of us are looking at this stuff either in the LZ waiting to ride up, or even on launch as we’re looking for a good window; page (in addition to the rest of the site) had to be very usable on phones (without tons of pinching/zooming, extra clicks, or extra page loads). Entire page stacks when you go down to mobile sizes and is organized in the same way – location: real data first (weather station data) followed by forecasts; this makes for easy scrolling and finding your way; on mobile sizes, all graphs & models are the full width of the screen (no matter if you’re oriented portrait or landscape)
• Minimal scrolling: page is information dense (graphs for multiple locations, additional links, etc); scrolling is necessary, but some of the visuals that are present on other pages (which provide continuity across the site) were removed from this one but scrolling is unavoidable. Primary goal was to make sure the data was clearly visible and usable (which means large graphs), so a balance was sought after there.

“Offline” status

Due to power or weather conditions, the weather stations frequently go offline or fail to report data for a long period of time. I was in the LZ a couple of weeks ago, and several pilots were talking about the current conditions that the Marshall station was reporting. I had to let them know that the data was over an hour old, as it wasn’t obvious on the charts that that was the case.

I put a check in the new graphs (and the compass gauges) to show an “Offline” message if the last data received is over an hour old. I think this is too long still, but wanted to start with low impact first.

Should this timeframe be lowered, and how much?