Mandriva web guidelines and policies

From Mandriva Community Wiki

Jump to: navigation, search
This page is a draft. It requires improvements.
If you want to contribute, simply click on the edit tab. View the other pages to improve and maintain.
The status of the Mandriva website is that it's a constant work in progress. Back in 2008 it was heavily inconsistent and unbalanced, since then, it's getting reorganized and improved - in architecture, design, platform, copywriting, localization, quality. This documentation is primarily intended to the Mandriva webteam as well as Mandriva partners webteams, but it's likely to be of some help form community web developers, designers, users. It is to be used as a set of reference guidelines.

Contents

Goal

@todo define website goals: inform about mandriva products, downloads, purchases, feedback, support & training services, community actors self-recognition and activities fostering, every user personal profile and needs recognition and information.

Content

Site map

There are 8 main spaces:

  1. Mandriva main
    • news - blog
    • company info (history, profile, people, jobs, contact, investors, legal docs, etc.)
  2. all products available - with info about who/how to use these
    • One/Free/Powerpack, Flash, Click'n Backup, Mini, Enterprise Server, Pulse, etc.
    • (howtos, tutorials, product events)
  3. Store where to purchase Mandriva products, services and other related relevant stuff
    • Online purchases & retail
    • (specific howtos, customer care)
  4. Downloads space, where to get all Mandriva/3rd parties downloadable software, public or private, especially:
    • Free, One, Powerpack, Flash rescue/upgrade ISOs, Enterprise Server, Pulse
    • (other downloads)
  5. Support space where to find information about products support and available services, both for pro and non-pro users
  6. Professionals portal, guiding enterprise users
    • Enterprise Server, Pulse
    • Education solutions
    • OEM solutions
    • Training
    • Consulting
    • Partners
  7. Community portal, mashing up several sources of info related to community and guiding people through:
    • Manifesto, forum, the wiki, planets, Assembly space, Labs (R&D), contribution guidance
    • Developers & technical contributors area (guides, docs, tools - bugzilla)
  8. Personal panel with all information
    • user profile
    • subscriptions
    • machines, purchases, support incidents, groups, networks

Plus one specific item, site wide search (not yet available, in the works)

8 spaces is a lot. It should not be made more global spaces available. Furthermore, we could reduce these

Navigation

All parts of the web site use the very same global navigation bar at the top. All parts have not been upgraded yet (regarding design or navigation); but it's getting better and better. See "Design" below.

One of the biggest issue on the previous website revisions was the lack of a consistent navigation scheme between all available parts of the website. Here our navigation bar proposes a revised, lighter contents tree, supported by a normalized design, to be used on every such zone:

  • each zone publishes all first-level tabs (one zone = one tab),
  • each zone publishes its own second-level tabs, in a common way with other zones,
  • the very same code and design is used through all platforms (made available through a centralized webservice).

Domains & URLs

@todo

  • transition addresses (www/www2 thing)
  • domain ownership mandriva.* mandrivalinux.* mandriva-linux.* mandrivausers.*
  • canonical addresses & redirection rules:
    • mandriva.fr => mandriva.com/fr
    • mandrivalinux.fr => mandriva.com/fr/linux
    • etc.

authoring and localizing (new cms tool)

community integration

search

Tools

  • delivery
  • code standards: (x)html, css, js, svg, accessibility, usability)
  • protocols standards
  • qa procedures & web tools (link checker, doc correctness, doc updates)

"keep it demonstrative, current and useful"

Design

We rely on YUI CSS (reset, fonts, grids) as a foundation for our layout & typography works for this run. We default to a fixed 974px width, centered page layout. You may use http://developer.yahoo.com/yui/grids/builder/ for help.

A common stylesheet is being written for the whole website. The reference may be found with these two:

(yep, ugly ones, but that's what we have to this day)

  • layout (YUI-based)
  • typography (provided by global stylesheet nav3.css)
  • color palettes (@todo)
  • logos (sources + do/do not), brand guidelines

Roadmap

Here is an uncomplete, indicative list of rough milestones for the mdv webteam: @pending:

  • better l10n for website/store (fr/en ok; es/br almost; others pending)
  • moving all stuff from old platform (www) to new one (www2)
  • forum migration (next)
  • store upgrade setup
  • unified user profile page
  • users maps and activities
  • expert upgrade (get satisfaction? zendesk?)
  • hcl upgrade + code public release
  • user auth: oauth/openid, bugzilla integration
  • start code public release + activation of custom feeds
  • guidelines/policies definition (above)
    • contents/navigation redesign
    • new mdv style book

@done:

  • store update (design) & upgrade (code)
  • download area redesign (done - first round)
  • wiki upgrade (done)
  • vignette update (done, cancelled)
  • blog upgrade (done, design update pending)

@todo

Below is old content that needs to be reorganized & rewritten. Soon.


Old notes to be sorted out

Country/language distribution

People want to access information in their own language. But they as well want information that can be locally relevant to them.

On one hand, we are distributing a product that is available in many languages, and the language distribution of contents makes sense. On the other hand, we have a commercial entity with many local representative entities for sales, services (support, training, consulting, etc.) both for home users and corporate customers.

A basic solution would be to localize everyhing per language, only. But that would mean that, once a user chose her language on the website, when coming to services, sales or piece of news that makes sense with geography, we would need to state everything available worldwide, more over, translated in all languages we have. For instance, a training session available in Paris, France, would be advertised on the French speaking website available to French Caledonians; or, a sales packages would be available in Euros to French-speaking people, although they are in Québec.

Communicating locally to people with a country targetted URL would make it obvious to people: go to mandriva.com/fr to get French (country) contents. We could have an override mechanism that makes mandriva.com/be contents depending on the /fr ones, but for contents specific to Belgium.

But what if people go directly to mandriva.com? The only hint we may have is the browser default language settings, which may give a local information, may not: only language in this case.

So as some suggested, we may split things this way:

  • a corporate zone on one hand, localized per country (so local entities are available in a consistent way) and language;
  • a community zone on the other hand for contents that are more relevant when based on language only.

What that requires are:

  • a navigation tree that addresses both country- and language- dependency (and going from one to another)
  • people to properly link to the right country/language zone when needed (that is, when on tne French or Belgium website, link to French-speaking contents, not English ones).

To be discussed, still.

Global/local contents/strategy

Related to the above part. Need to wait the partners meeting to detail this part.


Main publishing solution

Most CMSes we bumped into (we may have missed some, or missed the point) and that did not fit our basic need had this in common:

  • were database based (that is, most of the time, all documents contents and formats were strictly defined; which can be a good idea in some cases, may not in others; in our experience, XHTML is a good enough format for web documents publishing _and_ storage);
  • had no, or way too complex templates;
  • wanted to implement publishing workflow in an overly complex ways for people that do not need them (hint: because you think you need it does not mean you do);
  • wanted to do too much; that is, being a CMS, being a database, being a framework, etc.

We do not say, neither think that CMS (and our current one) are bad. They are great tools, the best reason being many people use it successfully, and do what they want with it. We just say that we are having serious with it, and would prefer to come with a more satisfying solution, tailored to our needs, flexible enough to grow as we do.


Basic needs

Actually, we ended up with some basic needs:

  • we master HTML/CSS/Javascript editing; we want to; we need to;
  • we need to be able to publish whatever we want, the way we want, within a consistent design;
  • we need to organize the contents as we want, in a reliable, stable, sustainable way (that won't be changed again in two years: stable, permanent, simple URLs);
  • we want a navigation menu/tree independant from the CMS itself (because we are dealing with many different web platforms), so it can be included "on demand" by each platform, with little code;
  • we want to have (take advantage of) valid, accessible, simple documents from the beginning to the end;
  • we want the documents to be editable as much as needed (so we can tweak the HTML, CSS, pictures or Javascript), without being bothered by the underlying publishing platform;
  • we want to be able to plug scripts here and there, when necessary and useful; that does not mean it will be ugly and unmaintainable;
  • we do not want to learn a new publishing language again (like, a wiki syntax, an unreliable wysiwyg editor or an exotic xml format); HTML is good enough;
  • we want multiple users to have access on it, parts of it;
  • we want versioning; branching;
  • we would like to separate the edition process from the publishing one (that is, not everything on the same server(s));
  • it has to be easy, so that skills to fix it, if needed, mostly relate to webmastering ones;
  • it has to require a little mastery, so that nothing obviously broken gets published (or it gets fixed quickly);
  • we don't need to have repetitive tasks;
  • we need to automate all we reasonably can (checking website against consistency/quality/scenario rules), still keeping flexibility;

That is for the technical part.

For the content design and management:

  • we want to localize it per country first, not per language; because, on the corporate side, we have several local representative partners (for sales, support and services); they already manage their own website, and we want to gather all these into a single brand/design/navigation; that does not exclude from making some parts of the website language based (there are);
  • we want to focus on it, and help the user focus on it, that is, not distract the user with out-of-context stuff;
  • we do not want to duplicate it through the web site: the one place is the most relevant one; that does not exclude summaries;
  • we want a consistent structure, consistent paths between each country trees (/fr/downloads & /de/downloads eg;
  • we want a reference/pivot content tree, with a mandatory part (each other country zone must have it), and a free part (for local specificities);
  • we need to find a good coordination process between editors/translators/developers.
  • we want to articulate in an efficient manner communities parts and corporate parts:
    • some resources should be mostly community-driven: forum, wiki documentation,


Candidate concept

The best option we found at this point is to:

  • rely on trust, conventions, people skills and practices, and automated tools;
  • rely on known, working systems that require low maintainance (SVN, rsync, mail notifications, continuous test/integration tools - see mira)
  • use mostly simple HTML documents to publish the base contents; not preformatted documents, database fields, or exotic XML formats; HTML is good enough;
  • use light and clever scripts to handle summary documents, data-displaying pages, as well as the final layout and design touch if needed;

These two last points allow globally applied style as well as very specific styles as well, in the most flexible way, which is, in my point of view, good, granted that the webmasters ensure the consistency of documents formats.

  • organize contents in a file hierarchy;
  • put all this in a subversion tree where we can manage people access rights and versioning;
  • at a later time, have a higher level interface (db indexing, graphical editing) to enable people that can not edit html files to input information in it.

It really looks like "web 1.0". Again, we may have missed the point, but after having discussed it with people using a similar approach, we could not find a blocking issue with such a concept, in particular when we are aiming at simplicity and long-term maintenance + full mastering of the website contents.

If your opinion differs, you are more than welcome to state it on the web-discuss mailing-list. We're definitely open to improve our process, but not at the cost of too much maintenance cost or loss of control.


Things to keep in mind

Publishing is not a tool, it is a craft. Do not believe you will find a tool to replace someone's job; a tool may just help the artist, skills and mastering are still needed. No artist: no art. Simple as that. You want quality content on the web. Then put quality and competent people in charge of it.

A CMS may help people to publish information and documents. It happens, though, that publishing requires fine placement, content design and careful copywriting, if not some programming for dynamic or clever information display. In a technical environment as ours, a CMS should then only be a tool for non-publishing people to register their content and submit those to publishing-people.

The tool must not be in the way of people.

Sure, we need something to register, index and organise the contents, and automate the publishing process. But it must stay simple and obvious for the publishing people. The inside of the engine may be complex, the interface and the access to data must be obvious.

Have a flexible, open solution, non exclusive

You will always need a way to do things differently, in a more brute manner (like, instead of using the publishing mechanism of a CMS, having a direct access with a single HTML document, or a single PHP script to a given URL).


Typical workflow we could have, bottom up

Note this is a copy from a draft, unrelated publishing workflow. Needs to be refined and rediscussed in our case.

  • [anyone] original content is suggested/provided by authors: copy, pictures, movies, sounds, directions, etc. anything relevant to the message;
  • [webmaster or designer/integrator] pages integrated and checked by webmaster/designer - goal: validate the content integrates into the website style/quality/copywriting guide and fits in the right place (keywords: design, typography, language, scripting)
  • [webmaster] if validated, pages are integrated in the website, checked and get published;
  • translators are notified to update their trees;

This makes a total of 4 roles, with 2 really specific to this workflow (whose jobs may contain other related tasks):

  • authors (anyone)
  • webmaster/editor (dedicated to web communication)
  • art director
  • integrator (dedicated to web publishing)


Comments about the current situation

From blog posts, others.

Retrieved from "http://wiki.mandriva.com/en/Mandriva_web_guidelines_and_policies"
Personal tools
Fund the Mandriva Linux project
In other languages