Clear and Concise

The article highlights a shift in the approach in product documentation (particularly in smaller startups)  from commercial software like Microsoft Word and Adobe FrameMaker were the industry standards. The trend is now towards open-source alternatives like Apache OpenOffice and LibreOffice. View Publication

Modern web applicatiox (such as Google Docs) implement many coordinated user functions and tasks traditionally associated with desktop software (such as Microsoft Office).. Key topics include: • Differences between modern web apps and traditional desktop software. • Open-Source Standards: The use of JavaScript, HTML5, and CSS. • MVC Architecture: Separation of concerns into Model, View, and Controller. • Single-Page Applications (SPA) enhance user experience without full page reloads. • Microservices: Breaking applications into smaller, independent services. • Responsive Web Design: Ensuring web apps work on various devices. • Web Services: Using REST and SOAP for server-side communication. The article also includes references and examples for further reading.  View publication

The impact on documentation is huge when project teams adopt agile practices to plan and deliver products and services. Key Takeaways: Agile Principles and Technical Documentation: Agile development prioritizes working software, collaboration, and adaptability, which significantly impacts technical documentation. Shift from Formal Specifications: In agile, writers must rely on working software, not formal specifications, to create documentation. Dynamic Documentation: Agile emphasizes creating documentation that is relevant, stable, and continuously updated based on feedback. Audience Analysis: Understanding the target audience is crucial for creating effective documentation. User Stories and Tasks: User stories and tasks provide a structured approach to breaking down documentation requirements. Continuous Delivery and Kanban: Agile's focus on continuous delivery and the use of kanban boards help ensure that documentation aligns with the evolving product. View publication

Contributor to the open source collaboration between Sun Microsystems and Liferay on the Liferay Community Edition  portal software ( https://sourceforge.net/projects/lportal/ ) that combines efforts and technologies from both companies to enhance and maintain web aggregation and presentation technologies. View Publication

I wrote my first blog about my issues with blogs and wikis (specifically blogging to arouse user interest in an early draft of an article). So...after a full month of revisions incorporating feedback from the project team after first posting my article to the wiki, I think the content is now "complete" (or at least it incorporates everything that everyone on the team can think of). Then comes the deafening silence of no responses from the Liferay community...kind of like that saying "If a tree falls in the forest, and no one is around to hear it, does it make a sound?" At first, I’m more than a little discouraged, because wikis (such as the  Liferay Community Edition)   are supposed to be this wave of the future that will bring about the age of collaborative documentation and forever break down the walls between professional technical communicators and the user community But perhaps I’m just being skeptical--it took 20 years before desktop publishing moved from the

I haven’t gotten any feedback on the articles that I posted have posted. But, just for argument\"s sake, I do get comments from users just after I start a review draft of the product documentation (which are based on the wiki articles). Do I incorporate the user comments as part of the product documentation as I would review feedback from the project team? Or should I just collect the user comments and have the product team review them for completeness and accuracy (as is done with bug reports)? In other words, should blog posts on  an open source project be considered as complete and accurate when the product documentation is available separately? Or, more to the point, can a blogreplace the need for separate product documentation? My past experience working on open source documentation projects is that, while blogs are a valuable opportunity to solicit feedback, they cannot replace the need for dedicated writers to create the required task, reference, and conceptual documentatio