12/06 Editorial: IT'S TIME TO RE-INVENT THE OWNER'S MANUAL

[MikeRivers]

Originally posted by UstadKhanAli But . . . .the reason why a product gets discontinued is so that they can stop supporting it. That's why they'd get major props for supporting a Wiki-esque owner's manual.

But who would be responsible for the misinformation that always creeps in if there's no moderator/editor? When they want to stop supporting a product, they want to stop supporting it - zero money. In Mackie's case, and to their credit, their Tech Support department continues to field calls and answer questions about discontinued products, but all too many people are reluctant to make a phone call (and surely it isn't all THAT bad even from outside the US if you really need help) and they get really upset that the compnay no longer supports the product.

But isn't it possible that the owner's manual would be largely self-sustaining, since after the product is "obsolete", there'd be presumably a lot less updates and traffic in the Wiki-esque owner's manual?

There have been no updates since this particular product (the Mackie HDR-MDR24/96) was discontinued. The problem is that Mackie dropped the manual before the last set of updates. This is why I wrote my book - to fill that gap, and not to completely replace Mackie's documentation. Anyone who wants it can buy it. How do you expect me to buy a new boat if someone started a Mackie Hard Disk Recorder Wiki and filled it up with all the info and (there are really no) secrets from my book?

[Rabid]

I prefer paper and usually print out pdf files so I can look through them while eating lunch or watching TV. Reading off of a computer screen bothers my eyes much more than a clearly printed manual. I have a real problem with companies that make significant changes in software and do not update their pdf

[Jon Gnash]

 

Originally posted by Anderton Let

[Jon Gnash]

- They (the manufacturers) could even supply a

[kurfu]

Hello.. McFly???

 

Wikipedia

 

[Anderton]

>

 

Funny you should mention that. When Opcode was having a really hard time with piracy, Dave Oppenheim jokingly (I think) said "We should just give the software away for free, but with no manual and they'd need to call a 900 number if they had questions."

[Jon Gnash]

Originally posted by Anderton When Opcode was having a really hard time with piracy, Dave Oppenheim jokingly (I think) said "We should just give the software away for free, but with no manual and they'd need to call a 900 number if they had questions."

Even better would have been to headquarter his "900 number" customer service department in Bangalore and staff it with workers with outrageous unintelligible accents. Even the simplest problems would become 30-minute phone calls.

[Lucky #9]

The paper manual ---

 

I like to highlight sections and refer back to them later --- often, many times.

 

PDFs are helpful for sure, but I don't want to print them out if I can avoid it.

 

Some manuals are so brutally out-of-date it's pathetic.

 

But ---

 

I am totally confident that the situation as it is with inadequate manuals today will not soon change.

[techristian]

I think that we need to re-think this whole question from the ground up. Yes *.pdf files are easier to update but shouldn't the ENGINEER design these things with the end user in mind from the very beginning? What I see happening is that fewer and fewer buttons are put on new hardware, so what happens is that there may not be a single RECORD button, for instance, but the end user may need to press a 3 button combination simultaneously or in sequence to activate recording. Wouldn't it be easier just to have activate recording as most of us are accustomed to? Yes I know that I'm making an ASSUMPTION about the end user. I'm assuming that he/she already has familiarity with recording gear.

 

Back to my point. I know it is CHEAPER to have fewer buttons but I would rather have a hundred LABELLED buttons controlling each a single function than having 25 buttons with 100 functions. If you work with that piece of gear every day, I'm guessing, on average, you will only use 1/4 of the function keys. That means that 3 weeks from now when you want to tweak a sound (or any other function that you may not use daily) , you will need to dig up the manual. If those buttons are labelled properly, you may not need to dig up that manual.

 

Regarding the electronic manual............

 

As LCD screens get smaller, clearer and cheaper ,well made MENUS should guide even a child in the operation of the device. There will be no reason for not having a well driven menu system AND as the software gets revisions, so the menus will be updated.

 

Next ,I will also need a manual to tell me where I put all of my manuals ! I'm trying to get away from this !

 

Dan

[Ernest Buckley]

Sorry I have not read any of the posts above except Craigs...

 

I would like a hard copy just for reference but I would also think it would be very valuable to have an online manual that is revised with each update and then this online manual would have a forum where users could exchange ideas.

 

I think this will eventually be the way manufacturers approach the subject in another 2 years or so.

 

Peace,

EB

[MikeRivers]

I just had an epiphany (I like that word even if I'm not sure exactly what it means) yesterday. Back in August I got an assignment to write a survey article about stereo editing programs. One on my list was Wavelab, so I contacted the rep to get a review copy. I waited and waited for it to arrive (after a week, he told me that it was out of stock, but that the order was in and I'd get it soon). Then, eventually, he figured out that he had already sent a copy to the magazine when Version 6 was released and suggested that I try to get hold of that - but it was off with another reviewer somewhere.

 

When the deadline got close and still no Wavelab, I contaced Greg Ondo, the marketing manger and former training manager for Steinberg. He lives near me, and I asked if he could swing by one day when he was in town and give me enough of a quickie tutorial so that I could learn enough about it to write my article. Greg came over and loaded a copy on to one of my computers, loaned me a dongle, and showed me around. I spent the next few days playing with it and got the article in (and no, it still hasn't been published).

 

Wavelab has extensive contex-sensitive help and I had the whole manual as a PDF, but time after time, I wished I had a printed manual so I could find what I was looking for by browsing rather than having ot know the right words to search for, or be in the right menu to start looking for help. I think I've used the program once or twice since then, reluctant to start anything because I didn't have the manual.

 

Out on the porch I heard such a clatter. I sprang from my computer to see what was the matter . . . . OK, it's close to Christmas. UPS had droped a package on my front porch. I wasn't expecting anything, and when I saw "Promotional item" from Yamaha I thought maybe it was something I had requested at the AES show. Turns out it was the copy of Wavelab.

 

So yesterday morning, I woke up at around 5 AM and couldn't get back to sleep, so I figured there's nothing better to do for insomnia than to read a manual. I opened up the Wavelab package, got out the manual, and just reading through the first couple of chapters (without even starting up the program) got me better oriented than I had been without any printed documentation. No question that the real manual was working for me. If I had the manual when I wrote the article, I would have given it some praise (OK, it's not all THAT good, but it sure helps).

 

I guess we all have our own ways of learning. I grew up with books and not computers or video games, so I guess that's how I learn best. Your methods might be just as good or different. But for me, I'm happy to have the manual to browse through when I want to find something. There might be some small changes and additions as the program ages, but the fundamentals will always be there.

[Ernest Buckley]

 

so I figured there's nothing better to do for insomnia than to read a manual.

 

 

Mike,

 

Funny story. I enjoy reading manuals from certain companies like Mackie. MOTU is OK, though a bit dry. However for sheer boredom, Yamaha and Roland take the grand prize.

 

EB

[MikeRivers]

 

Originally posted by Ernest Buckley Funny story. I enjoy reading manuals from certain companies like Mackie. MOTU is OK, though a bit dry. However for sheer boredom, Yamaha and Roland take the grand prize.

I haven't bought a new piece of Roland gear for years, but I remember the reputation that Roland manuals had, except for the few that were written by Paul Lehrman and, I think Craig. But just a couple of weeks ago, my across-the-street neighbor came over to borrow a tape deck to transfer a couple of old tapes and we got to talking about old music gear. He has a Korg SG piano.

 

I got out the manual for my Roland U-220 and was showing it to him and I realized just how detailed and complete it was. There's a lot of there there, but then it's a pretty deep synth. I pretty much just used the U-220 presets with a little tweaking when I was playing with MIDI actively, but taking a look at that manual ten years later It's not very engrossing bathroom reading, but everything you'd want to know to create a new sound is there. I should probalby dust it off and give it a try again.

 

But here's a real world, real people example of a bad manual. The old AT&T wireless network that carried my cell phone service is being phased out and I was forced to get a new phone in order to transfer my service over to Cingular's equivalent (the short story - prepaid service, I use it very rarely and it's really the best deal for me). I had a simple, straightforard Nokia phone that severd me well for five years.

 

As part of the "painless upgrade" they offered a rebate for the price of a new phone on the new network. On paper, they offered the deal on two phones, a Nokia which seemed like it was the current version of the phone I had, and a Motorola C139. I wanted the Nokia, but I couldn't find one. Apparently they had a very limited number of those phones and within days of the announcement there were none left. So much as I disliked the Motorola - it was just too small and I had to use my valuable guitar-playing fingernails in order to press the buttons - yesterday I bit the bullet and got my service switched over.

 

Then I sat down on the couch with the phone and the manual and tried to figure out what the multitude of options on the multitude of menus did. The manual, while volumous, explained in great detail how to navigate through the menu (which was perfectly obvious to anyone who ever worked with a menu) but gave no explanation as to what the option that you eventually got to actually did. I haven't yet figured out why I can't see a number that I stored in the SIM, and what the heck does "attach a phone number" mean? How is someone supposed to figure those things out if they're not explained in the manual.

 

On the other hand, I suppose it's not a significantly different issue than saying that a switch selects between +4 and -10. If you don't know what those mean, you don't know what the switch means. There are places where you can read about nominal operating levels, but I don't know where I can read about cell phone features, because they're all different.

 

And the user interface on the phone is another story. If it was good enough, I wouldn't need a manual.

[chipmcdonald]

Manuals are screwed up because they're all written based on the wrong paradigms.

 

A manual shouldn't be written from an encyclopedia standpoint, but from a "what does the user know at this juncture?" standpoint.

 

BECAUSE

 

the major malfunction of a manual occurs when one of two things happen:

 

1) the user knows more than what the manual assumes he knows, and likewise becomes frustrated trying to dig through "already known" info in order to retrieve what he's looking for or;

 

2) the user *doesn't* know what the manual assumes he knows, and goes about explaining what might be a mundane operation by refering to features/functions that are not immediately obvious.

 

.. AND, A MAIN PROBLEM IS....

 

 

Manuals do not weight the *real utility* of what it is it's "explaining". This is engineer-itis in action: some obscure function someone thinks is "really super cool" turns into a 3 page jaunt through obfuscated trivia, while the guy that wants a rather basic, *inherent function* to work has to first find where it is in the manual he needs to read.

 

In other words, the manual should be organized NOT from a feature>down perspective, but from a *use* perspective.

 

A well designed product lends itself to this action anyhow - Line6 gear comes to mind - but for a manual, "what is the user going to want to know how to do?" should be the first criteria.

 

I've had a lot of gear, been around a lot of gear, and looked at a lot of manuals. Sysex, while a useful thing, for example seems to take up as much space in manuals as "How To Store a Preset" - which in the REAL WORLD doesn't make sense.

 

DRIVE-BY THOUGHTS:

 

 

Roland.... It's amazing Roland can stay in business. They started doing their "Quick Start" manuals, but the ones I saw looked like stripped down "Main Manuals"...

 

Yamaha always has that "Japanese car manual" spartan language, but at least that's better than too much.

 

Mackie did ok for awhile; but sometimes their style buries needed info too deep, and sometimes the order in which operations occur becomes fragmented.

 

Line6 does good overall, from what I've seen - although they're sort of like Apple in that you never really know exactly what's doing on under the hood.

 

Outside the music industry:

 

Nokia: tough phones... but their manuals are ultra-obfuscated. Sometimes there's pictograms of pictograms, pictograms that *sorta* look like pictograms on a phone's menu, but they're not... and then, pictograms that are *supposed* to be on the phone are different, sometimes confusingly like *other* functions... on and on...

 

Sony: traditional, Nihon-esque engrish.

 

Samsung: seems to be hung up on cyclic redundancy checks from a manual point of view. 5 different ways of explaining what the same function does, or 3 different places in the manual that says the same thing. Sometimes, too much depend

 

WAIT...

 

That's important:

 

*I ABSOLUTELY HATE MANUALS THAT INSIST I LEARN SOME SILLY PICTOGRAM "LANGUAGE"!!!!*

 

In other words "when you see this "@" sign in the manual, this refers to feature X, except when you see a "**"".

 

Samsung has a lot of pictograms that take the "International Universal Illustration" thing too far. Does the female face silhouette mean "Wide Angle" or does it mean "auto exposure for closeup" or "?????"

 

 

OK, I'll stop, I know this is useless.

 

/ food poisoning is a curiously forceful, if inelegant, editor...

[AW - Cakewalk]

So, I see some clear examples of manuals y'all don't like.

 

I'm wondering what documentation you've seen that has been done right?

 

In any form - print, online, integrated...

[Anderton]

>

 

Well, I can tell you the manuals I've done that I'm proudest of...

 

The E-Mu Drumulator manual was done with a lot of diagrams that had numbers and arrows, so if you wanted to do a particular function, you just followed the steps in order, and the arrows showed you which buttons to push...kind of hard to explain, but I'm sure Drumulator manual owners will remember There was also an appendix about rhythmic notation and other useful stuff.

 

I did a manual for Dr. T's Beyond, and it was basically all graphics, almost like a comic strip that took you through every function.

 

One of my favorite manuals was for the Emulator II. When I asked E-Mu for a deadline and budget, they said "However long it takes, however much it costs." It was done in a 3-ring binder (hi Mike!) with each functional section separated by tabs, forming a reference section. However, what made it different from the norm was that it also had a chapter of "Guided Tours" for accomplishing specific things. Basically, the guided tour was a series of steps, with each step referencing particular sections of the reference manual. People really liked this, because if they were focused on something specific ("I want to create splits and layers") they were pointed exactly where they needed to go.

[Anderton]

Hey Alex, since you're reading this...

 

The Cakewalk documentation for Sonar 6 is very good -- when you can find it! The context-sensitive aspect is very helpful ("Here I am in AudioSnap, what does this thing do?") and the integration of tutorials with definitions, and the hyperlinks, really help.

 

But then you have things like the reviewer in SOS saying that the VC-64 doesn't have a manual because he didn't see the "manual" button on the front panel, or the users on your forum complaining about the "fact" that Session Drummer 2 doesn't have documentation -- because they don't know how to navigate the file path to find the "VST plugins" folder that contains the Session Drummer 2 folder that contains the documentation.

 

I complained in one review I wrote that the Sonar 6 documentation was disorganized. If someone could spend a month or two just pulling all the disparate elements together, weeding out/updating the legacy stuff, and making sure the sections located outside of the main manual were integrated with it, then I think Sonar 6 could become the poster boy for why you want electronic instead of printed documentation.

 

In fact, I actually think that a printed manual makes little sense with a program like Sonar given how deep it is, and how many ways you can use it. Trying to find one function in hundreds and hundreds of pages is, to me, far more difficult than doing a search on a term. The only problem is that sometimes one company uses a unique term to describe some common operation, so you end up typing the wrong word and can't find something. But that would happen with a printed manual and index, too.

 

For example, video support. Sonar does that quite well but I'm sure not all users take advantage of the video aspects. To clutter up a printed manual with dozens and dozens of pages on video would probably be a waste of money and resources. I found out all I needed to know about the video aspects in an evening of browsing the various pieces of online documentation.

[Anderton]

BTW, since this topic seems to have struck a chord, I'm doing a somewhat different version for print in the February issue of EQ. So the editorial will have both a print and online version -- just like how many of you want manuals to be

[AW - Cakewalk]

Originally posted by Anderton > Well, I can tell you the manuals I've done that I'm proudest of... The E-Mu Drumulator manual was done with a lot of diagrams that had numbers and arrows, so if you wanted to do a particular function, you just followed the steps in order, and the arrows showed you which buttons to push...kind of hard to explain, but I'm sure Drumulator manual owners will remember There was also an appendix about rhythmic notation and other useful stuff. I did a manual for Dr. T's Beyond, and it was basically all graphics, almost like a comic strip that took you through every function. One of my favorite manuals was for the Emulator II. When I asked E-Mu for a deadline and budget, they said "However long it takes, however much it costs." It was done in a 3-ring binder (hi Mike!) with each functional section separated by tabs, forming a reference section. However, what made it different from the norm was that it also had a chapter of "Guided Tours" for accomplishing specific things. Basically, the guided tour was a series of steps, with each step referencing particular sections of the reference manual. People really liked this, because if they were focused on something specific ("I want to create splits and layers") they were pointed exactly where they needed to go.

 

Thanks Craig - I'll check 'em out!

 

I found them here, in case anyone's interested:

 

http://www.emulatorarchive.com/Manuals/manuals.html

[AW - Cakewalk]

And thanks for the feedback on the SONAR documentation, Craig. That's why I'm reading this thread...

[tekkaman42]

I come from a slightly different background from most of you, since I am not an engineer or a professional musician, but an English and special education teacher with an interest in technology, music, and some post-grad study experience in how people read and use information. In my experience, the traditional "book" format is useful for reading novels and other narratives, as well as poetry, and is a serioius pain for technical text, particularly when it is not meant to be read from front to back.

 

In addition, many readers are less successful with text than they are with diagrams and pictures, and those become even more useful when they are interactive, such as hypertext and other graphical interfaces. Manuals written in PDF, or even as linked PowerPoint presentations would be more helpful than static, paper-based manuals, not to mention the capability for animation or video. Some of the screen-animation tutorials available for programs like Live and ACID are far more helpful to me than if I had actually read the manual.

 

I really like the idea of a Wiki-based manual, but maybe more as a supplement to a well-designed, interactive, multi-modal electronic manual that combines text with animation and interactivity, as well as a search function or table of contents link tree, since no-one actually reads the whole manual from beginning to end.

[jjbraunius]

Craig, I remember many years ago you did a book on Sonar 1 (or was it Cakewalk 9?) that I used extensively alongside the supplied manual. Your book pretty much went by the manual but it was much easier to read and understand. Once I got the edge on the material I was able to use the Cakewalk software manual instead and had no problems but the "getting started" part was done thanks to your book. The Cakewalk manuals are usually better than what I've seen in other apps, mainly Logic and Cubase which are much harder to understand (maybe it is the German root of the companies?).

 

My suggestion for manuals is to use the open source format. Being a system admin in "real life" there are great examples of Linux manuals online where there are people (gatekeepers) who control the info that gets posted into the manual but anyone can submit material to it. It is usually done in html format and all the info is crossreferenced with links.

 

I am referring to something of this type:

http://www.linux.org/docs/

[MikeRivers]

 

Originally posted by tekkaman42 In my experience, the traditional "book" format is useful for reading novels and other narratives, as well as poetry, and is a serioius pain for technical text, particularly when it is not meant to be read from front to back. [/QB]

I really want to be able to read a manual front to back. I'd like to know what the device can do before I start bumbling through its use. This is usually possible for a hardware device like a mixer, recorder, channel strip, reverb, or such.

 

It's usually impossible for a software product. Why? Because they put SO MANY festures and functions in it that you can't possibly remember them all. But what you should remember is that you've seen a way to do whatever you want to do (or know you didn't see it) when you read through the manual. An overview manual and a technical reference is a good combination for such a product. The manual should tell HOW to operate it (the logic, however warped, for organizing menus, where the ENTER and ESC buttons are, and any shortcuts).

 

It should also explain what the functions actually do once you find your way to them. For example, my former new cell phone had an item on the menu "Attach number" but nowhere in the manual did it tell you what this means - what number you're attaching, and to what are you attaching it. Turns out that when you select that item, you get a list of places where there are (presumably phone) numbers, pick one, then pick a number from that list. Then you get another list of places, you pick one, and it appends the number you selected to the number in the place you selected. So if I selected 7771234567 from the first list and selected my home phone number from the second list, I'd end up with my phone number in the dialing directory being 55599911117771234567. Now why in the heck would I want to do that? I still haven't figured that out, but if the manual told me, I'd get it.

 

The Technical Reference would be a logical thing to be computer-readable and linked. By the time you open up the Tech Reference, you already know what you're looking for, and want to read more about it. [QB]

In addition, many readers are less successful with text than they are with diagrams and pictures, and those become even more useful when they are interactive, such as hypertext and other graphical interfaces.[/QB]

I don't think it's a function of the reader, it's a function of the material. I get lost in a page of icons. I want to read text first, then see the icon that represents that function. Flow diagrams are very useful. Menu trees are useful. An interactive menu in the manual? Why bother? You can just use the menu in the program or device as long as the manual tells you how to navigate it. [QB]

Some of the screen-animation tutorials available for programs like Live and ACID are far more helpful to me than if I had actually read the manual.[/QB]

I haven't seen those, but I find that most video tutorials on the computer are too abbreviated for me and they move too quickly. I don't have time to explore the options when I take a step, all I can do is follow in the footsteps of the "instructor." And that's usually for something that's fairy simple that that I could figure out on my own. I have a couple of instructional videotapes that are an hour long and I can watch them in the living room in fromt of my TV set. It's like listening to a lecture. I can't get that sense from my computer. I get distracted too easily because "it's just the computer." But that's just me.

[johnebgood]

Maybe it

[Todzilla]

Gripe #1. Owners manuals are largely written as though they are read cover to cover. False. Owners manuals should be written for the more frequent occurrence of a user needing reference information quickly.

 

Gripe #2. Owners manuals that have not indexed every menu option are committing an unforgiveable sin. Are you listening MOTU?

 

Until tech writers make manuals more useful in these ways, there's not much point, IMO, about stressing the currency issue.