I’m puzzled by this. Unless someone tells you how to create a poll in discourse, you would simply never know through the UI. Why is there no poll button in the editor?
I’m not suggesting a full poll-wizard, just a simple button that inserts the most basic structure for you.
Related: Why is there no ‘formatting help’ button for users who don’t breath commonmark?
Same complaints. Really want a formatting help and poll button. 
There is a blog post on how to do it
http://blog.discourse.org/2015/08/improved-polls-in-discourse/
We have discussed the need for a “gear” icon in composer that lets you do advanced stuff like polls. But the composer is not an area we have had a lot of time to work in.
You guys spend days (presumably) on creating an advanced poll feature (and writing a great blog post) but don’t have the time to add a button to actually expose this to your users.
I understand how this stuff happens but this severely limits the effect of the work put into this.
Feel free to contribute a community PR 
Reality is, most posts (as in 99.9% of them) are plain text with zero or little formatting, and polls are a rather uncommon thing. Would you really want a topic with a dozen polls in reply?
I don’t buy it. We don’t want to expose advanced formatting options on purpose seems like an awfully coder-centric user strategy. Surely, we want all our users to have the same powers to express themselves.
How would you see it though? If you can mockup something that I can easily do, I’d be more that happy to slot that in for that release
I wouldn’t say it is that; it’s more like
The types of users who need advanced formatting will be able to figure it out
Not opposed in any way to a gear glyph on composer for advanced stuff, just needs to be scheduled and UI built for it. We tend to favor features that benefit the most users, and I’m not sure Yet Another Glyph in the Composer is necessarily a huge benefit right this second.
I actually want to reduce the number of glyphs shown in the composer, and/or make it hidden by default and click to expand, ala GMail and others.
Maybe, the most people can’t find the small gear icon to get it done 
People are lazy. They go the way with the lowest resistance. And this is to 99,9% plain text.
The issue is, that most people have to deal with more and more communication channels like meetup and doodle lists, to deal with polls. In my experience / use case universe, the people are looking for guidance to attend on certain events. And therefore, they need polls or are switching back to old school emails. Sadly.
@pakl you should take a look at the composer help plugin if you want a formatting help button.
How about a hamburger menu? 
So wait, you argue that they’re unhappy with Discourse because they can’t figure out how to add polls, so they switch to a format that has no support for said feature either? That makes no sense?
Regarding Meetup or Doodle, those are entirely different use-cases than a poll would be generally used for. I don’t see a poll ever replacing Doodle just for the ability to understand large numbers of responses. It sounds like you just want to use a poll to replace a much more complicated, but complete tool honestly.
A reference page added to the editor might be useful, but I don’t see the need for another button either.
I just say, the most frequent use case is creating polls in purpose of creating guest lists or delegating tasks (in our workflow). Thats why Doodle and MeetUp are more popular. People also could do this by creating polls with discourse, but they don’t.
I’d like to push them forward to do this with discourse, so everything could be in place and there will be no need for third-party platform, additional explanations, …
All I’d like to say is:
Creating polls has to be intuitive like the overall user experience with discourse.
Yes, it does and I’m not sarcastic. There is a reason why features are exposed in a user interface when building software. The major UI revolution in Office was not to hide features from the UI, but to better expose them.
There seems to be this weird collective agreement among discourse peeps that markdown and hidden syntax features are the pot of gold. Well, I disagree. This is coder-friendly, not user-friendly.
TBH I don’t mind a wall of buttons taking up real estate, The image I posted previous is nothing compared to the triple row advanced editor we had at vBulletin or some of the IDEs I’ve used.
But there is a bit of a learning curve and all users may not have the patience and perseverance that I have to learn what they all do.
IMHO it is better to not overwhelm those that want a simple editor menu with a mess of buttons they likely will rarely, if ever, use.
On the other hand, I would have no problem with one additional “advanced” button that displayed more.
A “help” button that showed what format to use might be enough. True, it would require more typing and be more prone to typo errors, but if someone took the time to review their post and edit any mistakes that shouldn’t be a problem. (problem being, it seems many don’t review their posts).
So that leaves the question of screen real estate.
I guess it would be more doable on desktop, but less so on mobile.
I have learned that one can never please everyone. Some will want more, some will want less. At some point a decision has to be made.
Do you think it would meet majority approval if there was an advanced option for desktop only?
Except that polls don’t expose who voted what, just the total number of votes and percentages for each option. That’s where purpose-built tools such as Doodle and MeetUp come in. Polls aren’t a calendaring tool, they’re a quick finger-in-the-air to sample opinion.
Or we can simply update our welcome message? Polls are one of the few shortcodes which users will ever need to pick up (unless you also use spoilers) and their basic syntax is a markdown list. It takes seconds to add a quick primer to the welcome message, which already stores all of the other reference material for new users.
From what I can see above, the responses have said the opposite, if you want to submit a design or PR to implement this in a way which makes sense it will be considered. If you can’t devise an approach for this either, then you can at least acknowledge the challenge the team faces. “Fix it, I don’t like it” helps nobody.
That could work as long as the poll plugin is installed and activated.
But it could cause confusion if it wasn’t and someone tried making a poll.
I wonder if there are any statistics that would prove it would be a good idea to move it from plugin to Core?
Polls were an official feature since 1.3, right?
