The Chairman
Chairman of the Board
That was classic Bob! 
A question about Scuba Board posting etiquette
- Thread starter FPDocMatt
- Start date
Please register or login
Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.
Benefits of registering include
- Ability to post and comment on topics and discussions.
- A Free photo gallery to share your dive photos with the world.
- You can make this box go away
gcarter
Contributor
Sometimes people may have a comprehension issue with the manual too. Sometimes they will read what it says but just have a question about how its worded or perhaps if its worded a little differently then they are used to seeing.
I think sometimes people see how blanketed a manual is so that it can be standardized for all readers they simply want an outside opinion or to talk one on one with someone with first hand experience.
To be honest Scubaboard has been around for quiet a long time. If no one posted a repeat question then there would likely be only a handful of new post per year.
I think sometimes people see how blanketed a manual is so that it can be standardized for all readers they simply want an outside opinion or to talk one on one with someone with first hand experience.
To be honest Scubaboard has been around for quiet a long time. If no one posted a repeat question then there would likely be only a handful of new post per year.
drrich2
Contributor
Sometimes with good reason. Oceanic's dive computer manuals have been, er, 'mentioned unfavorably' a few times on this forum, if memory serves, and I found trying to learn from the VT3 manual a wretched experience.
You'll notice Dive Nav's online dive computer tutorial offerings are quite popular. Why, oh why, if manuals are such obvious clarifiers can Dive Nav, a 3'rd party, put forth a workable business explaining dive computers?
I recently switched to an Atomic Aquatics Cobalt for a computer that I can understand. Banged out around 16 dives in Bonaire this past December and loved it. Cost a lot of money to switch computers, but, you know, sometimes clarity has a price.
Richard.
gcarter
Contributor
I have an Oceanic computer, and I did not find the manual friendly at all.
BUT had I not started there, I would not have known that. Had I not started there, there would have been no focus to the questions I brought back to my LDS. I would have wasted their time and mine. Had I not started there but instead relied solely on other sources, I would not now be able to have a quick glance at the manual to refresh myself.
My LDS will not be in my kit when I go on a dive. Dive Nav will not be in my kit when I go on a dive. The manual will.
No one is suggesting or has suggested that a manual is the be all and end all. But it does have its purpose.
For the instructors here, when you have a student sign up for a course and they show up having done zero preparation, no reading, no idea what is going on, how do you feel about that? How do you feel about how much time they waste for you and the rest of the class? What if they show up for the second class or the third still not having done any reading or other prep? How well will your patience hold up?
At some point you have to take some responsibility for doing some work on your own.
Ask your questions - I certainly do - just understand that there are different levels of tolerance for questions depending on how much the asker is taking ownership versus how much spoon feeding they are looking for. It isn't the repetition, it isn't the "level" of the question, it is the context.
For those who have great patience, kudos to you. But the rest of us aren't wrong either.
gcarter
Contributor
Every new ask of a question brings different dynamics to the discussion, as does a different mix of answers & opinions.
The gold is often in the nuance. I know for my part I read multiple threads on the same or similar topics and more often than not walk away with some new nugget to think about or to incorprate into my dive toolkit.
gcarter
Contributor
- Messages
- 93,476
- Reaction score
- 91,841
- Location
- On the Fun Side of Trump's Wall
- # of dives
- 2500 - 4999
Simple ... because some folks know how to produce documentation that's understandable, while others merely know how to produce documentation that's technically accurate. The two are not the same.
I've been earning a good living writing manuals since 1977. My most recent project is an online documentation project for a wastewater treatment plant ... it's basically an 18,000 (and growing) page website with about 10,000 linked PDF documents. I got involved in this program three years after our engineering department conceived the idea and had hired a consulting company to create it ... and while it's got some nice features, it's rather difficult to navigate ... and it wasn't real usable to the people who were its intended audience. I've been "fixing" it for about a year and a half now.
During my first meeting on this program, after about an hourlong presentation from the consultant, I asked a question ... "How did you decide to build it like this?" They said they'd made a list of all the features they wanted in it, and built the program around those features.
Wrong approach ... you create a document by first asking yourself who is your audience and what do they need to know? Before you build it, you get to know how your audience works, and how they go about processing information. You build the documentation in a way that's logical to the user ... rather than to the people who designed it.
The same goes for just about any type of documentation.
Most consumer manuals give you infinite detail on every feature. They'll describe very accurately what each control does.
What they'll fail to do is tell you how to use it in the context you will be using it in ... and in a way that "speaks" to the background knowledge of the person who's likely going to be reading the manual.
Those who consider the needs of the user first, and build the documentation around those needs rather than around the features of the product, will succeed at providing usable information.
Nobody cares how an alarm clock works ... they just want to know how to make it go ding-ding-ding on time ...
... Bob (Grateful Diver)
Similar threads
