dylanfm / buoys Goto Github PK

This repo's readme is bad.

In the worker we respond to errors in parsing the buoy gif/data. If an error occurs, we should flag this in a record alongside the other buoy conditions that are saved. This can be a rough, initial way of giving information to the user when a buoy is not working as it should be.

When I get readings (in worker.coffee) their created at timestamps should be local to the buoy (currently just AEST, which keeps it simple for now) and stored as UTC. Any display of the times should be local to the user. Or should they be displayed local to the buoy too? Maybe so for now, but explicitly say AEST in the UI when displaying times.

http://www.buoyalarm.com/stations/264/kaneohe-bay-hawaii/conditions/waves <- this page is hotttt

It's slow.

Especially in header. Padding so they're easier to tap.

I noticed it after I added the animated direction arrow.

About page, accessible from the header, probably top right.

Sometimes we've got an empty value in the database. When we graph this, we graph it as 0 which distorts the graph. The empty value is displayed as nothing in the bottom table. The distorting of the graphs bothers me. In the graph we should use the previous value again to preserve the graph. Maybe I could make note of this in the table beneath, or just keep it empty. If I keep it empty, try not to leave just an "s" when a second value isn't present.

Get sketching and play with some better ideas for conveying this information.

Better to have more detail here.

Swellcast API provides nice data for some locations on the NSW coast. Currently we'd just be able to use Sydney and Wollongong. Would be nice to integrate this into the buoys app. Also could be an opportunity for fetching forecasts daily, and then learning from the actual readings to see how accurate forecasts are.

Here's an example API response for Sydney: https://gist.github.com/4255871

Apparently the assets we're serving aren't browser cacheable. Sort it

Hey, look http://copypastecharacter.com/arrows there are lots of arrows. Maybe I can avoid SVG fonts and the sprite I'm using. Just play with these...

The direction history graph doesn't make sense. We should shift to an arrow per measurement.

Give credit to MHL, persistent link in footer.

Looking a bit fuzzy. Things might be off (maybe from #23, although that's now reverted).

Not so nice browsing a mobile app in the browser. This is useful on desktop too, and some interesting ideas can be played with there. More data...

Looks pretty ugly on my home screen at the moment.

Looks like there could be some more ocean readings and more data here http://www.bom.gov.au/catalogue/data-feeds.shtml

Tried 24hr times there. Shifted to the current relative hours (-1hr, -3hr). Might switch to trying @FinelySliced's suggestion of 12hr times with the most recent being "Now" if up to 30min old.

Flick between buoy show.

Also, smoothing out the corners would be nice.

Also concat scripts.

http://fontcustom.com/

From @sebr

The buoy in the graphic is kinda sweet.. I can imagine a loading animation where it bobs about by itself.

Allow a user to set an alert for a buoy and conditions. Implies other things... user accounts and so on.

What I like to do is check the current conditions and compare them to when I surfed last. This is often 24 hours ago. By bumping the time to 24 hours I'll allow for this. However, showing 24 x values beneath is going to be an issue. So, I'll split the past 24 hours into 6 times for which a label will be shown. Should work out OK I hope.

Alongside the history, I'd like an indicator of whether there's a rise or fall. e.g. surf is picking up.

Ala http://www.melbourneburning.com/

"This site is not affiliated with the Bureau of Meteorology and does not represent the views, policies or opinions of the aforementioned Executive Agency.

All data is Copyright Commonwealth of Australia, Bureau of Meteorology (ABN 92 637 533 532)."

Currently there's an API request whenever:

• the user visits the index page
• the user browses to a buoy
• the history is displayed on a buoy page

The API response on the index page contains the data for the index page and the latest section on each of the buoys. We should be using this and not requiring an API request for the buoy data on load of the buoy page, just the history data.

Also, these API responses should be cached. I don't want to keep requesting the same data when it could be stored in rootScope or something.

When we run an update in the background the user has to know to press the refresh button. If we were to push updates to the client when an update has been run, the refresh button could be removed.

We're loading the buoy details on the index page, so when the user browses to the buoy show page it should reuse what we got then. But if the user navigates straight to the buoy show page then we need to load it up as usual.

Get out of the 80's

http://www.brettjankord.com/2012/11/28/cross-browser-retinahigh-resolution-media-queries/

@media 
only screen and (-webkit-min-device-pixel-ratio: 2), 
only screen and (min-resolution: 192dpi) { 
    /* Retina-specific stuff here */
}

The space to the right of the end of this graph is the buoy being offline. For the past 5 hours or so the updates have fetched the same value. What should've happened is that the app realises the buoy is offline and reports that rather than the same value. What this might involve is taking not of the x position of each reading and then noticing when it's fetching repeated readings from the same x value

It would be good to know how the current conditions compare to past conditions - the past 24hrs, week, month, season etc.

How would I change the redis schema to handle this?
What sort of stats would be useful for the user?

The range of max Y and min Y in the graph is limited to the data set (here it's currently the past 6 hours). This bothers me because small variations in size or period appear more significant than they are. I could make the min Y value equal to zero. I could also look at the min and max values for the past 24hr (or week) and use them. This could help give the user a better idea of context, especially if I find an unobtrusive way of labelling it.

Especially on mobile. Subheads... ? Ruthlessness?

NSW is handy for me, but not for everyone.

WA: http://www.transport.wa.gov.au/imarine/19138.asp

Tabs for past 6 hours (default) and past 24 hours should be enough.

Move the refresh link to the top right of the page, in the menu bar. Make it work on events or something, so that the listing refreshes or if the user is on the buoy show page, it refreshes the history along with the latest conditions.