“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?

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.

The cameras have been a challenging topic. Few little hurdles to overcome with those:

• Currently, the Marshall and AJX cameras are FTPing an image every 5 minutes or so to the website; as you can imagine, that adds up (space) and would slowly gobble up storage unchecked. Props to Ken for dealing with that, as I’m sure that required either paying for storage or clearing out older files on a periodic basis. Definitely think it’s cool that you can “turn back the clock” to see older images (maybe the camera caught you on launch taking off), so will be setting up an integration with something like Amazon S3 (a cloud-based storage solution which is almost free) to handle the large volume of images (in addition to offloading all of the images posted in the forum).
• That animation is pretty rough (browser has to download and load all of those images before it looks like anything). Definitely like the idea of it – can look into developing a more robust solution for that (perhaps something that converts the last 24 images into an animated JPG and then compresses it which should be a huge boost to performance).
• AJX and Marshall both produce static images and Crestline produces “video” (I use the air quotes for video, since the viewer is actually streaming out a bunch of static images instead of real video); there are additional web cams in AJX as well, but they will only output video to the vendor’s mobile app (so we can’t embed those on the website). Both real video and static images have their pros and cons, but it would be great if we could move toward a consistent solution for all 3.
• Crestline cam – appears to be a very nice piece of hardware, but the software doesn’t really allow for embedding that on a website (on the current site, it’s their viewer stuck inside an iframe, and if you look at what’s going on behind the scenes, your browser is constantly downloading images – if you’re on launch and just want to check a camera, this will crush your connection)

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.