Gérer des centaines de themes sans poser de probleme de maintenance

Bonjour à tous,

Je suis à la recherche d'une méthode de travail plus qu'un outil technique concernant les thèmes graphiques.
En effet, je vais être amené à avoir des centaines de thèmes graphiques dans mon site web (selon des demandes client) et j'aimerai trouver un moyen pour gérer ces thèmes graphiques sans pour autant gener l'évolution de l'appli. Je m'explique :

Imaginons que le site web soit à une version 1.0 et que je fasse une centaine de thèmes graphiques (css et consorts) pour mes clients.
Imaginons maintenant que je fasse de la maintenance dans mes vues, que je bouge des choses, que j'en rajoute, que j'en supprime, bref, pas mal de changements qui impliquent derriere qu'il faille que je modifie chaque CSS pour :
- ajouter mes nouvelles classes
- supprimer des classes obsoletes
- modifier des classes existantes

Il va de soi que se taper une centaine de themes à modifier à la mimine ca va etre galere...
Je me demandais donc s'il y avait des sortes de best practices pour gérer ça ? Avez vous des idées ?

J'avoue que là je ne sais pas trop vers quoi me tourner
Merci d'avance

Bonjour,

je reformule pour être sûr : tu as une appli avec des centaines de clients et chacun peut la styler comme il veut, à la limite 1 CSS par client ; c'est ça ?
Quelle est leur liberté d'action ?
- changement de couleurs et c'est tout, taille des boutons,
- blocs et éléments de formulaire (boutons) complètement libres à styler
- avec ou sans border-radius, box-shadow, border, padding, etc pour chaque détail ?

Une arme anti-régression, c'est PhantomCSS (sur base de CasperJS (sur base de PhantomJS)). Cet outil est une tuerie.
Avec un script, tu peux faire N screenshots représentatifs de ton appli (sous WebKit) pour chacun des thèmes et dans autant de résolutions que nécessaire (si responsive). Puis tu fais une modif qui a un gros effet de bord dont tu t'aperçois pas tout de suite, mais en relançant le script, lui va refaire des screenshots, les comparer et t'afficher toute différence entre 2 versions. A toi de voir si la différence est attendue...
Y a pas d'outil (à ma connaissance) pour gérer la quantité de screenshots mais rien que de SAVOIR que tu viens de foirer quelque chose avec ta modif
Voir aussi Slimer.JS (équivalent Firefox / Gecko de Casper.JS) et bientôt Trifle.JS pour IE/Trident.

En fait j'ai une partie métier mutualisée.
Les clients l'utilisent et certains nous demandent de customiser leur theme.
On a donc un intégrateur qui, aujourd'hui, lorsqu'il reçoit une demande de customisation, copie colle le CSS de base, le customise et le met à dispo pour le client.
Sauf qu'en faisant ça, On a autant de CSS que de thème ce qui veut dire que quand la partie métier change (html au niveau structure ou autre) on doit se reprendre tous les CSS à la main c'est qui n'est pas top.
Je cherchais justement à voir comment on pourrait amoindrir cette maintenance (css généré à partir de quelque chose, je ne sais pas...)

Exemple tout bete :
On développe une nouvelle fonctionnalité, on doit ajouter 5 classes à tous nos clients. On doit ouvrir chaque css, coller les 5 nouvelles classes, enregister... et ce pour les centaines et les centaines de CSS...

Ce qui m'interesserait serait d'avoir une sorte de CSS de base, un "template" on va dire et qu'on puisse par défaut implémenter ces 5 nouvelles classes dans la CSS dite de template et ensuite customiser si besoin dans les css client.

En utilisant un ordinateur vous pourriez automatiser ce genre de tache avec un script maison, ou sinon il existent des logiciels que l'ont appelle éditeur de texte qui permettent de chercher/remplacer/insérer du texte dans plusieurs fichiers automatiquement...
Modifié par jb_gfx (07 Nov 2013 - 16:45)

Bonjour jb_gfx

Sans vouloir paraître désagréable, merci pour la réponse mais le ctrl+h pour remplacer du texte je connais et ce n'est absolument pas une méthode de travail.
En tant que chef de projet, je me vois très mal conseiller à mon équipe de faire du editer/remplacer...
Pour ce qui est d'un script, j'ai bien une idée en tête (templates T4 - très lié à l'outil Visual Studio de Microsoft) mais j'aurai préféré opter pour une solution standard de base, une best practice de la gestion des themes dans un site web et éviter de réinventer la roue quitte à tomber sur une autre problématique plus tard.
Je ne pense pas être le premier à avoir cette problématique et je pense que le sujet a du être réfléchi depuis et qu'il doit y avoir une méthode bien optimisée pour gérer ça.
En tout cas, ce que je cherche n'est pas une bidouille mais une vraie méthode. merci quand même.

Bonjour,

Une bonne méthode, que je cherche aussi a mettre en place, c'est de standardiser les noms de classes, je n'ai jamais trouvé de document fiable à ce sujet mais à mon avis c'est une bonne piste.

Les frameworks css mettent tous des nom differents, exemple wrapper, container, main pour l'enveloppe principale déjà il y a trois choix ça commence mal, puis ça va en s'empirant, main-menu, top-menu etc...

Ensuite il y a les classes générales là c'est pareil, box, dark-link, button-blue , il y a pas de règles précisent.

Qu'est ce que ça serait bien d'avoir tout les thèmes avec les mêmes nom de classes, déjà ça simplifierais bien la vie, on pourrais même faire des gabarits photoshop avec les calques qui est le nom des classes, les noms des images de fond les mêmes noms, le truc bien clair quoi

J'essaye de faire des choix de nom dans la structure et de m'y tenir à mon avis c'est la bonne méthode pour ton problème, par contre ce serait bien de trouver des vrais références histoire de partir sur des bases durables.

zax-tfh a écrit :
Bonjour jb_gfx

Sans vouloir paraître désagréable, merci pour la réponse mais le ctrl+h pour remplacer du texte je connais et ce n'est absolument pas une méthode de travail.
En tant que chef de projet, je me vois très mal conseiller à mon équipe de faire du editer/remplacer...
Pour ce qui est d'un script, j'ai bien une idée en tête (templates T4 - très lié à l'outil Visual Studio de Microsoft) mais j'aurai préféré opter pour une solution standard de base, une best practice de la gestion des themes dans un site web et éviter de réinventer la roue quitte à tomber sur une autre problématique plus tard.
Je ne pense pas être le premier à avoir cette problématique et je pense que le sujet a du être réfléchi depuis et qu'il doit y avoir une méthode bien optimisée pour gérer ça.
En tout cas, ce que je cherche n'est pas une bidouille mais une vraie méthode. merci quand même.

Je pense que l'incompétence est un vrai problème.

jb_gfx a écrit :
Je pense que l'incompétence est un vrai problème.

zax-tfh n'a pas donné assez de détails pour qu'on puisse juger de sa compétence ou de son incompétence en 3 messages.
N'interviens plus sur ce topic.


zax-tfh > je regrette la tournure prise par ce sujet et ... on en était où ?

L'usage d'un préprocesseur (LESS ou SASS/Compass) et de ces variables permettrait d'avoir un fichier de configuration pour chaque client puis un fichier commun (dans un monde idéal) puis peut-être des fichiers bonus pour chaque client (ou par type de personnalisation), quoique c'est cette partie bonus qui va foutre en l'air la facilité de personnalisation...
L'écueil de LESS/SASS, c'est que c'est un appel à faire des choses super complexes sans plus se soucier des CSS produites derrière (sélecteur de 15 lignes, instructions répétées 50 fois, etc). Ne jamais perdre de vue les CSS que ça compilera...
Si c'est pour modifier des couleurs, c'est génial. Si l'ordre des blocs change d'un client à l'autre ou les largeurs et gouttières, ça sera ingérable. Mais avec trop de libertés de modifs, c'est plus un problème d'outil mais de maintenabilité, rien ne sauvera le pauvre intégrateur.

La méthode OOCSS (présentation par Kaelig) ou BEM (j'aime pas la notation avec ses -- et __ mais c'est pas l'important) sont des méthodes de travail qui scalent.

Salut Felipe,

Merci d'avoir répondu. Pour LESS/SASS, j'y ai déjà jeté un coup d'oeil. Ca a l'air intéressant en effet mais j'avais bien vu la contrainte dont tu parles (les fameux fichiers supplémentaires bien spécifiques qui foutaient en l'air le principe de customisation). Maintenant, ça reste un moindre mal j'ai envie de dire...Entre gérer 90% des cas via un fichier de template (ou via un ctrl h d'apres jp-gfx...) et devoir se coltiner chaque CSS pour la moindre modif, je préfère largement celle où on économise 90% du temps
Mais ce qui m'étonne un peu c'est que dans le monde du CSS/design web il n'y ai pas (ou alors j'ai très mal cherché) de sorte de design pattern pour ça, pour éviter justement dans des problèmes de productivité et de maintenance.
L'approche OOCSS je ne connaissais pas, je vais m'y plonger Merci

Je laisse le débat ouvert, des fois qu'il y ait d'autres idées. De mon côté je vais essayer de chercher et trouver ce qui se rapprocherai le plus d'une solution viable. Si je trouve quelque chose, je viendrais le reposter ici parce que ce genre de question ne court pas trop les rues sur google.


@jb-gfx : Quand un mec te conseille d'utiliser un ordinateur (pour reprendre tes termes) ou un logiciel qu'on appelle éditeur de texte sur un forum technique CSS, excuses moi de le prendre mal ou en tout cas de penser que tu me prends pour un c... ou un kikoolol... La prochaine fois, essayes de pister la personne que tu tentes d'aider pour savoir quel genre de profil tu as en face de toi et surtout, essayes de proposer quelque chose de plus intelligent qu'un simple éditeur de texte... En tout cas, on s'est bien marrés avec mon équipe... merci pour ce moment de détente.
Signé : un nain compétent...

S'il y a un air de famille entre ces 100 variantes, alors OOCSS peut convenir.
Ça factorise/clusterise quelque peu les différences par couleurs, positionnement, etc

Mais s'il y a vraiment 100 variantes (avec un nom de classe différent sur body genre body.client1 body.groupe2-filiale3 etc), aucun outil au monde ne permettra de prévoir ce que deviendront 100 différences face à une nouvelle modif : un design pattern c'est l'inverse de 100 choses différentes ; c'est trouver des points communs.
Je suis pas assez développeur pour avoir utilisé les directives de compilation mais qu'il y ait 100 " #ifdef" à la suite dans 1 fichier ou 100 fichiers ne change pas grand chose au problème et je vois pas comment résoudre une telle pagaille enfin variété ^^ volontairement créée...

Non non, justement, on est d'accord sur le fait que la structure HTML, elle, ne bouge pas entre les différents thèmes. On parle bien de 100 CSS différents, point
Sinon c'est clair que là on rentre dans du thème ultra spécifique...ça ne sera pas gérable de façon automatisée (ou très peu... ).