This post contains errors due to my not seeing parts of the help and the manual. Read beyond this post before making conclusions about the manual and online help.
I wasn’t offended at all Marc. I know others know the program better than me - but I still sense I can make a contribution while hopefully learning quickly from others.
Thanks Lillie for your comments.
Please understand that you and Daniel are responding to a completely awed Dorico user who is delighted with how Dorico is designed. I wouldn’t bother making comments if it didn’t seem worthwhile for this reason.
Yes Lillie I see that there is a section labelled Dorico Concepts at the start of the manual but its focus is only on the fact that Dorico has less in built dependencies/rigidity than other programs. It then has a couple of links to individual concepts. The reason why I believe this is not adequate is because I believe people will only understand Dorico’s key concepts, and have the quickest introduction to the program, if you do each of the following three things:
1.——— begin by describing each of the key concepts independently of each other. And do so while attempting to predict which aspect of each will prevent the user from guessing incorrectly how the feature works. Every single key concept in Dorico is met by users with pre-existing expectations. For example:
-FLOWS - many users will think that flows are more of a unit for formatting than is the case. I have at the bottom of this comment made an attempt at introducing a user to flows. I’m sure others can do better than me but I post it in case it reveals where I am coming from.
-PLAYERS AND INSTRUMENTS-the issue with players is that they aren’t instruments and instruments aren’t players and yet Score view starts in page view which doesn’t show either instruments (with triangles pointing across and not down) or staves for each instrument - only galley view does. Therefore we don’t learn any difference between players and instruments by landing in page view - an introductory video could have prepared us.
-LAYOUTS -the issue with layouts is that users with any history with notation apps will likely expect a single score layout and a layout for each part and no more. And they will expect all entered music in a project to exist in all layouts. So the focus needs to be on correcting those expectations.
- ——— having introduced each concept separately I believe you must then explain the RELATIONSHIPS between the key concepts. I mentioned above that understanding the many to many relationships between players/instruments and layouts and flows, and then showing how Dorico’s user interface has been designed to reveal them, is very important. People must be led to seeing the WHY in the design. Part of doing that will require a user to understand why Dorico has modes. Why doesn’t the app just have one mode with lots of tab views around the edges?
3.——— having done these two things finally you must ensure that ALL of this information be IN ONE PLACE:
- in the manual (as if to say "You won’t get any one of these things until you understand each key concept in relation to the others - or at least REALISE that that’s what you will eventually need to achieve”.
-in an introductory concept video pinned to the top of the hub.
-as a separate menu choice in the Dorico help menu (above the general help). This information must not be WITHIN any help or manual (although in the case of the manual I’m only suggesting that it exist at the start and be given a heading style that indicates that it is the first “half” of the manual and the subject based help is the other half.
Finally, here is an idea which I believe would be of help not just to those writing documentation but to those designing and developing. You need to think Why then What then How. Watch this brilliant and famous talk by Simon Sinek to understand where I learned this.
I think that Dorico has absolutely nailed it with its thinking through on design issues. And thank God (I’m a believer) - the task is so complex. The design issues show that developers and UI people have been thinking hugely about the why first. But as yet I don’t think that this same emphasis on letting the structure of app help, videos and manual be governed by the why is there yet. I know that most app help doesn’t focus on the why. But if Dorico’s approach to help and documentation takes the same approach I believe it will suffer even more than other apps do when it is the case.
You will know when you have the manual right - it will lead people to read the vast majority of the many pages with an expectation of what must have to exist and how it will likely need to work. One helpful consequence of this is that you feel less need to make sure that every place in the manual reference every other one. When it does I believe it’s an admission that the manual has no power to guide users from big concept down to small.
FLOWS
A flow is a collection of adjacent entered music (including potentially any number of empty bars in metred music). Each flow is represented in the bottom panel in Setup mode and is given a default name (Flow 1, Flow 2 etc) but you can name each flow as you wish.
In a new blank Dorico project in which players have been added there is a single flow which displays staves for each player. If the user enters music without adding additional flows all the music will be added to that single flow. The user can then choose at any point in the music to split entered music into two separate flows and can also add new blank flows. Finally a user can re-order flows as a way of re-arranging their music.
Splitting music in Dorico into two or more flows enables Dorico to complete various operations by selecting one or more flows as the target for the operation. For example one or more flows could be chosen for export. Or an empty flow could be the destination for imported data. Flows also enable the user to quickly locate key points in the music for viewing, editing and playback.
Although flows are used primarily for organisation and operations flows can assist the user with two formatting tasks:
-by default bar numbers restart at bar 1 for each flow. This means that flows are suited to being used to distinguish movements in a score, or numbers in a musical etc.
-flows provide a way of telling Dorico the points in the music at which you wish to automatically generate titles. The titles are automatically generated from flow names.