it-swarm-eu.dev

Best Practices für die Online-Hilfe

wir entwickeln derzeit ein ziemlich komplexes Webportal. Um die Benutzererfahrung zu verbessern, möchten wir ein kontextsensitives Online-Hilfesystem bereitstellen, das dem Benutzer hilft, bestimmte Aspekte der Website zu verstehen.
In unserem Fall verfügt die Site über eine Vielzahl von Widgets, die alle Arten von Tabellendaten, Grafiken usw. anzeigen. Beispielsweise kann ein solches Widget das VIX und ein Hilfesystem bieten eine kurze Beschreibung des VIX.

Jetzt habe ich mich im Internet umgesehen und einige interessante Artikel gefunden, wie zum Beispiel Design Checklists for Online Help , aber das meiste, was ich gefunden habe, scheint ziemlich veraltet zu sein. Was mich besonders interessiert, sind Designprobleme wie diese:

  • ob (oder wann) Popups, Divs oder Links zu externen Seiten verwendet werden sollen
  • wie umfassend sollte der Hilfeeintrag sein? Wie viel ist der durchschnittliche Benutzer bereit zu lesen?
  • was ist ein guter Weg, um Zugang zum Hilfesystem zu erhalten? Das Überladen der Benutzeroberfläche mit Fragezeichen-Symbolen ist sicherlich nicht optimal
  • sollte der Hilfeeintrag bei Bedarf mit AJAX (irgendwie scheiße, Sie möchten die Informationen sofort)) geladen oder vorab geladen werden (was zu unnötigem Datenverkehr führt)
  • andere Dos und Don'ts

Die Antworten auf einige dieser Fragen mögen offensichtlich erscheinen, aber wenn es um Benutzerfreundlichkeit geht, habe ich die Erfahrung gemacht, dass die intuitive Antwort nicht immer die beste ist. Zweitens bin ich ein Softwareentwickler und als solcher neige ich dazu, Dinge aus der Sicht eines Ingenieurs zu betrachten. Und ich denke, wir alle wissen, dass dies meistens ein ziemlich schlechter Blickwinkel ist, um sich dem Design einer Benutzeroberfläche zu nähern. Aus diesem Grund würde ich sehr gerne Feedback von Leuten erhalten, die mehr Erfahrung auf diesem Gebiet haben.

34
n3rd

Ich werde eine enge Antwort einbringen, daher werde ich nicht alle Ihre Fragen beantworten.

  • Untersuchungen, die Andrea Ames vor einigen Jahren auf einer Minikonferenz auf dem UBC-Campus in der Innenstadt durchgeführt hat, haben ergeben, dass eingebettete Unterstützung und Benutzerfreundlichkeit besser sind als Hilfe. Sie erzählte die Geschichte, wie sie drei verschiedene Hilfemethoden mit/in einer Haushaltsfinanzsoftware verglichen hat. Benutzer betrachten eingebettete Unterstützung nicht als eine Form der Hilfe und berichten, dass sie "lediglich die Software verwenden", anstatt die Informationen zu verwenden, die sie anweisen und durch die Software führen. Wenn Benutzer häufig mit einem Problem befasst sind, ist das Letzte, was sie tun möchten, das Deaktivieren und Starten von etwas anderem. Für viele Benutzer passt das Starten der Hilfe zur Kategorie "etwas anderes" - wie unlogisch das auch sein mag. Das letzte, was ich hörte, war, dass Andrea für IBM arbeitete. Von eingebettete Unterstützung Ich beziehe mich nicht auf Beschriftungen und Schaltflächennamen, sondern auf Text, der direkt in einer Benutzeroberfläche angezeigt wird, deren Funktion darin besteht, den Kontext zu orientieren, zu erklären, anzuweisen und bereitzustellen.

  • Lois Hawk berichtete über eine unwillkürliche Reaktion im Gehirn, die als drohende Reizreaktion bezeichnet wird. Wenn sich etwas unerwartet in Ihrem Gesichtsfeld ändert - wie ein Tiger -, reagiert Ihr Gehirn wie folgt: 1) Spülen Sie das Kurzzeitgedächtnis, 2) setzen Sie etwas Adrenalin frei, um sich auf die Aktion vorzubereiten, und 3) führen Sie einen visuellen Scan der Umgebung durch. Sie können sich wahrscheinlich vorstellen, dass ein Popup, wenn es auch diese nfreiwillige Antwort auslöst und daher das Kurzzeitgedächtnis Ihrer Benutzer mit Ihren Hilfe-Popups leert und deren Stress erhöht, dies nicht tut Sie werden sicher sein, warum sie die Erfahrung nicht mögen, aber sie werden es nicht mögen. Dieses Forschungspapier befindet sich im Verlauf der STC Joint Region 7 & 8-Konferenz in Honolulu im Jahr 2000 (ich denke, das war das Jahr). Es ist schwierig, eine Kopie davon zu finden.

23
JeromeR

Es kann schwierig sein, Leute zum Lesen zu bringen. Manchmal gehen sie davon aus, dass sie wissen, was Sie wollen, und weigern sich, die Hilfe zu lesen. Die offensichtliche Antwort wäre, Ihre App so einfach zu gestalten, dass keine Erklärung erforderlich ist. Aber es ist nicht immer so einfach und es ist etwas, mit dem ich lange zu kämpfen hatte.

In Bezug auf die kontextspezifische Hilfe habe ich mich dafür entschieden, die Hilfe immer dann anzuzeigen, wenn Sie sich auf ein Textfeld konzentrieren. Das orangefarbene Feld unten ist beispielsweise nur sichtbar, wenn das Postleitzahl-Textfeld den Fokus hat ... alt text

Auf diese Weise muss der Benutzer nicht auf ein Symbol klicken, damit die Hilfe angezeigt wird. Es wird nur natürlich erscheinen, wenn sie die App ausfüllen.

Das funktioniert natürlich nicht bei allem. Es funktioniert nicht für Optionsfelder oder Kontrollkästchen, daher müssen Sie Ihren eigenen Mechanismus für diese erfinden. Die kleinen Informationssymbole i funktionieren neben einer Frage gut.

Ich werde versuchen, einige Ihrer anderen Fragen zu beantworten ...

ob (oder wann) Popups, Divs oder Links zu externen Seiten verwendet werden sollen

Niemand mag Popups. Versuchen Sie nach Möglichkeit, neben jedem Feld eine leere Stelle zu finden, an der die Hilfe wie oben abgebildet angezeigt werden kann. Auf diese Weise wird nichts verdeckt. Halten Sie alles (einschließlich Ihrer Hilfe) so kurz wie möglich, während Sie den Punkt dennoch vermitteln.

sollte der Hilfeeintrag bei Bedarf mit AJAX (irgendwie scheiße, Sie möchten die Informationen sofort)) geladen oder vorab geladen werden (was zu unnötigem Datenverkehr führt)

Sie müssen Ihre Optionen hier danach abwägen, mit wie viel Hilfetext Sie es zu tun haben. Wenn Sie die gzip-Komprimierung trotzdem verwenden, ist es möglicherweise keine große Sache, alles im HTML-Code zu belassen.

12
Steve Wortham

Ich bin teilweise an Tooltipps interessiert oder rufe Bereiche auf, die immer sichtbar sind und grundlegende Anweisungen geben, und verweise dann auf eine erweiterte kontextbezogene Hilfe. QuickInfos befinden sich in der Regel auf Fragezeichen oder Ähnlichem. Wenn jedoch Lose benötigt werden, verwenden Sie zu diesem Zweck lieber einen einfachen Beschriftungsbereich, der sich im ursprünglichen Entwurf befindet.

Der Tooltip oder Call-Out verwendet eine ID, um die Navigation zum richtigen Hilfeelement zu ermöglichen. Ich öffne kein neues Fenster/Tab/Popup/Div, aber wenn sie erweiterte Hilfe benötigen, bringe ich sie zu dieser Seite mit einem markanten Link ZURÜCK, der die Bildschirm-ID und die Tooltip-/Callout-ID verwendet, um sie zurückzugeben die richtige Stelle, wobei alle Formulare ausgefüllt bleiben.

Da es sich um eine erweiterte Hilfe handelt, greife ich immer noch auf den "RoboHelp" -Hilfestil zurück, bei dem Links zu verwandten Elementen und eine vollständige Hilfe zur Navigation vorhanden sind. Da die meisten Anwendungen, an denen ich arbeite, mit unterschiedlichen Zugriffsebenen/Benutzertypen/Rollenattributen authentifiziert sind, können Sie in der Hilfe anhand des Benutzertokens entscheiden, welche Informationen angezeigt werden sollen.

Hoffe, einiges davon ist hilfreich und adressiert die meisten Ihrer Punkte.

4
Susan R

Wenn sich Ihre Anwendung auf ein bestimmtes Thema konzentriert und voller Akronyme/seltsamer Begriffe ist, wissen Benutzer, dass es sich um eine fokussierte App handelt (die ihnen Produktivität bringen kann, wenn sie sie lernen), und möchten eine Lernerfahrung machen. Das Problem ist, dass diese Bereitschaft nur für die erste bis dritte Begegnung gilt.

Bei der ersten Verwendung können Sie den Benutzer fragen, ob er ein geführtes Tutorial möchte. Sie können dies wie einen Assistenten in Schritten erstellen, in denen hervorgehobene Elemente dargestellt werden, oder Sie können sich anhören, worauf der Benutzer klickt/sich darauf konzentriert, und Hilfe für das aktuelle Element bereitstellen. IMO ist dies wie ein Tutorial-Spielerlebnis, man lernt die Steuerung, man bekommt das Ziel. Der Benutzer sollte in der Lage sein, dieses Tutorial jederzeit zu beenden, zurück zu kommen, wenn er möchte, und zu überprüfen, ob die Einladung zum Tutorial nicht erneut angezeigt wird. Diese Erfahrung sollte für Anfänger bereitgestellt werden.

Für mittelschwere/fortgeschrittene Benutzer sind Akronyme und Titel-/Tooltip-Elemente meiner Meinung nach gerade genug (wenn Sie eine klare IA und intuitive/konsistente Elemente haben). Tooltips bleiben dem Benutzer nicht im Weg, aber gibt es sie, bei denen der Benutzer jemals Hilfe benötigt, ohne zu nerven. Sie sollten ziemlich diskret gestaltet sein, aber dennoch beobachtbar.

3

Dies ist ein Link zur Verwendung des Live-Chats als Tool für die Online-Hilfe. Ich hoffe, dies hilft https://www.experienceux.co.uk/ux-blog/2017/05/30/6-steps -zu-liefern-erstklassige-Live-Chat-Benutzererfahrung /

Zusammenfassung des Beitrags:

  1. Machen Sie den Live-Chat-Aufruf zum Handeln leicht sichtbar/zugänglich (z. B. unten rechts auf der Website).

  2. Machen Sie mehr auf die Handlungsaufforderung aufmerksam, indem Sie sie nach dem Rest des Seiteninhalts laden (z. B. einige Sekunden später).

  3. Helfen Sie mit, die Barriere „Ist das ein echter Mensch?“ Zu überwinden, indem Sie den Namen und das Foto der Person anzeigen.

  4. Erleichtern Sie Benutzern das parallele Surfen, indem Sie das Chat-Fenster vor Ort in das Browserfenster laden und es den Benutzern ermöglichen, es zu minimieren.

  5. Reduzieren Sie die Notwendigkeit für Benutzer, neue Dinge zu lernen, indem Sie den Entwurfsmustern bekannter Messaging-Dienste wie Facebook Messenger und WhatsApp folgen.

  6. Ermöglichen Sie das Minimieren des Web-Chat-Fensters, während weiterhin Benachrichtigungen über neue Nachrichten angezeigt werden.

0
Adedoyin Akande