Yes, The Docs Again... INDEX!!!!!

‘Direct Routing’… a marquee feature, right? Not in the index.

OK… Ctrl-F to ‘find’ direct routing.

Hmmm… not exactly a ‘Relevance’ based search is it?

QED… I dunno about the rest of y’all, but I do NOT consider the Op Manual a real page turner. I do not spend my nights reading this thing from cover to cover. I use it as a -reference-. When I want to know something, I want to know it… FAST. While I’m working.

But what you guys seem to do with each release is simply pump more copy into the same basic structure, rather than taking the time to (at least a -little-) re-think the presentation… including titles, topics, index keywords, relevance weighting, etc. It should be getting -easier- to find stuff with each version and it’s generally not.

Sadly, I have to agree. I have been frustrated on a number of occasions while trying to look up something that should have been indexed but was not. On the whole, I think the doc is pretty good, but it really deserves a more thorough indexing treatment.

…took me 24 seconds to find
Setting Up Direct Routing (Cubase Pro only) …pg340

How fortunate for you. However, there is no index entry for this topic under “direct” nor is there one under “routing” and there is not even an entry in the table of contents. So it seems to me that the OPs point is quite valid.

As someone who in a previous life had to procure technical writing, I totally agree. The content is very well written, but the index needs to include way more entries. It really should be a comprehensive index. At least with pdf we can search, imagine how difficult stuff would be to find in hardcopy only. But searching can take a long time if you need to use keywords that are common in the text and generate tons on false positives.

The other area where I think the manual is lacking is in giving an overview of using Cubase (maybe they assume to videos fill this space). The docs are real good at explaining the how but kinda lacking on the why.

Like suntower I use the docs strictly as a reference, which is how they are designed to be used. But every so often someone will recommend in a post that folks read the whole thing through :question: :open_mouth: :question: :open_mouth: :question: which just seems unrealistic and not very useful. A couple of years ago I needed to start using the Score Editor which I had previously ignored. So I read/scanned that entire section and a huge portion didn’t really initially provide me anything useful. Later when I got to the point where I needed a specific piece of info and looked it up then it made sense. Reference books are like that, they answer specific questions but you need to understand the question before it can do that.

The Op manual is typical ‘programmer’ content. It has very good functional descriptions and that is -it-. It is very poorly indexed. It has almost no recipes. Programmers typically feel that ‘someone else’ should generate those. Only weak, girly-men ask for ‘hand-holding’.

This is the key to Apple’s initial success: they turned that on its head: If you can’t figure it out? It’s OUR fault, not the end-user.

SB hasn’t had that epiphany yet. It’s a cultural thing. The whole company has to make ‘intuitive’ a first principle.

What kills me is that I left ‘software’ because I didn’t WANT to be ‘tech guy’ anymore. And then I get Cubase and I find that most people who are into it just -expect- to be geeks… even MORE than be musicians. That was a tough realisation. It never ceases to amaze me that DAW makers don’t put ease of use at the top of the list.

—JC

Just seems to me that it was more effort to create this topic and discussion than to find the tiny bit of info reqd.

But it’s not just about “a tiny bit of info.” That is only one example of a systemic problem with the index being incomplete. I’m pretty sure if this was a one-off occurrence, suntower wouldn’t have made the post. I’m guessing this has happened to him a lot (it has for me) and this was the straw that broke the camel’s back. Sure maybe this example only took a few seconds to find, but I’ve also had times were it took many minutes because a search produced 80, 100, or more hits. And you might go through those only to discover the manual is mute on the topic.

It is a defect in otherwise decent documentation. Nothing wrong with pointing it out. Also I bet a good quality index would significantly reduce the number of questions posted to the forums.

Nobody ever convinced anyone of anything in an on-line forum. You feel as you do. And people like me are hyper-sensitive sissies who should just RTFM. I get that. I used to be that guy.

  1. It’s not my job to list out -all- the shortcomings of the docs. To me, it’s self-evident. I just gave one example. If it’s not an important ‘benefit’ for some, I get that. It certainly doesn’t sell product. No company ever made a sexy advert: NOW WITH 50% BETTER ON-LINE HELP! But that said, if a marquee feature is missing, what does that say about the state of the entire doc?

  2. You wrote that it took 24 seconds to find the topic. Maybe that seems fast to you. But let point out that ‘fast’ is a relative term. If you open your web browser, type a search phrase and it takes 24 seconds for the page to render… is that ‘fast’?

-Most- people who are focused on work–really focused–do NOT want to lose focus. That is NOT petty. And this has been studied to death.

I do wood working. If I’m working on something and realise I need a tool, I don’t lose focus having to go over to the bench to get another tool IF I -know- where I’m going to find it. No problem. I’m still -thinking- about my work. Now… if instead I realise that I don’t know where the tool is? OR if I realise I have to make a trip to the home centre to get something? I’m screwed. I’m thinking about something else now. I’ve lost focus. And that is what poor docs do… they take one OUT OF THE MOMENT. You have to stop thinking about what you’re thinking about and instead think about finding the information. It SUCKS.

YMMV.

Part of my dual life is hardcore, sometimes boring, sometimes exciting electrical engineering for the oil and gas industry.
I think I have a good grasp of creative thinking and logical deliberate number crunching.

The point I’m making is that a piece of software is the tool to get to the end - it’s a means to an end - and so is a manual.

All of these things are engineered with compromise in mind - why, cause no user would be willing to pay for the ultimate solution.

I don’t get sidetracked because I’ve taught myself that done activity is either left brain and some are right brain (colloquially) … when I’m in a creative space i stick to the familiar and when I’m mixing/editing i switch to a different mindset which gives me the patience to figure technical things out.
All manuals are comprises - as mentioned i use software, in which the manuals are worth more $$$ then a entire Cubase/Nuendo installation. … and still there “things” that could be better.

Here’s a thought: why not post an example of how this manual could be made better, without it incurring 1000s of hrs of rewriting? Just a thought.

I did give a specific example of how it could be made better. :smiley:

Since I used to write such manuals, I know what it takes to improve them. It ain’t 1000s of hrs. It’s more like 10hrs.
1a. Have a guy go to the webmaster and get a list of all the most common search keywords and topics.
1b. Cross check that against the current PDF index.
2. Double check that all topic headings, subheadings, etc. are indexed and in the TOC.
3. Go to the HTML file that makes up the on-line help (it has a LOT of topics -not- in the PDF) and add those items to the PDF. If that’s too much like work, just include the topic headings from the CHM in the PDF with a line… see on-line help for details!
4. Go to the guy who writes the Key Command Editor and cross check that -every- key command function is included in the PDF.
5. With the remaining time, create a 2 page What’s New In This Version topic which is simply the new features blurb from the web site with hyperlinks to the relevant pages in the PDF. (BTW: this used to be S.O.P. until V7).

Ta da!

One example of the additional thought & effort already made in the since version 7.

Project Handling was broken down into
65Creating New Projects
65Steinberg Hub
67Project Assistant
68About Project Files
68About Template Files
70Project Setup Dialog
73Opening Project Files
75Saving Project Files
76Reverting to the Last Saved Version
76Choosing a Project Location
77Removing Unused Audio Files
77Creating Self-Contained Projects

This has now become Working with projects
55 Creating new projects
57 Opening projects
57 Closing projects
58 Saving projects
60 The Archive and Backup functions
62 The Project Setup dialog
64 Zoom and view options
69 Audio handling
69 Auditioning audio parts and events
70 Scrubbing audio
70 Editing parts and events
80 Range editing

Each section requiring additional wording and thought …

Webmaster? …are you serious? :wink:

I would contend, experience in one type manual does not imply wisdom for all forms of instruction. In fact, given the various ways in which information is obtained in this day and age - a “standard” is always going to require more effort than “10hrs” :unamused: