Ich habe neulich den Beitrag von Anna Kaley mit dem Titel „Listboxes vs. Dropdown Lists“ gelesen. Es ist ein ziemlich geradliniger Vergleich verschiedener UI-Implementierungen zur Auswahl von Optionen. Dort gibt es viele gute Ratschläge. Klassiker sind zum Beispiel, dass man Radio-Buttons (Einzel-Auswahl) oder Checkboxen (Mehrfach-Auswahl) verwenden sollte, wenn man fünf oder weniger Optionen anzeigt, und unterschiedliche Optionen, wenn die Anzahl der Optionen von dort an wächst.
Eine Sache, die nicht angesprochen wird, ist, *wie* man diese Dinge implementiert. Ich stelle mir vor, das ist auch irgendwie beabsichtigt, da es darum geht, UX und nicht Technik zu besprechen. Aber wie man sie implementiert, spielt eine große Rolle für die UX. In Kreisen des Webdesigns und der Webentwicklung dreht sich die Unterhaltung über diese Dinge normalerweise darum, ob man diese Dinge mit nativen Steuerelementen umsetzen kann oder ob man sie von Grund auf neu erstellen muss. Wenn man native Steuerelemente verwenden *kann*, dann sollte man das oft auch tun, denn es gibt unzählige UX-Vorteile, die man kostenlos erhält und die ansonsten verloren gehen oder vergessen werden könnten, wenn man sie neu erstellt – wie zum Beispiel, dass alles über die Tastatur funktioniert.
Der Grund, warum sich Leute für „Neuerstellung“ entscheiden, sind oft Styling-Gründe, aber das ändert sich langsam im Laufe der Zeit. Wir haben jetzt *viel Kontrolle über Radios und Checkboxen*. Wir können das Äußere von Selects ziemlich gut stylen und mit etwas Trickerei *sogar das Innere*.
Aber selbst ohne individuelles Styling haben wir immer noch einige UI-Optionen. Wenn Sie eine Option aus vielen auswählen müssen, haben wir <input type="radio">-Buttons, aber im Hinblick auf Daten und Endergebnis ist das dasselbe wie ein <select>. Wenn Sie mehrere Optionen auswählen müssen, haben wir <input type="checkbox">, aber das ist im Hinblick auf Daten und Endergebnis dasselbe wie <select multiple>.
Sie wählen basierend auf dem verfügbaren Platz und der UX dessen, was Sie gerade erstellen.
Ich habe eine Frage dazu. Wenn man auf dem Desktop zu viele
<input type="checkbox" />hat, möchte man diese Eingaben vielleicht auf Mobilgeräten in einen<select>-Typ umwandeln. Gibt es dafür eine Möglichkeit, die nur mit CSS funktioniert? Alle Implementierungen, die ich gesehen habe, basieren immer auf JavaScript.Das ist eine interessante Situation. Ich glaube nicht, dass CSS allein das schaffen könnte. Selbst wenn Sie verschiedene Teile des Formular-HTMLs mit CSS ein- und ausblenden, sind diese Formularelemente immer noch vorhanden und werden wahrscheinlich übermittelt. Zumindest mit JavaScript könnten Sie die anderen aus dem DOM entfernen oder etwas an ihnen ändern, um zu verhindern, dass sie übermittelt und mit assistiven Technologien abgerufen werden. Aber selbst dann müssen Sie sehr vorsichtig sein, dass das Formular Daten im exakt gleichen Format übermittelt.
Eine der Lösungen, die mir einfällt, ist, dem Element, das nicht angezeigt werden muss, CSS-Eigenschaften zu geben wie
{
display: none,
/* ODER */
opacity: 0,
width: 0,
height: 0
}
Wenn Sie jedoch wirklich HTML-Elemente entfernen möchten (nicht nur stilistisch ausblenden) abhängig vom Gerät, dann benötigen Sie tatsächlich JavaScript, da CSS nur Stile auf HTML-Elemente anwenden kann, sie aber nicht entfernen oder hinzufügen.
Ich wäre vorsichtig mit
<select multiple>, da die Leute dazu neigen, nicht zu wissen, wie man mehrere Elemente aus einer Liste auswählt, wenn dazwischen nicht ausgewählte Elemente sind (auf dem Desktop). Im obigen Beispiel wäre dies die Auswahl von „Choice 1“ und „Choice 3“, aber nicht „Choice 2“.Auf Mobilgeräten wird es, wenn das Element den Fokus hat, als Liste von Checkboxen gerendert.
Dem stimme ich voll und ganz zu und vermeide tendenziell
<select multiple>. Selbst wenn ein Benutzer weiß, wie man mehrere Elemente auswählt, ist es immer noch leicht, einen Fehler zu machen (versehentlich Shift statt Strg oder umgekehrt drücken). Außerdem kann ein Benutzer bei einer Liste, die die Größe des Select-Elements überschreitet, nicht die Gesamtheit seiner Auswahl sehen, was leicht dazu führen kann, dass ein Benutzer unwissentlich falsche Daten übermittelt (besonders bei Bearbeitungen).So ziemlich – wie der verlinkte NNG-Artikel aufzeigt
(meine Hervorhebung) Also ja, die Daten, die man erhält, sind die gleichen, aber im Hinblick auf das „Endergebnis“ kommt es irgendwie darauf an, wie man das definiert – beinhaltet es den UX-Wert der Offensichtlichkeit?