Politique et directives des sites Mandriva
De Wiki de la communauté Mandriva.
Si vous voulez contribuer, cliquez simplement sur l'onglet modifier. Consultez également les autres pages dont le contenu est à réviser.
Sommaire
|
Objectif
Buts du site : information au sujet des produits Mandriva, téléchargements, achats, retours d'expérience, assistance et services de formation, auto-identification des acteurs de la communauté et promotion des activités, reconnaissance et renseignement des besoins et profil personnel de chaque utilisateur.
Contenu
Carte du site
Il y a 8 espaces principaux :
- Mandriva principal
- news - blog
- infos de la société (histoire, profil, personnel, jobs, contact, investisseurs, documents légaux, etc.)
- tous les produits disponibles - avec des informations sur qui/comment les utiliser
- One/Free/Powerpack, Flash, Click'n Backup, Mini, Enterprise Server, Pulse, etc.
- (howtos, tutorials, manifestations promotionnelles)
- Boutique où acheter les produits Mandriva, services et autres marchandises associées
- Achats en ligne & détail
- (howtos specifiques, service client)
- Espace Téléchargements, où obtenir tous les logiciels téléchargeables de Mandriva/Parties tierces, publics ou privés, particulièrement :
- Free, One, Powerpack, Flash rescue/upgrade ISOs, Enterprise Server, Pulse
- (autres téléchargements)
- Espace Assistance où trouver l'information concernant les produits l'assistance et les services disponibles, à la fois pour les utilisateurs professionnels ou non.
- informations de sécurité sur les produits et updates
- informations sur le cycle de vie des produits
- base de données de la compatibilité matérielle
- Expert
- Portail Professionels, guide des utilisateurs professionnels
- Enterprise Server, Pulse
- Solutions pour l'éducation
- solutions OEM
- Formation
- Consulting
- Partenaires
- portailCommunautaire, mélange de plusieurs sources d'information relatives à la communauté et aide des personnes au travers de :
- écran personnel avec toutes les informations
- profil utilisateur
- souscriptions
- machines, achats, incidents du support, groupes, réseaux
Plus un espace spécifique : recherche sur tout le site (pas encore disponible, en cours)
8 espaces, c'est beaucoup. Il ne devrait pas y en avoir d'autres, et mieux : on pourrait réduire ceux-là.
Navigation
Toutes les pages du site web utilisent exactement la même barre de navigation en haut. Tout n'a pas encore été mis à jour (en ce qui concerne la conception ou la navigation); mais cela s'améliore. Voir "Conception" ci-dessous.
Un des plus gros problèmes sur le précédent site web était le manque d'homogénéité de la navigation entre les différentes parties du site. Ici notre barre de navigation propose un contenu arborescent révisé et plus léger, d'une conception normalisée, pour une utilisation dans chaque zone :
- chaque zone présente tous les onglets de premier niveau (une zone = un onglet)
- chaque zone présente ses propres onglets de second niveau, de façon analogue avec les autres zones
- exactement les mêmes codes et conceptions sont utilisés pour toutes les plate-formes (rendus disponibles par un service web contralisé)
Domaines et URL
à faire
- adresses transitoires (www/www2 quelque-chose)
- domaine de propriété de mandriva.* mandrivalinux.* mandriva-linux.* mandrivausers.*
- adresses canoniques et règles de redirection :
- mandriva.fr => mandriva.com/fr
- mandrivalinux.fr => mandriva.com/fr/linux
- etc.
Création et localisation (nouveaux outils cms)
Intégration de la communauté
Recherche
Outils
- livraison
- code standards: (x)html, css, js, svg, accessibilité, utilisabilité)
- protocoles standards
- procédures AQ et outils web (vérif des liens, correction documentaire, mise à jour documentaire)
"le garder démonstratif, actuel et utile"
Conception
Nous comptons sur YUI CSS (initialisation, polices, grilles) comme base pour nos arrangements et typographies de travail. On fixe comme valeurs par défaut une largeur de 974px, page centrée. Vous pouvez utiliser pour vous aider http://developer.yahoo.com/yui/grids/builder/.
Une feuille de style commune est en cours d'écriture pour tout le site. La référence peut être trouvée ici :
- http://webapps.mandriva.com/style/nav/style/nav3.css
- http://www2.mandriva.com/g/style/default/base.css
(yep, c'est moche, mais c'est tout ce que nous avons aujourd'hui)
- layout (YUI-based)
- typographie (fournie par la feuille de style générale nav3.css)
- palettes de couleur (à faire)
- logos (sources + faire/pas faire), directives des marques
Feuille de route
Voici une liste incomplète, indicative de jalons à l'état brut pour l'équipe web de Mandriva :
en cours :
- meilleur l10n pour website/store (fr/en ok; es/br presque; autres en cours)
- déplacer tout le contenu de l'ancienne plateforme (www) vers la nouvelle (www2)
- migration du forum (suivant)
- paramétrage de la mise à jour du store
- page de profil utilisateur unifiée
- (NdT ??? users maps and activities)
- évolution d'expert (obtenir satisfaction ? bureau zen ?)
- évolution hcl+ mise à jour du code public
- (NdT ??? user auth: oauth/openid, bugzilla integration)
- commencer la mise à jour du code public + l'activation des fils de syndication personnalisés ?
- définition des directives/politiques (ci-dessus)
- reconception contenu/navigation
- nouveau livre de style de mdv
fait
- mise à jour du store (conception) et évolution (code)
- reconception de la zone téléchargement (fait - premier tour)
- évolution du wiki (fait)
- (NdT ??? vignette update (done, cancelled))
- évolution du blog (fait, mise à jour de la conception en cours)
à faire
- démarrer mira (outil de vérification de la cohérence d'un site web) et intégrer les règles locales/orthographe
- s'intéresser à l'accessibilité. Vérifier http://www.w3.org/WAI/intro/wcag.php et http://www.w3.org/WAI/quicktips/Overview.php
Ci-dessous est l'ancien contenu qui nécessite d'être réorganisé et ré-écrit. Vite.
Anciennes notes à trier
Pays/langue de la distribution
Les gens veulent un accès à l'information dans leur propre langue. Mais ils veulent aussi une information qui leur soit localement pertinente.
D'un coté, nous distribuons un produit qui est disponible en de nombreuses langues, et la langue de distribution de contenus est importante. D'un autre coté, nous avons une entité commerciale avec beaucoup de représentants locaux pour les ventes, les services (assistance, formation, consulting, etc.) à la fois pour des utilisateurs privés et des clients en entreprises.
Une solution générale pourrait être de tout localiser en fonction de la langue uniquement. Mais cela signifierait que, une fois que l'utilisateur aurait choisi sa langue sur le site web, venant ensuite s'intéresser aux services, aux ventes ou aux nouvelles, ceux-ci soient géographiquement pertinents, nous aurions besoin de tout rendre disponible au monde entier, de plus, traduit dans toutes les langues que nous utilisons. Par exemple, une session de formation disponible à Paris, France, serait proposée sur le site parlant français accessible aussi par les calédoniens ; ou, un article en vente serait proposé en Euros aux personnes parlant français, bien que vivant au Québec.
Communiquer localement avec des gens utilisant une URL reliée à un pays pourrait sembler évident : aller sur mandriva.com/fr pour obtenir des contenus français (le pays). On pourrait avoir un mécanisme de dérivation qui rende le contenu de mandriva.com/be dépendant de celui de /fr, sauf pour les contenus spécifiques à la Belgique.
Mais qu'arrive t-il si les gens vont directement sur mandriva.com ? Le seul élément que nous pouvons connaître est la langue par défaut du navigateur, ce qui peut donner une information sur la localisation, ou peut-être pas, nous n'avons dans ce cas, que la langue.
Ainsi, comme certains l'ont suggéré, nous pouvons séparer les choses comme ceci :
- d'un coté une zone générale, localisée par pays (ainsi les entités locales sont disponibles de façon cohérentes) et langue ;
- d'un autre coté une zone communautaire pour les contenus qui sont plus pertinents s'ils ne sont basés que sur la langue
Ce que cela requiert :
- une arborescence de navigation qui pointe à la fois sur le pays et la langue (et qui va de l'un à l'autre)
- des gens pour relier correctement sur la bonne zone de pays/langue si besoin (c'est-à-dire, sur le site français ou belge, relier au contenu en français, pas en anglais).
Devant être encore discuté.
Contenus généraux/locaux - stratégie
Rapporté dans le chapitre ci-dessus. Besoin d'attendre la réunion des partenaires pour détailler cette partie.
Solution pour la publication principale
La plupart des CMS que nous avons testés (on a pu en oublier certains, ou pas compris leur intérêt) et qui ne satisfont pas nos principaux besoins ont ceci en commun :
- ils sont basés sur une base de données (c'est-à-dire, la plupart du temps, tous les documents, contenus et formats étaient strictement définis ; ce qui peut être une bonne idée certaines fois, mais pas d'autres ; de notre expérience HHTML est un format suffisamment bon pour la publication et la conservation des documents web.
- n'ont pas de modèles, ou de façon trop complexe ;
- imposent l'implémentation du traitement automatisé de la publication de façon bien trop complexe pour des gens qui n'en ont pas besoin. (sous-entendu : penser en avoir besoin ne signifie pas que c'est vrai).
- veulent en faire trop ; c'est-à-dire être un CMS, être une base de données, être une structure, etc.
Nous ne disons pas, ni ne pensons que les CMS (et le nôtre actuellement) sont mauvais. Ce sont de bons outils, la meilleure preuve étant que beaucoup de personnes les utilisent avec succès, et font ce qu'elles veulent avec. Nous disons seulement que nous avons de sérieux problèmes avec et préférerions venir avec une solution plus satisfaisante, taillée sur mesure, suffisamment flexible pour grandir avec nous.
Besoins essentiels
En fait, on arrive avec quelques besoins essentiels :
- on pilote l'édition HTML/CSS/Javascript ; on le veut ; on en a besoin ;
- on veut être capables de publier ce que l'on veut, de la façon qu'on veut, au sein d'une conception cohérente ;
- on veut organiser les contenus comme l'on veut, de façon stable, fiable et durable (cela ne sera pas changé dans 2 ans : URL stables, permanentes et simples).
- on veut un menu/arborescence de navigation indépendants du CMS lui-même (parce qu'on gère plusieurs plate formes web différentes), aussi, ils doivent pouvoir être inclus "à la demande" par chaque plate-forme, avec peu de code.
- on veut avoir (tirer avantage) des documents valides, accessibles, simples du début jusqu'à la fin ;
- on veut des documents aussi souvent éditables qu'on le souhaite (ainsi on peut améliorer les HTML, CSS, images ou Javascript), sans être ennuyé par la plate-forme de publication sous-jacente.
- on veut pouvoir insérer des scripts ici ou là, "quand c'est nécessaire et utile" ; cela ne signifie pas que le résultat devienne horrible et impossible à maintenir ;
- on ne veut pas encore apprendre un nouveau langage de publication (comme une syntaxe wiki, un éditeur wysiwyg pas fiable ou un format xml exotique) ; HTML convient ;
- on veut que de multiples utilisateurs y aient accès, ou à des parties ;
- on veut la gestion des versions, des ramifications ;
- on aimerait séparer le processus d'édition de celui de publication (c'est-à-dire, pas tout sur le même serveur)
- il doit être facile, pour que les compétences nécessaires à sa réparation, si besoin, soient celles du webmestre ;
- il doit exiger peu de maîtrise, afin de ne pas publier quelque chose de manifestement détruit (ou bien il est rapidement réparé) ;
- on n'a pas besoin de tâches répétitives ;
- on a besoin d'automatiser tout ce qui peut l'être raisonnablement vérifier le site dans ses règles de cohérence/qualité/scénario), tout en conservant sa flexibilité ;
Ceci concerne la partie technique.
Pour la conception et la gestion du contenu :
- nous souhaitant une localisation par pays, et non par langue; du coté entreprise, nous avons plusieurs partenaires locaux qui nous représentent (pour les ventes, le support et des services); ils gèrent déjà leur propre site Internet, et nous souhaitons regrouper tous ces différents sites en une seule et même branche/conception/navigation; ceci n'exclut pas de faire certains parties du site basées sur une langue (s'il y a);
- nous voulons nous concentrer dessus, et aider l'utilisateur à se concentrer dessus, ceci dit, ne pas distraire l'utilisateur avec du contenu hors sujet;
- nous ne voulons pas le dupliquer à travers tout le site : la place unique est la meilleur des places; ceci n'exclut pas les résumés;
- nous voulons une structure consistante, des chemins consistants et logiques pour chaque arbre de pays (/fr/downloads & /de/downloads par exemple);
- nous voulons un arbre de contenu pivot/référence, avec une partie obligatoire (chaque pays doit l'avoir), et une partie libre (pour les spécificités locales);
- nous devons trouver un bon processus de coordination entre éditeurs/traducteurs/développeurs.
- nous voulons articuler le site d'une manière efficace, pour les parties communautaires et les parties entreprise:
- la plupart des ressources devraient être conduites par la communauté : forum, documentation, wiki...
Concept pressenti
Note d'un lecteur (ptyxs) : je n'ai pas la moindre idée de ce que signifie "concept pressenti".
La meilleure option que nous avons trouvée jusqu'à maintenant est de :
- s'appuyer sur la confiance, les conventions, les compétences et pratiques des gens, les outils automatisés ;
- s'appuyer sur des systèmes opérationnels connus qui nécessitent peu de maintenance ((SVN, rsync, notifications de courrier, essais continus/outils d'intégration - voire mira)
- utiliser de simples documents HTML pour publier les contenus de base ; pas de documents pré-formattés, de champs de base de données ou de formats xml exotiques ; HTML est suffisamment bon ;
- utiliser des scripts clairs et bien construits pour manipuler les documents récapitulatifs, les pages de données, ainsi que la disposition finale et la touche de style si nécessaire.
Ces deux derniers points permettent aussi bien l'application d'un style général que de styles très spécifiques, de la façon la plus flexible, ce qui est, à mon point de vue, bon, à la condition que les webmestres assurent la cohérence du format des documents.
- organiser les contenus dans une hiérarchie de fichiers ;
- mettre tout cela dans une arborescence subversion où l'on peut gérer les droits d'accès des gens et le versioning ;
- plus tard, avoir une interface de haut niveau (indexation des bases de données, édition graphique) pour permettre aux gens qui ne savent pas éditer les fichiers html de pouvoir y ajouter des informations.
Cela ressemble vraiment au "web 1.0". A nouveau, on a pu manquer notre objectif, mais après en avoir discuté avec des gens qui utilisent une approche similaire, on ne voit pas de problème bloquant avec ce genre de concept, en particulier quand on vise la simplicité et la maintenance à long terme + la maîtrise totale des contenus du site.
Si votre opinion diffère, vous êtes le bienvenu pour aborder le sujet sur la liste de diffusion web-discuss. Nous sommes tout à fait ouverts à l'amélioration du procédé, mais pas au prix de trop d'une maintenance trop chère ou de la perte de contrôle.
Choses à garder en tête
La publication n'est pas un outil, c'est un métier. Ne croyez pas que vous trouverez un outil pour remplacer le travail de quelqu'un ; un outil ne peut qu'aider l'artiste, les compétences et la maîtrise sont toujours nécessaires. Pas d'artiste : pas d'art. Aussi simple que cela. Vous voulez du contenu de qualité sur le web, alors mettez-y en charge des gens de qualité et compétents.
Un CMS peut aider les gens à publier des informations et des documents. Il arrive, cependant, que la publication exige une fine disposition, un style de contenu et une rédaction soigneuse, quand ce n'est pas un peu de programmation pour un affichage clair ou dynamique de l'information. Dans un environnement dynamique tel que le notre, un CMS ne devrait alors être qu'un outil pour permettre aux personnes non initiées d'enregistrer et de soumettre leur contenu aux spécialistes de la publication
L'outil ne doit pas entraver les gens.
Bien sûr, nous avons besoin de quelque chose à enregistrer, d'indexer et d'organiser les contenus, et d'automatiser le processus de publication. Mais cela doit rester simple et évident pour les personnes en charge de la publication. L'intérieur du moteur peut être complexe, l'interface et l'accès aux données doit être évident.
Ayons une solution flexible et ouverte, non exclusive
Vous pourrez toujours avoir besoin d'une méthode pour faire les choses autrement, d'une façon plus brutale (comme, au lieu d'utiliser les mécanismes de publication d'un CMS, avoir un accès direct avec un unique document HTML, ou un unique script PHP pour une URL donnée).
Processus typique qu'on pourrait utiliser, déroulement ascendant
Notez que ceci est une copie d'un brouillon, sans lien avec le processus de publication. Il nécessite d'être redéfini et rediscuté pour notre cas.
- [quiconque] le contenu original est suggéré/fourni par les auteurs : copie, images, vidéo, sons, directions, etc. toute chose en rapport avec le message ;
- [webmestre ou styliste/intégrateur] pages intégrées et vérifiées par webmestre/styliste - objectif : valider le contenu, intégration dans les directives de style/qualité/rédaction du site web et arrangement correct de la disposition (mots clés : conception, typographie, langage, script)
- [webmestre] si validé, les pages sont intégrées dans le site, vérifiées et publiées ;
- les traducteurs sont invités à mettre à jour leurs arborescences ;
Cela fait un total de 4 rôles, dont 2 vraiment spécifiques à ce processus (dont le travail peut comporter d'autres tâches en rapport) :
- auteurs [quiconque]
- webmestre/éditeur (attaché à la communication sur le web)
- directeur artistique
- intégrateur (attaché à la publication sur le web)
Commentaires au sujet de la situation présente
En provenance du blog
