How should we implement polls?

Continuing the discussion from So, you want to help out with Discourse:

Almost all forum software out there supports “polls”. They can be quite fun and allow you to easily gauge what people like / dislike.

@Hunter was asking for some sort of spec of how I would see this work, so here I go.

  • Polls should be designed as a standalone plugin. This important cause it ensures our extensibility story is solid and allows us, further down the line, to upgrade poll functionality outside of core releases.

  • I think polls should simple be an extension of markdown that only applies on the first post in a topic. Eg:

      - This is the first option
      - This is the second option
      - This is the third option
  • Initial implementation should only allow one vote per option.

  • Initial implementation should not allow for anonymous voting.

  • Choices must be locked in after 5 minutes

  • On initial render it should not display the results, you must either vote or click on “show results” to see them.

  • Initial implementation does not need to worry about randomising options on first view

  • Data for the polls should be stored in Topic or Post meta_data (an hstore column) or in PluginStore, a custom migration in a plugin is a major work to undertake which we can skip for now.

  • Controller to receive voting should be registered by the plugin using a rails engine, example is my blog GitHub - SamSaffron/blog: blog plugin for Discourse

Questions / ideas?

I would like to keep the first go at this rather simple with minimal features.


Thanks, I was thinking something along those lines, but would have missed a few details e.x. [quote=“sam, post:1, topic:11911”]
Choices must be locked in after 5 minutes
I’m looking through the existing code right now, but will probably have to wait till tomorrow to get started on actual implementation.

1 Like

I was thinking extra UI in the editor, with the traditional “enter each option in its own textbox” and some options (choose one/choose many), and the actual poll being inserted right underneath the topic map.

1 Like

That would be a significantly more complicated thing to build as a plugin

1 Like

Like this, except better designed and not thrown together in 10 minutes:

1 Like

I agree with @sam, this is not a good idea. Use markup instead, otherwise it is going to be hellaciously complicated, and you will also end up with terrible UI to boot.


Okay, I guess that’s fine. Going to need some help somewhere for it, though.

I also suggest starting the topic title with Poll: triggers this markup behavior. The first list you find in the first post, that is the poll choices, provided the title starts with “Poll:” (case insensitive).

Throw an error if you start the topic with poll: but do not have a list in it anywhere.

1 Like

On a UI note, it would be great to see poll results displayed as a responsive pie chart rather than the traditional drudgery of static horizontal bars.

This is a perfect example, taken from

and this is the apex of the old tradition, a fluxbb mod

1 Like

I think we should stray away of pie charts, as they are known to confuse readers. See second paragraph of Pie chart - Wikipedia and its references.

A more legible chart would be a stack bar chart, like this.


I think the stack bar chart suffers from exactly the main criticism you cite for pie charts. Its hard to tell the relative size of two pieces.

A simple bar chart as proposed does not suffer from this, and seems like the most sensible first option to provide.

Additional views of the data as options would all be nice of course, then you can choose a pie chart, a stackbar chart, or the next thing someone comes up with if you like it better.

Something like this perhaps? All basic HTML, which is nice.


I like this one since it’s simple to implement and it’s also very elegant. Any customization can be done later too. One vote for this .

I am thinking of something like facebook:

I really like facebook’s clean approach to Polls, can’t say about rest though. :wink:


I always thought it would be pretty neat to more than one poll per topic. Use case would be for long running threads, like one about politics. The first post would then link to the post with each poll.

If there’s are criticsm it has to be a different one. When comparing stacks in the stacked bar graph, you’re really comparing lengths and not areas (since the width is constant), and you have a linear relationship between the results and the areas.

In the case of the pie, you’re actually comparing areas (or more precisely angles). You still have a linear relationship between angles and results, but humain brain suck at comparing angles.

Basically we can compare lengths but not much more :slight_smile:


OK, well to be more specific, both suffer from the fact that its hard to compare the relative sizes of two non-adjacent parts.

Assume we’re better at comparing lengths though (you’re probably right about that).

Imagine you have a pile of pencils, or even two pencils… the wooden kind you sharpen that get shorter after use.

You want to compare their lengths.

Would you line them up end to end with each tip touching the next one’s eraser to do so? Or would you line them up side by side?


I don’t see how several bars solve the problem of comparing non-adjacent parts. You’ll always get non-adjacent bars, afaict.

As for the pencil example, it doesn’t really map to our problem.
I believe that we need to both be able to compare any answer with any other answer AND any answer with the sum of all the answers (that is comparing 23% and 45% AND comparing 17% to 100%).

In the case of unstacked bars (not sure if there’s a name for this), one cannot compare a single answer with 100% so you end up in situations where for example you have 8 answers w/ 10% votes, 1 with 0% and 1 with 20%. All of a sudden, the 20% bar seems huge compared to the others and you may think that you’ve find a clear consensus, when you haven’t.

Good points, I see where you’re coming from.

But the facebook example @techAPJ posted above , with each bar shown within a 100% bar solves that.

In any case, as far as the first, out-of-the-box visualization goes, I don’t see any reason to do anything more complicated or contentious than a traditional bar chart, along the lines of what @codinghorror and @techAPJ pasted above.

After that, folks can add more of the fancier options fueled by debates like these


I agree with this as the initial implementation, but would like to see being able to choose multiple options later (a feature that likely doesn’t get a lot of usage; but there are times it is needed).

I also liked the cleanliness of the markup you provided, I could easily see that being a good solution to how to create one.