# How should we implement polls?
**URL:** https://meta.discourse.org/t/how-should-we-implement-polls/11911
**Category:** Feature
**Created:** [January 13, 2014, 2:48am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911 "2014-01-13T02:48:03Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [January 13, 2014, 2:48am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/1 "2014-01-13T02:48:03Z")
Continuing the discussion from [So, you want to help out with Discourse](https://meta.discourse.org/t/so-you-want-to-help-out-with-discourse/3823/56):
> [@Contributing to Discourse development](https://meta.discourse.org/t/contributing-to-discourse-development/3823/56):
>
> Yes, that sound quite interesting. Are there any specific/unusual functionality it should have beyond the generic web poll option?
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:
- 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: samsaffron.com blog plugin for Discourse · GitHub](https://github.com/samsaffron/blog)
Questions / ideas?
I would like to keep the first go at this rather simple with minimal features.
---
### Author:  [@Hunter](https://meta.discourse.org/u/Hunter)
#### Post date: [January 13, 2014, 3:09am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/2 "2014-01-13T03:09:01Z")
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
[/quote]
I’m looking through the existing code right now, but will probably have to wait till tomorrow to get started on actual implementation.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [January 13, 2014, 3:15am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/3 "2014-01-13T03:15:15Z")
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [January 13, 2014, 3:17am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/4 "2014-01-13T03:17:58Z")
> [@riking](#):
>
> 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
That would be a significantly more complicated thing to build as a plugin
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [January 13, 2014, 3:26am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/5 "2014-01-13T03:26:54Z")
Like this, except better designed and not thrown together in 10 minutes:
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [January 13, 2014, 5:28am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/6 "2014-01-13T05:28:22Z")
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.
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [January 13, 2014, 5:32am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/7 "2014-01-13T05:32:26Z")
Okay, I guess that’s fine. Going to need some help somewhere for it, though.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [January 13, 2014, 5:35am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/8 "2014-01-13T05:35:50Z")
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.
---
### Author:  [@wander](https://meta.discourse.org/u/wander)
#### Post date: [January 13, 2014, 8:39am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/9 "2014-01-13T08:39:10Z")
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 [Ghost.org](https://ghost.org/features/)
[ ](https://i.imgur.com/removed.png)
and this is the apex of the old tradition, a fluxbb mod
---
### Author:  [@cpa](https://meta.discourse.org/u/cpa)
#### Post date: [January 13, 2014, 1:08pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/10 "2014-01-13T13:08:31Z")
I think we should stray away of pie charts, as they are known to confuse readers. See second paragraph of [Pie chart - Wikipedia](https://en.wikipedia.org/wiki/Pie_chart) and its references.
A more legible chart would be a stack bar chart, like this.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [January 17, 2014, 11:47pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/11 "2014-01-17T23:47:22Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [January 17, 2014, 11:56pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/12 "2014-01-17T23:56:01Z")
Something like this perhaps? All basic HTML, which is nice.
[http://www.codinghorror.com/blog/2008/04/help-name-our-website.html](http://www.codinghorror.com/blog/2008/04/help-name-our-website.html)
---
### Author:  [@nXqd](https://meta.discourse.org/u/nXqd)
#### Post date: [January 18, 2014, 5:55am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/13 "2014-01-18T05:55:10Z")
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 .
---
### Author:  [@techAPJ](https://meta.discourse.org/u/techAPJ)
#### Post date: [January 18, 2014, 10:04am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/14 "2014-01-18T10:04:58Z")
I am thinking of something like facebook:
I really like facebook’s clean approach to Polls, _can’t say about rest though_. 😉
---
### Author:  [@haiku](https://meta.discourse.org/u/haiku)
#### Post date: [January 18, 2014, 12:30pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/15 "2014-01-18T12:30:58Z")
> [@sam](#):
>
> I think polls should simple be an extension of markdown that only applies on the first post in a topic.
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.
---
### Author:  [@cpa](https://meta.discourse.org/u/cpa)
#### Post date: [January 18, 2014, 1:35pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/16 "2014-01-18T13:35:45Z")
> [@mcwumbly](#):
>
> 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.
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 🙂
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [January 18, 2014, 2:05pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/17 "2014-01-18T14:05:09Z")
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?
---
### Author:  [@cpa](https://meta.discourse.org/u/cpa)
#### Post date: [January 18, 2014, 4:25pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/18 "2014-01-18T16:25:38Z")
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.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [January 18, 2014, 4:34pm UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/19 "2014-01-18T16:34:05Z")
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
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [January 24, 2014, 11:12am UTC](https://meta.discourse.org/t/how-should-we-implement-polls/11911/20 "2014-01-24T11:12:55Z")
> [@sam](#):
>
> Initial implementation should only allow one vote per option.
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.
[Next page](https://meta.discourse.org/t/how-should-we-implement-polls/11911.md?page=2)