3 ms·

Agreed, weird to say this to a lisper as you guys are all about the elegance etc, but you should really take a leaf out of some JS library authors' books. http

Agreed, weird to say this to a lisper as you guys are all about the elegance etc, but you should really take a leaf out of some JS library authors' books. http://oesmith.github.com/morris.js http://oesmith.github.com/morris.js http://humblesoftware.com/flotr2#!basic http://humblesoftware.com/flotr2#!basic http://wijmo.com/widgets/ http://wijmo.com/widgets/ You seem to have mixed some nice 'magic' (i.e. enough magic to draw a somewhat beautiful map of the United States, and your very interesting theming feature) with some very odd low-level stuff, e.g. ':path.state {:d (geo->svg (get states state-name) :projection proj' What is that about? Why should I have to know about those things? Also I think you should seriously consider factoring your styles out of your ClojureScript, that's what CSS is for. i.e. this stuff: [:div {:style (style {:height bar-height ... :background-color "gray"})} [:span {:style "color: white;"} label]]))]) ... should no more be written in ClojureScript than it should be written in JavaScript. That's CSS's domain. You will reap the rewards (first simple win being able to tweak and experiment with styles in Chrome's dev tools) if you start using CSS classes to define your styles. Apart from that it's very interesting work and you clearly have an eye for beauty, look forward to seeing more.

milroc 14y ago
Just a little info on this, this is not a charting library, it's probably closer to a graphics or visualization library. It pulls a lot of it's ideas from d3.js, allowing CSS to dictate a lot of your style choices, but also allowing the data to change the style (a typical example is a chart where you have different categories of data, coloring those categories depending on the data). This is low level for a reason, most charting libraries take a specific stance on how to visualize something. d3 and c2 let that be dictated entirely by the developer. It may take more effort to get a bar chart working in either of these libraries but generally the control you have allows you to fit it into your design rather than your design molding around the charting library you use.
- nilliams 14y ago
  Okay, interesting. I perhaps don't understand enough about the syntax to appreciate why those lower-level constructs would be beneficial w.r.t the geo stuff. On the styling sure, data should often dictate the style in visualisations - the most noddy example people tend to give in JS as the exception to the rule of never 'programatically' (JS) setting styles is the progress bar where the width has to be data-based (as CSS-classes only make sense for discrete increments or 'states'). Of course the same applies for colouring/shading and sizing based on say population data or whatever is being modeled in a visualisation, I get that. But, in the example on the first page the bars of the histogram are all explicitly coloured gray w/ white text programatically and the bar heights are manually set to '20' (presumably px). What would make more sense is for them to have a default class of say 'hist-bar-default', which is set in CSS to { height: 20px; background: gray; color: white }. If anything it would just make the example simpler as it actually muddles up the code where the widths are being dynamically set. shrug Edit: btw, you will see that d3.js does this, it applies classes where appropriate rather than setting styles explicitly: http://mbostock.github.com/d3/ex/cartogram.html http://mbostock.github.com/d3/ex/cartogram.html
  - milroc 14y ago
    This is more of a choice of how the creator wanted to display the usefulness of C2. That can just as easily be done with C2. [:div {:class "hist-bar-default"}] would likely be the way to do it. Also d3.js examples are riddled with bars.attr("style", "height: " + 30px) just because sometimes it's easier to think about it while developing there. It's not maintainable and very problematic in large designs but I would recommend not judging a library based off of design choices like that with examples of d3 or c2. I'm glad you're passionate about visualization though, you should definitely start using these libraries, and after a while (d3.js has been said to "melt your brain initially) you'll realize the benefits of working at a lower level with the data.
lynaghk 14y ago
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/src/cljs/cassowary-cljs-demo/core.cljs 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
- nilliams 14y ago
  Ah great, good to hear it! And yes using SASS sounds like a definite win :)
euroclydon 14y ago
If you want to render the generated SVG in <IE9 via svgweb, then inline styles are the only way to go, because svgweb doesnt support style sheets.

milroc 14y ago

Just a little info on this, this is not a charting library, it's probably closer to a graphics or visualization library. It pulls a lot of it's ideas from d3.js, allowing CSS to dictate a lot of your style choices, but also allowing the data to change the style (a typical example is a chart where you have different categories of data, coloring those categories depending on the data). This is low level for a reason, most charting libraries take a specific stance on how to visualize something. d3 and c2 let that be dictated entirely by the developer. It may take more effort to get a bar chart working in either of these libraries but generally the control you have allows you to fit it into your design rather than your design molding around the charting library you use.

nilliams 14y ago
Okay, interesting. I perhaps don't understand enough about the syntax to appreciate why those lower-level constructs would be beneficial w.r.t the geo stuff. On the styling sure, data should often dictate the style in visualisations - the most noddy example people tend to give in JS as the exception to the rule of never 'programatically' (JS) setting styles is the progress bar where the width has to be data-based (as CSS-classes only make sense for discrete increments or 'states'). Of course the same applies for colouring/shading and sizing based on say population data or whatever is being modeled in a visualisation, I get that. But, in the example on the first page the bars of the histogram are all explicitly coloured gray w/ white text programatically and the bar heights are manually set to '20' (presumably px). What would make more sense is for them to have a default class of say 'hist-bar-default', which is set in CSS to { height: 20px; background: gray; color: white }. If anything it would just make the example simpler as it actually muddles up the code where the widths are being dynamically set. shrug Edit: btw, you will see that d3.js does this, it applies classes where appropriate rather than setting styles explicitly: http://mbostock.github.com/d3/ex/cartogram.html http://mbostock.github.com/d3/ex/cartogram.html
- milroc 14y ago
  This is more of a choice of how the creator wanted to display the usefulness of C2. That can just as easily be done with C2. [:div {:class "hist-bar-default"}] would likely be the way to do it. Also d3.js examples are riddled with bars.attr("style", "height: " + 30px) just because sometimes it's easier to think about it while developing there. It's not maintainable and very problematic in large designs but I would recommend not judging a library based off of design choices like that with examples of d3 or c2. I'm glad you're passionate about visualization though, you should definitely start using these libraries, and after a while (d3.js has been said to "melt your brain initially) you'll realize the benefits of working at a lower level with the data.

lynaghk 14y ago

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/src/cljs/cassowary-cljs-demo/core.cljs 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

nilliams 14y ago
Ah great, good to hear it! And yes using SASS sounds like a definite win :)

euroclydon 14y ago

If you want to render the generated SVG in <IE9 via svgweb, then inline styles are the only way to go, because svgweb doesnt support style sheets.