| A: | Two reasons. First, because John is very interested in single-sourcing from XML and wanted to learn how to use a range of XML-related technologies (DocBook DTD, Website DTD, XML, XSLT, XML parsers, XML editors, and so on). It was a satisfying challenge to get a few relatively complex technologies to work together. Second, it's very easy to maintain. Once the XML structure is in place, you can add, update, and delete pages, and then recreate the website in seconds. Creation is fast and automated. An added bonus is that links between pages are automatically maintained. |
| A: | Here are just some of the things I do. First and most importantly, I talk to the client to understand the
scope and constraints of the project. Also, if there are any acceptable
tradeoffs (for example, among time, money, resources, deliverables, and
quality). Next, I gather information from as many sources as possible (for
example, proposals, design documents, business plans, project plans,
specifications, even old documentation if appropriate). I read, analyse,
and synthesise the information. I find out who the project stakeholder
are and, if possible, interview them. If available, I use the hardware
or software and find out for myself how it works. I start sketching out
publication plans for the required documentation. Starting and
continuing a project is an iterative process. Finally, I start putting everything together. |
| A: | You must understand something about the project you're working on before talking to software developers, mainly because they are usually very busy people under tight deadlines. It's essential to know what you want and to know what you don't want. Prepare a series of tightly directed questions. Arrange a mutually convenient time. Be prepared to take plenty of notes. Be prepared to probe to get the answers you need. Summarise afterwards and double-check that you've got "the truth, the whole truth, and nothing but the truth" - an email message is good for this purpose. |
