Sollten WordPress-Plugins dem WordPress-Admin-Panel-Design entsprechen?

Im Allgemeinen sollten Sie versuchen, den standardmäßigen WordPress-Verwaltungsstil (Schaltflächenformen, colors usw.) visuell einzuhalten.

Gibt es irgendwelche Vorteile von benutzerdefiniertem Styling außer für das Branding (ich nehme an, dass WP-Teams einige Usability-Tests an ihren Designs durchführen)?

Solutions Collecting From Web of "Sollten WordPress-Plugins dem WordPress-Admin-Panel-Design entsprechen?"

Nach den vorherigen Antworten würde ich mich in den meisten Fällen an die WordPress-Standardstile und -muster halten – für Design und auch Markup, functionen, APIs und cod, nicht nur für das CSS -, besonders wenn es sich um ein Plugin für die allgemeine Öffentlichkeit handelt im offiziellen Repository gehostet werden.

  1. Wie Milan darauf hinwies: “Es gibt viele Fälle, in denen das WordPress-Admin-Styling nicht ausreicht.”
  2. Wie Mark sagt, “Nutzer hassen es, die neue” Snow Flake “UI zu lernen, vor allem, wenn sie 20 Plugins mit jeweils eigenem” Snow Flake “-Design haben.”
  3. Ihre Plugins werden mehr “zukunftssicher” sein. Zum Beispiel, wenn WordPress seine CSS und Styles in der Zukunft ändert, wird Ihr Plugin in den meisten Fällen automatisch folgen.

Das heißt, es wird Zeiten geben, in denen du zwischendurch etwas verändern musst oder etwas komplett ändern musst. Mein Rat ist, darauf aufzubauen, was WP tut, und zu ändern, was wirklich benötigt oder gerechtfertigt ist.

Meine Firma verwaltet 3 WordPress-Multisite-Netzwerke: A für unsere eigenen Kunden, B für eine bestimmte Nische gemanagter Sites / CMS / Digital Hub SAAS und C für andere Boarder-Nischen-Managed-Sites SAAS.

  • Alles, was wir in A machen, folgt WordPress-Styles nach dem Buch.
  • Auf B haben wir die meisten WordPress Stile / Muster für einen APP / Material Design ähnlichen Ansatz fallen gelassen. Wir wollten, dass der Nutzer eine App und nicht WordPress als Nutzer empfindet, da dies für den Service sinnvoll ist. Wir haben eine Menge Design- / Präsentations-Sachen mit CSS verändert, aber so viel wie möglich von WP HTML-Markup- und PHP / Javascript-Codemustern behalten.
  • Auf C haben wir WordPress Styles / Patterns an einigen Stellen entfernt.

Und für Plugins, die wir “in the wild” veröffentlichen, folgen wir meistens den WP-Stil / Patterns.

Es hängt alles ab. Es gibt viele Fälle, in denen der WordPress-Admin-Stil nicht ausreicht: komplexe Steuerelemente wie Repeater mit einem oder mehreren Feldern, komplexe verschachtelte Einstellungen und andere Dinge. Wenn Sie viele Einstellungen haben, kann das Standard-WP-Styling einschränkend sein.

Auf der anderen Seite gibt es Plugins und Themes, die Styling verwenden, die sehr fremdartig und übertrieben aussehen, mit riesigen bunten Buttons, Ersatz für Standard-HTML-Steuerelemente und vielem mehr. Sie sehen sehr fehl am Platz aus und können für den Endbenutzer verwirrend sein.

Wenn Sie einfache Steuerelemente und Einstellungen erstellen müssen, ist es am besten, sich an den WordPress-Standardstyling zu halten (dieselben classn wie WP verwendet), der dafür sorgt, dass Ihr Plugin mit allen WordPress-Versionen gut aussieht. Wenn Ihr Plugin viele Einstellungen hat und Sie eine bessere Möglichkeit haben, Dinge zu organisieren, können Sie Ihr eigenes Design entwickeln, das in der Nähe des WordPress bleibt, Ihnen aber mehr Flexibilität bietet.

Für all meine Plugins habe ich meine eigene standardisierte Interface-Bibliothek, die auf dem WordPress-Styling mit wenigen zusätzlichen organisatorischen Elementen basiert, und bis jetzt hatten meine Benutzer kein Problem, sich auf meine Plugins-Benutzeroberfläche einzustellen, weil sie WordPress sehr ähnlich sieht.

Diese Frage erinnert mich an die schlechten alten Tage der frühen Java-Versionen. Java sah gut aus, wenn man sich nur auf seine Elemente konzentrierte (naja, zumindest gut genug), aber im Zusammenhang mit jedem Betriebssystem sah es wie ein hässliches Bastardkind aus.

Kein wordpress-Benutzer wird es wahrscheinlich vermeiden, Ihren Code zu verwenden, da die Benutzeroberfläche nicht den Konventionen entspricht, aber die Benutzer die neue Benutzeroberfläche “snow flake” nicht kennen, besonders wenn sie 20 Plugins mit jeweils eigenem “Schneeflocken” -Design haben.

UX Design 101 soll immer den Konventionen der Umgebung folgen, in der Ihr Code läuft, und nur wenn Sie etwas drastisch anderes machen, benutzen Sie verschiedene UX. Ehrlich gesagt folgen sogar Apple und MS diesem Leitfaden nicht immer, wenn sie Dinge für ihre eigenen Produkte auf ihrem eigenen Betriebssystem entwickeln, aber es ist unwahrscheinlich, dass sie so groß sind, dass es ihnen egal ist.