Les plugins WordPress doivent-ils adhérer au style du panneau d'administration WordPress?
En général, essayez d’adhérer visuellement au style d’administrateur par défaut de WordPress (formes des boutons, couleurs, etc.).
Le style personnalisé présente-t-il des avantages autres que la stratégie de marque (je suppose que les WP équipes effectuent des tests d'utilisabilité sur leurs conceptions)?
Après les réponses précédentes, dans la plupart des cas, je me contenterais des styles et modèles par défaut de WordPress - pour la conception , ainsi que du balisage, des fonctions, des API et du code, pas seulement le CSS -, surtout s’il s’agit d’un plugin destiné au grand public et hébergé dans le référentiel officiel.
- Comme Milan a souligné "Il existe de nombreux cas où le style de l'administrateur WordPress n'est pas suffisant."
- Comme l'a dit Mark , "les utilisateurs détestent apprendre la nouvelle interface utilisateur" flocon de neige ", en particulier lorsqu'ils disposent de 20 plugins, chacun avec son propre" flocon de neige ". conception."
- Vos plugins seront plus "futurs" comme. Par exemple, si WordPress change ses styles CSS et CSS par défaut à l'avenir, votre plugin suivra automatiquement dans la plupart des cas.
Cela dit, vous aurez parfois besoin de modifier, ou de changer complètement d’événement, quelque chose. Mon conseil est de construire sur ce que WP fait et de changer ce qui est réellement nécessaire ou justifié.
Mon entreprise gère 3 réseaux multisites WordPress: A pour nos propres clients, B pour un site géré de niche spécifique/CMS/Digital Hub SAAS et C pour d’autres sites gérés de niche SAAS.
- Tout ce que nous fabriquons en A suit les styles WordPress du livre.
- Sur B, nous avons abandonné la plupart des styles/modèles WordPress pour une approche similaire à celle d'une application/conception de matériaux. Nous voulions que l'utilisateur se sente comme une application et non par WordPress, car cela a du sens pour le service. Nous avons modifié de nombreux éléments de conception/présentation avec CSS, tout en conservant autant que possible les WP balises HTML et les codes PHP/Javascript.
- Sur C, nous avons abandonné des styles/modèles WordPress à quelques endroits.
Et pour les plugins, nous publions "à l'état sauvage", la plupart du temps, nous suivons WP style/patterns.
Tout dépend. Il existe de nombreux cas où le style de l'administrateur WordPress ne suffit pas: contrôles complexes, tels que les répéteurs avec un ou plusieurs champs, paramètres imbriqués complexes, etc. Si vous avez beaucoup de paramètres, le style par défaut WP peut être limitant.
D'autre part, il existe des plugins et des thèmes qui utilisent un style très étrange, avec d'énormes boutons colorés, des remplacements pour les contrôles HTML par défaut et bien plus encore. Ils semblent très déplacés et peuvent être déroutants pour l'utilisateur final.
Si vous devez créer des contrôles et des paramètres simples, il est préférable de vous en tenir au style par défaut de WordPress (mêmes classes que celles utilisées par WP,), ce qui garantira que votre plug-in sera bien avec toutes les versions de WordPress. Si votre plugin comporte de nombreux paramètres et que vous avez besoin d’un meilleur moyen d’organiser vos tâches, vous pouvez développer votre propre style, qui restera proche de WordPress, tout en vous offrant davantage de souplesse.
Pour tous mes plugins, j'ai ma propre bibliothèque d'interface standardisée basée sur le style WordPress avec quelques éléments d'organisation supplémentaires. Jusqu'à présent, mes utilisateurs n'avaient aucun problème à s'adapter à l'interface utilisateur de mes plugins, car elle ressemble beaucoup à WordPress.
Cette question me rappelle le mauvais vieux temps des premières versions de Java. Java avait l'air bien si vous vous concentriez uniquement sur ses éléments (enfin, assez bon au moins), mais dans le contexte de n'importe quel système d'exploitation, cela ressemblait à un vilain enfant bâtard.
Aucun utilisateur de wordpress n'est susceptible d'éviter d'utiliser votre code car l'interface utilisateur ne respecte pas les conventions, mais les utilisateurs détestent apprendre la nouvelle interface utilisateur "flocon de neige", en particulier lorsqu'ils disposent de 20 plug-ins ayant chacun leur propre design "flocon de neige".
UX Design 101 est de toujours suivre les conventions de l'environnement dans lequel votre code est exécuté, et utilisez une autre UX uniquement si vous faites quelque chose de radicalement différent. Franchement, même Apple et MS ne suivent pas toujours ce guide lorsqu'ils développent des solutions pour leurs propres produits sur leur propre système d'exploitation, mais il est peu probable que vous soyez si gros que vous n'en ayez rien à faire.