Adding a "spectrogram" poll type

What about a spectrogram poll type?

[poll type=spectrogram][/poll]

And behind the scenes, having something like the number poll type with a min of -100 and a max of 100?

Here’s a description of a Spectrogram as discussed by Catherine Bracy of Code for America at PDF15 last week:


Sounds interesting. What have you got so far?

1 Like

An idea inspired by Catherine’s talk that hopefully somebody in the Discourse community finds compelling enough to take a stab at :slight_smile:

I know the CfA folks seems to be interested…

To save some time: Catherine talks about spectrograms around 12:40

I think the backend is already in place (number poll with some arbitrary range, eg. 0-100).

The missing pieces:

  • better input UI
    perhaps <input type="range" (..) could be used when rendering poll type=spectrogram? (example1, example2)
    this would make „fuzzy” voting between two options fast and intuitive

  • additional spectrogram visualization of multiple datapoints

1 Like

I like the idea of spectrograms, but (without listening to that talk or reading anything about it) do we really need 200 choices (-100 to 100)? I guess -/+5 (or maybe -/+10) should be enough.

Please don’t. Numeric sliders have such a bad UX most of the time. Imagine you have a large range like -100 to 100. Try selecting 76. Good luck! In that case a numeric input is way better. And when you have only a few options, it’s easier to just select the option by clicking on a button.

1 Like

A slider is a good choice when you know that users think of the value as a relative quantity, not a numeric value. For example, users think about setting their audio volume to low or medium—not about setting the value to 2 or 5. — Microsoft

But that’s exactly what we’re trying to achieve - capture relative quantity, with users being able to place themselves in a spectrum in relation to others. And perhaps, after some discourse/debate, change their position “relative” to other spectrogram respondents.

I agree we can make the range smaller, I still think a “slider-like” UI is still better than buttons (see the screenshot above). The primary reason being is that one feature of the spectrogram is the ability to see how other users are on the spectrum. Can that be done with a button interface?

1 Like

While we’re talking UX, what about a mode using user avatars when placing your response on a spectrogram?

In that way, you can see at a glance not only where the responses are, but also, who’s voting what.

I say avatar mode, because I’d still like a simple UX where you just see the responses.


I’ve been at events with spectrograms and they are super fun and informative, and a quick shortcut to gauging where people are at and how their opinions change as arguments are made during the course of the exercise.

What I’d like to see in polls is the ability to allow a comment each time a vote is cast and each time a vote is changed, and the ability to see the transformation visually as time passes until a deadline is reached and a decision is taken or the exercise is ended.

This is what loomio does quite well, though not (I don’t think) with a nifty spectrogram visual interface. It’s been a while since I’ve looked at the project.

I’ve talked about this before. Ah. Here it is…


Here’s one implementation idea:

  • use slider control to let the user choose where he/she lies in the spectrogram. User has to press vote button to cast.
  • use ImageMagick thru rMagick to render the spectrogram as an SVG. And show this SVG as the visualization of the spectrogram. We use SVG for the latest version of the spectrogram so we can take advantage of mouse-over effects
  • we can even use ImageMagick to animate votes over time (animated GIF)
  • After poll is closed, the final tally is computed, but users can show how votes changed over time using animated GIF

What do you think of this approach?


Two ideas on top on that:

If backend provides a JSON with data points, the graph could be rendered client-side using one of JS graphing libraries:

Draggable slider that represents the arrow of time would be better :blush:


Great! Rendering client-side using JS graphics libraries will be more elegant and is not as kludgy :smile: However, that means Discourse will have to store all the intermediate vote states.

The reason I went for the RMagick suggestion is so that Discourse doesn’t have to store voting states over time, as seems to be the case with the current polls looking at the poll attribute.

It will only have to store the latest vote, and the historical votes can be “stored” by just time-stamped previous ImageMagick renders.

1 Like has done the super-deluxe version of this, to great effect in Taiwan, and elsewhere.

As I understand it, participants agree/disagree/pass on multiple statements (essentially an opinion survey on a topic area, which they can extend with statements of their own, like “Playing football in high school is reasonably safe”),then identifies groups of people who more or less agree on sets of statements.

You can then either attempt to craft statements that everyone agrees on, or drill down on one particular cluster to see what differentiates those participants from other clusters, or from one another.

Write-up of the VTaiwan project where this is working here:

Screen demo of the clustering in action:

(skip forward to about 41:00)

Cool beans.


An update based on some more experience with

I just tried out for a small FB group and discovered a few bugs and misfeatures. The devs were quite responsive, fixing a few on the fly and explaining what was going on. I think some UX tweaks are still needed to make it more intuitive for newbies and reduce friction.

In reading about how it’s been used in Taiwan, it seems that one use pattern is to encourage the various groups that emerge to develop statements that gain significant agreement across groups, and then use those “consensus” statements as the basis for f2f deliberation. So, as always, there’s important stuff that’s not captured by the software per se.

A key tenet of is that “responses don’t scale” in large conversations. Better that you either agree/disagree with my point or post your own. Of course, that’s amusing to write here, of all places, in a community that’s dedicated to scaling responses and is doing pretty well at it. It’d be interesting to find out if there’s a line of demarcation (i.e. if X>A and Y is true, go with a Discourse type process, if not, use Shift between to and Discourse as X and Y change.)

My excitement about is in how it provides a kind of filter for large scale discussions. It seems to me very useful to be able to say that, in some large hubbub of discussion, there are roughly these two/three/five subgroups. This is a little more sophisticated than Reddit-style upvoting, in two ways. First, in distinguishing between a statement that got, say net 5 upvotes via 5 up minus 0 down and one that got 105 up vs 100 down and thus clearly represents a pretty large subgroup. Second, in the grouping.


Here’s another update on I saw them at the Personal Democracy Forum conference this summer, and was quite intrigued by what they’re trying to do.

Nowadays, algorithms/AI/Big Data is being used by Google, FB, et. al., seeing us more as “consumers” rather than “citizens” with their ad-driven biz models, that hack our lizard brains.

What’s refreshing about them is they’re using technology to bring tribes closer together rather than balkanizing the internet into echo chambers.