Who remembers eDispa? On April 15, 2007 I wrote: "I suspect that eDispa will disappear into oblivion". On April 16 I added: "That poster says so many implicit things than demolishing it point by point would be easy and funny".
I haven't heard of it again. Did you? Are you longing for eDispa?
Saturday, 31 May 2008
Friday, 30 May 2008
Manual
Today I am free write the most outrageous ideas that cross my mind. They say that nobody reads the manuals. I have put the title "Manual" and now anything I write will be read by myself only. Yes, I read the manuals and sometimes I even read them twice. I don't like doing it, yet it's a precious activity. If I am going to use a program, I know I can't learn it by trial and error, it's only a waste of time. I look for the manual and study it.
A well-written manual it's hard to find today. If people were to choose program on the clearness of their manuals, the documentation writers would be as rich as Bill Gates and our kids would aspire to become doc writers instead of football players. That's not the case. I myself have maintained, for years, that programmers can't neither be the testers nor the doc writers of their own programs. Today I have changed opinion, not because my idea was bad, but just because a bad manual is better than no manual.
Let's hope that, at least, the manuals are up-to-date. Have you ever found a manual that refers to an old version of the program? It easily happen that they change the program, even drastically, but forget to update the manual. That's the worst thing that can happen. A less sad situation, yet still annoying, is when you buy the Mac version of a program and all the figures of the manual refer to the Windows version.
Are they to blame? They are not, because they have been told that nobody reads the manuals, so why should they invest time into the job of writing manuals? Why? WHY?
After years I have found the answer. I had to. I was writing pages over pages, and receiving the confirmation, day after day, year after year, that nobody was reading them. They still use to call me and ask: "where can I found the manual?". They keep printing it, losing it and printing it again, but never finding the time to read it. I stopped and told to myself: "Either you find valid a reason, in the next 5 minutes, for doing it, or cease writing manuals forever". In the next 2 minutes I realized that, quite often, I consult my own manuals because I forgot how my programs are supposed to work. Consulting the manual is simpler and faster than reading the code of the program
Now I write manuals for myself. I attach the manual to the product because you can't sell a program without any manual (and there's even the risk that somebody checks if the manual actually describes the enclosed program or a different one), but I write the manual for myself. I am not proud of it but, hey, you don't know how difficult it can be to write a good manual.
After years of frustration I finally have a thing in common with Scaruffi. (I seem to remember that he once stated, in an interview, that he writes a lot because his memory has always been week; but being my memory week too, I may be confusing him with another person...).
A well-written manual it's hard to find today. If people were to choose program on the clearness of their manuals, the documentation writers would be as rich as Bill Gates and our kids would aspire to become doc writers instead of football players. That's not the case. I myself have maintained, for years, that programmers can't neither be the testers nor the doc writers of their own programs. Today I have changed opinion, not because my idea was bad, but just because a bad manual is better than no manual.
Let's hope that, at least, the manuals are up-to-date. Have you ever found a manual that refers to an old version of the program? It easily happen that they change the program, even drastically, but forget to update the manual. That's the worst thing that can happen. A less sad situation, yet still annoying, is when you buy the Mac version of a program and all the figures of the manual refer to the Windows version.
Are they to blame? They are not, because they have been told that nobody reads the manuals, so why should they invest time into the job of writing manuals? Why? WHY?
After years I have found the answer. I had to. I was writing pages over pages, and receiving the confirmation, day after day, year after year, that nobody was reading them. They still use to call me and ask: "where can I found the manual?". They keep printing it, losing it and printing it again, but never finding the time to read it. I stopped and told to myself: "Either you find valid a reason, in the next 5 minutes, for doing it, or cease writing manuals forever". In the next 2 minutes I realized that, quite often, I consult my own manuals because I forgot how my programs are supposed to work. Consulting the manual is simpler and faster than reading the code of the program
Now I write manuals for myself. I attach the manual to the product because you can't sell a program without any manual (and there's even the risk that somebody checks if the manual actually describes the enclosed program or a different one), but I write the manual for myself. I am not proud of it but, hey, you don't know how difficult it can be to write a good manual.
After years of frustration I finally have a thing in common with Scaruffi. (I seem to remember that he once stated, in an interview, that he writes a lot because his memory has always been week; but being my memory week too, I may be confusing him with another person...).
Subscribe to:
Posts (Atom)