Where we are today

The Apache OpenOffice project maintains the following web properties today:

Property

Technology

Content size

Usage level

www.openoffice.org

Static pages, mainly HTML, some MDText.
Uses Apache CMS,

19,697 html pages
198 mdtext

Top page (download/index.html) receives 3.5 million visits/month.
Over 5000 pages receive more than 100 visits/month.

openoffice.apache.org

Static pages mainly MDText.
Uses Apache CMS,

49 mdtext pages
4 html pages

155K total page views/month

cwiki.apache.org/confluence/display/OOOUSERS/

Confluence Wiki

~180 pages

Unknown, but mainly active project members, not end-users, though permissions permit public editing.

cwiki.apache.org/confluence/display/OOODEV/

Confluence Wiki

1 page

Unused

wiki.openoffice.org

Media Wiki

11,281 pages

~900K page viewers per month
Over 1300 pages receive more than 100 visits/month

forum.openoffice.org

phpBB

?

?

extensions.openoffice.org

Drupal?

?

?

templates.openoffice.org

Drupal?

?

?

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

  • No labels

1 Comment

  1. Re: "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."

    A thread concerning the wiki from 2011:

    http://markmail.org/message/rksb7blqqwlzh4mh

    mentioned MoinMoin, currently in use for other Apache projects.

    The following links might prove useful for comparison:

    http://www.mediawiki.org/wiki/MoinMoin http://www.wikimatrix.org/compare/MediaWiki+MoinMoin http://moinmo.in/MoinMoinVsMediaWiki