I am writing new test score, using Dorico 4 SE for the first time. By default the piece is in the key of C, and there is an annoying red rectangle above the first measure that says “C Major”. I am at a loss to understand the benefit of this. This rectangle overlays any chord name or any other symbol that I choose to put above the first measure (such as a rehearsal mark). If I change the key to something else, the red rectangle disappears. I had high hopes of making it disappear permanently, but when I change the key back to C the rectangle is there again. Is there any way to get rid of this thing? I’m aware that it appears only in “Write” mode and doesn’t appear on the printed score, but I want it to disappear in every mode including “write” mode. Thanks.
Try View > Signposts and turn off Key Signatures. You’ll find many other signposts (or can turn them all off). (See Signposts)
Because Dorico knows the difference between C Major and Atonal, etc. Neither show anything but users need to know if no Key Sig is set or it’s set to Atonal or C Major or A Minor.
Craig_F: I am writing a jazz lead sheet. There is a chord name atop the first measure. There may also be a rehearsal mark, a tempo designation, or other materials up there. When entering notes the time division of the measure also appears there. The “signpost” pretty much obscures everything else that I might want to see. Then there is the strangeness of the fact that Dorico doesn’t seem to feel the need to display the signpost when any other key signature (example, D major or B minor as you prefer) is used. If there is an option to use “signposts” then it should there should be some obvious way to turn it off that does not require someone having background knowledge of all the menus and terminology of the app (how about a useful context menu when I right-click on it?).
Other keys are indicated by the presence of sharps or flats in the staff. C major, A minor, and “no key signature” have none of those. (You’ll similarly see signposts for other keys on transposing instruments.)
You can hold the ` key (usually next to Z) to preview the page without any ‘screen-only’ objects. There are also methods to click on things hiding behind signposts.
You won’t get the best out of Dorico just by looking at the screen and hoping to discover everything. Having some background knowledge about the terminology, philosophy, and process is essential. Luckily, there is excellent documentation.
I don’t know of a Dorico UI general discussion forum so I guess this is as good a place as any. I began writing software in 1969 and I became a professional in 1977, so I got my start in the pre-graphics era; if I wanted the machine to do anything at all I needed to know its command line syntax, and to execute a command I needed to study its options heavily. To typeset a document I had to understand much of the typesetting language so that I could embed commands in my text that would tell the typesetter what to do with it. So I am no stranger to environments where people had to study user interfaces (if you want to call them that) significantly in order to use them at all.
That said, we now live in a different world. Graphic UIs have made all sorts of things possible. A few of my general rules for a UI are:
- There is a huge library of expected keyboard/mouse behaviors. Apps should be consistent with these as much as possible and implement as many of them as possible.
- Users should be able to delete objects as easily and intuitively as adding them.
- Whenever it is possible to do some visual movement or insertion of something (e.g. moving a note within a measure) drag-and-drop should be the preferred technique.
- Alternatively, apps should allow users to add things by clicking on 1) what to add and 2) where to add it. (e.g. adding notes).
- All possible manipulations of a visible object (within reason) should be doable via a context menus that can be made to appear by right-clicking the object, regardless of what other avenues (e.g. menus, shortcuts) might be available.
- Objects that perform operations (e.g. buttons) should have hover messages identifying their functions; it is ridiculous to expect people to interpret icons.
- Items that perform certain types of functions (e.g. the upper right palette/keyboard buttons) should be very visually distinct from items that perform other functions.
- Expecting users to explicitly understand a lot of context rules (i.e. what “mode” we are in) is bad. Minimize context sensitivity as much as possible, and when context is needed, make it clear to the user what the current context is and how to easily change it.
The list goes on. App developers can ignore these at their own peril. There seems to be this hubris within the Dorico community that Dorico can’t do point-and-click editing and that this is a good thing - it makes for an exclusive club, I guess. Good luck with that. Apps succeed or fail due to their installed bases; Dorico will either cruise to success or plunge to failure based upon how many people are willing to invest time in learning it. It doesn’t require a marketing degree to understand that more people casually using Dorico means more available scores and more of a community to which new users will want to belong.
No manufacturer can afford to hire the staff to build the document base required to dominate the field; you must induce volunteers in your user base to do that - ARMIES of volunteers. If lots of casual users can create simple scores in Dorico then there will be a large volume of ready-made scores for other users to simply select or modify (rather than starting from scratch). For most consumer apps (in my opinion) this snowball effect is the central thing that determines whether they live or die. If I were in Dorico’s management or on its developer team, my highest priority at this point would be to make Dorico’s UI as casually usable as possible.
Interesting observations. Clearly your background gives your thoughts a gravitas that is to be respected. I would just quibble with one point - the last one (although some aspects of it show up in your other bullets). The idea of which Mode to work in is deliberate (obviously), and while it can be maddening in some ways, it is great fail-safe. In other programs I have used - and used for many years - I (and others) have had the experience of adjusting one aspect of a score only to have that change alter the content. Write Mode is content; Engrave Mode is appearance. In some ways it creates more work, but once one is at the point of laying out the music, it’s impossible to change (for that, read mess up) the musical content. While it is nice to be able to do everything from one place/view, it opens up the possibility of drastically altering the music, and in ways that are unintended. It took me some time to come to grips with how Dorico works, but now no amount of score layout inadvertently changes the substance. For me, that is a positive game-changer.
I would imagine everyone is in agreement with you on this. I can’t find the thread right now, but I remember the developers saying that the lack of popovers on the icons on the right panel in Dorico 4 was due to a Qt issue. Hopefully this will get resolved with a future update.
I kinda get what you are saying. But I get the impression that Dorico is aimed at the professional engraving community (for now, unlike, e.g., Musescore), similar to the Adobe products. Every time I go back to Photoshop, InDesign or Illustrator I have to relearn how to do things. Great power can beget complexity.
I disagree. Neither Sibelius nor Dorico will fail and disappear due to having a relatively small user base, because music copying is a niche market. Your marketing approach sounds like that of MuseScore – so there is already such a product.
Regarding UI modes, I believe this team has a ton of experience with Sibelius trying to stay modeless as much as possible, because it was based on that design from the start. When they designed Dorico from the ground up, that model was found to be deficient. Having used both programs quite a lot, I agree with the choice.
The reason for the signpost (the original topic) is simply that Dorico shows signposts for objects that are otherwise invisible. I hide/show signposts often enough that I have assigned a keyboard shortcut to it.
I have been using computers since 1967. In those days they were exclusively mainframes and the user had to program in Fortran and know the ASCII codes for punching cards. Since c. 1985, I have had Kaypro, NeXT, RISC PC, and have programmed extensively in Pascal, Postscript, Objective-C, HTML etc. My experience with Dorico, having been learning it since it was first launched, are still that it has the steepest learning curve of any program I have used. (It may well be, of course, that if I had to learn Sibelius from scratch today, I should say the same about it.) I do not know whether it is the documentation, or the complexity of the cases that cause work arounds that make learning Dorico so difficult for many people, as evidenced by the basic questions that continue to crop up in theis forum. As far as documentation is concerned, I have taken to making my own notes of how to do things and where information about them is to be found.
There is no doubt that the chosen philosophy of the program, which seems eminently sensible to me, causes different implementation problems than would be encountered by another philosophy. The biggest problem for a user such as me is that certain behaviour is set immutably in stone (at least at present) and the flexibility needed to respond to the house styles I am working with is consequently withheld.
As somebody who is “challenged by deciphering icons” (I have mastered very few similies 
), I absolutely agree with this statement. It seems to me that some tool-tips and other features of the Write Mode and maybe elsewhere in the program, have disappeared during an upgrade, and I hope that they will be restored soon.
David
Yes, this has been documented repeatedly. They broke, and they’re coming back.
Interesting. My experience was almost the opposite. I found Dorico very straightforward and consistent – though admittedly, I followed the initial videos and blogs that explained the concepts and methodology quite closely, and I’ve watched as the program has grown.
I learnt Finale without any recourse to documentation or internet help, which was not without obstacle; and sat swearing at InDesign as it stood there motionless until I learnt to over-ride the master page (kind of inverse Dorico!) Even MuseScore, which vaunts the discoverability of its UI, I’ve been scratching my head, and looking up stuff online.
I’ve been lucky to have formal training in several programs, and there’s always been an “Aha!” moment of something that I never realised was possible. Good UI is important, but it’s not everything.
One could almost think of Dorico as a programming language:
# Setup
P Violin
P Soprano
P Piano
# Write
M 4/4
K Bb
B 45
N 6bcade
H ferm
I’ve had a few ‘Aha!’ moments. The first came watching the video tutorial on creating Piano Duet layouts. Something I’d struggled for months to do in other software.
Newton’s Law of Equal and Opposite Opinions of Software?
When I tried Finale (c. 1986), it came with three manuals. I decided that life was to short to go down those rabbit holes!
D
Yippee!
I feel compelled to observe the obvious that: just because something isn’t how you would design it does not mean that it is poorly designed. It is just designed differently. In fact, many of us who support Dorico do so specifically because it is designed differently from its competitors.
Imagine for a moment how much worse it would be if you thought you had no means of selecting and changing objects that are inherently invisible! What would you do then? Turns out sign posts aren’t such a bad idea after all. And it is very easy to hide them, and, go figure, the options are right in the view menu just where you would expect to find them. Just like every other program that has any sort of screen overlay functions whatsoever. Do you curse InDesign for showing grids/bleed/margins? Or do you just tick the option to hide them when you don’t need them? I suspect the latter.
Personally, I dont care how it is designed: what is important to me is that it works better than the competition. This is generally the case with Dorico, and explains why I and others are so disappointed by the exceptions.
My hazy memory tells me that such things were pretty much the same in Sibelius, except that Dorico has more types of signpost.
Actually, I think there are more stunning examples of brilliant features–like the separation of Writing and Engraving, which avoid accidental formatting changes and produce extremely stable results.
rpearl: I am not arguing against the notion of context entirely. Clearly SOME context is required in a program of any complexity. I have no problem with Dorico’s obvious tabs indicating whether we are setting up, writing, engraving, or printing. These are situations where we clearly need a different set of options and Dorico makes it clear which mode we are in. My frustrations are with contextual inconsistencies and other behaviors that don’t seem to make sense. Why is there a signpost for the key of C Major but not for any other key I’ve tried? The palette and the keyboard icons at the top of the right panel select different sets of icons in the rest of the panel. I suspect I could go to some new 4.0 document somewhere and look this up, but why not explain what these two buttons do by providing a message when I hover the mouse over them? Then there are the inconsistencies in note entry; sometimes in note entry mode I can click on a staff line or bar and make a note appear, while other times the only way I can enter a note is to type its name (in which case I cannot select the horizontal note position, requiring that I move the note later). Stuff like that. I’m sure there are many here will condemn me for wanting Dorico to save me a trip to the documentation when it would cost almost nothing to do so, or for my expectation that Dorico would behave in an apparently consistent manner. Whatever. So be it.
Signposts indicate the presence of invisible things, generally. D major has a key signature which can be selected, and thus altered. C major doesn’t, so a signpost is there to be selected.
It sounds like you are inadvertently alternating between note entry with and without the mouse option.
That’s the internet writ large. Mostly here you’ll find helpful people. A bit enthusiastic about Dorico, admittedly.