However, I wonder if these are the top priorities of the user community. I completely understand that Obsidian must be a complex project, and the developers must be swamped, but it would be reassuring to have some sense that the development priorities are guided — at least partially — by user needs.
Has any formal survey been conducted to assess and prioritize those needs and to see to what degree user requests overlap? Or, is the roadmap driven more by other business considerations or internal priorities than by current user requests?
For many of us, Obsidian has become an irreplaceable tool, and we want to see it survive and flourish. Any insights into the development roadmap would go a long way toward validating our commitment to using Obsidian for the long hall.
Yes, development decisions are driven by user interest. WYSIWYG was prioritized, for instance, because of a long ago poll on the Discord and, well, it is the most popular request of all time:
Filter and sort the forum feature requests for popularity by selecting a category and then choosing your time frame and sorting options. Here’s all Feature requests sorted by popularity:
Of course, popularity isn’t the only factor. Ease of implementation is a major consideration. For example, multiple windows is currently very difficult because of Electron’s fundamental engineering.
Then there are other factors: the devs’ designerly perspective; sometimes features are developed with other features also in development that work together; FR velocity (e.g., a lot of attention on a FR in rapid time); whether there are good alternatives or workarounds for the need; and so on. (I’m not speaking for the devs, here, by the way. This is just what I’ve observed in software development.)
But yes, the Feature requests category is a major driver of development direction. That’s why we ask users to please follow instructions carefully when submitting a new idea.
As for swamped… well, there are currently 2,600 Feature requests. (779 #feature-request-archive isn’t so bad, though.)
Great question and equally great response! But for the nontechnical users in the forum, can you give us a little explanation on the complexity of implementing WYSIWYG in Obsidian? Is it primarily Electron and/or making it work across all the platforms (all at once)? Specifically to the OPs post, of the two FR’s listed, I’m more interested (FWIW) in Export/Printing than WYSIWYG (maybe because I don’t know W’s impact on me). Thanks for listening!
It’s worth remembering that the community of Obsidian users extends over time, future as well as past. WYSIWYG is a major feature for many current users, and probably an even higher proportion of future users (assuming successful implementation). It’s key to most interactions with the program, not simply a missing feature.
WYSIWYG like Typora was a promise to the community when Obsidian was launched, so not just a feature request. I think it’s the last of these to be implemented.
I can’t really comment, but it is a big project. The devs are building the WYSIWYG experience on top of CodeMirror 6, while the original app was built on CodeMirror 5.
I would argue the initial premise is false. Roadmaps and development should not be primarily driven by user requests. This is a common misconception on how great products are developed and particularly meaningful change in a product lifecycle occurs.
User feedback is one input, it’s a signal on where to explore, but user driven development doesn’t generally yield the best results. Instead, gathering many signals across a variety of inputs creates a foundation for exploration of opportunities.
Users are fickle. And you often only get direct feedback from louder voices. I prefer a user informed over user driven approach. Obsidian is blessed by an active community providing lots of feedback, but I wouldn’t want progress prioritized by that feedback.
Speaking of WYSIWYG, are there more screenshots posted in a thread? I am curious to see it. There is a post with block excerpts, but I would like to see more. Thanks!
