Rewriting Mandriva's web site

From Mandriva Community Wiki

Jump to: navigation, search

We are going to lay down our website anew, bring our communities and partners to discuss, and build something more useful, helpful, consistent, and beautiful.

As always, discussions will happen on the web-discuss mailing list.

Contents

[edit] Accessibility

Progressive enhancements. Check http://www.w3.org/WAI/intro/wcag.php and http://www.w3.org/WAI/quicktips/Overview.php

[edit] 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.

[edit] Global/local contents/strategy

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

[edit] Global navigation tree

One of the biggest issue on the existing web site, apart from up-to-date contents, is the lack of a consistent navigation scheme between all available zones.

We propose a revised, lighters contents tree, supposed 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.

The current navigation tree we defined is... currently being discussed again internally. Will be posted later.

[edit] Design

To be discussed.

[edit] Main publishing solution

[edit] Current status, issues

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.

[edit] An other 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.

[edit] Basic needs

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; this is 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;
  • 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);
  • we want to articulate in an efficient manner communities parts and corporate parts:
    • some resources should be mostly community-driven: forum, wiki documentation,

[edit] Candidate concept

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.


[edit] Things to keep in mind

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).

[edit] 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.

  • 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):

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


[edit] Comments about the current situation

From blog posts, others.

Retrieved from "http://wiki.mandriva.com/en/Rewriting_Mandriva%27s_web_site"
Personal tools