Agree: supporting mobile devices is essential. My front-end for WeeRT used D3. Maybe you're more of a whiz at Javascript/D3 than I am, but I would not call programming it "easy." There were a ton of little details --- clipping rectangles, CSS tags, smooth refreshes --- that I can't say I ever did get exactly right!
I didn't try anything other than local time. It would be nice to support other time zones, but not essential. Indeed, it could be confusing to look at, say, local temperature, in anything other than the local time. The Weather Underground supports only the local time zone. Glad you're showing an interest! -tk On Sun, Jan 8, 2017 at 6:30 PM, Chris Matteri <[email protected]> wrote: > Graphing lines in pure D3 is easier than you might think, and gives you a > lot of flexibility. It's even easier if you use SVG, because D3 will > generate the axes for SVG plots. See http://bl.ocks.org/mbostock/3883245 > > I think making the weather display app mobile friendly is an important > design goal. Smartphones are ubiquitous throughout the world, and are some > peoples' primary computer. Making the app responsive would also allow the > use of cheap tablets (some Android tablets are becoming absurdly cheap) as > permanent weather displays. I modified WXPlot a while ago to make the plots > responsive. Basically you let CSS determine the size of the canvas (or SVG) > and use a Javascript event to redraw whenever it changes. You draw fewer > x/y axis labels/ticks/gridlines as the plot size decreases. D3 doesn't help > much with responsive plots. I wonder if any of the D3 libraries do. > > Another important feature is time formatting. I believe D3 still only > allows time to be formatted in the browser's local time or UTC. I used > Moment.js in WXPlot to format the x-axis labels in the weather station's > timezone. Moment also handles daylight savings time, which, the last time I > checked, browsers don't handle at all. > > If we can't find a suitable library, it wouldn't be too hard to create our > own plot component using Moment and D3. WXPlot essentially has one already, > though it uses canvas, and the view is a bit tangled up with the model (I'm > working on cleaning that up). > > I don't see any problems with using ES6. The vast majority of people use > browsers that support it (http://caniuse.com/#search=es6). I used ES6 > liberally in WXPlot. There were a few features that didn't work without > Babel in Firefox and Safari, but Babel works well and is necessary anyways > if we use React with JSX. > -Chris > > On Sat, Jan 7, 2017 at 8:07 PM, Thomas Keffer <[email protected]> wrote: > >> I agree. The difference in size is not that great, and the absolute sizes >> are small compared to the other things that have to go over the wire. >> >> Either Riot or React would be fine, although I would be a bit concerned >> about the long-term future of Riot as it is supported by such a tiny >> company. >> >> More important is whether there are any off-the-shelf components for >> working with D3. >> >> One other thing to discuss: whether to target only ECMAScript 6 browsers. >> I'd say yes: it is so much easier to program in it and, at this point, we >> would not lose many potential end-users. Chrome and FireFox have supported >> most features for a long time. Safari's support is more recent, but >> complete. >> >> -tk >> >> >> >> On Sat, Jan 7, 2017 at 3:35 PM, Chris Matteri <[email protected]> >> wrote: >> >>> It doesn't seem like the size of React would be such an issue (10 kB for >>> Riot vs 45 kB for React, from the Riot website). I suspect that React's >>> boilerplate and explicit handling of state/dataflow help make large apps >>> more consistent and easier to debug. I also like how JSX feels like HTML >>> and Javascript (it doesn't introduce new syntax), though that's of lesser >>> importance. Certainly the community around React is larger, which means >>> more libraries, tooling, etc. >>> >>> I'll take a look at your comparison of plotting tools. So far I only >>> know about raw D3. >>> >>> You could implement just about anything in canvas, but the performance >>> benefits of canvas are probably not worth the increased complexity, so I >>> agree that SVG should be used. >>> >>> On Sat, Jan 7, 2017 at 2:09 PM, Thomas Keffer <[email protected]> wrote: >>> >>>> react too heavyweight? Wow! Remind me never to go backpacking with you. >>>> :-) >>>> >>>> -tk >>>> >>>> On Sat, Jan 7, 2017 at 10:13 AM, mwall <[email protected]> >>>> wrote: >>>> >>>>> chris, >>>>> >>>>> angular (1 or 2) has way too much overhead >>>>> >>>>> react is more heavyweight than i would like as well >>>>> >>>>> i lean toward riot: >>>>> >>>>> http://riotjs.com/ >>>>> >>>>> if you're going to do dashboards right, you either need a dashboard >>>>> framework that can do everything, or you need a bunch of components that >>>>> play well together and don't get in your way, either when you are building >>>>> or maintaining. >>>>> >>>>> since the former will never be true, i gravitate toward the latter. >>>>> >>>>> right now that means some d3-based plotting tool that can talk to >>>>> influx (or weert), a dials/gauges library (e.g., http://justgage.com/), >>>>> a sparkline library, and a reasonable ui-controls library (e.g., riot). >>>>> use them with jquery and bootstrap on the front end, and websockets on the >>>>> 'back' end. >>>>> >>>>> m >>>>> >>>> >>>> >>> >> >
