But you can already do this. Post in a “feature voting” category, then people like the first post to indicate support, and sort the category by likes via query string. See the “bug” and “feature” home page links that @sam set up here as examples.
@codinghorror is a ‘feature voting’ category a setting or is that just a concept you apply yourself?
I agree with @sam’s initial assessment that this feature requires at least three things:
Without this, this is of limited use.
@pakl, that link does order the bugs by the number of likes. I just added the word “Voted” in front to make that more obvious. (Anyone got suggestions for a better word?)
I’m surprised that this isn’t much of a priority and that you guys seem to be happy with your ‘order by likes’ custom headers. I doubt that this system is very transparent to the average user.
We will get to some of this but for now our biggest priority is billing and onboarding customers which is key to our survival as a company.
We will get to some extensibility stuff for the next release.
makes sense. good to hear and good luck!
A lightweight solution for that would be:
- Only allow a total of 10 likes in open threads for the
- When a thread is closed (because accepted or dismissed), that Like no longer counts towards your limit.
[quote=“sam, post:5, topic:19812”]
Custom view for specific category topic listing
Custom view for topic[/quote]
Really looking forward to this kind of thing being possible.
Doing it as a plugin will usually be the way to go of course, but in a pinch one could always make a separate app as well. One could point a category to an URL like
features.discourse.org which would take users to a stand-alone app built on the Discourse API.
People have done a lot of really cool things with the GitHub API. Among them are completely new interfaces for GitHub Issues, e.g. with a greater focus on project management.
It’d require considerably more work than a plugin, but on the plus side developers can work with the toolbox of their choice, and there are no restrictions whatsoever on layout.
Bumping this topic - we are evaluating using Discourse, and would like to allow each user to have a limited number of votes in a given time period, e.g. 5 votes per day.
Given the price of alternative solutions out there, I’m surprised that there isn’t more interest in this. Surely having a well integrated uservoice/getsatisfaction-like service would be a major selling point for discourse?
Indeed, I’m quite surprised myself that no one has made a bet on this type of (premium) plugin for Discourse yet. Literally hundreds if not thousands of Discourse forums are product-centric, and most of these would benefit from a more formalised platform for feature requests.
I suppose one major detractor for prospective developers is that how to implement it is not abundantly clear. There are different roads you could go down:
Likes could be selectively stylised as “Votes” for a given category.
Problem: “Post likes” and “Feature likes” don’t always overlap well. If a company makes a popular Android app, the first person to type up a 70-character long “Make an iOS port” feature request could quickly garner 1000 Likes. In this case the number of likes does not accurately reflect the quality of the post nor the user’s community participation, which bothers me.
Would allow a more tailored solution, e.g. something that closely mimics UserVoice’s more flexible rating system.
Problem: Yet another points system is added, which can get confusing. There’s also the matter of whether Likes should remain, alongside the custom points system, as a way to acknowledge high quality posts.
Piggyback the same system, but treat them as separate entities, so that votes on features don’t count towards Trust Levels and such. So while the average post can have “Likes”, a special category could allow “Votes" instead. Maybe that’s what @strager had in mind in the first place but I thought it important to point out these subtle but important differences.
Problem: There’s still the issue of “how do I acknowledge a post of high quality?”, but…
In conclusion, I favour the last option, the “Likes archetype”. It is conceptually close to what Discourse users are already familiar with, it shouldn’t be as complicated to do as a completely custom rating system and when it comes to post quality I’ve realised that, as far as boosting your community rep goes, it’s actually kind of cool if the way to play the “feature game” is to make valuable additions to other people’s feature requests, as replies would receive Likes instead of Votes.
Also, it would still allow for some important customisations:
- Votes should be revokable at any point in time
- The plugin would be activated per-category, just like Solved.
- Individual topics could still be unflagged as a feature request, to remove the votes counter and use it purely as a discussion (alternative workaround is to have a sub-category for feature discussions).
- A user should only be allowed to have 10 active Votes (see below).
- The plugin would add “planned” and “done” buttons for moderators to click on, which would do a combination of actions like “close topic + apply ‘done’ tag + return active votes (while retaining vote count)”.
- The Votes button should be viewable and clickable by unregistered users (want to vote without registration? just attach your email to your vote and we’ll keep a staged account for you, no fuss)
I’ll keep this separate from the rest of the list since this one might not be as straight forward to implement, but I’d love it if users could also have 3 “Super Votes” as a way to differentiate between popular wishlist items and MUST-HAVEs. Both types of votes would count towards the same grand total of “Votes” (so technically the Super Vote is just an ordinary Vote with a special flag attached) but say;
If one feature has 50 Votes and 3 Super Votes, while another feature has 10 votes and 6 Super Votes, that’s interesting data.
Furthermore, only fully registered users (perhaps even limited to a TL, but this could be tweakable per community) get Super Votes, so it could work as an added incentive to participate as a real member of the community.
Currently we’re using “top” discussions by feature category as in meta, but it’s not easy to understand if users like the discussion or the feature itself. With a separate vote system it should be more clear and valuable.
I love your idea and think it’s a Discourse must-have
Here’s a proper mockup of how I imagine this plugin working:
- Votes are displayed above the topic creator’s post, distinguishing the title as a separate thing that you can vote on. You’re voting on the proposal, not the person.
- Below, the forum works as normal. OP’s post can be Liked, just like everyone else’s.
- Votes would be anonymous to everyone except admins (could be toggle-able though).
- If you click on the Vote button as an unregistered user you could still vote by adding your e-mail, and a staged account would be created for you:
As a result of such a plugin, the average like count on the first post in a feature request would almost certainly take a hit, but I don’t see that as a bad thing.
Clear and minimal, I like it.
We should permit to activate it just for a few categories and implemented features should be disappear from the category list.
That’s a super feature good incentive
Great mockup. Thanks for the effort.
I want to echo your surprise. I’d gladly buy this as a premium plugin.
Surely this would be a setting?
Also, what if I find that a feature/request/option that I had sort of ignored is more important than anticipated? Am I stuck, or can I remove one of my votes from another topic to make room to vote for my new priority?
Number of active votes should be a setting, yeah.
No. I covered this in my earlier musing:
I should probably get a fresh start with a new spec-topic.
I’d also be interested in this as a premium plugin.
Decided to start a new topic for this as a complete spec. Hope you don’t mind the hijack @pakl!