lynaghk

Check it out, and if it doesn't work for your team we'd be happy to issue a refund.

Re: WYSIWYG CSS, we initially started w/ flexbox but things like the difference between margins, padding, and absolute positioning confused tons of designers coming from Photoshop/Sketch.

We ended up implementing our own layout system, which can be used directly in production (if you want to ship a runtime), otherwise it's possible to map layouts to something like flexbox+grid or native engines if your designers stay away from things that are hard to implement on those platforms (e.g., aspect ratio).

Our goal is to help people think about layout directly, not try to hide the inherent complexity from them. At the end of the day, most all digital products require close collaboration between designers and implementors.

Hi HN, author here (along with RyLuke).

We launched Subform on Kickstarter in 2016, but are just now opening up our beta to the public.

Subform's focus is on layout. Dynamic layout systems are pretty functionally complex, but creating them is more of a visual process that really benefits from direct-manipulation and a tight feedback loop. (Rather than the endless tweak-reload/recompile-tweak-reload/recompile cycle)

We started with flexbox, but ended up designing our own layout system, which is both simpler and more expressive.

For HN folks who like thinking about conceptual design: https://medium.com/subform/why-not-flexbox-ddbe60396163

Or if you just want to check out the layout system in code, there's a WebAssembly build: https://github.com/lynaghk/subform-layout

Beyond the layout semantics, we've also spent quite a bit of time on the user experience for adjusting layout and hierarchy in the app: https://medium.com/subform/dynamic-layout-at-design-time-91d...

I'm the author of C2, and you're exactly right. React provides everything that C2's underlying DOM manipulation library (https://github.com/lynaghk/singult/) does. React is faster, capable with more browsers, and has better API hooks that let callers control the low-level details.

I bought a ShopBot Desktop with a spindle, and it cost about $8,000. I decided that I wanted to focus on my phone project, rather than on trying to get a cheaper/homemade machine to work properly. (It's the same reason I bought an Apple laptop.)

If your budget is limited but you still want to get a sense of designing/making physical objects, buy a lot of Renshape foam, x-acto knife, and laser print designs to trace/cut.

Once you do that for a few hundred hours on your designs, shoot me an email and I'll be happy to mill them out for you = )

I used Autodesk Inventor w/ HSMWorks for the physical enclosure (both packages have 30 day free trials).

For the PCB, I tried using Eagle (very tedious / confusing) and KiCAD (couldn't figure out how to install on OS X without compiling from source) and ended up using Altium Designer via a friend's dad, who is an electrical engineer. Unlike Inventor / SolidWorks, Altium was very tedious and confusing and I was stuck until I bought an excellent video course on the topic: http://www.fedevel.com/academy/

Photos of two current phone designs and PCBs are here: https://twitter.com/lynaghk/status/632937349458956288

I gave this talk. Slides are here: https://keminglabs.com/talks/#bangbangcon2015

I'll post some photos of the current version and more details on my twitter (@lynaghk) tomorrow (in 10 hours).

Software is all on an 8-bit Atmel microcontroller, written in C in the style of Harel Statecharts (http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...).

Stephen Few has an excellent overview of why pie charts should be avoided: http://www.perceptualedge.com/articles/visual_business_intel...

Neither pies nor mosaic charts should be used if you need exact readings of the data --- though mosaic plots do have the advantage of being rectangular, making segments much easier to label with values than the segments of pie charts.

Full rewrite of The Weathertron iOS app (http://theweathertron.com/) from Angular.js + ClojureScript to React.js + ClojureScript.

The original Weathertron is still runnin' happily for about 40,000 iOS users from a single $5/month Digital Ocean VPS (backend server is written in Clojure).

The motivation for the full rewrite is React.js and the latest Android OS inclusion of a decent WebKit. React's virtual DOM makes rendering more efficient than Angular.js on slower devices and the recent WebKit supports all of the responsive CSS we used in the original iOS version.

Since I don't carry a smartphone at all, I also recently released a free Weathertron Google Chrome extension so that I could use the app myself: https://chrome.google.com/webstore/detail/weathertron/jljkok...

Are you referring to this example: https://variancecharts.com/examples/bar_grouped/ ?

I tend to prefer horizontal bar to vertical bar charts for English graphics because the label text reads left-to-right, making it easier to read.

It's a good observation though; readers often expect the independent variable to be on the abscissa. We'll be discussing these kinds of graphical decisions in a series of free articles on the site.

Variance is currently built on Angular, but that's not part of the public API contract. It's very likely that at a future point we will whip up a faster/leaner DOM compiler and drop 100kB of Angular features that Variance does not need.

We haven't exposed it on the site yet, but if you have an existing Angular.js app then you can import Variance as an Angular module for a cost of about 34kB. Email variancecharts@generalreactives.com and we can get you squared away.

We have some stuff planned, but nothing on a firm timeline.

That said, remember that Variance was designed to embrace HTML and CSS. You want hover effects? Use a plain ol' CSS selector. If you want something more elaborate, you can definitely just throw some classes onto different parts of your visualization and use other JS libraries like Bootstrap's tooltips.

Variance, like Vega, draws a ton from Wilkinson's "Grammar of Graphics". In particular I wanted something like Hadley Wickham's ggplot2 R library, but on the web.

I toyed with the idea of an explicit data format that could be generated by different tools (I talked about this at the 2012 Clojure/conj https://www.youtube.com/watch?v=xyGggdg31mc). Conceptually that route is cleaner.

However, the reality is that any such scheme requires "escape hatches" to drop into the target representation (be it HTML/CSS, Canvas, &c.). We decided it would be best to embrace a single target, HTML+CSS, rather than try to build an abstraction targeting multiple final rendering systems.

Variance is production-oriented which, for data visualization, requires a ton of the "designer interface" as much as it does from the "developer/analyst interface".

The CSS is broken out into necessary structural bits (where everything is gray, there are no margins, &c.) and then into visual themes. If you aren't a designer, you can just use the stock theme. If you are a designer then you can start from the ground up to build the visual identity that you need.

At no point do you ever have to start throwing `!important` everywhere to override our styling decisions. We intend to release actual SASS/Compass mixins so that you can generate the structural CSS directly in your workflow instead of juggling multiple CSS files and their implicit relationships.

As for IE9, it's all flexbox issues. All of the charts are responsive, and Variance leans on flexbox CSS quite a bit (which IE9 does not support).

No apology necessary, as there isn't a useful distinction between "form" and "substance" here = )

My dev background is in the Clojure community, where Rich sets a strong tone about the importance of discussing tradeoffs. We outlined those tradeoffs explicitly on the site because that's always what's on the forefront of my mind when making a technical decision. I'm glad you found it helpful.

Hi, developer lead here. Variance is not built on D3; we're using some of the scale code, but that's it.

In fact, variance-standalone.min.js is about 10kB smaller compared to current d3.min.js = )

Neither of them were released when we started development. Also, I tend to think that it's better to explicitly manipulate JavaScript data structures through ClojureScript than try to build some potentially leaky abstractions on top of them.

Since ClojureScript's protocols are so flexible, it doesn't take a lot of work to teach ClojureScript about JavaScript---whereas the other direction is much more difficult to get right.

Yep; the app is packaged up for distribution via PhoneGap, and we're also using its geolocation shims.

One of the app authors here; The Weathertron uses the backend API provided by the forecast.io guys (who also do the DarkSky app).

Yep, it's about 1200 lines of ClojureScript and 2000 lines of SASS, packaged up for distribution via PhoneGap. We will probably cut an android version soon.

There's no webserver built into C2. The visual REPL is a separate (toy) project.

To use within Clojure, just add c2 to your deps as usual and then

    (ns your-ns
      (:use [c2.core :only [unify!]]))

Use from within ClojureScript is pretty much the same. Checkout

https://github.com/lynaghk/cassowary-cljs-demo

for a rough demo.

We needed it working on the JVM.

Also, it wasn't clear how to wrap D3's functions in a consistent way w.r.t. data handling. For instance, D3 has a histogram calculator that will bin your data--should that return a Clojure map/vector (so you can use those densities in ClojureScript) or should it return the plain JavaScript construct (so you can pass directly to other D3 functions).

It wasn't something that I thought much about at first, but the DOM-representation as hiccup vectors instead of chained syntax is a huge win because it makes mapping data to hierarchies much easier than in D3.

I've talked with Hadley about this at length = )

There's a benefit to working in Hadley's / Wilkinson's grammar, but the tradeoff is that it obscures the underlying DOM representation (or R's graphics subsystem, as the case may be).

ggplot is for analysts, and c2 is for web devs and hackers.

I agree with you 100% re: mixing generic styling (i.e., the bar height/color) with the actual data-driven attributes (the bar width). The styling is just inlined in these demos because I wanted something that worked immediately out of the box from a single file. In production we use SASS to generate CSS styles for visualizations.

The question of how to separate data-driven attributes (the top/left positions for points on a scatterplot) vs. incidental layout considerations (the ordering of bars on a bar chart or grid positions of small multiples) is something I've been thinking about for some time. Ideally I can use C2 for the former and something like constraint solvers for the latter. See:

https://github.com/lynaghk/cassowary-cljs-demo/blob/master/s...

Getting everything tided up for public release was actually on my agenda for this weekend, but someone found the github and posted to HN early =P

C2 isn't a charting library; it's a collection of composable primitives for building statistical graphics. There are some built in helpers---scales, axis templates, and the tick-selection algorithm---that would make it pretty easy to build exactly the histogram graphic you want.

If you want to pick from a menu of fixed data graphics, though, HighCharts, R's ggplot, or Tableau are much better choices than C2.

It's Twilight:

http://keminglabs.com/css/twilight.css

github: https://github.com/lynaghk/c2

video intro: http://www.youtube.com/watch?feature=player_detailpage&v...

I have a CoffeeScript fork (based on Michael Bolin's work) targeting Google Closure's Advanced mode here:

https://github.com/lynaghk/coffee-script

The motivating use case for me is that ClojureScript (the Clojure->JS compiler) is built on Closure, and when I've wanted to integrate third party JS into my ClojureScript projects I've found it easier to port JS to CoffeeScript than to annotate the existing JS for use with advanced mode.

This interview is from November 2011; ClojureScript tooling has improved since then.

Evan Mezeske's lein cljsbuild plugin (https://github.com/emezeske/lein-cljsbuild) is a great place to start.