This is cool, but I'm curious what makes this superior to just using javascript in a browser? Could still use the same input syntax. Bonus points for having a graphic that could easily scale up if someone right clicks to open it specifically.
You're brave using custom fonts in Word. Fine for personal use, a nightmare if the document is ever shared. And what terminals allow you to change font from the program writing to stdout?
Oops, the site was hackernewsified and is intermittently down for me.
Neat idea, and I do like the OTF hacking, but why not use simple SVG?
<svg viewBox='0 -20 85 40' style="height: 1.5em">
<!-- data in d parameter below as x,y pairs -->
<path d='m 0,0 L 10,5 20,8 30,6 40,3 50,-2 60,-8 70,4 80,6'
fill='none' stroke='black'/>
<circle cx='80' cy='6' r='2'/>
</svg>
It has the advantage of using actual data, it is trivial to generate, is embedded into HTML without an extra fetch, won't confuse screen readers, doesn't require the normal web-font alternative file format dance, and isn't quantised to a set of precreated values.
Isn't the problem worse with this approach? You get
{2,3,4,6,5,4,8,8}
It doesn't look like the thing you copied, and the numbers make no sense (our stock price is 8? since when?). You're back to trying to get people to install the correct fonts, not use it in emails, etc.
Only if they happen to a) be in the range 0-9 (for the sparkline) or 0-99 (for the dot or bar chart) and b) cover (pretty much) the whole of that range. See the page examples, the data in the sparkline bears no obvious relation to the start and end values.
People generally tend to see a lot of percentages so 0-99 should seem reasonable, and the 0-9 is merely a "per dec" and you just need to imagine another digit behind it to get a percentage.
Maybe the set notation curly brackets isn't enough of a signal to think of them as percentages if the font is unavailable, but adding that as a note when copying/pasting isn't entirely strange.
The simpler format is easier to generate, which can make the difference between having something and having nothing.
An example: our company uses redash for sharing ad hoc data sets internally. It'd be easy to generate a SQL expression with array_agg that could be wrapped in a span w/this font. I currently cruft up a call to a google charts replacement to do just that, which sucks because it adds a bunch of image requests.
I _could_ do it with SVG, too, but the expression to create it would be a lot more complex.
I can imagine submitting a PR to redash to autoformat any SQL column named "sparkline" with this font, actually.
(Valid criticism: maybe I should use a richer tool than redash for this...but I love it when a general tool can do a lot just because of composable primitives, AtF Spark fits the bill perfectly here.)
Yeah, "a lot more complex" is pretty sloppy. "A lot more annoying", perhaps. It's doable. The complexity comes when you aggregate tuples of (row number, value) instead of just aggregating value.
To fit in the redash model, you need a single expression that returns a string of HTML. So the example you cite isn't quite there, as I don't think it's valid SQL (or is it? I'm mainly familiar with Postgres--perhaps that example is valid in some other DB?)
So you need something like:
SELECT
'preamble' ||
(SELECT string_agg(ROW_NUMBER() OVER (ORDER BY Date Desc), ...) ||
'postamble'
Except aggregate functions can't contain window functions, so something like:
WITH windowed as (SELECT ROW_NUMBER(), ...)
SELECT 'preamble' ||
(SELECT string_agg(row_number || ',' value, ',') FROM windowed) ||
'postamble'
is needed. Which isn't a big deal, but since you don't really care about the row number, it's nice to be able to skip the CTE and just directly smash the values into a string_agg.
I don't disagree SVG isn't difficult and a lot more flexible, but I think in this case, the font has the advantage that it is accessible to screen readers.
345,
A screen reader is going to see an SVG element and I imagine at best it will use some alt-text or other "description" of the graphic. Versus if the data is literally `123{123,234,435}424` then a person without vision can get much more information about what's actually being conveyed.
I see what you're saying but I'm skeptical. The point of graphs is to show the gist of a lot of numbers. What's more useful, a screen reader spewing dozens of numbers at you for one of those little graphs or a generalization of what our brains are seeing? "an upward trend from 123 to 789."
It only accepts numbers in the range 0-10 (for a sparkline) or 0-100 (for the bar or dot plot), and because it performs no vertical normalisation, you have to remap to that. Making either your data gibberish, or your sparkline oddly offset and scaled (e.g. if you put in the brexit FTSE data / 100).
Except the data density is likely far more than needed for a screen reader. A simple graph that establishes context becomes a trail of 15-20 numbers only a few of which may be relevant.
I'd like a screen reader that read the graph like "One hundred twenty three. Boop. Boop. Boop. Boop. Boop. Four hundred twenty four." with the pitch of the "Boop" proportional to the value.
The accessibility of it kinda irked me too. The real problem with this approach is that it's a kludge. The element here is semantically, a chart. The font makes it lie about that - "Look more text!" Anyone having to deal with accessibility issues regarding icon fonts will have the same issues here: 123{30,60,90}456 isn't a chart, and you'd have to wrap it in another element to make that clear to any accessibility technology.
This is a neat idea, but a tool to generate actual charts will have more longevity.
I like the idea of sparklines and I have used them myself on occasion. But now that I think about it, I'm not sure I've actually ever found a sparklines plot insightful or useful.
We run a Spark cluster for distributed processing.
Spark is awesome - makes it dead easy to parallelize work.
But it's also easy to write bad Spark code that doesn't parallelize well.
So I wrote a report to let us view key stats broken out by Spark job, including a sparkline of avg load on the machines running the job for its duration.
This provides an easy way to see whether a job uses the cluster efficiently, and if it doesn't, where the key points in the job are that it's sitting idle.
It also lets us eyeball the repeatability -- if a given batch job's sparklines are wildly varying from run to run, it usually suggests that something funky is going on in the code.
Also, it lets us have "Spark" lines. Worth it for the pun alone, IMO.
Every product only needs one sparkline anyway. 0% on the left, and bit of up and down (to make it look realistic) then a steep climb to 101% on the right.
The examples listed with sparklines embedded in headlines are not graceful or intuitive at all... to me it instinctively appears to be an ad and i gloss over it.
Sparklines are good for at-a-glance monitoring, as they're a way to show travelling-window patterns in a small space. They're useless for numbers, but great for patterns.
I prefer something to that that I'm sure that has a name, but I don't know it (but would love to), at least for real-time things:
Let's say you have X buckets, with Y slots each. Each tick, you put the current value in the current slot of the first bucket, and advance the index by one. When the index reaches the number of slots, reset the index to 0, and put the average of all slots of the first bucket into the current slot of the second bucket. When the second bucket overflows, put the average into the current slot of the third bucket, and so on. This way you can fit both current and very old values into the same tiny graph, to give a rough impression of "level of activity" (e.g. for tray icons).
If that doesn't have a name yet because I invented it (I doubt that), I call it syrup buckets (syrup is how it can look like depending on the amount of buckets, slots and the tick speed).
I've met finance wonks that find them incredibly useful as quick glance activity meters on stocks and currencies. There are finance widgets that auto-add them every time someone even mentions a stock code like AAPL or a currency code like EUR in a webpage or an email. I don't personally think I would want to live in that world, but more power to those that do, I suppose.
There is no HTML, it is literally text like: {1,2,4,6}
I'm not versed on screen readers, would wrapping that text in an HTML element (like a span) with a title attribute that read: stock price for last 5 years - solve accessibility issues? How do screen readers generally handle charts?
Usually a chart would be an SVG that contained a <title> and <desc> tags. Or an <img> tag with an alt attribute.
I haven't tried it, but perhaps aria-label would do the trick.
My point is, people create these fairly novel approaches all the time, but never think about the structure of the markup, and if the semantic meaning is at least usable for screen readers. Turning on screen reading functionality in Chrome, the first example in the article read as follows:
"1 2 3 left brace 10,20,30,40,50,60,70,80,90,100 right brace 7 8 9"
A quick check with ChromeVox confirms that, at least for that screenreader, aria-label works fine. e.g. <span aria-label="sparkline showing a linear upward trend">{10,20,30,40,50,60,70,80,90,100}</span>
Ha, I dig the name `spark`. I did a tangentially related project years ago — also called spark — that did simple sparklines in shell: https://github.com/holman/spark
Just as a warning, though; over the years I’ve gotten 3-4 requests by media companies to write a book on Apache Spark, so, um, watch out for that one. (Regardless of whether you know Apache Spark or not, you should go for it. I believe in you.)
Reading those examples hurt my brain, but probably because I'm used to reading figures with labelled axes. My first gut reaction was, "great, figures with no x-axes," however, he had the x-axis in the text, which made my head hurt more.
First, my eye gravitates towards the figures. This forced me to look at the sparkline to get the shape, go back to the left to see the y-axes min-limits, then scan to the right to see the other limit. Then, I had to read around the line in the text to understand the x-axis, then look back at the sparkline again to understand the trend line in context. It caused more confusion for me than enlightenment.
I tend to like sparklines. They can be pretty useful on dashboards and for reports. But this implementation, in my opinion, is not as visually digestable as the JS implementation [1]
lol ok, it is if you're trying to gauge whether a stock's behavior is local to itself, or signifies a trend in all the stocks in the same related sector .
Nice idea! This approach could be useful for quick charting in data analysis tools like Jupyter Notebook and the like. It can even be embedded into Markdown.
There are several predecessors with the same idea of using a font that represents numbers as a graph: FF Chartwell [1], Chartjunk [2], Datalegreya [3].
65 comments
[ 2.5 ms ] story [ 124 ms ] threadNeat idea, and I do like the OTF hacking, but why not use simple SVG?
It has the advantage of using actual data, it is trivial to generate, is embedded into HTML without an extra fetch, won't confuse screen readers, doesn't require the normal web-font alternative file format dance, and isn't quantised to a set of precreated values.Poor old SVG, it is constantly being reinvented.
Maybe the set notation curly brackets isn't enough of a signal to think of them as percentages if the font is unavailable, but adding that as a note when copying/pasting isn't entirely strange.
An example: our company uses redash for sharing ad hoc data sets internally. It'd be easy to generate a SQL expression with array_agg that could be wrapped in a span w/this font. I currently cruft up a call to a google charts replacement to do just that, which sucks because it adds a bunch of image requests.
I _could_ do it with SVG, too, but the expression to create it would be a lot more complex.
I can imagine submitting a PR to redash to autoformat any SQL column named "sparkline" with this font, actually.
(Valid criticism: maybe I should use a richer tool than redash for this...but I love it when a general tool can do a lot just because of composable primitives, AtF Spark fits the bill perfectly here.)
> it would be a lot more complex
I don't use redash, but isn't the 'complexity' just the boiler plate literal text? The query is rather simple.
No more complex than the google chart call, surely?To fit in the redash model, you need a single expression that returns a string of HTML. So the example you cite isn't quite there, as I don't think it's valid SQL (or is it? I'm mainly familiar with Postgres--perhaps that example is valid in some other DB?)
So you need something like:
SELECT 'preamble' || (SELECT string_agg(ROW_NUMBER() OVER (ORDER BY Date Desc), ...) || 'postamble'
Except aggregate functions can't contain window functions, so something like:
WITH windowed as (SELECT ROW_NUMBER(), ...) SELECT 'preamble' || (SELECT string_agg(row_number || ',' value, ',') FROM windowed) || 'postamble'
is needed. Which isn't a big deal, but since you don't really care about the row number, it's nice to be able to skip the CTE and just directly smash the values into a string_agg.
It's a minor thing, but I'm lazy.
Mind sharing what you're doing today with me (the Google Charts approach)? My email is arik at redash.io.
Thanks!
I don't disagree SVG isn't difficult and a lot more flexible, but I think in this case, the font has the advantage that it is accessible to screen readers. 345, A screen reader is going to see an SVG element and I imagine at best it will use some alt-text or other "description" of the graphic. Versus if the data is literally `123{123,234,435}424` then a person without vision can get much more information about what's actually being conveyed.
It's an interesting problem, to be sure.
Alibaba: 93.89{40,27,69,58,44,42,52,39,27,8,40,45,33,37,24,20,30,36,36,29,40,60,50,40,50,63,87,100}152.11
Brexit: 5562{4,27,48,37,60,40,56,54,59,62,37,63,30,59,75,68,50,40,47,30,5,9,50,74,59,75,100,92}7501
It only accepts numbers in the range 0-10 (for a sparkline) or 0-100 (for the bar or dot plot), and because it performs no vertical normalisation, you have to remap to that. Making either your data gibberish, or your sparkline oddly offset and scaled (e.g. if you put in the brexit FTSE data / 100).
Sounds like a job for aQuery! ;)
http://donhopkins.com/mediawiki/index.php/AQuery
Because author's goal was to create charts "without using code". And SVG is much more "code" than simple "{}" markup.
This is a neat idea, but a tool to generate actual charts will have more longevity.
Spark is awesome - makes it dead easy to parallelize work.
But it's also easy to write bad Spark code that doesn't parallelize well.
So I wrote a report to let us view key stats broken out by Spark job, including a sparkline of avg load on the machines running the job for its duration.
This provides an easy way to see whether a job uses the cluster efficiently, and if it doesn't, where the key points in the job are that it's sitting idle.
It also lets us eyeball the repeatability -- if a given batch job's sparklines are wildly varying from run to run, it usually suggests that something funky is going on in the code.
Also, it lets us have "Spark" lines. Worth it for the pun alone, IMO.
Any new HR product should have a hero page with:
- a couple of sparklines
- a mugshot of user/candidate
- some important looking numbers in a giant-assed sans serif font
Throw in a social media-like feed down the side of the page for added oomph.
Things have moved on from the days when a pie chart was table stakes.
Maybe we can just relabel everything in terms of "features discovered".
Let's say you have X buckets, with Y slots each. Each tick, you put the current value in the current slot of the first bucket, and advance the index by one. When the index reaches the number of slots, reset the index to 0, and put the average of all slots of the first bucket into the current slot of the second bucket. When the second bucket overflows, put the average into the current slot of the third bucket, and so on. This way you can fit both current and very old values into the same tiny graph, to give a rough impression of "level of activity" (e.g. for tray icons).
If that doesn't have a name yet because I invented it (I doubt that), I call it syrup buckets (syrup is how it can look like depending on the amount of buckets, slots and the tick speed).
I'm not versed on screen readers, would wrapping that text in an HTML element (like a span) with a title attribute that read: stock price for last 5 years - solve accessibility issues? How do screen readers generally handle charts?
I haven't tried it, but perhaps aria-label would do the trick.
My point is, people create these fairly novel approaches all the time, but never think about the structure of the markup, and if the semantic meaning is at least usable for screen readers. Turning on screen reading functionality in Chrome, the first example in the article read as follows:
"1 2 3 left brace 10,20,30,40,50,60,70,80,90,100 right brace 7 8 9"
The semantic meaning is lost.
Just as a warning, though; over the years I’ve gotten 3-4 requests by media companies to write a book on Apache Spark, so, um, watch out for that one. (Regardless of whether you know Apache Spark or not, you should go for it. I believe in you.)
http://sparkjava.com
First, my eye gravitates towards the figures. This forced me to look at the sparkline to get the shape, go back to the left to see the y-axes min-limits, then scan to the right to see the other limit. Then, I had to read around the line in the text to understand the x-axis, then look back at the sparkline again to understand the trend line in context. It caused more confusion for me than enlightenment.
[1] https://omnipotent.net/jquery.sparkline/#s-about
https://finance.google.com/finance?q=NYSEARCA%3ASPY
[1]: https://typographica.org/typeface-reviews/chartwell/
[2]: https://nsfmc.github.io/chartjunk/
[3]: http://figs-lab.com/datalegreya
https://github.com/aftertheflood/spark#using-atf-spark-in-ms...
The "how it works" section doesn't really explain anything, it's more of a "how to use it".