I attended several sessions on metrics, including the conference keynote, and a few key points jumped out at me:
The wrong metrics can be worse than no metrics at all
Metrics should be stable over time to allow for tracking
Start by figuring out what decisions you need to make – then gather the metrics you need to make that decision
Showed the results so far to one of the developers yesterday, output to multi-page xhtml, and came away with some useful questions. Selecting the <prolog> and then Help > Show content model – I'm so pleased with my choice of editor – pointed me in the direction of prodinfo and reminded me about critdates, and output to Web Help added navigation and docset search …
All the topics in the test project are now ready: next stage, scrutinise them to see where I can best demonstrate links and re-use. But while I'm grappling with that side of DITA, a whole new potential benefit seems to be dawning – accessible metadata.
Most of the development teams I'm working are quite comfortable with the idea of XML even if they hadn't thought about applying it to documentation. The chance of using custom attributes in the <author> element to have some idea of who provided the information is making them sit up and take notice.
In pursuit of the ultimate techCom information architecture
Why is the result often a million little pieces even though DITA does not encourage authors to chunk information in such a way?
A lot of discussions and confusion in social media has recently, as it seems, dealt with two issues concerning the use of DITA (see for example a discussion in the DITA awareness group on linkedIn or another discussion on LinkedIn or a blog post by Tom Johnson). The first issue relates to the question if topics shall be nested or not, that is, shall DITA topics be kept as separate files or shall authors instead use a <dita> document and nest topics within it?