TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: [Techshoret] How to get Android's documentation appearance (http://developer.android.com)
Subject:Re: [Techshoret] How to get Android's documentation appearance (http://developer.android.com) From:Laura Lemay <lemay -at- lauralemay -dot- com> To:SB <sylvia -dot- braunstein -at- gmail -dot- com> Date:Wed, 29 Jun 2011 10:08:08 -0700
I don't know specifically how Google does their android docs -- I haven't worked there. But we did something extremely similar for the developer documentation at Yahoo, and it was all hand-coded in HTML/CSS/Javascript/PHP, with the API reference docs generated out of the code from custom versions of Javadoc and doxygen developed in-house. The entire doc set was built from code and HTML source as if it were an application. Writers were expected to behave like engineers and work in the source, check everything into a source code control system, and do local builds to ensure new edits and changes did not break the overall build. We used no GUI tools more sophisticated than Dreamweaver.
I designed most of this system myself, with the goal to get the docs as close to the source as possible, and to be able to do continuous integration and frequent releases. In my experience it's easier to maintain developer docs if there are fewer people and fewer barriers between the developers and the docs. In this world writers *are* developers, are fully integrated into developer teams, and are using most of the same tools. The tradeoff is that you lose the power of the high-level documentation tools for writing, formatting, review, indexing, and so on. We worked specifically with writers who were comfortable in the code. Obviously this isn't a solution that isn't going to work with a lot of companies, especially those who are still doing "traditional" documentation and help.
Given the very high level of technical geekery at Google, I would assume they are doing something similar and it's all an internally-built custom system.
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-