Since there are so many feature requests here, I think it would be benefitial to have a more systematic way of both collecting features and voting for features than forum postings and likes, i.e. an issue tracker or something like UserVoice. It could even be a weighted voting where users who bought a license are given a greater say. This could also motivate more people to buy a license and help creating a sustainable business while still not making it a commercial thing.
Good point, Iâm glad you raised it.
The popularity of feature requests based on replies and likes is the same thing, no? Sort the Feature Requests section by Top.
Also, I canât speak for the devs, but I donât think they should value input of license holders any more than other usersâ requests. Conformity to the appâs principles, value/innovation of the feature request, and popularity should be the driver of development decision-making⌠and Iâm not convinced of the popularity one.
âIf I had asked the people what they wanted, they would have asked for faster horses.â
I agree with you on the licence bit.
Replies and likes are important, and create context, always important, but they are spread over a thread, sometimes very long ones.
Perhaps the way to do it would be to have some sort of summary at the top of the page to show the number of likes. There is a caveat: a like can be for the feature or for the comment someone makes. They would need to be kept separated. Whether thatâs feasbile I donât know.
I kinda agree with you, but I donât think youâll get much more nuanced rankings in a different voting service. If you look at the rankings for Top you get a pretty great picture of what the people want!
To use likes and replies as the metric for popularity of a feature is flawed, because there is no way to gauge the weighting of that preference. e.g. if one user has given 3 feature requests a like each, one of those features may be a âsemi-likeâ another a âloveâ and the final one the user would walk over the Sahara to have that included in the next release. But there is no way of knowing that from a simple like
Therefore, a proper vote gets my vote.
These issues of granularity in crowdsourced data are, as it happens, a core topic of my research. See my latest paper on the subject, âDesigning for granularity in data crowdsourcing.â
Sad to say, but all data crowdsourcing platforms are fraught with design flaws that skew the takeaways you can draw from them. An instantiation of democratic decision-making via voting is one route, but what of brigading? How do you deal with the expertise a user is bringing to their feature requests? What of the feature requests that are poorly worded?
Discourse doesnât save us from these issues. The point is that (a) no platform will really return high quality data and (b) interpreting feature requests is fuzzy anyway. The best quality insights for designers/developers will come from the nuances of discussion. Splitting into even more foraâespecially ones that reduce the complexity of feature request discussionsâwould obliviate that nuance.
Once again, though, this forum is effectively the same thing as whatâs being requested on this thread. Sort the Feature Requests category by Top and you get a view that shows the most popular feature requests. Youâre not going to get a significantly different list on any other platform.
I donât doubt that either the forum or a formal voting system could be used successfully. However, if the forum is used it needs to clear what influences new features and decisions (unless the devs prefer otherwise). Maybe I am not the normal case but I donât like most initial feature requests because they are not thought through well. Only after discussion and sometimes contradicting opinions is it clear what specific implentation may be good. In some cases i would like/vote for a feature only as specifically suggested by someone. There are also a lot of duplicates, which one to like? The other issue is that nothing prevents me from liking every feature - presumably voting forces you to choose and prioritize. A voting system might also allow the devs to curate by time/resource investment - vote for one killer feature or ten meh features . So, speaking for myself, I prefer a vote system
As some have already mentioned, a proper voting system should only allow a certain number of votes that you can dispense. Those who bought a license could have some more votes to dispense, but that is debatable. My idea here was that these users are more probably those who care about the software and use it, and who actively support the developers, so they should have at least a little bit greater say. But developers should not be thought of as being obliged to implement what the license holders or the majority wants. If that would be the only measure, we would end up with another mass market product like OneNote or Evernote instead of an innovative, powerful tool for knowledge workers.
Another important point is that the list of features should be curated - duplicates should be closed or merged together, features that have already been implemented should be closed etc. This is a bit difficult when using forum discussions. Though I must say the discourse forum software used here is awesome - great choice. And I just noticed that merging forum posts is actually possible and already practiced here. So after all, maybe the forum is in fact sufficient. More important is that the forum/list is curated and maintained by somebody.
Hi everyone. Let me quickly chime in on this.
The current idea is to let you freely express yourself and we periodically plow through the forum and annotate what stands out AND makes sense to us.
While it is true that the feature request section is unorganized (with duplicates etc), it is still possible to distinguish the signal from the noise.
We still have a long list of things to do from the initial plan. Weâll add some of the signal to our backlog as we go.
We understand the value of the voting system as (1) it lets us know what features are important and highly requests and (2) it helps us prioritize. But we already get a pretty good idea from looking at the forum from time to time, and (2) isnât really true, because software prioritization is a lot more nuanced than that.
We have recently added a placeholder text to the feature request topic creation. We suggest users to search and contribute to already open requests.
When you merge 2 similar feature requests, do you also transfer the number of likes at the top to the other request?
All data from a post is mergedâwe move the posts themselves.
Or do you mean we take the 2 votes on a repeat requestâs thread OP and add them to the 24 on a previous thread? In that case, noâbut I wouldnât be surprised if Top sorting takes likes across the entire thread into account. Nonetheless, again, we donât need not use a raw likes count to know whatâs popular or what valuable feedback looks like. See @WhiteNoiseâs commentary about regular review.
Can you implement some kind of voting pool to each question related to new features?
So you can get impression about what kind of feature is / will be popular among the core fan people of obsidian app.
We already had some discussion about this (see thread link below). I think the answer was that the forum is sufficient and the feature request template added info about this.
I was wondering from an academic perspective, should feature requests actually be a discussion of what the person would like to do and what hoops they have to jump through instead?
This is a sort of a problem I see where students will ask a question about say code, âis there a function that does xyz?â but when I ask what theyâre trying to actually do it turns out they donât need a function that at all, they need something completely different.
Similarly as users of software we might be asking for features which should be solutions to a specific problem. Instead we should be saying what weâre trying to accomplish?
I can see that being useful. Are you suggesting a change to the template text that now shows up with new threads?
Oh haha I was just dumping thoughts (probably should be putting this in obsidian âŚ) sort of along the ideas of âfeature requests are solutions to potentially the wrong problemsâ but yeah something like
- what are you trying to do (and why) 2. what are you doing now and why is it annoying 3. what would you propose instead
For example: I want a recent/recently created functionality similar to starred
-
Locate/see recently created notes in one place because theyâre ones that Iâm actively working on. It can be difficult to find if Iâve stored them in different folders.
-
manually searching for them. itâs annoying because I have to store what theyâre called in my memory and if the note isnât fully formed, I may not have called it something useful. I donât want to create a note of recent notes either for similar annoyance reasons of having to curate this. the recents opened in the opener is not enough generally.
-
A recently created/opened functionality.
This is frequently an issue when someone asks for a feature they liked in another program. The request is always for the feature as implemented in that program rather than an explanation of the need they want addressed.
Any official response from developers?
Otherwise discussion is pretty useless.
they read it, they usually donât respond directly