Quote:
Originally Posted by Pelican
I have to chuckle at the discussions about the user manual. I can dimly recall that our first versions of WordPerfect arrived at at the office with a user manual (hard copy) that looked like a dictionary. I was too busy to bother with it. A few years later, I was stuck in a bad work situation, without support, and basically forced to fend for myself. With a little help from sympathetic friends, I plunged into Word and related Office programs, no training, just doing what I could, asking questions, using the Help function. What I learned was that the user manual was worthless, the programs were intuitive and designed to “learn by doing”, and that support was available when I needed it, specific to the issue I had.
Flash forward a couple of decades, my latest Mac Mini arrives, typical simple Apple packaging. No manual. Plug it in and turn it on. Problems? Easy access to FAQ and Apple Support. A whole world of users to consult. Responsible patches and updates. To me, OOTP works on that same model. And it works for me.
I mention all this because, with OOTP, I have only rarely and early on relied on anything in the user manual, such as it is. (The gap I found at that time has now partly been filled by the tutorials, which can be tedious.) Instead, I plunged ahead and began setting up my season sims. Once I realized how easy it was to save and back up, I worried less about getting caught in a bad place. I could start over; although that has only been necessary a couple of times, due to user error on my part. When I stumbled, I could turn to OOTP for support, or turn to these forums as basically an FAQ source, or to raise my issue. So, I don’t know that a comprehensive rewrite of the OOTP Manual is necessary, or would improve the knowledge base. As long as support works this well, and so many users are active with advice, I have the backup that I need.
|
Agreed. Most ppl don't read manuals period. But, the manual could serve as a binding contract. A point of reference of what the game is supposed to do and what every setting should do right down to the percentage effect if should have on whatever catalyst it is relevant to.
Then there are no arguments or spin. It's just "if you don't believe me look it up in the book".
When I programmed we had to keep meticulous documentation, run-books, flowcharts, all that stuff.
But, I frequently found myself in situations where the user disagreed with the documentation. The product didn't perform as the documentation said it should. So, I would actually sit down with the user (higher level liaison representing the particular department) and show them the code.
I had many of my administrative users acclimated enough to unix/Linux script, Cobol, glink script (script languages in general that are very powerful), VB, etc. they could see the intent in the code. It was then up to them to document outcomes that digressed from what the code stated. When/if they could do that I would revisit the code in the context they found the issues.
But, no offense, with OOTP product I keep seeing statements from key people (I guess developers) that suggest it's all random and you're liable to see just anything. And, we'll back up the egregiously rare yet prevalent (contradictory statements I'm aware and my point) outcomes with points of time in baseball history that this transpired.
I never had that luxury. It worked exactly as advertised or it didn't and suddenly I was being called into a "come to Jesus" meeting with the Directors.
The code I supported was of the state government variety and any citizen of the state was actually entitled to look at it if they so choose. I didn't hide anything because I couldn't. I would have loved to have been able to call bugs..features. But, it didn't work that way. I was accountable and completely transparent.
Guess I'm coming from that "old-school" philosophy and standard. Likely not relevant anymore.