diagram1Add my vote for this tag information_design2Add my vote for this tag user_interface1Add my vote for this tag visualization1Add my vote for this tag create new tag
, view all tags

Support Sparklines

Sparklines are "intense, simple, wordlike graphics" such as SparklineExample.png or Example sparkline or tambar1.gif. They are typically embedded into the flow of text.


Sparklines were invented by information design guru Edward Tufte. In lieu of a more detailed introduction, Professor Tufte's site has an early release of a chapter on sparklines.

Links of interest:

Examples of Use:

Use on TWiki.org

I'd like to use Sparklines on TWiki.org to display the results of some form of feature voting on the Release topics (DakarRelease, EdinburghRelease etc.) and the CurrentState field topics to indicate there how much proposals were wanted by the TWikiCommunity. (Voting would also be allowed from these topics.)

Initially I'd thought this could be done by a simple one person, one vote system that could be stored in a WebForm field. I then dropped that idea as inherently inaccurate, and thought about a DesireMeter style voting/polling system where individuals could vote on a scale of 1-9 how desirable they found a change but that would probably mean a crude average instead of displaying complete summary of the spread of opinions as there was no specific meaning assigned to to each number. We have used DesireMeter for a kind of feature voting, but it was used in an ad-hoc fashion and couldn't be easily compiled into the Release topics and the CurrentState field topics.

Instead I'd like to use GradientsOfAgreement. This has implications for how the poll is taken and how the results can be used and interpreted.

When to seek group Agreement/Consensus

Previously when we have tried to use feature voting, it didn't work very well (at least, not the way we tried it). It is more useful in situation where a contributor is trying to make up their mind which of several features they want to concentrate on than in trying to decide how a particular feature should be implemented. Lack of support could indicate that a feature's proposed implementation does not suit everyone and could lead to further discussion, but unanimous consent shouldn't be needed on every implementation detail.

It also only works in the context of a fixed roadmap, which TWiki has never had. One way it might be useful is in putting together such a roadmap. Make a big list of all the features/featurettes that should be considered for EdinburghRelease. Set up some infrastructure that allows people to "bounce on a button" to raise the priority of certain features. Then start at the top and work your way down until you think Edinburgh release is ready.

We need a set of voting options that is suitable for use in these situations and a way of using it that allows for quick polling and easy compilation of results. The set of voting options to use on TWiki.org will be discussed in GradientsOfAgreement; the implementation of it will be discussed below.

What it should look like

We need a way of condensing a table such as this:

6 4 2 1        
Endorsement Endorsement with a Minor Point of Contention Agreement with reservations Abstain Stand Aside Formal Disagreement, but Willing to Go with Majority Formal Disagreement, With Request to be Absolved of Responsibility for Implementation Block
"I like it." "Basically I like it." "I can live with it." "I have no opinion." "I don't like this, but I don't want to hold up the group." "I want my disagreement noted in writing, but I'll support the decision." "I don't want to stop anyone else, but I don't want to be involved in implementing it." "I veto this proposal."

into a simple wordlike graphic like this: Sparkline Example


This topic is for discussing how sparklines should be used on TWiki.org, that's why it's in the Codev web. Once we have the requirements for the system it will be implemented as a plugin. (Either by adapting VotePlugin, ChartPlugin and/or creating a plugin of it's own. SparklinesPlugin?)

We need a system that can both record the results of polls and display them. I don't know if those two functions should necessarily be combined. It might make some sense to separate them into separate modular components, although they are probably too tightly coupled.

Possible requirements for such a system may be:

  • Vote interfaces and results for any topic can be displayed from any other topic.
  • Vote interface should show a users previous vote if they have made one.
    • Votes are by individuals so TWikiGuest doesn't get to vote.
  • Can generate different styles of "views" of any vote on any topic. Simple wordlike sparklines for summary topics with many results on them, complete tables on the proposal topics with labels for each gradient.
  • A "view" that shows all votes that have been cast and who cast them.
  • Fast at rendering many vote results on the same topic.
    • This may mean that images are generated at poll time, not view time or some caching mechanism is used.
  • Not holding the vote data in topics might also be desirable, although not essential provided it doesn't impact performance.

In future we may want the following. They may also be useful to other organisations:

  • Secret Ballots - hide who has made votes until a set time has elapsed/minimum # of votes taken
  • reset votes for new round (keep old scores available?)

To implement voting/polling system of this type that will scale well I think we could use the VotePlugin written by MichaelDaum.

I've been playing about with the example on the NATS wiki and I like the way it allows you to recast your vote.

I think with some modifications this plugin can be made to fulfil all the requirements I listed above.

Alternatively it might be possible to adapt ChartPlugin to display raw VotePlugin results as sparklines.

-- Contributors: SamHasler, MartinCleaver, CrawfordCurrie, PeterThoeny, ArthurClemens


Great idea! I can think of other uses too. For example:

  • Each topic could have a sparkline indicating the age and frequency of updates in time, perhaps the topic length (see also this example: http://independenttorrents.com/ and also TiddlyWiki's Sparklines)
  • One that indicates the visit (read) frequency.
  • Users could have a sparkline indicating their recent activity.
  • twiki.org could have one indicating the download frequency of Dakar.

-- ArthurClemens - 29 Nov 2005

Those are all good ideas. I think that reinforces the idea that data source and rendering should be decoupled/orthogonal. Adapting ChartPlugin would probably be the easiest option. Then we could get VotePlugin to output raw numbers and create a SiteStatsPlugin or TopicStatsPlugin for the data sources.

-- SamHasler - 30 Nov 2005

Ageed on separating data from presentation. Instead of ChartPlugin i'd add sparklines features to the GaugePlugin. That Plugin's intention is to be a collection of different gauges. Sparklines can be looked as some extended form of gauges. The tambar1.gif tambar already is a sparkline.

-- PeterThoeny - 01 Dec 2005

I hadn't thought of GaugePlugin. I agree that it's a good fit in terms of what it's used for, but I initially thought of ChartPlugin because it already does graphs, just not at the right size, and it has parameters for accepting the kind of input that sparkline would have, so I thought there would be a good opportunity for code reuse. Having said that I was going to see if anyone else wanted to write the code before I worked up the motivation myself. I'm not fussed which plugin sparklines are implemented in as long as all the requirements are met.

I should raise a counter-argument to separation of data collection from presentation. We must consider how use of these will affect server performance. For polling data and most of the suggestions Arthur made the rate that the underlying data changes will be a lot less than the view frequency. It makes more sense then to generate the sparklines for this data when the data changes, when people vote or pages are saved, not when the sparklines are viewed. Especially because I want to put these on the Release topics (to allow at-a-glance assessment of which are the most wanted features) so there could be many hundreds of sparklines on a single page. I suspect that generating at page view time would kill the server.

I think I'm returning to my original idea that it will have to be based on VotePlugin (possibly with some code reuse from other plugins).

(Refactored Arthurs links to the top, removed the pdf link because the attachment is corrupt.)

-- SamHasler - 03 Dec 2005

Fixed the pdf.

-- ArthurClemens - 03 Dec 2005

Here is a very visual example of WikiSpaces using sparklines to report activity:

-- PeterThoeny - 19 Oct 2006

It is not intuitive to me why this would fit into GaugePlugin better than ChartPlugin. A sparkline in concept is the same as the line graph already supported by ChartPlugin but much smaller and with minimal frames/axis/etc. I also think of a gague as something that displays a single value where as a chart is something that displays many different values. Likewise a sparkline is something that displays many different values but in a small space.

-- RickMach - 20 Oct 2006

ChartPlugin is for charting data that is in TWikiTables - whereas GaugePlugin plots comma-seperated lists of values. To my mind, this makes GaugePlugin more flexible, and more appropriate for use in transient indicators. Then there are the ploticus and gnuplot plugins too - but they use yet another TML syntax, and (i think) grab their data from attachements.

This makes the GaugePlugin the closest fit - though really, a generic result set approach for all the plotting plugins would be even better.

-- SvenDowideit - 17 Sep 2007

Greatest flexibility would be to generate a SVG file (see http://search.cpan.org/~ronan/SVG/) and rasterize the SVG to a PNG using Image::Magick.

-- ArthurClemens - 16 Dec 2007

GeneralisedCHARTdefinition should also be useful for this

-- SvenDowideit - 29 Dec 2007

See also SparkMaker 4.0 - Sparklines for Excel, Word, PowerPoint, and HTML documents that uses a special truetype font to render data as sparkline.

-- ArthurClemens - 12 Jul 2008

That is a cool little feature.

I desire such a little feature smile

-- KennethLavrsen - 12 Jul 2008

JQuery sparkline plugin - The plugin is compatible with most modern browsers and has been tested with Firefox 2+, Safari 3+, Opera 9 and Internet Explorer 6 & 7.

-- ArthurClemens - 15 Oct 2008

I think it would be nice to have sparklines in TWiki. IMHO, most logical to add sparklines to the GaugePlugin. See GaugePluginDev.

-- PeterThoeny - 2010-03-30

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng SparklineExample.png r1 manage 0.1 K 2005-11-27 - 01:21 SamHasler Sparkline Example
GIFgif activesp.gif r1 manage 4.1 K 2006-10-19 - 19:39 PeterThoeny Using sparklines to report activity
PDFpdf sparklinesintext01.pdf r2 r1 manage 6.2 K 2005-12-03 - 13:39 ArthurClemens Sparkline example by Rafe Donahue (see http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&topic_id=1)
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2010-03-30 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.