|
A common complaint among users regarding software documentation is that only one of these three approaches was taken to the near-exclusion of the other two. It is common to limit provided software documentation for [[personal computer]]s to [[online help]] that give only reference information on commands or menu items. The job of tutoring new users or helping more experienced users get the most out of a program is left to private publishers, who are often given significant assistance by the software developer.
its no good yall are bad
=== Composing user documentation ===
Like other forms of technical documentation, good user documentation benefits from an organized process of development. In the case of user documentation, the process as it commonly occurs in industry consists of five steps:<ref>Thomas T. Barker, [http://www.writingsoftwaredocumentation.com/index.htm Writing Software Documentation], Preface, xxiv. Part of the [[Allyn & Bacon]] Series in Technical Communication, 2nd ed. [[Upper Saddle River, New Jersey|Upper Saddle River]]: [[Pearson Education]], 2003. {{ISBN|0321103289}} {{webarchive |url=https://web.archive.org/web/20130513033153/http://www.writingsoftwaredocumentation.com/index.htm |date=May 13, 2013 }}</ref>
# [[User analysis]], the basic research phase of the process.<ref>Barker, pg. 118.</ref><br>
# Planning, or the actual documentation phase.<ref>Barker, pg. 173.</ref><br>
# Draft review, a self-explanatory phase where feedback is sought on the draft composed in the previous step.<ref>Barker, pg. 217.</ref><br>
# [[Usability testing]], whereby the usability of the document is tested empirically.<ref>Barker, pg. 240.</ref><br>
# [[Editing]], the final step in which the information collected in steps three and four is used to produce the final draft.
== Documentation and agile development controversy ==
| 