Where we are today

The Apache OpenOffice project maintains the following web properties today:

What is working well today

• We've successfully migrated and preserved a huge amount of content (over a decade's worth) and brought it over to Apache.
• The CMS mechanism allows us to quickly push out page changes to the website, including site-wide template changes.   The most common site-wide changes can be made efficiently, without touching every page, an important consideration for a website of this size.
• MediaWiki user interface is well-known and accepted by its users.
• Our websites have many backlinks and has high PageRank.  Our content is authoritative and is well-placed in search engine results for most relevant user queries.
• Site-wide integration of Google Analytics has enabled us to track how our sites are being used and provides concrete data for decision making.

Challenges

• Redundancy of services, in particular the multiple wikis and websites.  This fragments content, causes confusion and increases maintenance effort.
• UI inconsistency between our web properties.
• Inconsistency within individual properties, e.g., within the www.openoffice.org website, especially with the NL websites.
• Inconsistency at the markup level as to what HTML version is being targeted, what encodings are used, whether document is even well-formed. In other words, all the liabilities of human-authored HTML.
• In general lack of a consistent information taxonomy that allows the user (or the content author) to know where a given topic belongs on the website(s).
• Perception that website is "tired" and lacks freshness and modern appeal.
• Large amounts of outdated content on website and wiki.
• Lack of consistent, documented best practices and techniques for maintaining NL websites.  What is translated and how?
• Skill mismatch between what translators know and what is actually needed to maintain an NL website.  (Translators are not HTML designers and certainly not CMS experts)
• Similar for potential content authors, the skill level needed to maintain an HTML-based website with the CMS exceeds that of most potential volunteers.
• Sustainability concerns due to our use of unsupported applications (from Apache Infra perspective), including phpBB and MWiki and reliance on a very small number of system admins.

High Level Goals

• Maintain easy-to-find content, up-to-date content that helps visitors research the suitability of OpenOffice for their needs, download and configure OpenOffice, use OpenOffice effectively and troubleshoot/resolve any issues encountered.
• Facilitate the translation of a subset of the user-facing materials into native languages, using technology appropriate for end-user/translators, in a way that allows us to keep the content in sync.
• Provide tools for project members to brainstorm on ideas, collaborate on plans, coordinate on tasks, and report results.
• Introduce a means to engage with the user, rather than merely broadcast information to them.  This could be through built-in feedback/discussion mechanisms, social network integration, etc.
• Ensure the website follows appropriate web standards and best practices localization and accessibility.
• Design and implement a consistent information taxonomy for the web properties to make it easier for visitors to find what they are looking for, and for project volunteers to know where to put things.
• Aim to support mobile browsers and provide a good user experience.  Although the OpenOffice product is desktop-only, it is reasonable for users to want to research, seek support, engage, etc., from any device.
• Enforce consistent branding, notices and look & feel across our web properties.
• Modernize the visual appearance so user first-impressions reenforce our message.
• Consolidate the websites and wikis into the minimal number necessary to accomplish the above.

Specific Tasks to Support Goals

• Consistent branding: see related AOO4 - Websites