I’m asking more from curiosity than specific need. In general, I’ve been thrilled with the current build, and I’m looking forward to future updates.
I’m curious as to how the team decides what to work on next, whether big or small. It’s obviously a business, and the goal is to overcome limitations that would prevent people from switching from their existing software. If one user is stridently demanding a very specialized, niche feature that requires a ton of time, that user shouldn’t expect the squeaky wheel will get the grease.
I wonder if there’s been a consideration of a vote-based system. Users vote on features, which at least informs the team of the amount of general interest in a particular thing. I know that other users want things I don’t care about, and vice versa, but probably there are items that many users agree should happen.
The forum is a nice way to voice these requests, but I have a feeling we represent a small subset of Dorico users. It does seem like a diverse group, which is good. I’ve definitely benefited from the wisdom here!
I suppose it could make sense to tie a voting system to registered licenses. But maybe that’s a pain to implement. Or maybe the point is that they want to hear from users who haven’t yet switched. Or maybe the whole thing is a dumb idea…
Interesting idea, but for what it’s worth I am happy to leave these decisions to the Dorico team. (And I should add, I’ve learned a lot from you on this forum!)
Usually, that’s part of the project manager’s role. I don’t envy anyone having to make such prioritizations.
It’s a balancing act between the importance of adding a feature (or bug fix) and the amount of resources (people, time) it requires. Importance may not just be popularity, of course, but whether it’s crucial on the road to some long-term goal. Let’s say you’ve got four months till the next release: do you choose between six new small features or one big one?
I concur that Dorico seem to have it all under control. Every feature request or bug report I’ve seen here has been answered “Yes, we’re working on it” or “Maybe, but not now.”
Daniel has previously stated that user feedback, particularly in the few weeks after an update, is an important factor in deciding what to work on next.
In terms of larger features, the groundwork for some has to be laid in order that others can happen. For example (and I’m guessing here, really) we have divisi functionality but we don’t yet have condensing (the opposite). “Condensing” involves displaying the music from multiple instruments on one stave. My guess is that implementing Percussion Kits, which are also a form of Condensing, and seeing the difficulties there, has made it much easier to implement general Condensing in a future update.
There’s also Steinberg’s roadmap. I don’t know what the plans are to integrate Dorico with other Steinberg software but it is one business and it may be that there are things that Steinberg need from Dorico in order to make it talk to Nuendo and Cubase further down the line.
There’s a sizeable team actually working on Dorico, and, though it’s not a democracy, I’m sure Daniel listens to his team. They’re musicians in their own right and between them they have more experience coding notation software than any other team in the world (most of them used to work on Sibelius).
Also, Steinberg uses beta testers. I don’t know how many, as this isn’t made public, but one would assume that they arguably shape new and updated features more than we do here, as they must see these features before we do.
I have to say that I feel privileged to be part of this user community. I know that at least one small feature has been added specifically at my request (chord symbols above the system, regardless of which instruments are showing) and in the last few days I seem to have been shaping the documentation. With Sibelius I couldn’t imagine getting close to that - I’d have been lucky to persuade one of the big plugin authors to develop a plugin that made it to general release.
Avid tried that with Sibelius, but it didn’t seem to work very well. I guess the biggest problem is getting enough people to actually vote, to make the exercise worth doing.
With the Sibelius system, it looked like the majority of people who voted were people posting a new suggestion, and typically they only voted for recent suggestions that were on the first page - after all, what is the incentive to spend a hour of one’s time going through 100 or more suggestions and deciding which are really worth voting for?
The end result was that most suggestions only got a handful of votes before they disappeared from the “most recent” page of the suggestion list - though a few slowly rose to the top of the pile after accumulating votes over a timescale of years. But who wants to wait years for a good suggestion to be recognized as such?
Even with adequate voting participation this is still a one-sided view, because the users can’t judge how to balance the cost of implementing a suggesting against the benefit. You can’t do that unless the development team are involved in evaluating the suggestions - which seems to be the way it works with Dorico!
Dan, I do not think it is a dumb idea. But: let us make use of the fact that developing software is a highly creative business too. I would not like to narrow down creative peoples work method by implementing a strict voting system. It is wonderful to see, how things turn out ‘by themselves’.
You have to be stopped before you go mad with power, leo. I would summon Lillie to this topic, to have her perform her by-now trademark putdowns, if doing so wasn’t a faux pas!
I suppose only Daniel can answer this question properly, and with the appropriate amount of detail within his right to set the tone of this discussion, but he has talked in the past about the idea of the “bell curve”: what are the most common denominators in the notation of all kinds of musical practices? It was wise to start at the (imaginary) center and try to widen the focus. They’re also in contact with industry leaders and are marvelous in their communication with the user base — even when the user base doesn’t quite deserve it…
Dorico’s development is very fluid. On one hand we have a very good idea of where we want to get to and which feature areas we need to address in order to ensure that the main market segments have their needs addressed. On the other hand we have the advantage of re-evaluating the requirements of a feature area from scratch and creating a true Dorico implementation (how many users, when saying “I can’t believe Dorico doesn’t do slashed notes yet”, would have envisaged the implementation we arrived at?) As a result these features often take longer than expected, which throws some of our planning out of the window. There are occasions when users suggest things which strike us as good ideas and we try to get those in. There are times when opportunities arise at a good time for us to take advantage of.
Within the team (and it’s not a big team) some people have special interests that feed into how we approach the features. As we implement them, there’s continual dialog between the developers, testers and Daniel. We’re in contact with a large number of people across all areas of the industry, whose feedback shapes the features.
One thing that really has no impact on features is how loud you shout or the number of times you ask. Squeaky wheels will remain ungreased.
Of you do request features, one bit of advice: it’s better to describe the problem you have, rather than what you think the solution is.
Don’t mean to sound like a fanboy, but as a user from Professional Composer for PC (anyone else remember that one?) through Finale v1.0 ($1K and unusably buggy) through Sibelius and now Dorico, I am constantly amazed by the vision shown by the Dorico team. The choices they make in what to do and [especially] how to find an elegant, easy way to do it are just remarkable.
And Daniel, 35 years as a military musician has taught me that no team, no matter how strong, excels without strong, effective leadership.
So kudos to all of you, and thank you for giving us this remarkable tool to use.
Anyone remember the lyric tool in Finale 98? Add an unresolved hyphen, and you’d get unending hyphens through the entire piece. You had to hunt for it and delete it. Oh the memories… Ha!!
