Refondre le site web Mandriva

Un article de Wiki de la communauté Mandriva.

Jump to: navigation, search

Main Page < Refondre le site web Mandriva

Début de traduction de la page écrite par Romain d'Alverny : "Rewriting Mandriva's web site".

Nous allons poser à plat notre site Internet de nouveau, chercher nos communautés et nos partenaires pour en discuter, et puis construire quelque-chose de plus utile, accessible, pertinent et agréable à voir.

La discussion interviendra sur la mailing list web-discuss comme d'habitude.

Les sujets suivants sont sur le tapis :

   * accessibilité des contenus 
   * répartition des pays/langues
   * schéma de navigation, les 2 premiers niveaux
   * schéma global du contenu
   * contenus obligatoires
   * contenus locaux/optionnels
   * design
   * plate-forme de gestion de contenu et méthodes
   * autre ?

[modifier] Solution de publication

[modifier] Statut actuel et problèmes

I am not sure that coming from the problems we have with the existing solution will help that much. Why not. The biggest issues we have with our current system, that can be summarized in "it's broken" are:

it takes about half a day to make a lousy page that would have taken about 2 minutes if we had manually done it, with a better result, and most likely as manageable in the long term as a database-stored document + template,
editing/saving is sloooooow and unreliable,
saved contents gets randomly updated/deleted without a notice,
it's a beta version, unsupported, and no one here to dig in it or fix it.

[modifier] Un autre gestionnaire de contenus (CMS) ?

So any valuable alternative solution is welcome. Still, considering alternatives, all 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).

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.

[modifier] Besoins basiques

Actually, we ended up with some basic needs:

we need to be able to publish whatever we want, the way we want;
we need to organize the contents as we want, in a reliable way;
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;
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 XHTML, CSS or Javascript code), 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);
we want multiple users to have access on it, parts of it;
we would like versioning;
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.

That is for the technical part.

For the content design and management:

we want to localize it per country first, not per language;
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 relevant, meaningful, localized paths (like, /fr/telechargement or /uk/download);
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);

[modifier] Concept candidat

The best option we found at this point is to:

rely on trust, conventions, people skills and practices;
use mostly simple XHTML documents to publish the base contents; not preformatted documents, database fields, or exotic XML formats; XHTML 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 xhtml 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.

If your opinion differs, you are more than welcome to state it on the web-discuss mailing-list.

[modifier] Points à garder en mémoire

Publishing is not a tool, it is an art. Do not believe you will find a tool to replace someone's job; a tool may just help the artist. Skills are needed; unless you're talking about playing with toys. 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 most publishing requires fine placement, content design and text rewrite, 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).

[modifier] Principes de Workflow à avoir

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

original content gets set by authors (market, comm, isv, sales, technical, community people); they submit media (picture, video, sound, other) as well, if relevant;
content is checked and validated by an editor in chief, which should validate all steps to ensure consistency of content;
content gets translated by translators;
content gets organised by a webmaster (job is to make sure the content is consistent and in the right place, according to the company publishing rules - as well related to web as to corporate communication guidelines, ready to be published or not);
art director checks in the medias (or propose alternative ones) and the integration with the integrator;
content and design gets integrated by an integrator (job is to integrate all contents and make sure it is consistent and in context; requires skills: design, graphism, xhtml, css, javascript, language typography and l18n, scripting)

Webmaster and editor in chief may be merged in the same role.

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