This week I’m writing about writing about doing something. I mean, this week is about documentation!
After reading and writing documentation (and having had it on the back of my mind for a while because of my project), I think the key to good documentation is be specific and assuming whoever is picking up after you knows only the bare bones. This is just a rule of thumb though, with more knowledge about what you’re documenting you can adapt your level of hand-holdiness. For example, if you’re writing documentation for a program that will be read by new and returning users, more detail is always better. In another case if you’re writing documentation for a mod of Minecraft you may have to explain how to install it but you won’t have to explain how to play the game.
For my project, I haven’t gotten far enough to start documenting a set process yet however I can already smell trouble brewing. Because my project uses in depth functions of TimelineJS I will have to very carefully explain the obscure functions that barely anyone uses… and their quirks. (For example, sometimes the background color doesn’t want to work, or a row labeled “era” doesn’t display anything other than the main title.) I will need to first figure out exactly what I’m doing, then will I be able to document it. I’m also messing around with the CSS formatting so documentation wouldn’t start until I finish up with that. I’m also unsure if I should document the CSS formatting in case it messes with something far down the line and no one knows what I did. I think comments within the CSS may be good for that.