BEM, Sass et A/B Testing

Bonjour tout le monde.

/!\ Avant toute chose veuillez me pardonner car je suis sur un clavier allemand, donc ce sera un post sans accents (je ne corrigerai que ce que le correcteur automatique me propose).

Alors aujourd'hui, ce n'est ni une réponse a un problème précis, ni une critique que je suis venu chercher, mais plutôt des informations, un partage d’expérience.

Je travaille aujourd'hui sur un site web en tant que développeur front-end pour une startup. Une grande partie de mon travail est de dessiner et d'implementer des versions differentes de pages cles, afin d'en comparer le rendement. Comme beaucoup le savent deja probablement sur ce forum, c'est ce qu'on appel le A/B testing.

Au dela de ca, il y a des routes completes qui peuvent etre "A/B testees", ce qui s'ignifie que l'on peut tres rapidement arriver a des feuilles de style assez fouillies. Depuis longtemps deja, j'utilise Sass/Compass (via gruntJS bien souvent) et hierarchise mes .scss le plus proprement possible.

C'est parfaitement confortable a partir du moment ou la structure du site reste classique, même sur un site tres complexe. Mais un niveau plus haut, on trouve le testing. Et encore un niveau plus haut, on fait du testing dans une start-up qui part dans tous les sens (dans le bon sens tu terme). Alors forcement, on multiplie les feuilles de style, les routes, et versions, les couleurs de boutons, etc. Ça en devient très rapidement problématique quand il s'agit de tout organiser.

Alors je vais attaquer simplement, j'ai deux questions assez précises, et d'autres viendront probablement agrémenter ce topic.

1) Je m'adresse aux professionnels travaillant depuis un certain temps avec la syntaxe CSS BEM, et vous donne un exemple:

Page A:

.header {
	// Rules
}

.header__logo {
	// Rules
}
	.header__logo--b-version {
		// Rules (modifiers)
	}



.header__headline {
	// Rules
}

.header__contact-data {
	// Rules
}
	.header__contact-data--b-version {
		// B version rules (modifiers)
	}
	.header__contact-data--c-version {
		// C version rules (modifiers)
	}

C'est aujourd'hui ma manière de faire dans le cadre d'un A/B testing sauvage. Je trouve personnellement ca parfois ennuyeux a maintenir. Apres, je suis bien conscient que dans le contexte dans lequel je me trouve, il est difficile de faire des miracles.

Quelles sont donc vos pratiques dans ce contexte ? Toutes les idées sont les bienvenues.



2) Dans la question 1, je vous expose un cas dans lequel je concentre tout dans une partiale _header.scss". Une autre solution consiste alors a diviser le code de chaque version différente dans des partiales différentes, que je range dans des sous-dossiers nommes selon le nom de code de la version.

// Version simplifiée

scss/
|
|-- core/
|   |-- _reset.scss
|   |-- _colors.scss
|   |-- _header.scss
|   ...
|
|-- default-version/
|   |-- _header.scss
|   |-- _buttons.scss
|   ...
|-- b-version/
|   |-- _header.scss
|   |-- _buttons.scss
|   ...
|
|-- c-version/
|   |-- _header.scss
|   |-- _modifiers.scss
|   ...
|

Encore une fois, je suis preneur de conseils, expériences.



Finalement, je lance aussi un sujet de fond que je n'ai pas vu sur le forum d'alsacreations. Si chacun pouvait apporter son témoignage, ses "bonnes pratiques"...


Je m'excuse aussi pour ce sujet rasoir une veille de Pacques


En vous souhaitant une bonne fin de journee.

[petit bonjour au passage a Kusto ]
Modifié par Cr4sH (17 Apr 2014 - 16:48)

Bonjour,

les 2 méthodes se défendent ; y a rien qui me choque en tout cas (l'indentation à droite des règles 2 à N par contre oui :o).

HS : ça se compresse bien (gzip) tes CSS comportant toutes les variantes dues à tes tests A/B ? Si ce n'est pas le cas, je te conseille de les passer dans grunt-uncss, si ce n'est pas déjà ce que tu fais (encore faut-il tenir à jour une liste des pages à analyser pour chaque test... pas si facile que ça en fait)

Coucou Felipe, et merci pour ta réponse !

Petite parenthèse concernant l'indentation, c'est pour détecter d'un coup d’œil rapide les modifiers. Je trouve ca confortable dans mon travail de tous les jours, et ca ne pose bien sur aucun problème sur l'output.

Concernant uncss et gzip, je ne suis pas bien sur de comprendre. Tu veux bien préciser un peu ?

Perso, je n'utilise pas uncss, je n'ai pas encore vraiment eu le temps de mettre les mains dedans, mais de ce que j'en ai lu, c'est avant tout un outil qui supprime les règles inutilisées d'un framework css (Bootstrap and co). Créant toujours mes feuilles de style sans librairies externes, je ne suis que peu intéressé pas cette task...

indentation > c'est les goûts et les couleurs, comme espace vs tab

uncss > je pensais à la méthode 1 où tu charges les CSS pour toutes les variantes d'un bloc alors que le visiteur ne voit qu'une seule variante. Uncss permettrait d'enlever après coup les variantes qui ne sont plus utilisées pour chaque cas. Mais ça crée autant de CSS que de variantes et il faut donner en entrée les bonnes pages, celles où la variante à garder figure.
Mouais beaucoup de contraintes alors que gzip est probablement très efficace.

Alors dans ce cas, je dois préciser la structure sur laquelle je travaille actuellement. C'est une seule et unique installation de WordPress sur laquelle je code de nouvelles variantes (templates,modules...). Il est très courant qu'un visiteur visite plusieurs versions/routes sans même y prêter attention, car les modifications sont parfois minimes.

Comme tu l'auras compris, je veux aussi éviter de multiplier les requêtes, c'est pour ça que j'ai opté pour une seule feuille de style globale + gzip. La feuille pèse aujourd'hui environ 120k, et est difficilement optimisable... C'est qu'on a un paquet de versions . Mais malgré tout, étant le seul intégrateur, je me dis qu'il est difficilement possible de partir sur quelque-chose de plus complexe.

(Depuis mon mobile)

Je me permet un petit UP, ne m'en voulez pas trop