Ich denke schon seit einiger Zeit über Ton auf Websites nach.
Wenn wir über die Verwendung von Ton auf Websites sprechen, runzeln die meisten von uns die Stirn und denken an die alten Zeiten, als beim Laden der Website laute Hintergrundmusik abgespielt wurde.
Heute ist und muss dies kein Thema sein. Wir können mit Klängen clever umgehen. Wir haben jetzt die Web Audio API und sie gibt uns eine große Kontrolle darüber, wie wir Klänge für die Verwendung in unseren Webanwendungen gestalten.
In diesem Artikel werden wir ein einziges, einfaches Beispiel ausprobieren: ein Formular.
Was wäre, wenn Ihnen beim Ausfüllen eines Formulars neben visueller auch akustische Rückmeldung gegeben würde. Ich sehe Ihre grimassierenden Gesichter! Aber geben Sie mir einen Moment.
Wir haben bereits viel akustische Rückmeldung in den digitalen Produkten, die wir verwenden. Die Tastatur eines Telefons erzeugt ein Tippgeräusch. Selbst wenn Sie die Töne für "Nachricht empfangen" ausgeschaltet haben, hören Sie höchstwahrscheinlich, wie Ihr Telefon vibriert. Mein MacBook gibt beim Neustart einen Ton von sich, ebenso wie Spielekonsolen. Akustische Rückmeldung ist überall und ziemlich gut integriert, bis zu dem Punkt, an dem wir nicht wirklich darüber nachdenken. Wann haben Sie zum letzten Mal beim Mikrowellenherd gegrinst, als er gepiept hat? Ich wette, Sie sind froh, nicht zusehen zu müssen, um zu wissen, wann er fertig war.
Während ich diesen Artikel schreibe, hat mein Computer gerade gepiept. Einer meiner offenen Tabs hat mir eine nützliche Benachrichtigung gesendet. Mein Punkt ist, dass Ton hilfreich sein kann. Wir müssen vielleicht nicht alle mit unseren Ohren wissen, ob wir ein Formular falsch ausgefüllt haben, aber es gibt vielleicht viele Leute da draußen, die es nützlich finden.
Also werde ich es versuchen!
Warum jetzt? Wir haben die Möglichkeiten jetzt zur Hand. Ich habe bereits die Web Audio API erwähnt, mit der wir Töne erstellen/laden und abspielen können. Dazu kommen die HTML-Formularvalidierungsfähigkeiten und wir sollten bereit sein.
Lassen Sie uns mit einem kleinen Formular beginnen.
Hier ist ein einfaches Anmeldeformular.
Sehen Sie den Pen Simple Form von Chris Coyier (@chriscoyier) auf CodePen.
Wir können ein Formular wie dieses mit wirklich robuster Validierung verdrahten.
Mit allem, was wir aus Chris Ferdinandis Anleitung zur Formularvalidierung gelernt haben, hier ist eine Version dieses Formulars mit Validierung
Sehen Sie den Pen Simple Form with Validation von Chris Coyier (@chriscoyier) auf CodePen.
Vorbereitung der Sounds
Wir wollen keine unangenehmen, aufdringlichen Töne, aber wir wollen, dass diese Töne Erfolg und Misserfolg repräsentieren. Eine einfache Möglichkeit hierfür wäre, höhere, hellere Töne zu haben, die nach oben gehen für Erfolg und tiefere, verzerrtere Töne, die nach unten gehen für Misserfolg. Dies gibt uns immer noch sehr breite Optionen zur Auswahl, ist aber ein allgemeines Sounddesign-Muster.
Mit der Web Audio API können wir Töne direkt im Browser erstellen. Hier sind Beispiele für kleine Funktionen, die positive und negative Töne abspielen
Sehen Sie den Pen Created Sounds von Chris Coyier (@chriscoyier) auf CodePen.
Das sind Beispiele für die Erstellung von Sounds mit dem Oszillator, was ziemlich cool ist, weil es keine Webanfragen erfordert. Sie programmieren buchstäblich die Töne. Es ist ein bisschen wie das SVG der Klangwelt. Es kann Spaß machen, aber es kann auch viel Arbeit und viel Code bedeuten.
Während ich mit dieser Idee herumspielte, veröffentlichte Facebook sein SoundKit, welches
Um Designern zu helfen, zu erforschen, wie Klang ihre Designs beeinflussen kann, hat Facebook Design eine Sammlung von Interaktionsgeräuschen für Prototypen erstellt.
Hier ist ein Beispiel für die Auswahl einiger Töne daraus und deren Wiedergabe
Sehen Sie den Pen Playing Sound Files von Chris Coyier (@chriscoyier) auf CodePen.
Eine andere Möglichkeit wäre, die Sounddatei abzurufen und den audioBufferSourceNode zu verwenden. Da wir kleine Dateien verwenden, gibt es hier nicht viel Overhead, aber die obige Demo ruft die Datei jedes Mal über das Netzwerk ab, wenn sie abgespielt wird. Wenn wir den Ton in einem Puffer speichern würden, müssten wir das nicht tun.
Herausfinden, wann die Sounds abgespielt werden sollen
Dieses Experiment, dem Formular Sounds hinzuzufügen, wirft viele Fragen bezüglich der UX der Verwendung von Sound in einer Benutzeroberfläche auf.
Bisher haben wir zwei Töne: einen positiven/Erfolgs-Ton und einen negativen/Fehler-Ton. Es macht Sinn, dass wir diese Töne verwenden würden, um den Benutzer über diese Szenarien zu informieren. Aber wann genau?
Hier einige Gedanken zum Nachdenken:
- Spielen wir den Ton für jeden ab, oder ist es ein Opt-in-Szenario? Opt-out? Gibt es APIs oder Media Queries, die wir verwenden können, um die Standardeinstellung zu informieren?
- Spielen wir Erfolgs- und Fehlertöne beim Absenden des Formulars oder auf der Ebene des einzelnen Eingabefeldes? Oder vielleicht sogar Gruppen/Feldsets/Seiten?
- Wenn wir Töne für jedes Eingabefeld abspielen, wann tun wir das? Beim
blur? - Spielen wir Töne bei jedem Blur ab? Gibt es eine andere Logik für Erfolgs- und Fehlertöne, wie z. B. nur ein Fehlerton, bis er behoben ist?
Es gibt keine wirklich etablierten Best Practices für diese Dinge. Das Beste, was wir tun können, ist, geschmackvolle Entscheidungen zu treffen und Benutzerforschung zu betreiben. Das heißt, die Beispiele in diesem Beitrag sind Ideen, keine in Stein gemeißelten Wahrheiten.
Demo
Hier ist einer!
Und hier ist ein Video mit Ton, das zeigt, wie es funktioniert
Stimme
Greg Genovese hat einen Artikel, der sich ganz um Formularvalidierung und Screenreader dreht. „Reader“ ist hier relevant, da es hierbei nur um Audio geht! Es gibt viel zu tun mit Aria-Rollen und Fokusverschiebung usw., damit Fehler klar sind und klar ist, wie sie zu beheben sind.
Die Web Audio API könnte hier auch eine Rolle spielen, oder wahrscheinlicher die Web Speech API. Akustische Rückmeldung für die Formularvalidierung muss nicht auf Screenreader-Software beschränkt sein. Es wäre sicherlich interessant, das Vorlesen von tatsächlichen Fehlermeldungen zu experimentieren, vielleicht in Verbindung mit anderen Tönen, wie wir hier experimentiert haben.
Gedanken
All das nenne ich Sound Design im Web Design. Es geht nicht nur darum, Musik und Töne abzuspielen, sondern darum, dem Klangbild Gedanken zu widmen und Planung und Design zu betreiben, wie Sie es bei jedem anderen Aspekt dessen tun würden, was Sie entwerfen und bauen.
Es gibt noch viel mehr zu diesem Thema zu sagen und absolut mehr Wege, wie Sie Klänge in Ihren Designs verwenden können. Lassen Sie uns darüber sprechen!
Ich könnte weitermachen, aber das fängt an, negativer zu klingen, als ich möchte. Ich versuche nicht, unhöflich oder beleidigend zu sein. Es ist ein nützlicher Artikel über die Verwendung von Sound. Ich stimme der Anwendung nicht zu, und ich bin nicht davon überzeugt, dass unsere Welt voller Pieptöne ist, noch dass sie es sein sollte.
Toller Beitrag! Ich stimme zu, dass wir unnötige Hürden bezüglich Audio im Web haben. Das Interessante ist, dass wir diese Hürden nicht bei Audio-Feedback auf Desktop- oder Mobile-Apps haben. Ich habe vor 2 Jahren auf der Fluent Conference darüber gesprochen (https://www.safaribooksonline.com/library/view/fluent-conference-2015/9781491927786/video213375.html), aber trotz der Tatsache, dass Web Audio einen langen Weg zurückgelegt hat, hat sich nicht viel geändert – wir haben immer noch hauptsächlich Angst, es zu benutzen.
Danke, toller Beitrag.
Stimme zu, das lässt sich durchaus nicht-intrusiv implementieren.
Betriebssysteme machen es, warum nicht Webbrowser ;-)
Als sehbehinderter Mensch fand ich Bushaltestellenschilder immer besser, wenn sie visuelle und akustische Hinweise kombinierten, im Vergleich zu einem einzelnen Hinweis.
Ich muss zugeben, ich war unglaublich skeptisch, als ich den Titel sah. Ich dachte, das würde mit Barrierefreiheit einfach ein Albtraum werden. Nachdem ich es mit VO überprüft hatte, war es nicht so aufdringlich, wie ich dachte. Ich denke, mit weit verbreiteter Akzeptanz und Konsistenz könnte dies ein zusätzlicher Bonus sein. Andernfalls müssten wir meiner Meinung nach den Benutzer aufklären, dass Sound1 gut und Sound2 schlecht ist. Interessanter Artikel.
Ich denke, es wäre weniger ärgerlich mit negativen Tönen. Ich stimme nicht zu, dass jeder Ton im Web irritierend ist, aber häufige Töne können es definitiv sein, und da die Wahrnehmung besteht, dass sie störend sind, kann die Verknüpfung mit dem Verlassen eines Eingabefeldes wie eine Bestrafung wirken. Also vielleicht sollten sie nur mit Eingabefeldern verknüpft werden, die man vermasselt hat und für die man bestraft werden sollte! Auf jeden Fall ist dieses positive Klingeln unaufhörlich, und ich würde meinen Ton ausschalten, wenn ich ein Formular mit mehr als drei Feldern damit ausfüllen müsste.
Anmerkung zum Mikrowellenherd: Ich besitze derzeit keinen, weil die Leute in Bewertungen oder Vergleichen nicht oft darauf hinweisen, wie laut sie piepen, sodass ich Schwierigkeiten habe, sie zu kaufen. Mein vorheriger klang wie ein LKW beim Rückwärtsfahren und das kann ich nicht mehr ertragen. Ich hätte lieber etwas, das leise fertig kocht – es summt sowieso schon.
Völlig am Rande des Artikels: Viele der von uns besessenen Mikrowellen haben eine Option (wenn auch manchmal versteckt), alle Pieptöne zu deaktivieren. Als unsere Kinder Kleinkinder/Kleinkinder waren und bei jedem seltsamen Geräusch aufwachten, haben wir die grellen Pieptöne deaktiviert. Sie müssen also keine Mikrowelle aufgeben, besorgen Sie sich einfach eine, bei der Sie den Ton ausschalten können.
(Obwohl als Nebengedanke zu meinem bereits Nebengedanken: Bei unserem aktuellen Modell werden *alle* Pieptöne deaktiviert, einschließlich des Countdown-Timers, der sich vom Kochtimer unterscheidet, was ihn zum nutzlosesten Countdown-Timer der Welt macht, es sei denn, Sie starren ihn während des gesamten Countdowns an. Dafür könnte ich jedoch auf den Countdown-Timer meines Handys umschalten und die Mikrowellenstille genießen.)
Auch ich war unglaublich skeptisch – aber nachdem ich den Artikel gelesen und die Demo gesehen habe, sehe ich sicherlich die Vorteile der Berücksichtigung von Sound. Letztendlich würde ich dies jedoch niemals bei einem Projekt implementieren. Es gibt einfach zu viele Überlegungen
Ob der Benutzer Audio erwartet und, falls nicht, wie seine Reaktion wäre.
Ob das Audio das erwartete Ergebnis erzielt (d.h. der Benutzer hört ein Geräusch und weiß, dass etwas falsch ist) im Gegensatz zu einem unerwünschten Ergebnis (d.h. der Benutzer assoziiert das Geräusch mit Telefonbenachrichtigungen und prüft, ob er eine SMS erhalten hat, oder denkt, dass die Batterie seines Rauchmelders leer ist, usw., usw.).
Argumente für diesen Ansatz, die auf der Verbreitung von Audio in Betriebssystembenachrichtigungen basieren, scheinen die Tatsache zu übersehen, dass dieselben Systeme eine Vielzahl von Optionen zur Steuerung dieses Audios bieten – aus gutem Grund: Die Einbeziehung eines anderen Sinnes kann gemischte Ergebnisse haben.
Einige Benutzer werden es als eine willkommene Möglichkeit der Benachrichtigung empfinden. Andere werden abgelenkt oder sogar beunruhigt sein; der Ton ist unerwünscht oder in bestimmten Einstellungen sogar unpassend.
Die größte Stärke dieses Ansatzes (die Einbeziehung eines anderen Sinnes zur Unterstützung des Benutzers) ist gleichzeitig sein größter Nachteil.
Ich denke, einer der größten unterscheidenden Faktoren ist, wie aufdringlich die Geräusche sind. Ein subtiler, so leiser "Du hast es geschafft"-Chirp oder ein trauriges "Tut mir leid, Kumpel"-Posaunengeräusch verleiht die gleiche Art von Freundlichkeit wie eine subtile Überblendung oder eine Bewegungsanimation. Aber wie bei der Animation ist es sehr einfach, zu übertreiben. Genauso wie meine Animationen meine Arbeit oder meinen Fokus nicht stören sollen, sollten es auch keine Töne.
Danke euch allen für die Unterhaltung!
Die interessantesten Überlegungen für mich sind tatsächlich: „Ist Audio auf Benutzeroberflächen aufdringlich oder verbessernd und hilfreich?“ Und ja, ich denke, das kommt darauf an, wie die meisten Leute auf die eine oder andere Weise erwähnt haben: die Art des Geräusches und wann wir es verwenden. Absolut @goose, niemand mag das wiederholte Piepen des rückwärtsfahrenden LKWs, aber mit dem Funktionsumfang der Web Audio API gibt es keinen Grund, warum wir aufdringliche Töne machen müssten :)
Außerdem können wir das größere UX-Bild berücksichtigen – wie Stummschalttasten. Ja @aminimalanimal, nur ein kleines Fehlgeräusch zu erzeugen, ist vielleicht angemessener und weniger störend :)
Und @Brian Rinaldi, ich schaue mir diesen Vortrag an – er hat ziemlich dieselbe Ansicht, die ich für meinen letzten Vortrag bei CSS Day hatte. Wir erwarten und akzeptieren Klänge auf OS-Ebene, bei Software und Apps, aber sobald wir uns einem Browser zuwenden, ist es kulturell inakzeptabel.
Vielleicht liegt es wieder an der Stummschalttaste…
Sieht für mich vielversprechend aus. Wenn die E-Commerce-Welt diese Art von Feedback ausprobiert und testet und sieht, was es für die Konversionsrate tut, wird es nicht lange dauern, bis wir einige Best Practices haben.
Wir vermeiden Ton, weil er meistens super nervig ist. Heben Sie die Hand, wenn Sie automatisch abspielende Videos lieben.
Aber Ton könnte ein großartiges Werkzeug zur Verbesserung der Barrierefreiheit sein. Vibration auch – Apple verwendet haptisches Feedback, um Erfolgs- und Fehlerzustände anzuzeigen.
Um den Nervfaktor zu vermeiden, denke ich, dass das Hinzufügen von Ton und Vibration mit einer User-Media-Query, ähnlich der Reduced-Motion-Query, ein großer Gewinn für die Barrierefreiheit sein könnte.
Earcons (der Name, den ich für diese Audio-Hinweise kenne) erzeugen viele Meinungen. Ich habe meine eigenen Meinungen, einige basierend auf Forschung und Tests, und einige einfach als Benutzer. Ich erspare allen die Details.
Ich verlinke ein Video, das ich von der Demo mit NVDA 2017.3 und Firefox 55 erstellt habe, da ich vermute, dass wenige Leser diese Einrichtung zur Hand haben: http://adrianroselli.com/wp-content/uploads/2017/09/CSS-tricks_form-validation-web-audio_NVDA-FF.mp4
Ich sage nicht, ob das gut oder schlecht ist, da dies von vielen Faktoren abhängt (Benutzer, Kontext, Audioauswahl, technische Implementierung usw.). Zumindest dachte ich, es wäre aufschlussreich zu hören, wie dies von SR-Benutzern erlebt werden könnte, wenn man es mit einem Screenreader (mit sehr langsamer Sprechgeschwindigkeit) hört.
Ich habe ein Problem gefunden: Wenn ich vom Submit-Button mit Shift + Tab weggehe. Das Verlassen des Submit-Buttons löst den Erfolgs-Ton aus. Wenn ich ein Screenreader-Benutzer bin, weiß ich erst, dass ich das letzte Feld vermasselt habe, wenn ich zum Submit-Button komme. Wenn ich also Shift + Tab drücke, kann dieser Erfolgs-Ton verwirrend sein.
Unabhängig vom Audio-Aspekt einige (unaufgeforderte) Vorschläge aus jahrelangen Usability-Studien: 1. Vermeiden Sie es, ein Feld als Fehler zu markieren, wenn ein Benutzer nichts weiter getan hat, als den Fokus darauf zu legen; 2. Die Fehlermeldungen sollten identifizieren, welches Feld betroffen ist (ich weiß, das ist nur eine Demo); 3. Ich liebe es, dass Sie
aria-describedbyverwenden, um diese Fehlermeldungen mit den Feldern zu verknüpfen. Vielen Dank dafür.