Manual annoyances

Having delved into the Dorico manual quite a few times since the first release it has definitely improved a great deal.
Notwithstanding one major issue for me that just doesn’t make sense and I believe needs global revision…
The manual describes processes at great length but the thing that most people need is the keystroke to do it. Instead of vaguely describing how things can be changed it would be great to have a side bar that lists the keystroke/s or menu path.
None of which detracts from the keystroke manual - different animal.

1 Like

Sorry to hear that - I wonder if you’ve been caught out by how information is segmented in the manual? We have tasks that describe the necessary steps to perform individual operations, and then references for more detailed information. This is consistent across all Steinberg manuals.

For Dorico, what I tend to do is in general terms introduce a few key operations in the introduction or reference, and then related links at the bottom take you to the dedicated steps for each operation. If the steps involve a key command, you should find it there. We went to great lengths not so long ago to format all the key commands in the manual so that they’re automatically translated for each language.

E.g. the introduction to Figured bass talks in paragraphs about how you can change the font and hide figured bass. Then in the related links at the bottom, there are links to tasks including hiding/showing figured bass in layouts. I try to make sure the wording in the introduction matches the title of the task to make the link clear.

Lillie, I have no complaints with what is there. It’s what isn’t. An inset box or side panel with the keystroke instead of having to search for the process of achieving what is expansively detailed in the body text. The number of times I have enjoyed reading the text but not finding that vital step is the issue.
Another suggestion from the Score manuals 1 through 4 (if I remember correctly). The Index lists the page numbers and keystrokes.
With the example you have given in the Score manual it would have the keystrokes for the example giving you a full explication of both the process and keycode method. There would be no confusion whatsoever. (I do understand that personalisation can cause some confusion but this could be made clear contextually with Dorico in its default status.

I see, that’s not really Steinberg’s style, and although experienced users will know the contexts in which certain key commands are available or even functional (Write vs Engrave modes, selection-dependent key commands etc), I think it’s important to clarify those in the manual itself.

There is a separate guide focused solely on key commands, which if you haven’t come across before (although it sounds like you have) is possibly more what you’re after?

This is not about style. It is about effective communication of vital information.
I know there is a separate guide but you have a manual that hasn’t properly integrated the two arms which could also be done through some hyperlinking.

I think Dorico is becoming a very fine programme but it is issues like this that will continue to reduce its effectiveness among some users. It’s a commercial imperative as much as a pedagogical one to create the best solution or provide alternative solutions to allow for the greatest productivity return.

On the contrary, I thought the explanations pretty good. The idea of outlaying a task as a procedure and what the expected result should be was the sort of thing I’d expect to see in a program spec.
Admittedly there were omissions - and I didn’t expect something as complex as notation software to detail every avenue to get out of trouble but as a newcomer to such software I find that most times I call up help I get a definitive answer.
It’s a huge manual…but it has to cover a huge amount of procedures.

It may be ‘huge’ but that is no excuse for leaving out vital information on the topic at hand.
Complex software? I started in the 1980s on Score whose manuals were as comprehensive although didn’t spend as much time on the philosophical or editorial because it was the purvue of music publishing experts. In that context everything was (and is) based on understanding hundreds of parameters and key codes. The manuals did what was expected of them being models of clarity and integration.

I don’t understand why there is a need to be defensive about the positive qualities of the Dorico manuals. I am suggesting an improvement. You can take it or leave it. Either approach has it’s implications.

At least in my SCORE 3 manual, the Index is just page numbers not keystrokes. The SCORE 3 manual reads more like Lillie’s First Steps guide rather than a comprehensive manual. If you haven’t checked out that link, you may prefer it to the online documentation. SCORE’s manual walks you through how to do certain things and shows you the keystrokes as below:

I’m not sure how that’s any better than this:

In fact, with the added visuals for each command and step, I find Dorico’s First Steps guide much more clear than SCORE’s. How exactly do you find SCORE’s guide preferable here?

Your example is a good one. Such is just not consistently the case. There are many pages without reference to a single keystroke where such information would be the very solution one would be expecting.
In checking the Score 3 Reference Manual - not the Users Guide.
The layout of information and thus effectiveness is what I (not everyone) would wish for.
The Index most definitely does point you in the right direction to know the parameter, keystroke or operation needed for any aspect of the programme.
The Index of Letter Commands (also at the back of the Reference Guide) is self explanatory.
Again, I don’t see this as a reason to be defensive. It’s simply that what is good can be even better.
(Cross stave beaming and note/stave displacement is an area close to my heart - being a harpist).

I would be very interested (and indeed grateful) if you have links to specific examples in the Dorico 3.5 (the latest) Operation Manual where key commands are missing in the tasks for operations that have a default key command. There are a decent number of tasks that only involve a menu option by default, but tasks for these should ideally have a tip at the end about how to assign a custom key command should you so wish.

If you mean more that where possible actions are mentioned in passing in a topic that’s not primarily about that operation, the key command isn’t included, then I take the point but at the moment that is deliberate: we try to keep information categorized and restricted to their dedicated pages as much as possible. It both keeps boundaries clear and helps up maintain documentation across multiple product versions and for each update. But that said, if you have some specific examples (that I can more easily investigate) where you’d really expect or benefit from the key command being shown, I’d be happy to hear that to take into consideration.

Your figured bass page is germaine.
It would have been helpful to have the line of key strokes underneath the example. And a mention about the figured bass options so that one would end up with the same result.
I certainly wouldn’t expect tangential issues to be explained in any way that detracts from the main point of the page.

Ah, right, I was looking in the Users Guide.

In general I agree with you regarding the Reference Manual. It is very clear, presents all the P values possible, and contains little extraneous or editorial information, allowing users to get the information they need quickly. Dorico’s equivalent of the “Index of Letter Commands” is Preferences/Keycommands/Print Summary. An advantage Dorico has here is that this will contain all of your custom Keycommands too. One of the features I like best about Dorico is the ability for users to modify and create custom keycommands to suit individual workflows. Summarizing all the commands this way allows all the user-configured keycommands to be included too.

Right, so you would like to see essentially instructions for how to recreate the figured bass in the example screenshot included on that page? That’s an interesting thought, I’ll make a note, although I’m not sure that’s how we would approach something like that. Additional tutorials/walkthroughs could be a possibility though.

If you take a look at the reference page specifically for the figured bass popover (which covers the things you can enter into that popover to achieve different results), you’ll hopefully see why we segment this information. Some popovers only have a few possible entries, but others - like figured bass - are somewhat complex. This is why we segment: all the information about “things you can enter into the popover” should be findable on the page about that popover. Each popover has its own page, where there is a screenshot confirming what it looks like, a bullet point list of how to access it, and table(s) of popover entries.

The benefit of Steinberg manuals being segmented in this way (according to information type and content) is that it’s better suited to online usage, which is increasingly how users access the manuals. Relevant keywords for specific pages can be embedded in the metadata, and online searches can get you directly to the part of the manual that’s relevant. It’s a different writing style to other, more paragraph-based manuals, but I can assure you that my colleagues in the manuals team are dedicated and experienced in the world of user documentation and we take our job seriously. There are good reasons for why we do things the way we do them, although of course we’re always listening to feedback and exploring other possibilities.

Clearly there should be automation advantages in a program that isn’t 35 years old (in DOS). Notwithstanding its lack of personalised keystrokes, Score’s ability to create surprisingly user-friendly tailor made macros extended its power dramatically in much the same way but always better than Sibelius’s attempt through Manuscript/plugins.

I understand the idea of segmentation but the figured bass example is but one of many where the user needs that connextion.
It’s what turns theory into practice.
Talking about something without programme integration is an issue of data fragmentation.
A digital medium may appear to be different but fundamentally each screen is a page or part thereof. I’m not easily convinced that because something is newer it is automatically and paradigmatically different.
This is what you do - this is how you do it.
Your professionalism has never been in doubt.

I think one major difference between the SCORE and Dorico documentation involves the target audience. SCORE’s target audience is/was music engravers. Dorico’s includes students, amateur and professional musicians, teachers, musicians used to working with MIDI and DAWs, and yes also music engravers. How each program describes clefs I think is a good comparison between the target audiences.

SCORE — virtually all the information a user would ever need to know about inputting clefs is contained on 2 small pages. (There are 2 parameters on the 3rd page about scaling.)

Dorico — the entire first page contains no actual information about how to input or modify clefs.

I could do without all the additional editorial information about Clefs here, but I think considering Dorico’s target audience there may be many users who benefit from this. Certainly I would prefer a slimmed-down manual without additional information that I don’t need, but a user coming to Dorico from Cubase that isn’t used to notation may need this type of info. The diversity of experience of Dorico’s target audience I think correctly calls for a different approach than the fairly unified user base that SCORE has/had.


Can’t argue with that.

I have frequently had cause to complain about the lack of help given in the Dorico manual. I see now from this discussion that the problem is that there is a Steinberg party line on how manuals should be written. It seems to be prettty inflexible, and explains why Lillie is forced to push back against suggestions for improvement.

The reason why the manual is so counter-intuitive to my way of thinking may be that the Steinberg manual writing specification is designed for the German mind, which is very different from the English or American way of doing things.

Personally, I have just given up on the manual, as I find it too time-wasting, without telling me what I want to know. I mean no disrepect to those who compile it and I am sure they are doing the best job they can within the constraints put upon them by Steinberg.

1 Like