> I'm the first one to admit that the documentation is a lot to > wish for, > and it is outdated. However, as I have stated lots of times, we don't > have the time to do both the coding and the documenting. In fact, we > barely have the time to do the coding. There's a documentation center > where everybody can contribute. Either someone joins in or I'm afraid > the docs are going to continue being a bit of a disappointment.
I'm a fair hand at technical writing, and at least in my own mind, I think fairly good at writing tutorials (if I know the kind of audience I'm aiming for). But up until about a year ago, my primary focus was simple HTML, XHTML, XML and CSS. JavaScript was only for "pretties" like mouseovers. Once I realized that there was far more that could and should be done with it, I've been soaking up as much info as I can about it. Problem is, I'm one of those "beginners" that is taking the leap over the chasm that lies between the "drag and drop" types that someone else termed beginners as, and someone who develops for fun or profit. I know enough about JavaScript to get myself into trouble, but I will admit to frankly having spent about the last month or so pulling my hair out over DynAPI. There are a lot of things that this API could do, and should do. And I would be more than willing to write up docs and manuals and "how-to's" - but I'd need to interview and get some insights into the brains of some of the developers to do a good job. Things like: "What did you REALLY intend to do with this bit of coding?" It is easy to be elitist about anything - especially in the technological arena. But what about the next generation? What about those who want to expand their learning? Let me give you an example from science: All current scientific knowledge is based on the experiments and previous work done by other scientists throughout history. Without the notes and explanations left by those historical scientists, our modern scientists would be required to "reinvent the wheel" every time they wanted to move forward. For example, because I had some difficulties understanding the resize functionality of the DynAPI product, I used a workaround gleaned from the DynDuo files (liquid.js) It works fine, but it's not using the correct functionality. But it was better documented and better explained. Once something is explained in detail, it encourages further thoughts on "How can I use this in other ways?" Which automatically expands the project. I don't think it is too surprising that when I printed out both sets of documentation (DynDuo vs. DynAPI) that DynDuo has 119 pages of docs, and DynAPI has less than 40. But again, if the developers of the community are willing to let me pick their brains about their additions to the API, I for one would be MORE than happy to put forth an effort to write docs and tutorials for it! Cat _______________________________________________ Dynapi-Help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dynapi-help
