Mes collègues m’entendent souvent râler dans l’open space lorsque je vois un thème WordPress conçu sur une base de Twitter Bootstrap, d’autant plus lorsque l’on voit le code source et l’usage qui en est fait. Cette traduction d’un article de Fränk Klein défend assez bien mon point de vue.

NDA : Certains compléments ou interprétations sont ajoutés entre crochets, certaines tournures de phrase sont légèrement adaptées. Enfin, certains termes ne sont pas traduits car ancrés dans le jargon des métiers du Web.
——

Depuis sa sortie en 2011, Bootstrap est rapidement devenu le framework le plus populaire sur Github. Cette popularité a également eu un impact sur ​​le monde des thèmes WordPress, avec de plus en plus d’auteurs utilisant cet outil au cours du développement ou même au moment de publier des thèmes présentant Bootstrap comme argument de vente unique. (ou principal)

C’est quelque chose de surprenant car Bootstrap n’est pas vraiment l’outil adapté pour le développement d’un thème WordPress.

Bootstrap : le mauvais outil pour cette tâche

Bootstrap a été créé chez Twitter comme outil pour que les développeurs back-end puissent aisément créer des interfaces pour leurs applications. Avant Bootstrap, beaucoup d’autres bibliothèques furent utilisées, aboutissant en des interfaces incohérentes et difficiles à maintenir.

Bootstrap a donc été créé avec un but précis en tête, et continue à être développé d’après cette vision initiale du projet. Il a été créé pour que les développeurs puissent se concentrer sur du code back-end et itérer rapidement sans se soucier de l’aspect front-end.

C’est pourquoi Bootstrap n’est pas le bon outil pour créer un thème WordPress : le thème WordPress, ou l’apparence du site une fois le thème activé, est tout ce qui compte. [Il n’y a rien à attendre d’original dans votre thème, dans son aspect graphique, avec un outil de back-end]

Bootstrap ne fait pas les choses à la WordPress

WordPress facilite le développement de thème en mettant à disposition un lot de fonctions utilisables dans les fichiers de template. En tirant parti de la sortie HTML de ces fonctions, les développeurs peuvent écrire du code propre et efficace qui fonctionne avec une grande variété de contenus [ou de structures].

bootstrap

Bootstrap, d’autre part, a sa propre approche de la façon dont le code HTML est [et doit être] structuré, et il ne cadre pas très bien avec ce que WordPress fournit par défaut.

Partant de cette différence, les développeurs doivent prendre des mesures supplémentaires et écrire un surplus de code pour modifier le comportement de WordPress afin de l’ajuster au fonctionnement du framework. Un bon exemple pour cela sont les menus de navigation. Au lieu d’utiliser le code généré par wp_nav_menu(), les développeurs doivent écrire des Walkers personnalisés qui changent la structure HTML de sortie de sorte que les codes CSS et JavaScript de Bootstrap puissent être utilisés.

De cette approche en ressortent davantage de code et une efficacité moindre, une maintenance plus difficile et un temps de développement supérieur, tout en ne permettant aucun bénéfice sur les améliorations produites par les fonctions natives de WordPress.

Bootstrap est pléthorique

Le code d’un framework ne peut jamais être aussi efficient qu’un code écrit pour une proposition spécifique, pour la simple raison que les frameworks se construisent sur une base générale pour tendre vers des cas plus spécifiques, et ajoutent des redondances dans le processus. Souvent, plusieurs classes CSS doivent être ajoutées à des éléments HTML pour obtenir le résultat visuel désiré, classes CSS qui une fois combinées apportent le CSS nécessaire.

C'est assurément plein de fonctionnalités…
C’est assurément plein de fonctionnalités…

Ce qui s’ajoute à ce problème est que, bien des fois, le code CSS utile pour la conception du thème n’est pas le seul packagé, mais l’ensemble du code du framework l’est également.

Bootstrap n’encourage pas au bon design

L’une des fonctionnalités les plus populaires de Bootstrap est le colonage (12 colonnes), cette grille « full responsive« . En ajoutant des classes à la structure HTML, les développeurs peuvent créer des sites web adaptés à toutes les tailles d’écran.

Malheureusement, l’utilisation d’une grille prédéfinie est une mauvaise approche pour l’aboutissement d’un bon design. Le problème majeur est que vous concevez de l’extérieur, bousculant le contenu dans des boîtes prédéfinies. En résultent des modèles qui offrent un sentiment de rigidité et un aspect mécanique, sans proportions appropriées ou harmonie.

L’approche de la « taille unique » garantit également que le thème que vous concevez ne s’adapte pas à toutes les contraintes telles que les dimensions de l’image ou de la longueur de la ligne. Que vous utilisiez une [police de caractère] sans-serif étroite ou une didone-serif qui a besoin d’espace pour respirer, la grille reste la même. Il en ressort souvent une mauvaise lisibilité et une typographie non harmonieuse.

Une meilleure approche

Tout grand design de thème commence avec une vision. Quel est le but derrière le thème que vous concevez ? Qui envisagez-vous comme utilisateur et dans quel contexte ?

Cela vous informe sur les contraintes avec lesquelles vous devez travailler. Concevoir un portfolio riche en images est un défi [(voire besoin)] différent de celui de créer une expérience optimale pour une thème de magazine proposant de longs articles.

Une fois que vous avez défini une vision, vous commencez alors la conception de l’intérieur. Obtenez un échantillon du contenu pour effectuer des tests, puis commencez à concevoir l’expérience du parcours de ce contenu. Vous verrez qu’une fois que vous vous concentrez sur le contenu, vous pouvez construire autour de lui les éléments du design qui restent, et obtenir un résultat harmonieux.

Sur le plan technique, utilisez un gabarit de thème de départ qui vous permette de démarrer rapidement avec une structure de base et vous permette de plonger rapidement dans le balisage de présentation, sans trop porter votre attention sur le design. Utilisez des bibliothèques et les extraits de code (snippets) pour réduire le temps de développement. Les thèmes par défaut fournis avec WordPress sont généralement de bonnes ressources pour extraire des fragments de code.

Article issu de la traduction et de l’adaptation de : Why Bootstrap is a bad fit for WordPress Themes

Bien entendu, selon moi, cela ne s’arrête pas uniquement à Bootstrap en particulier. D’autres bibliothèques du même type soulèvent la même problématique, bien que certaines soient plus adaptées à un aspect front-ent, mais l’objet de l’article n’est pas de les lister mais de soulever le problème de leur utilisation pour du thème WordPress. D’ailleurs EdenPulse a également écrit un billet sur le sujet.