1. Web policies
Here we define the policies of www.gnome.org. This is a key planning document that depends only from the GnomeWeb/WgoScope and affects any implementation.
Changes in this document might imply a revision of the GnomeWeb/LayoutPlanning, the GnomeWeb/LooknFeel, the GnomeWeb/CmsRequirements and the GnomeWeb/Localization.
Contents
1.1. Address and naming policies
URIs should be simple and easy to understand, remember and type for our users. They should also build up a logical document hierarchy where there the documents can be placed and found without much cognitive work by the users. The path and query part should not be like: /index.php?pageid=1545353 or /portal/page?_pageid=33,31321&_dad=portal&_schema=PORTAL. More like /support/tutorials/guide_to_garnome or /news/2006/large_deployment_to_local_schools.
URIs should be:
- short
- easy to read
- easy to remember
- unique
- reflecting the document hierarchy
Related reading:
1.2. Format policies
The website should conform to certain standards, to enforce consistency among browsers and accessibility for users and search engines. It is obvious for the GNOME web site to conform to the XHTML and CSS standards, and it is important that all parts of the site will do this, also the parts made by content management systems or wikis. We should support all major browsers and versions, and not avoid the standards if there are workarounds that we will use for the major browsers not complying to the standards. The content and design should be completely separated, in ways that we use semantic web elements (such as em, strong and code) instead of styling elements (such as i, b or tables for layout). It is also a good habit to encode meta information (such as author, copyright), preferably in Dublin Core tags. Where documents consist of multiple pages, the pages should be linked together (with previous, next and toc links). The site should also strive to conform to the Web Content Accessibility Guidelines, that focuses on usability for people with some sorts of functional disabilities. It must work for people and devices with small screen resolution, such as handheld devices. The documents should also be made available in alternate versions for printing or feeds etc.
The documents should
- conform to XHTML1.0 Strict
- conform to CSS2.1
- be marked up with semantic structure
- allow referencing page fragments
- contain meta information (in Dublin Core, when one of those 15 tags fits the purpose)
- link to the neighbor documents when they are part of larger documents
- provide alternate versions for printing and rss-feeds
- be usable for people not using a mouse or a keyboard
- be usable for blind people and people with reduced sight
- be usable on handhelds and other devices with small screen resolution
- be tested with validators during development
Related reading:
1.3. Content policies
The user pages should be easy to read, and your children or grandma should be able to understand the vocabulary. Our message should be clear, both in terms of readability and marketing. The text should be made understandable for people not having the particular language as their primary language. Even the translated languages, as many of those are easier to understand than english for many users throughout the world. We cannot make such restrictions on the developer pages. If we will ever have business pages or pages for other groups, write for those users. Always keep your users in mind when writing.
The pages should be direct and informative, not telling too much about what you will find on every page or the subpages, but contain more of the information directly. The design of the pages should be made simple, so that the users does not get overloaded with lots of unrelated information.
User pages should be easy to read, by
- using a simple vocabulary
- having a clear message
- being written in second person (to you, the reader)
- keeping the translated text as simple as the original
- having a structured and simple layout
- not containing irrelevant information
- not explaining too much about content
- having usable links (not "click here" etc.)
Related reading:
1.4. Authoring policies
Pages should have responsible maintainers that have the time to update the information, and the pages should contain contact information. Generic lists addresses are more reliable than personal addresses, and those should be used. The pages should also contain information about their status (draft, current, deprecated, obsolete), and this status should be made more visible by using graphical elements such as symbols or colors. Also the pages should contain information about their last change, as a last resort for people wanting to know if the page is outdated. Some information about the last editor should be maintained, as that person possibly is the one to make new updates as well.
On www.gnome.org, only updated pages should be visible for users. If a page is outdated either we update it or we unpublish it. Deprecated subsites should be made unavailable to search engine crawlers. Drafts should only be accessible to users with permissions, such as editors, reviewers or translators.
Pages should
- be made unavailable if they are not updated
- be available only to editors (and other privileged users) when they are not in published state
- have a responsible editor (maintainer) or a small editor group
- provide contact information (email address) to the maintainers
- indicate authoring status
- show information about the last change
1.5. i18n policies
Pages on www.gnome.org should be available in multiple languages, and the users should easily be able to view the page in another translated language. The language should default to language settings in the browser, and if a user chooses another language in the web interface, this language setting should be made persistent. It should be easy for existing translators to translate the site, and the translators should be able to view the last changes done in a page, to see what updates are needed. To get as many existing translators as possible to translate the site, it should have translation mechanisms integrated with the existing GNOME translation tools.
Pages should:
- be accessible in multiple languages
- provide a list or drop down menu where the user can select from the other languages that the page is translated to
- default to language settings in the browser that users can override
- be easy to translate for existing translators
- have some sort of showing what has changed and needs to be updated in the translations
- be translatable in existing translation tools
1.6. Design and theme policies
The styling and theming should use logos that are compliant with the logo guidelines and should be inspired by and use colors from the default desktop theme, Clearlooks. When the brandbook reaches some final state and is accepted by the board, www.gnome.org should strive to comply to this. If the default desktop theme later uses Tango colors, the web interface should also convert. The design should have a fluid layout to fit different window and font sizes, to support mobile devices and old monitors.
The style should
- be compliant to logo guidelines and the upcoming brandbook
- be inspired by the current GNOME desktop and the default theme
- use colors from the GNOME Human Interface Guidelines Color Palette, like the default desktop theme does
- be fluid, not having a fixed width, supporting a minimum screen resolution of 800x600 pixels
Related reading:
2. Improve this document
This is an approved document. We invite you to improve it by adding your comments below. Note that this is a key planning document, we might not touch it during the production phase of each release. Only the maintainers of this document can approve changes to it.
2.1. Comments
Just an idea: does it make sense to introduce (meta)tags for pages as a policy? -- QuimGil
I'm not sure what we will earn from this. The most used arguments for using this is that the metatags once was used by the search engines. Newer versions of search engines doesn't give much boost score from these tags anymore. The format policies section already mentions the usage of metatags and Dublin Core. I'm not sure that this is important enough for beeing part of the policies. -- SigurdGartmann
By "(meta)tags" I meant the tags that are being increasingly used in blog posts, that could serve as well as old school metatags. I wonder why the tag coolness should be restricted to blogs, perhaps they can be useful in websites like wgo. A small block somewhere showing the tags can guide newcomers and can be used to offer topic browsing, generate a wgo tag cloud as semantic sitemap... I'm not sure myself how far should we go with this and how useful would it be, but we are in the right moment to decide it, since adding tags to a already created (and translated) site is quite boring.
However, no need to rush. If there is not quick agreement let's leave it for later. -- QuimGil I now understand what kind of tags you mean. This seems to me like a good idea, but there may be a better one out there, so I agree on the «no need to rush» part, and think we should defer this. -- SigurdGartmann
Not for this release, but for the next it would be good to include here well planned policies about subdomains: when it is appropriate to have one and nomenclature of subdomains (i.e. fr.gnome.org - if correct). Perhaps the same could be done with own domains i.e. gnomesupport.org. -- QuimGil
We need a policy about content licenses. -- QuimGil
It isn't practical to require XHTML, since it would have to be sent as text/html to support IE. In doing so, it becomes impossible to take advantage of its features, as all browsers would simply render it as malformed HTML. Overall, I recommend HTML 4.01 Strict for maximal support. Some links that explain this debate in more detail: http://www.hixie.ch/advocacy/xhtml and http://www.webstandards.org/learn/articles/askw3c/sep2003/ -- RickyZhou