An alternative view for MHL buoys.
Latest index
Latest buoy page
An alternative view for MHL buoys.
Home Page: http://buoys.surftourist.com
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.
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.
It's slow.
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
Looking a bit fuzzy. Things might be off (maybe from #23, although that's now reverted).
Give credit to MHL, persistent link in footer.
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?
Flick between buoy show.
Get sketching and play with some better ideas for conveying this information.
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...
This repo's readme is bad.
Also, smoothing out the corners would be nice.
Tabs for past 6 hours (default) and past 24 hours should be enough.
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.
Apparently the assets we're serving aren't browser cacheable. Sort it
Currently there's an API request whenever:
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.
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.
Also concat scripts.
About page, accessible from the header, probably top right.
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.
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.
The buoy in the graphic is kinda sweet.. I can imagine a loading animation where it bobs about by itself.
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)."
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.
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.
Especially on mobile. Subheads... ? Ruthlessness?
I noticed it after I added the animated direction arrow.
http://www.buoyalarm.com/stations/264/kaneohe-bay-hawaii/conditions/waves <- this page is hotttt
Especially in header. Padding so they're easier to tap.
Better to have more detail here.
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 */
}
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...
The direction history graph doesn't make sense. We should shift to an arrow per measurement.
Looks pretty ugly on my home screen at the moment.
From @sebr
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
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.
Alongside the history, I'd like an indicator of whether there's a rise or fall. e.g. surf is picking up.
Looks like there could be some more ocean readings and more data here http://www.bom.gov.au/catalogue/data-feeds.shtml
NSW is handy for me, but not for everyone.
Get out of the 80's
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.