Web3-Designprinzipien

Ein Framework von UX-Regeln für Blockchain-basierte verteilte Anwendungen (Teil 1)

Hinweis: Dieser Beitrag ist ziemlich lang> zum Spickzettel oder zu den Schlussfolgerungen springen

Blockchain-Entwickler treiben die großartige Vision einer dezentralen Zukunft voran, aber die Erfahrung dieser Vision durch die Distributed Applications (Dapps), die wir erstellen, ähnelt immer noch einem klobigen Prototyp des Web2.
 
Es ist wahrscheinlich passend, dass die meisten Benutzer, die diese Dapps verwenden würden, noch im Web2 "leben" und noch nicht einmal von den Versprechungen des dezentralen Web3 gehört haben.
Selbst wenn sie diese glänzenden neuen Apps sehen würden, würde es ihnen schwer fallen, den Jargon, den Zweck und die Dynamik dieser Dapps zu verstehen und sie sogar visuell von normalen Web-Apps zu unterscheiden.

Es muss gesagt werden, dass es viele gute Tools (Drizzle, MetaMask) gibt, die herauskommen und einige dieser Probleme angreifen. Wir werden dort ankommen.

Diese Gestaltungsprinzipien möchten einige Vorschläge zur Behebung dieses Problems unterbreiten, mit Richtlinien, die Designern und Entwicklern helfen sollen, damit wir alle diese glänzende Zukunft für alle zugänglicher und näher machen können.

Web3 Design gegen Blockchain Design

Andere haben über „Blockchain Design“ [1] geschrieben und gleichzeitig Lösungen zum Front-End-Benutzererlebnis von dezentralen Apps (Dapps) vorgestellt.

Obwohl der Artikel von Sarah Mills, Hauptdesignerin bei Consensys, eine inspirierende Lektüre ist und sie eindeutig die führende Stimme für Designer im Blockchain-Bereich ist, denke ich, dass die Formulierung „Blockchain-Design“ besser geeignet ist, die Eigenschaften und ihre Interaktionen zu definieren , des Blockchain-Konstrukts selbst: Dinge wie der Konsensalgorithmus, die Versorgungsbasis, die Blockbelohnungen, die Vollständigkeit, die Berechnungs- / „Gas“ -Kosten, die Kontrollmechanismen in oder außerhalb der Kette und vieles mehr.
 
In diesem Artikel beziehe ich mich stattdessen auf „Web3-Design“ und zeige hauptsächlich Prinzipien an, die bei der Erstellung von Benutzeroberflächen für Teile von dezentralen Apps angewendet werden sollten.

Es ist verlockend, das Wort "Blockchain" im Titel zu verwenden, aber das wäre Clickbait

Warum Web 3-Designprinzipien

Heutzutage kann ein Benutzer auf verschiedene Arten mit einem in der Blockchain bereitgestellten Smart Contract interagieren: entweder direkt über die Befehlszeile, über die formularähnlichen Schnittstellen seiner digitalen Brieftasche oder seines Dapp-Browsers oder über das umfangreichere Front-End, das der Smart Contract-Entwickler entwickelt hat hat oder wird sich entwickeln.
Es ist offensichtlich, dass der Weg zur Massenakzeptanz von Dapps durch Letzteres führt: Bereitstellung einer umfangreichen Benutzeroberfläche, die mit der Erfahrung des Umgangs mit einer Blockchain-basierten verteilten Anwendung vereinigt ist.

Heute sind wir als Entwickler zu Recht sehr damit beschäftigt, die Infrastruktur der Blockchain und die intelligenten Verträge unserer Projekte aufzubauen. Daher ist es offensichtlich, dass derzeit nicht viele Dapps ein nutzbares Front-End haben oder, wenn sie eines haben, für den Inhalt sicher sind. Sie sind hauptsächlich nicht von anderen Web-Apps zu unterscheiden.

Dapps unterscheiden sich jedoch grundlegend von normalen Web- oder mobilen Apps, da sie auf den leistungsstarken Prinzipien der Blockchain basieren und diese stark vermitteln sollten: Dezentralisierung, Transparenz, Vertrauenswürdigkeit, Unveränderlichkeit, Unempfindlichkeit usw.
Diese Eigenschaften der Blockchain und die Reflektion der Front-End-Dapps sind das, was diese Konstruktionsprinzipien in verwendbare Tools kodifizieren.

Das Ziel ist, dass ein Benutzer, der auf einem Dapp landet, nach korrekter Anwendung sofort erkennen kann, dass er mit einem Dapp interagiert, und vor allem auf die leistungsstarken Eigenschaften der Blockchain zugreifen kann und daher weiß, dass er jeder Interaktion mit der Anwendung vertrauen kann.

Zu berücksichtigende Variablen zum Verständnis der Prinzipien

  • Das Hauptziel ist ein nicht-technischer Benutzer, obwohl einige Prinzipien auch für erfahrenere Benutzer gelten
  • Nicht alle Dapps brauchen alle Prinzipien
  • Die in den Beispielen gezeigten Lösungen sind nur einige erste Ideen, um das Gespräch zu beginnen
  • Einige Prinzipien können von jedem Dapp-Entwickler auf unterschiedliche Weise implementiert werden
  • Einige Web3-Prinzipien legen die Notwendigkeit eines externen Tools, Dienstes oder einer Bibliothek nahe, anstatt sich vorzustellen, dass jeder Entwickler seine Lösung implementieren würde (mehr dazu in den nächsten Schritten).
  • Die meisten, wenn nicht alle web3-Designprinzipien würden davon profitieren, wenn sie in einer Bootstrap-ähnlichen, entwicklerfreundlichen Bibliothek codiert würden (mehr dazu in den nächsten Schritten).

Wenn Sie daran interessiert sind, fahren Sie am Ende mit dem Abschnitt „Nächste Schritte“ fort, um zu sehen, wie wir zusammenarbeiten können.

Designansatz

Beim Design geht es auch darum, Probleme zu antizipieren und Lösungen anzubieten. In diesem Fall habe ich versucht, die Fragen, die ein Benutzer bei der Interaktion mit einem Dapp haben könnte, zu „projizieren“ (ein besseres Wort meiner Meinung nach, da dies etymologisch bedeutet, in die Zukunft vorzudringen).

Fragen wie:

  • Ist es sicher, dies zu tun (action_dapp_asks_me_to_do)?
  • Wird Geld in Gefahr sein, wenn ich es vermassle?
  • Ich habe gehört, dass Krypto vertraulicher sein soll. Was passiert mit den von mir gesendeten Daten? wo wird es aufbewahrt? Kann ich identifiziert werden?
  • Wer sieht die eingegebenen Daten? Wo wird der Code ausgeführt?
  • Was wird passieren, nachdem ich dies getan habe (Aktion)?
  • wie soll ich das machen (crypto_action_here)
  • was bedeutet das (weird_crypto_word)
  • Angeblich kann der Blockchain vertraut werden, aber wie kann ich feststellen, welchen Daten in dieser App vertraut werden kann?
  • Welche Daten stammen aus der Blockchain?
  • Wie kann ich überprüfen, ob die Daten wirklich in der Blockchain gespeichert sind?
    etc.

Die Entwurfsprinzipien bieten Entwicklern Tools, mit denen sie diese und weitere Fragen beantworten können, die Benutzer möglicherweise haben.

Web 3-Designprinzipien (Index / Cheatsheet)

Dieser Beitrag ist ziemlich lang, sodass Sie dieses Cheatsheet verwenden können, um einen schnellen Überblick über die Prinzipien zu erhalten und zu denjenigen zu springen, die Sie besser verstehen möchten

//// TTT: Vertrauen durch Transparenzgestaltungsprinzipien

1 - (Daten lesen) Transparenz der Datenprovenienz

➤ Klären Sie, welche Daten aus der Blockchain stammen und welche nicht
➤ Geben Sie die Adresse des Vertrags (der Verträge) an.
➤ Verknüpfen Sie alle Blockchain-Daten mit unabhängigen Blockchain-Explorern
➤ Klären, welche Daten von Orakeln stammen (∞link> 5.Transparenz des Codes)
 - Wie> Beispiele

2 - (Schreiben von Daten) Transparenz von Transaktionen

- Arten von Transaktionen (Wertübertragungen, Funktionsaufrufe, Vertragsgenerierung)
➤ [Dauerhaft] Klärt irreversible Aktionen
➤ [Wert] Klären Sie Aktionen, die Geld oder Wert beinhalten
➤ [Datenschutz] Klären Sie Aktionen, die möglicherweise zur Benutzeridentifikation führen können
➤ [Factory] Klären Sie Aktionen, die neue Verträge im Benutzernamen erzeugen
- Richtlinien für alle Transaktionen:
- ➤ den neuen zukünftigen Zustand klären und vorab bestätigen
 - ➤ zeigen die Daten, die für eine Transaktion verwendet werden, in einem für Menschen lesbaren Format und in der Weise an, wie es der Smart Contract erfordert (∞link 5.Transparenz des Codes)
- ➤ Klären Sie die vorgeschlagenen Werte für den Gaspreis und das Überschreiben des Senders (∞Verbindung 9.Gaspreis und Transaktionsumkehr).
 - ➤ Transaktionswartezeit verwalten (∞link> 6.Time / Wait Management)
 - ➤ möglicherweise klären, welche Aktionen NICHT Transaktionen und damit sicher sind
 - Wie> Beispiele

3 - (Pushed Data) Transparenz intelligenter Vertragsereignisse

➤ Klären Sie alle Ereignisse und machen Sie sie dem Endbenutzer zugänglich, auch wenn sie nur für Entwicklerzwecke bestimmt sind
➤ Relevanz anwenden: Unterbrechungsmeldungen nur für Informationen anzeigen, die für den aktuellen Benutzer relevant sind
➤ Benutzer können bestimmte Ereignisse abonnieren, abbestellen oder vorübergehend stummschalten
 - Wie> Beispiele

4 - (Verlauf) Transparenz und Zugänglichkeit des Interaktionsverlaufs des Benutzers

➤ einen Verlauf aller Transaktionen von einer bestimmten Adresse aus bereitstellen
➤ klären, wo der Verlauf gespeichert ist (lokal oder auf dem Server) (∞link 5.Transparenz des Codes)
➤ Tools zum Navigieren, Suchen, Exportieren und Löschen des Verlaufscaches bereitstellen
 - Wie> Beispiele

5 - (Code & Umwelt) Transparenz des Codes

➤ klären, welche Blockchain verwendet wird
➤ Klären Sie die Adresse der Smart-Verträge, die für Lese- / Schreibvorgänge verwendet werden
➤ klären, welcher Code Open Source ist (und wo er zu finden ist)
➤ klären, wo Code ausgeführt wird (lokaler oder entfernter Server)
➤ Klären Sie den Web3-Anbieter / Blockchain-Knoten (lokaler Knoten, Dapp-gesteuerter Knoten, MetaMask, Infura usw.).
➤ klären Sie, ob der Dapp auf MainNet oder TestNet läuft
➤ klären, welche Daten von Orakeln stammen oder von Orakeln beeinflusst wurden (∞link> 1.Transparenz der Datenprovenienz)
➤ DIY-Code-Ausführung zulassen: Ermöglichen Sie fortgeschrittenen Benutzern, den ausgeführten Code zu sehen und selbst über die Befehlszeile auszuführen
➤ Klären Sie die für die Smart Contracts erforderlichen Eingaben
 - Wie> Beispiele

//// Allgemeine Web3 UX-Prinzipien

6 - Zeit- / Wartezeitverwaltung

➤ (Verwalten Sie die Erwartungen des Benutzers) Klären Sie Blockchain-spezifische Zeiten und verwalten Sie das Warten des Benutzers in verschiedenen Phasen
➤ (Verwalten der Wartezeit) Zeigen Sie während der Wartezeit die Aktivitätsindikatoren an
 - Wie> Beispiele

7 - Vom Menschen lesbare Hashes-Formate

➤ zeigen eine kompakte Version der Hashes, aber immer die Anfangs- und Endteile
➤ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵ ̵
➤ Stellen Sie immer das "0x" voran, um anzuzeigen, dass es sich um einen Hash handelt
➤ Benutzer können die vollständige Adresse / den Hash erweitern
➤ Benutzer können es leicht kopieren
➤ Verwenden Sie nach Möglichkeit Abkürzungen als Titel und die abgekürzten Adressen als Untertitel
➤ Ermöglichen Sie dem Benutzer nach Möglichkeit, den Adressen und Hashes auf einfache Weise einen benutzerdefinierten, von Menschen lesbaren Namen oder Text zuzuordnen
➤ Wenn möglich, verknüpfen Sie eine bestimmte Form der deterministischen visuellen Darstellung des Hashs (z. B. Identicons, Blockies usw.) mit der Adresse

8 - Permanenter Anfängermodus

➤ Lerninformationen mit normaler Interaktion einbinden
➤ bieten 2 oder mehr Lerninhalte: Blockchain-Grundlagen und Dapp-spezifische Fachsprache
➤ Minimieren und erhöhen Sie schrittweise die Menge an neuen Dingen und Konzepten, die der Benutzer lernen muss
➤ falls möglich oder relevant, beschleunigen Sie das Lernen, indem Sie die Interpretation des Experten bereitstellen.
➤ Verlieren Sie nicht den Kontext
 - Wie> Beispiele

9 - Gaspreis- und Transaktionsumkehr

➤ klären, was ist Gas und Gaspreis (wie bei jedem anderen Jargon Link 8.Newbie-Modus)
➤ Schlagen Sie Gaspreisbereiche vor und klären Sie die Zeitnäherungen für die obere und untere Grenze
➤ möglicherweise auch in FIAT umgerechnete Gaswerte anzeigen
➤ Transaktionsstornierungen zulassen

//// DDP: Decentralization Design Principles

10 - Gemeinschaftsgefühl

➤ klären Sie, wie viele andere Mitglieder sich in der Community befinden
➤ klären, wer die anderen Mitglieder sind (entsprechende Kategorien auswählen)
➤ Klarstellung der Zusammensetzung der Community (d. H. Untergruppen und deren Macht über das Projekt)
➤ Teilen Sie die größere Mission des Projekts (falls vorhanden) und wie die Teilnahme des Benutzers zu dessen Erreichung beiträgt
 - Wie> Beispiele

11 - Zukünftige Entwurfsprinzipien zur Untersuchung (Teil 2)

➤ Identität und Ansehen
➤ Governance
➤ Brieftaschen
➤ Austausch
➤ ICO & Token Sales Mechanics
➤ Token-Mechanik

Nächste Schritte

TTT: Vertrauen durch Transparenzgestaltungsprinzipien

Web3-Postulate:

- Es ist nicht transparent, wenn Sie nicht wissen, wo und wie Sie suchen sollen
- Wenn es nicht transparent ist, kann es nicht als vertrauenswürdig eingestuft werden.

Alle in diesem Raum und ihre Mutter sprechen darüber, wie „vertrauenslos“ und „transparent“ die Blockchain ist.
Zu erklären, warum diese beiden Annahmen nur teilweise zutreffen, würde einen längeren Zeitraum in Anspruch nehmen und dazu führen, dass diese Annahme falsch ist.
Auf programmatischer Ebene ist es (fast) sicher, dass Software Daten überprüft, aber diese beiden Annahmen fallen auseinander, wenn Sie sie mit der tatsächlichen Endbenutzererfahrung konfrontieren.

Abgesehen von der Tatsache, dass viele Kryptoprojekte oder Dapp-Frontends dem Benutzer selten die Smart-Contract-Adressen anzeigen, mit denen er interagiert oder von denen die Daten stammen, ist es derzeit für einen nicht-technischen Benutzer schwierig oder unmöglich, die Informationen und Funktionen zu verstehen von unabhängigen Blockchain-Entdeckern wie Etherscan.
Das einzige, was der Benutzer heute teilweise steuern kann, ist, wenn zwischengeschaltete Wallets den Transaktions-Hash aufzeichnen, der in den oben genannten Blockchain-Explorern überprüft werden kann.

Wenn ein Benutzer, insbesondere ein nicht technischer Benutzer, auf der Benutzeroberfläche nicht erkennen kann, ob es sich bei einem Dapp tatsächlich um ein Dapp oder eine normale Webanwendung handelt, kann er auch nicht überprüfen, ob der Inhalt angezeigt wird oder ob er damit interagiert Sind sie tatsächlich mit einer Blockchain verwandt, erhält sie nicht die Vertrauenswürdigkeit und Transparenz, die die Blockchain liefern soll.

Die Web3-Designprinzipien in dieser Kategorie (TTT) schlagen einen radikalen Transparenzansatz vor, der es jedem Dapp-Front-End-Benutzer, auch nicht-technischen, ermöglicht, die Datenherkunft vollständig zu kennen und die Auswirkungen von Transaktionen vor, während und nach ihrer Ausführung zu verstehen. und letztendlich in der Lage sein, dem vorliegenden Code und Service zu vertrauen.

Zurück zum Spickzettel

1 - (Daten lesen) Transparenz der Datenprovenienz

Ein Benutzer muss in der Lage sein, zu erkennen, dass ein bestimmter Datenpunkt oder Inhalt tatsächlich in der Blockchain gespeichert ist, möglicherweise nur durch einen Blick auf die Seite. Es ist nicht benutzerfreundlich, sie raten zu lassen, und es reicht nicht aus, sie davon ausgehen zu lassen, dass "alle" angezeigten Daten in der Blockchain gespeichert sind.
Diese Anforderung mag für datenintensive Dapps wie Distributed Exchanges schwierig klingen, aber es gibt einige Lösungen, die in den Beispielen vorgestellt werden.

Grundsätze

Das Dapp-Frontend sollte:

➤ klären, welche Daten aus der Blockchain stammen und welche nicht
➤ die Adresse des Vertrags / der Verträge klären
➤ Verknüpfen Sie alle Blockchain-Daten mit unabhängigen Blockchain-Explorern
➤ klären, welche Daten von Orakeln stammen (∞link> 5.Transparenz des Codes)

Wie> Beispiele

  • Verwenden Sie CSS, um die Farbe / Schriftart / Form zu ändern, um Blockchain-Daten klar zu unterscheiden. Versuchen Sie offensichtlich, in Ihrem Projekt konsistent zu sein und immer die gleiche „Blockchain-Farbe“ zu verwenden.
Datenprovenienz AUSDatenprovenienz EIN: Färbt die Daten aus einem bestimmten Vertrag
  • Verwenden Sie erweiterbare Referenzen:
    Wenn Sie mit der Maus über einen Blockchain-Datenpunkt fahren oder auf einen Blockchain-Datenpunkt klicken, können Sie einen kontextbezogenen erweiterten Tooltip mit weiteren Informationen zu dem Datenpunkt bereitstellen, aus dem hervorgeht, wo in der Blockchain, in welchen Verträgen sich die Daten befinden.
Beispiel einer kontextbezogenen erweiterbaren Referenz
  • Styling-Konflikte mit Link-Icons verwalten
    Wenn ein Datenpunkt sowohl ein Blockchain-Datenpunkt als auch ein Link zu einer beliebigen Stelle in Ihrer App ist, gibt es zwei Möglichkeiten, die doppelte Aktion zu lösen:
    1- Fügen Sie ein Verknüpfungssymbol hinzu, ein Symbol, das auf einen „Blockchain-Datenpunkt“ folgt und die erweiterbare Referenzfunktionalität bietet, während das normale Funktionieren der Verknüpfung erhalten bleibt.
    2- Öffnen Sie die erweiterbare Referenz und fügen Sie einen sekundären Link ein (bedenken Sie jedoch, dass dies zu mehr Reibung führt, da Sie den Benutzer auffordern, zwei Aktionen anstatt einer durchzuführen).
Beispiel eines Verknüpfungssymbols, das die Kontextreferenz öffnet. Dies dient zum Hinzufügen der chainView-Funktionalität zu einem Link, der sich irgendwo in Ihrer App befindet
  • Verwenden Sie einen "Chain-View" -Modus und / oder eine Seitenwand
    Für datenintensive Schnittstellen wie Decentralized Exchanges oder Market Views würde das Befolgen der vorherigen Vorschläge wahrscheinlich bedeuten, den Großteil der Schnittstelle zu gestalten, was wahrscheinlich mehr Verwirrung stiftet. Um dies zu lösen, können Sie sich eine Schaltfläche "Kettenansicht" vorstellen, die die Daten vorübergehend formatiert, wenn Sie den Mauszeiger darüber bewegen oder darauf klicken. Es ist so, als würde man einen Filter über die Seite setzen. Mit diesem Filter kann der Benutzer erkennen, welche Daten ein Blockchain-Datenpunkt sind.
     
    Als Erweiterung dieser Idee könnte die „Kettenansicht“ auch ein Seitenbereich sein, in dem viele der in den Web3-Designprinzipien beschriebenen Funktionen gehostet werden können. In diesem Fall verfügt das Bedienfeld "Kettenansicht" möglicherweise über die oben genannte Option, die Sichtbarkeit der Blockchain-Datenpunkte zu aktivieren oder zu deaktivieren. In den nächsten Beispielen werden wir viele weitere Verwendungen des Bedienfelds "Kettenansicht" sehen.
Seitenbereich der Kettenansicht mit geöffneter Daten-Provenienz-Option
  • Zeigen Sie deutlich, welche Links den externen Blockchain-Explorer öffnen
    Wenn ein Link den Benutzer zu einer anderen Seite weiterleitet, ist es besser, den Fluss des Benutzers auf der Seite wie folgt zu steuern:
    1 - Hinzufügen eines Klärungsschalters, der angibt, was passieren wird: "In Etherscan öffnen"
    2 - Fügen Sie ein Link-Symbol für unabhängige Block-Explorer hinzu und verwenden Sie es konsistent in Ihrer Benutzeroberfläche

Zurück zum Spickzettel

2 - (Schreiben von Daten) Transparenz von Transaktionen

Der Benutzer muss sich darüber im Klaren sein, dass Daten in die Blockchain geschrieben werden, insbesondere dann, wenn ein wirtschaftlicher Wert (Kryptowährungen oder Token) ausgetauscht werden muss. Auch wenn Wallets den Benutzer vor dieser Absicht warnt, sollte der Dapp dies klären, bevor er die Transaktionsanforderung an den Wallet sendet.

Arten von Transaktionen

Es gibt verschiedene Arten von Transaktionen, die bei der Interaktion mit der Blockchain auftreten können und jeweils unterschiedliche Konsequenzen haben.
Der Benutzer sollte in der Lage sein, sie anhand der von der Benutzeroberfläche bereitgestellten Informationen in verschiedenen Phasen zu unterscheiden, noch bevor die Transaktion gestartet wird.

2.1 - Wertübertragungen
 - 2.1.1 - ETH
 - 2.1.2 - Token
 2.2 - Funktionsaufrufe
 - 2.2.1 - Vertragsmethoden mit wertmäßigen Auswirkungen
 - 2.2.2 - Vertragsmethoden ohne Wertübertragung
 2.3 - Fabriken: Funktionen zur Auftragserzeugung

Transaktionsdaten und Kosten

Transaktionen haben normalerweise eine "Nutzlast", einige Daten werden angehängt, zum Beispiel an die Vertragsmethoden übergeben, und diese werden normalerweise verwendet, um zu schreiben oder zu berechnen, was in die Blockchain geschrieben werden soll.

Darüber hinaus ist das Schreiben von Daten in die Blockchain in der Regel kostenpflichtig und mit einer „Gasgebühr“ für die Transaktion verbunden.
Der Benutzer sollte diese beiden Informationen verstehen und auf ihren Inhalt aufmerksam gemacht werden.

Grundsätze

Das Dapp-Frontend sollte:

➤ (Permanence) Klären Sie irreversible Aktionen (alle schreibenden Txs).

➤ (Wert) Klären Sie Aktionen, die Geld oder Wert beinhalten

➤ (Datenschutz) Klären Sie Aktionen, die möglicherweise zur Benutzeridentifikation führen können
Dies ist eines der am schwierigsten umzusetzenden Prinzipien, da potenziell das Schreiben von Daten dazu beitragen kann, den Benutzer zu identifizieren (bis ZTKSnarks), und wir als Smart-Contract- und Web3-Entwickler sind uns möglicherweise der aktuellen und zukünftigen Weiterentwicklung von forensischen Tools nicht bewusst in der Regel Closed-Source-Lösungen. Berücksichtigen Sie einfach dieses Prinzip, wenn der Datenschutz ein Hauptmerkmal Ihres Dapp ist, und verwenden Sie es, um die Entwurfsentscheidungen zu treffen, um zu klären, welche Aktionen potenzielle Risiken für Ihre datenschutzinteressierten Benutzer darstellen.

➤ (Werkseitig) Klären Sie Aktionen, die neue Verträge im Benutzernamen generieren
Dieses Prinzip gilt nur für Dapps, mit deren Hilfe der Benutzer Verträge mit seiner Adresse als Ersteller der Nachricht erstellt. Wenden Sie dies besonders an, wenn es sich um ein MainNet-Gerät handelt.

Richtlinien für alle Transaktionen:

➤ klären und bestätigen Sie im Voraus den neuen zukünftigen Zustand
➤ Zeigen Sie die Daten, die für eine Transaktion verwendet werden, in einem für den Menschen lesbaren Format und so an, wie es der Smart Contract erfordert (∞Link 5. Transparenz des Codes).
➤ Erläutern Sie die vorgeschlagenen Werte für den Gaspreis und das Überschreiben des Senders (∞Verbindung 9.Gaspreis und Transaktionsumkehr).
➤ Verwalten der Transaktionswartezeit (∞link> 6.Time / Wait Management)
➤ Nachdem die Transaktion aufgezeichnet wurde, zeigen Sie dem Benutzer eine relevante Zusammenfassung der Transaktion und wie er auf den Verlauf zugreifen kann (∞Link 4. Benutzerinteraktionsverlauf).
➤ Klären Sie möglicherweise, welche Aktionen NICHT Transaktionen und damit sicher sind

Wie> Beispiele

  • Verwenden Sie CSS, um alle irreversiblen Aktionen anzuzeigen
    Verwenden Sie möglicherweise eine Warn- / Markierungsfarbe wie Rot
  • Fügen Sie zusammen mit der Schaltfläche eine winzige schriftliche Warnung hinzu
    dh: Aufmerksamkeit irreversibles Handeln voraus> Erfahren Sie mehr
  • benutze die doppelte Bestätigung:
    Öffnen Sie ein Popup oder einen Toast, nachdem der Benutzer die Taste gedrückt hat und bevor Sie die Brieftasche / MetaMask aufrufen. Dort können Sie den Benutzer über alle Auswirkungen informieren und eine Bestätigung anfordern.
    Bieten Sie dem Benutzer außerdem Folgendes an:
     - die Aktion abbrechen
     - Zeigen Sie diese Popups nie wieder an (da sie eine erfahrene Benutzerin ist) und teilen Sie der Benutzerin dabei mit, dass sie die Funktion im Chain-View-Seitenbereich möglicherweise reaktivieren kann.
  • Klären und antizipieren Sie die zukünftig erwarteten Schritte
    Entweder mit winzigen schriftlichen Beschreibungen, Untertiteln für Beschriftungen oder mit assistentenartigen Abläufen, die mehr Schritte zum Ausführen einer Aktion enthalten.
    Bei Assistenten:
     - Zeigen Sie dem Benutzer deutlich die Nummer und den Titel der nächsten Schritte
     - Ermöglichen Sie dem Benutzer, die zukünftigen Bildschirme zu inspizieren, um zu verstehen, was los ist und was passieren wird (∞Link 8.Newbie-Modus), obwohl Sie auch die Funktionalität ausblenden sollten, um nicht die Tatsache zu verwechseln, dass sie einen Sneak Peak haben kann Vorschau mit der aktuellen Aktion.
  • Fügen Sie dem Seitenbereich von Chain-View Optionen hinzu
    Das Seitenpanel könnte der Ort für viele dieser Warnungen sein sowie einen Inspektor in die Transaktionen einweisen und definieren
     - die Art der Transaktion
     - die mit der Transaktion verbundenen Daten
     - die Gaskosten
     - alle anderen relevanten Informationen (∞link 5.Transparenz des Codes)

Zurück zum Spickzettel

3 - (Pushed Data) Transparenz intelligenter Vertragsereignisse

Ereignisse sind die Benachrichtigungen der Web3-Ära

(Ethereum) Smart-Contracts können Ereignisse ausgeben, die verwendet werden, um Protokolle in der Blockchain zu speichern und Dapps Frontends reaktiv über Javascript zu informieren, dass etwas passiert ist.

Es ist wichtig, diese Ereignisse zu verstehen
 - können Parameter und Informationen zu den Protokollen hinzugefügt werden
 - sind dauerhaft in der Blockchain gespeichert und können daher gesucht werden
 
Ereignisse werden normalerweise von Entwicklern für verschiedene Zwecke verwendet, z. B. zum Signalisieren, wenn eine bestimmte Bedingung erfüllt ist oder eine bestimmte Aktion ausgeführt wurde: Ein neuer Benutzer wurde Token-Inhaber, es wurde eine Einzahlung getätigt oder es wurden Daten von einem empfangen Oracle und viele mehr.

Die Tatsache, dass nach Ereignissen gesucht werden kann, ist immens nützlich, um das Verhalten eines bestimmten Dapp zu protokollieren und zu verstehen, was seit der Dapp-Erstellung in Tausenden oder Millionen von Blöcken wann passiert ist.

Um besser zu verstehen, warum dies so wichtig ist, erzähle ich Ihnen schnell eine persönliche Geschichte:
Als das Dao im Jahr 2016 gehackt wurde, hatte ich die Möglichkeit, mit der Gruppe zusammenzuarbeiten, um einen Teil des großen Problems zu lösen: zu verstehen, wem welche Ethermenge vom ExtraBalance-Konto geschuldet wurde.
Wenn Benutzer während des ICO Dao-Token kauften, flossen gemäß der Gebührenordnung unterschiedliche Mengen an Äther in das ExtraBalance.
Zwei der Problemlöser der Gruppe, Nick Johnson und Bokky Poobah, verwendeten das "CreatedToken" -Ereignis, um alle Transaktionen im Zusammenhang mit dem DAO ICO nachzuverfolgen, während ich mir eine Situation vorstellte, in der Events nicht implementiert und entwickelt worden waren Ein deterministischer Parser für die Blockchain, ein forensisches Tool, das bei böswilligen oder schlecht geplanten Smart-Verträgen sehr nützlich ist. Ich habe dies auch getan, weil es kein Ereignis wie "ReceivedByExtraBalance" gab, um diesen Teil der Transaktion genau zu bestimmen.
Hier wird es interessant: Während ihre Skripte einige Stunden dauern würden, würde meine einen Tag oder länger dauern; Das liegt daran, dass ich jede einzelne Transaktion in der Blockchain durchlaufen (erneut ausführen) musste, während sie dank der Ereignisprotokolle bereits Zugriff auf die (fast) „richtigen“ Transaktionen hatten.
Trotzdem brauchten wir drei ungefähr zwei Monate, um die Zahlen abzustimmen und den gesamten Restbetrag an die ursprünglichen Eigentümer zurückzugeben.

Was hat das mit den Web3 Design Principles zu tun?
Ereignisse werden von den Entwicklern willkürlich verwendet: Sie können wählen, ob sie ein Ereignis setzen oder nicht, um etwas Wichtiges über ihre App zu signalisieren. Es ist transparent, dem Front-End-Benutzer Zugriff auf die Ereignisse im Smart Contract zu gewähren.

Ein hohes Maß an nützlichen Ereignissen kann ein Zeichen für einen transparenten Smart Contract und Dapp sein, der keine Angst davor hat, Ihnen mitzuteilen, was er intern tut. Während kleine bis keine Ereignisse ein Zeichen für einen schlampigen oder gar bösartigen Smart Contract sein können.

Wie in der obigen DAO-Geschichte würde das Fehlen von Ereignissen eine Benutzerin dazu zwingen, ihre eigenen deterministischen Blockchain-Parser zu entwickeln, um zu verstehen, was im Inneren passiert. Eine praktisch unmögliche Aufgabe, auch weil sie einen Archivierungsknoten benötigen würde.

Darüber hinaus sind Ereignisse für Entwickler nützlich, um verschiedene Arten von Analysen, Benachrichtigungen und reaktiven Datenquellen zu erstellen, auch unabhängig vom Smart Contract-Eigentümer / -Ersteller. Möglicherweise sollte diese Leistung auch dem Front-End-Benutzer zur Verfügung gestellt werden, ohne dass Code erforderlich ist.
 
Web3-Postulate:

- Es ist keine Transparenz, wenn es eines großen Aufwands bedarf, die Daten zu finden, zu sehen und zu überprüfen
 - Es ist nicht transparent, ob 99% der Nutzer davon abgehalten werden, nachzuschauen. [2]

Grundsätze

Ein Dapp-Frontend sollte:

➤ Klären Sie alle Ereignisse und machen Sie sie dem Endbenutzer zugänglich, auch wenn sie nur für Entwicklerzwecke bestimmt sind

➤ Relevanz anwenden: Unterbrechungsmeldungen werden nur für Informationen angezeigt, die für den aktuellen Benutzer relevant sind, der Benutzer kann jedoch weiterhin alle Ereignisse in einer separaten Benutzeroberfläche überprüfen

➤ dem Benutzer das Abonnieren, Abbestellen oder vorübergehende Stummschalten bestimmter Ereignisse ermöglichen

Ereignisse sind vertragsspezifisch, sodass dies einfache Vorschläge für mögliche Implementierungen sind.
Darüber hinaus können diese Ideen besser durch ein externes Tool, einen Dienst, ein Plugin oder eine Bibliothek gelöst werden, ohne dass die Dapp-Front-End-Entwickler all diese "Nicht-Core" -Funktionen in ihre Dapp implementieren müssen.

Wie> Beispiele

  • Wenn Sie über ein Benachrichtigungscenter verfügen, auf das der Benutzer zugreifen kann, handelt es sich wahrscheinlich um einen Abschnitt im Seitenbereich von "Chain-View"
  • Verwenden Sie Toasts für wichtige Nachrichten
  • Erstellen Sie Filter, um nur bestimmte Ereignisse auszuwählen oder deren Auswahl aufzuheben, oder passen Sie Benachrichtigungen nur auf der Grundlage bestimmter Parameter an.
     Einige Filter können sein:
     - wenn es Ether / Token enthält
     - basierend auf der Adresse (meine / die des Benutzers oder eine andere Adresse oder Adressen)
     - zwischen timeX und timeY, blockX und blockY
    etc.

Zurück zum Spickzettel

4 - (Verlauf) Zugänglicher und transparenter Benutzerinteraktionsverlauf

In einer Zukunft, in der wir mit Hunderten oder Tausenden von Dapps, Tokens und wahrscheinlich Ketten interagieren, ist es sinnvoll, dass die Benutzerin eine eindeutige Historie ihrer Interaktionen mit jedem dieser Dapps zur späteren Bezugnahme aufzeichnet.
 
In Brieftaschen wird bereits der Verlauf aller Transaktionen gespeichert. Dies ist ein Anfang, jedoch nur für jeweils ein Konto. Daher kann es schwierig sein, herauszufinden, ob Sie über mehrere von ihnen interagiert haben.
Darüber hinaus wären Brieftaschen immer noch schwierig, wenn keine zusätzlichen Funktionen erstellt würden, um beispielsweise nur diejenigen herauszufiltern, die zu einem bestimmten Dapp gehören.

Es ist sicherlich benutzerfreundlich für einen Dapp, sich an jede Interaktion zu erinnern, die Sie damit gemacht haben, genauso wie Sie in jeder normalen App zum "Kaufverlauf" zurückkehren können.

Es ist noch wichtiger für Distributed Exchanges und Dapps, die Hunderte oder Tausende von Transaktionen für jeden Benutzer generieren können.

Grundsätze

Ein Dapp-Frontend sollte:

➤ einen Verlauf aller Transaktionen von einer bestimmten Adresse aus bereitstellen
Ermöglichen Sie dem Benutzer, alle jemals mit dem Smart Contract vorgenommenen Interaktionen zu überprüfen, wahrscheinlich hauptsächlich solche vom Typ 2, die in die Blockchain schreiben und daher den Status ändern

➤ klären, wo der Verlauf gespeichert ist
Um einen Verlauf in Bezug auf einen bestimmten Benutzer bereitzustellen, müssen Sie wahrscheinlich die Transaktionshashes in einer Datenbank aufzeichnen, entweder auf einem Remote-Server oder besser in der lokalen Index-Datenbank des Benutzers. Dies stellt natürlich ein potenzielles Datenschutzrisiko dar. Beachten Sie daher die Datenschutzgrundsätze (∞link 2.Transparenz von Transaktionen) und die Grundsätze der Codetransparenz (∞link 5.Transparenz von Codes), um dem Benutzer zu verdeutlichen, wo diese Daten gespeichert sind.

➤ Tools zum Navigieren, Suchen, Exportieren und Löschen des Verlaufscaches bereitstellen

Wie> Beispiele

  • Ähnlich wie bei der Ereignisbenachrichtigungszentrale haben Sie eine Registerkarte "Benutzerhistorie" oder eine spezielle Seite, wahrscheinlich in der Seitenleiste der Kettenansicht
  • Ermöglichen, nach verschiedenen Arten von Transaktionen zu filtern (value-eth, value-tokens, Funktionsaufrufe, Vertragserstellung, falls zutreffend)
  • Erlaube das Filtern nach Datum, von Anfang an oder zwischen Daten
  • optionale benutzerfreundliche Hinzufügung: Ermöglichen Sie Benutzern, der Transaktion ein Feld für nicht verkettete Notizen hinzuzufügen, z
  • Optional: Haben Sie ein Suchfeld, falls es Hunderte von Interaktionen gibt und dies für Ihr Dapp relevant ist
    Das heißt: Dezentrale Börsen möchten möglicherweise eine solche Funktion hinzufügen, damit der Benutzer nach Transaktionen suchen kann, die sich nur auf bestimmte Token beziehen
  • export: Ermöglicht dem Benutzer, die Daten optional in csv zu exportieren und auf andere Weise zu untersuchen. Dies ist insbesondere bei großen Datenmengen sinnvoll
  • Löschen: Ermöglicht es dem Benutzer, den Verlauf aus dem lokalen Cache zu löschen. Es muss jedoch klargestellt werden, dass der tatsächliche Verlauf von Transaktionen weder aus seiner Brieftasche noch aus der Blockchain gelöscht wird
  • importieren: Es ist nur dann sinnvoll, eine Importoption hinzuzufügen, wenn der Benutzer mit dem Dapp jeder Transaktion benutzerdefinierte Notizen hinzufügen kann. Andernfalls können die Informationen einfach aus der Blockchain rekonstruiert werden

Zurück zum Spickzettel

5 - (Code & Umwelt) Transparenz des Codes

Wenn ein Dapp vertrauenswürdig ist, bedeutet dies auch, dass der ausgeführte Code vertrauenswürdig ist.
Um vertrauenswürdig zu sein, sollten Dapps in allen Aspekten ihres Codes so transparent wie möglich sein.

Web3-Postulate

- Damit ein Dapp als vertrauenswürdig eingestuft wird, muss sein Code als vertrauenswürdig eingestuft werden
 - Damit Code einigermaßen vertrauenswürdig ist, muss er transparent, unabhängig ausführbar und überprüfbar sein

Grundsätze

Ein Dapp-Frontend sollte:

➤ Klären Sie, welche Blockchain verwendet wird
Es scheint offensichtlich, aber in einem Szenario mit sich vermehrenden Dapps können viele Blockchain-Agnostiker sein oder verschiedene Versionen auf verschiedenen Ketten ausführen. Auch mit Plasma, Polkadot, Cosmos und anderen Skalierungslösungen kann ein Dapp Transaktionen in seiner eigenen Unterkette verfolgen, die tief in einem Baum aus anderen Plasmaketten oder anderen Fallschirmen oder Cosmos-Zonen oder Hubs verschachtelt ist. Der Benutzer sollte über den Ort informiert werden, an dem seine Daten geschrieben werden, und daher über die technischen Variablen (Sicherheit, Geschwindigkeit usw.) und über den Ort, an dem er die Daten unabhängig überprüfen kann.

➤ Geben Sie die Adresse der Smart-Verträge an, die für Lese- und Schreibvorgänge verwendet werden
und Verknüpfung zu unabhängigen Blockchain-Explorern (∞ Verknüpfung 1.Transparenz der Datenprovenienz).

➤ Klären Sie, welcher Code Open Source ist und wo er zu finden ist.

➤ Stellen Sie fest, wo Code ausgeführt wird (lokal oder Remote-Server)
Dies ist möglicherweise eine der schwierigsten und umständlichsten Implementierungen auf visueller Ebene. Wenn jedoch Teile auf einem Server ausgeführt werden müssen, muss auf mindestens einer Seite erläutert werden, welche Teile und warum und von welchen relevanten Teilen der Benutzeroberfläche darauf verwiesen werden.
Wenn der in den Beispielen der ersten Prinzipien (∞link 1.Transparency of Data Provenance) gezeigte Modus „Chain-View“ implementiert wurde, ist dies ein guter Ort, um diese anderen Ansichten hinzuzufügen.
 
➤ Erläutern Sie den Web3-Anbieter / Blockchain-Knoten (lokaler Knoten, Dapp-gesteuerter Knoten, Infura, MetaMask? Oder anderer Knoten).
Warum? Weil instrumentierte Knoten Daten wie Etherscan aufzeichnen können und potenziell eine Quelle von Datenschutzrisiken für den Benutzer darstellen können.
 
- Wenn möglich oder relevant, erlauben Sie Benutzern, zu ihrem eigenen Knoten zu wechseln
Obwohl dies bereits von Anbietern wie MetaMask erledigt wird, gilt dieses Prinzip für den Fall, dass Ihre web3-App aus irgendeinem Grund Transaktionen an bestimmte Knoten sendet. Außerdem können Transaktionen, die über Ihren eigenen privaten Knoten laufen, schneller ausgeführt werden, da sie die potenziellen Warteschlangen öffentlicher Knoten vermeiden, insbesondere bei Ereignissen mit hoher Nachfrage wie Crowdsales.

➤ Stellen Sie fest, ob die App im MainNet oder im TestNet ausgeführt wird
Stellen Sie sicher, dass der Benutzer versteht, dass im MainNet Aktionen ausgeführt werden, wenn dies der Fall ist (beachten Sie auch die anderen Grundsätze in ∞Link 2.Transparenz von Transaktionen).

➤ Stellen Sie fest, welche von der Kette gelesenen Daten von Orakeln stammen oder von Orakeln beeinflusst wurden

Benutzerfreundliche Ergänzungen
➤ Ermöglichen Sie die Ausführung von DIY-Code
Fortgeschrittene Benutzer können den Transaktionsfunktionsaufruf sehen, bevor er gesendet wird, damit sie ihn überprüfen und die Aktion selbst über die Befehlszeile reproduzieren können.
Dies mag übertrieben erscheinen, da das Dapp-Front-End dazu dient, den Benutzer zu vereinfachen und bestimmte technische Angelegenheiten zu verbergen. Ein skeptischer / paranoider Benutzer möchte jedoch auch nur einzelne Transaktionen überprüfen: Wenn die Blockchain wie eine verteilte Datenbank ist, sollte ein Benutzer dies tun in der Lage sein, die Schreibvorgänge unabhängig durchzuführen, und der Dapp sollte weiterhin funktionieren.
In einer radikalen Transparenzhaltung gegenüber dem Code signalisiert ein Dapp, das diese Funktion zulässt, "Don’t Trust. Überprüfen Sie "https://blog.wizsec.jp/2018/02/kleiman-v-craig-wright-bitcoins.html?m=1"

Eine erweiterte Version von Data Provenance, bei der die Benutzer den Code auch kopieren und einfügen können, um die Daten selbst abzurufen

➤ Klären Sie die vom Smart Contract geforderten Eingaben:
Intelligente Verträge erfordern häufig große Zahlen mit vielen Nullen, die für den Benutzer unfreundlich sind, insbesondere weil es sehr leicht ist, kostspielige Fehler zu machen. Es ist normal und ratsam, dass die Dapp-Benutzeroberfläche diesen Prozess für den Benutzer vereinfacht und kleinere Zahlen in einem verständlicheren und weniger fehleranfälligen Bereich wie 0 bis 100 zulässt. Angesichts der vorherigen Transparenz der Code-Prinzipien sollte dies jedoch erfolgen Machen Sie dem Benutzer klar, wo diese Eingaben von der Benutzeroberfläche vereinfacht werden, und klären Sie insbesondere im DIY-Code-Inspektor die tatsächlichen Eingaben, die der Smart Contract erwartet.
Ein realer Fall, in dem dies verwirrend war, wurde in einer Diskussion mit Jorge Izquierdo über die Aragon Voting-App angesprochen. Entwickler können dieselbe Lösung für diesen Fall verwenden und dem Benutzer einige Beispiele erläutern: die einfache Nummer, die wissenschaftliche Notation und die tatsächliche Eingabe (mit allen Nullen), die der Smart Contract erwartet.

Detail des Beispiels aus dem Aragon-Wiki

Wie> Beispiele

  • Auf eine Seite mit Codetransparenz kann wie auf die Seiten mit den Nutzungsbedingungen oder den Datenschutzrichtlinien stets zugegriffen werden
  • Verlinken Sie Ihre Github-Repos an mehreren Stellen
  • Fügen Sie dem Bereich „Chain-View“ (siehe Beispiele in Kapitel 1.Transparency of Data Provenance) einen Abschnitt hinzu, der der Codetransparenz gewidmet ist
    ○ Informationen zu:
     - die verwendete Blockchain,
     - die Eigenschaften einer solchen Blockchain, insbesondere die durchschnittliche Blockbestätigungszeit (∞link 6.Time / Wait Management)
     - Verdorren ist es MainNet oder TestNet
     - der verwendete web3-Provider (Wechsel zulassen),
     - die Vertragsadressen,
     - möglicherweise eine vereinfachte Version des ABI des Vertrags mit nur den vom Code tatsächlich aufgerufenen Methoden
     - Wenn ein Teil des Codes nicht lokal ausgeführt wird (Texterklärung und Motivation)
     - der link zu den github repos
    ○ Schalter, Filter oder Optionen für:
     - mit Symbolen und / oder durch Ändern der Farben anzeigen, welche Teile / Komponenten Daten enthalten, die auf einem Server verarbeitet werden
     - Anzeige, mit (dem "Cloud-to-Chain" -Orakel) -Link-Symbolen und / oder durch Ändern der Farben, welche Daten von Orakeln stammen
     - Ändern Sie gegebenenfalls den web3-Provider
     - eine Vorschau der mit den Funktionsaufrufen aufgerufenen Transaktionen, die in der Befehlszeile kopiert und ausgeführt werden konnten
     ggf. mit Hinweisen zu den Eingängen.
Ein Beispiel für das Fenster und die Informationen zur Codetransparenz

Zurück zum Spickzettel

Allgemeine Web3 UX-Prinzipien

Die folgenden Prinzipien beziehen sich nicht mehr direkt auf die Eigenschaften "Transparenz" und "Vertrauenswürdig" und zielen vielmehr darauf ab, eine Reihe anderer UX-Probleme zu lösen, die sich aus der allgemeinen Verwendung und Implementierung verteilter Anwendungen auf der Basis der Blockchain ergeben.

6 - Zeit- / Wartezeitverwaltung

Bis die Skalierbarkeitsprobleme gelöst sind, sind Transaktionen asynchron und können entsprechend der zugrunde liegenden Blockchain und der aktuellen Netzwerküberlastung eine lange Zeit in Anspruch nehmen und vollständig bestätigt werden.

Ein gut gestalteter Dapp muss diese Informationen klären und die Wartezeit des Benutzers bis zur Bestätigung seiner Aktion verwalten.

Grundsätze

Ein Dapp-Frontend sollte:

➤ (Erwartungen des Benutzers verwalten) Bei jeder Transaktion die durchschnittliche Blockbestätigungszeit der zugrunde liegenden Blockchain und die aktuelle Netzwerküberlastung klären

➤ (Verwalten der Wartezeit) Zeigen Sie während der Wartezeit die Aktivitätsindikatoren an

Wie> Beispiele

Als Folge von UX-Ereignissen sollte ein Dapp

  1. Erläutern Sie, wie sich die Gasauswahl auf die Wartezeit auswirkt ((link.9 Umkehrung von Gaspreisen und Sendungen).
  2. Warnung vor kettenspezifischen Zeiten anzeigen
  3. Zeigen Sie ein Status- oder Wartesymbol an, bis es nicht mehr behoben ist
  4. Wenn die Dinge länger dauern als normal, zeigen Sie ein Feedback und mögliche Ursachen und / oder Lösungen
    Das heißt: „Es dauert länger als erwartet. Das Netzwerk ist derzeit überlastet.
     Hier sind Ihre Optionen:
     -> Warten Sie weitere X Sekunden / Minuten
     -> mehr Gas hinzufügen, um die Transaktion zu beschleunigen
     -> werde benachrichtigt, wenn du fertig bist
  5. Informieren Sie den Benutzer in jedem Fall über die erfolgreiche Ausführung
  6. Sobald der Vorgang abgeschlossen ist, informieren Sie die erfolgreiche Ausführung mit einem Bericht über die Daten (dh den Transaktions-Hash), die sie unabhängig überprüfen können

Zurück zum Spickzettel

7 - Vom Menschen lesbares Hash-Format

Bis Namensregister weit verbreitet sind, müssen wir uns auch dann noch mit der Schwierigkeit langer Adressen und Transaktions-Hashes auseinandersetzen.
Dies sind nur einige Vorschläge, wie Sie die Lesbarkeit verbessern und gleichzeitig die Transparenz der vollständigen Informationen gewährleisten können.

Grundsätze

Dapps Frontend sollte:

Temporäres Update 2018–07–11 Derzeit wird die Sicherheit einiger dieser Grundsätze diskutiert. Kommen Sie in ein paar Tagen zurück, um eine bessere und sicherere Version zu erhalten

➤ zeigen eine kompakte Version der Hashes, aber immer die Anfangs- und Endteile
dh: 0xABCD… EFGH
Beachten Sie jedoch, dass dies Sicherheitsprobleme enthalten kann, da Vanity-Adressgeneratoren in einer Woche Sequenzen mit 8 Zeichen erzeugen können.

➤ Wenn Sie eine noch kürzere Version, ̵ bevorzugen Anfang bis Ending ̵
̵I̵e̵ ̵u̵s̵e̵ ̵0̵x̵A̵B̵C̵D̵… ̵r̵a̵t̵h̵e̵r̵ ̵t̵h̵a̵n̵ ̵0̵x̵… ̵E̵F̵G̵ (dies hat Auswirkungen auf die Sicherheit, wie von Tom Nash hier angegeben)> wie folgt geändert:

➤ Wenn Sie eine noch kürzere Version benötigen, ziehen Sie das Ende dem Anfang vor
 dh benutze 0x ... EFGH anstatt 0xABCD ...
(Obwohl es besser lesbar ist und besser aussieht, die ersten 4 Zeichen im Vergleich zu 0x ... EFGH zu haben, gibt es ein Sicherheitsproblem, da die ersten 4 Zeichen einfacher zu brachialisieren und zu generieren sind, wie es bei Vanity-URLs der Fall ist, aber Es ist astronomisch schwierig, die exakte Übereinstimmung für die letzten 4 Zeichen zu generieren.)

➤ Verwenden Sie lieber Blöcke mit 4 Buchstaben als 3 Buchstaben für jedes Teil
dh benutze 0xABCD ... anstatt 0xABC ...

➤ Stellen Sie immer das "0x" voran, um anzuzeigen, dass es sich um einen Hash handelt

➤ ermöglichen eine optionale Ansicht, in der die gesamte Adresse sichtbar ist

➤ Benutzer können die Adresse einfach kopieren

➤ Verwenden Sie nach Möglichkeit Abkürzungen als Titel und die abgekürzten Adressen als Untertitel

➤ Erstellen Sie nach Möglichkeit ein System, mit dem der Benutzer den Adressen auf einfache Weise einen benutzerdefinierten, von Menschen lesbaren Namen oder Text zuordnen kann
Diese Notizen sollten lokal auf dem lokalen Computer des Benutzers und nicht auf einem Server gespeichert werden (greifen Sie auf ∞link 5.Transparenz der Code-Prinzipien zurück).
Wenn es existiert, greifen Sie auf eine bekannte Aliase-Datenbank wie die ENS-Registrierung oder Etherscan zurück, um bekannte Verträge und Adressen zu finden.

Zurück zum Spickzettel

8 - Permanenter Anfängermodus

Wenn wir verteilte Anwendungen massenhaft einsetzen wollen, müssen wir Menschenmassen den Zugang zum Weltraum ermöglichen, die weder über technische Kenntnisse noch über Kenntnisse der Blockchain und ihrer Umgangssprache verfügen.
 
Dies ist mehr als bei anderen Bereichen, die ein wenig Schulung erfordern, und zwar sowohl aus Sicherheitsgründen (Umgang mit privaten Schlüsseln) als auch, um zu verstehen, warum die Eigenschaften der Blockchain so revolutionär sind und wie sich Dapps von anderen Apps unterscheiden.

Wichtig ist auch die Tatsache, dass dieser Raum so wunderbar facettiert ist, dass häufig neue Denkmodelle und ein multidisziplinäres Verständnis erforderlich sind: Das Internet der Werte schafft Tausende von symbolisierten Ökosystemen, die von der Marktdynamik beeinflusst werden, die normalerweise in Wirtschaft, Finanzen und Spieltheorie studiert wird. Es ist sehr unwahrscheinlich, dass die Massen mit diesen Disziplinen vertraut sind oder jemals Kontakt hatten.
Daher sollten verteilte Anwendungen sich bemühen, neue und erfahrene Benutzer für alle Aspekte ihrer Arbeit zu sensibilisieren.

Die meisten der vorherigen Prinzipien haben einen Neuling im Sinn, aber es gibt noch ein paar andere Dinge, die Entwickler berücksichtigen sollten.

Grundsätze

Ein Dapp-Frontend sollte:

➤ Verweben Sie Bildungsinformationen mit der normalen Interaktion
Die Hauptaufgabe für Dapp Designer wurde von Nick Neuman hervorragend zusammengefasst: „Eine gute Endbenutzeranwendung wird Bildung in die Produkterfahrung einfließen lassen. Dies bedeutet, dass Sie in einer präzisen und interessanten Weise erklären, warum ein Benutzer etwas tut, während er es tut, und das Produkt so erstellen, dass es für den Benutzer sehr schwierig ist, etwas Unsicheres zu tun. "

➤ Bieten Sie 2 oder mehr Lerninhalte an: Blockchain-Grundlagen und Dapp-spezifische Fachsprache
Dies ist kein Prinzip nur für unsere Zeit, in der Neulinge an Bord kommen. Es wäre eine gute Praxis für alle Apps, insbesondere für Apps mit internem oder kontextbezogenem Jargon oder einem einzigartigen Mechanismus, eine weitere Bildungsebene hinzuzufügen: z. Wenn Sie einen Token-Fondsmanager aufbauen, gehen Sie nicht davon aus, dass Ihre Benutzer die Finanzen kennen und wissen, was jeder Begriff bedeutet. Machen Sie sie stattdessen mit den Grundlagen von Blockchain und den Grundlagen des Finanzwesens vertraut, um zumindest die von Ihnen verwendeten Wörter zu verstehen.

➤ Minimieren und erhöhen Sie schrittweise die Anzahl der neuen Dinge und Konzepte, die der Benutzer lernen muss
Blockchain-Projekte müssen trotz der angebrachten Anreize zur Einführung immer noch die normale Reibung und Abwanderung in Kauf nehmen, die ein Software-Dienst erfährt: Benutzer werden einfachere Alternativen wählen, insbesondere wenn ein Dapp zu viel von ihnen verlangt. Daher sollten Dapps bei der Bereitstellung ihrer Lerninhalte für Neueinsteiger versuchen, die Verwendung neuer Wörter und Konzepte zu minimieren, insbesondere auf den Seiten für die allgemeine Öffentlichkeit (dh die Homepage), und schrittweise mehr Lernergebnisse auf Seiten für engagierte Benutzer (dh Benutzer) anzeigen Dashboards). Dies kann auch durch Verwendung einer einfacheren Sprache, Vermeidung von Jargon und Verwendung von Analogien zum Erläutern komplexer neuer Informationen mit Kenntnissen erreicht werden, mit denen der Benutzer möglicherweise bereits vertraut ist. Als Beispiel sehen Sie, wie Spankchain das Konzept einer Karte entwickelte, um nicht die Zahlungswege erklären zu müssen.

➤ Wenn möglich oder relevant, beschleunigen Sie das Lernen, indem Sie die Interpretation des Experten bereitstellen.
Entmystifizieren Sie die Bedeutung Ihrer Dapps-Funktionen, wie sie interagieren und wie ein Experte über die Auswirkungen nachdenken würde.
Was würde ein Experte über eine bestimmte Sache wissen? Wie würden sie die Daten interpretieren? Wie würden sie darauf reagieren? Welche Entscheidungen würden sie treffen?
Die Antworten auf diese Fragen können als Vorschläge in die Benutzeroberfläche von Dapp eingewoben werden, wenn sie relevant sind.
Beispiele reichen von der Vorwegnahme guter Gaspreise (∞link 9.Gaspreise) bis zur Anzeige, dass es ein guter oder schlechter Moment ist, ein bestimmtes Token auszutauschen (nur ein Beispiel).

➤ Verlieren Sie nicht den Kontext
Versuchen Sie, die Snippets in der Benutzeroberfläche zu verweben. Dabei werden temporäre Popups angezeigt, die leicht ausgeblendet werden können und dann detailliertere Informationen in einem anderen Tab öffnen. Lassen Sie den Benutzer beim Lernen schnell und „vor Ort“ lernen, ohne die Seite zu wechseln und den Überblick zu verlieren, was er gerade tut.

Wie> Beispiele

  • Fügen Sie überall kleine Untertitel für Befehle hinzu (und verweisen Sie auf andere Prinzipien, um vorauszusehen, welche Transaktionen ausgeführt werden).
  • Lernmodus einstellen
    Fügen Sie der "Kettenansicht" oder anderen Teilen der Benutzeroberfläche einen Schalter (eine "universelle Fragezeichen" -Schaltfläche) hinzu, der ein- und ausgeschaltet werden kann und Lernfunktionen aktiviert oder deaktiviert
  • Popup-Glossar
    Wenn Sie die in einem Wörterbuch verfügbare Umgangssprache verwenden, zeigen Sie ein Verknüpfungssymbol an, ein Symbol nach dem Wort, das beim Klicken oder Überrollen ein Kontext-Popup mit den angegebenen Informationen anzeigt
    In einigen Fällen sollte das Popup auch die Möglichkeit bieten, "mehr zu wissen", wodurch eine andere Registerkarte oder eine Seitenleiste in der "Kettenansicht" geöffnet wird, die auf der Registerkarte "Glossar" geöffnet ist.
  • Glossarseite
    In der Kettenansicht oder auf einer anderen Seite sollte der Dapp eine Seite mit allen Begriffen (Blockchain und Dapp-spezifisch) bereitstellen, die im Dapp selbst verwendet werden oder die zum Verständnis seiner Funktionsweise erforderlich sind. Diese Seite sollte aus dem Glossar-Popup umgeleitet und nicht direkt verlinkt werden.
  • In jedem Assistenten ist es ratsam, die schnelle Weiterleitung zu den nächsten Schritten zu aktivieren, damit Sie sehen können, was kommt. Alle Layouts sollten jedoch ausgegraut und deaktiviert sein, bis Sie die vorherigen Schritte ausgeführt haben. Dies ist ein gutes Prinzip für jede Benutzeroberfläche, nicht nur für Dapps.

Zurück zum Spickzettel

9 - Gaspreise und Transaktionsumkehrungen

Benzin ist eines der verwirrendsten Dinge für Neulinge. Selbst wenn der Name aussagekräftig ist, sind die Kosten für die Berechnung von Diensten, die Sie immer kostenlos hatten, kaum vorstellbar.
Darüber hinaus wissen die Benutzer beim ersten Auftreten von Gas weder, wie sie den Preis festlegen sollen, noch, was für eine gute Wahl sie für den Gaspreis treffen würden.

Selbst wenn das Gas heutzutage in praktisch allen Fällen von Geldbörsen gehandhabt wird, die die Transaktion ausstrahlen, gilt dieses Prinzip weiterhin, sowohl für Geldbörsen-Designer als auch für all diejenigen, die jemals einen Gaspreis verlangen oder von den Benutzern verlangen, diesen zu wählen.

Zum Glück für Entwickler gibt es Tools wie die Ethereum-Tankstelle, die eine komfortable API bietet.

Grundsätze

Dapps Frontend sollte:

➤ Klären Sie, was Gas und Gaspreis sind
(genau wie bei jedem anderen lingo ∞link 8.Newbie mode)

➤ Schlagen Sie einen guten Bereich für den Gaspreis vor und klären Sie die Zeitnäherungen für die oberen und unteren Bereichsgrenzen
Dies sind Funktionen der aktuellen Überlastung des Netzwerks. Daher besteht die optimale Lösung darin, die aktuelle Ethereum-Tankstellen-API https://ethgasstation.info/json/ethgasAPI.json abzufragen, um diese Bereichsgrenzen vorzuschlagen.
Es ist wichtig, dem Benutzer klar zu machen, dass dies ein zeitbasierter Vorschlag ist und dass sich die vorgeschlagenen Werte in Zukunft ändern können.
 
➤ möglicherweise auch in FIAT umgerechnete Gaswerte anzeigen

➤ Transaktionsumkehr zulassen: Falls der Benutzer ein TX mit niedrigem Gaspreis gesendet hat, sollte dies dem Benutzer mitgeteilt werden
(∞link zu 6.Time / Wait Management)
- dass der Sendevorgang nach dem Start nicht abgebrochen werden kann
- dass die einzige Lösung darin besteht, einen weiteren Sender mit dem gleichen Nonce und einem höheren Gaspreis zu senden
> bieten sie daher die möglichkeit an, das tx nonce automatisch wiederherzustellen und mit einem höheren gaspreis zu versenden.

Zurück zum Spickzettel

Entwurfsprinzipien für die DDP-Dezentralisierung

Dezentralisierung ist eine neue mächtige Form der Globalisierung.
Eine, die zum ersten Mal möglicherweise von Massen selbstsouveräner Individuen angeführt wird, die sich um grenzenlose Ideen, selbstverwaltende Organisationen und verteilte Marktsysteme bemühen.

Diese Gestaltungsprinzipien wollen nur die Konversation in Gang bringen, indem sie darüber nachdenken, wie der Benutzer sich als Teil einer Gemeinschaft und als Teil einer etwas größeren Zielgruppe als sich selbst fühlen kann.
Sie sind nur ein Hinweis für Entwickler, um ganzheitlich über die Funktion ihrer Dapps und die neuen UX-Anforderungen nachzudenken, die sich im größeren Kontext der von uns geschaffenen verteilten Gesellschaften ergeben.

10 - Gemeinschaftsgefühl

Dapps sind etwas anderes als Apps, weil sie nativ verteilt sind: Auch wenn es sich bei einigen um auf den Einzelnen zugeschnittene Dienste handelt und deren Interaktion eine einsame Erfahrung darstellt, sind sie dennoch für eine große Gruppe von Menschen auf der ganzen Welt und werden häufig von ihnen erstellt.
 
Das Zugehörigkeitsgefühl zu einer Community ist in diesen Dapps wichtiger, da Benutzer eine Bindung zu einer dezentralen Marke und einem dezentralen Produkt herstellen müssen.
Das bedeutet nicht, ein soziales Netzwerk im Dapp einzurichten, obwohl einige von einer engeren Integration in den vom Projekt ausgewählten Community-Chat profitieren könnten.

Unnötig zu erwähnen, dass diese Ideen für DAOs ziemlich wichtig sind.
 
Betrachten Sie das Folgende als einige generische Vorschläge im Rahmen des klarer interpretierbaren Ziels, den Benutzern das Gefühl zu geben, Teil von etwas Größerem als sich selbst zu sein.

Grundsätze

Dapps Frontend sollte:
 
➤ klären, wie viele andere Mitglieder in der Community sind
➤ klären, wer die anderen Mitglieder sind (entsprechende Kategorien auswählen)
➤ Klarstellung der Zusammensetzung der Community (dh Untergruppen und deren Macht über das Projekt)
➤ die größere Mission des Projekts (falls vorhanden) und wie ihre Teilnahme zu dessen Erreichung beiträgt

Wie> Beispiele

  • Bereitstellung eines Landing Dashboards mit Statistiken über eindeutige Token-Inhaber oder die Anzahl der Mitglieder eines Dapp oder DAO
  • Übernehmen Sie das Transparenzprinzip und zeigen Sie insbesondere alle Informationen an, die von den Benutzern selbst durch Analyse der Blockchain abgeleitet werden könnten:
     - Token-Vermögensverteilung,
     - Adoptionszeitdiagramme,
     - Token-Inhaber seit Block XX und JJJJ-MM-TT
     etc
  • in DAOs erwägen, die Informationen mit allem zu bereichern, was relevant sein könnte (falls verfügbar), wie:
     - Art der Mitglieder (dh Anzahl der Züchter gegen Nichtzüchter in Crypto Kitties oder Anzahl der Musiker und Hörer in Music / ART Dapps wie UJO Music, Stakers gegen Non-Stakers usw.)
     - Abstecken von Verteilungsstatistiken
     - Vielleicht geografische Standorte / Zeitzonen ?,
     - Vielleicht Geschlecht, Alter? (Aber nur, wenn es für Ihre Community Sinn macht und die Akzeptanz Ihres Dapp nicht anstößig oder schädlich ist.)
  • Suchen Sie offensichtlich nach den Kategorien, die für Ihr Projekt geeignet und relevant sind: Zum Beispiel ist es meine persönliche Meinung, dass Geschlecht und Alter in DAOs keine relevanten Informationen sind, auch wenn sie der Idee der Schaffung erlaubnisloser und unvoreingenommener Gesellschaften nicht entgegenstehen, aber vielleicht sehr entgegenstehen relevant in Projekten wie SpankChain.
  • Vielleicht können Benutzer ihre eigenen Tags, Kategorien, Biobeschreibungen usw. auswählen. Jedes Mitglied kann in verschiedenen Projekten unterschiedliche Identitäten haben. Dies deutet bereits auf andere Prinzipien über Identitäten hin, die in Zukunft präsentiert werden.

Zurück zum Spickzettel

11 - Weitere zukünftige Gestaltungsprinzipien

Wie Sie vielleicht verstanden haben, erfordert das vorherige Prinzip einige weitere Überlegungen zu Identitäten, Reputation und Governance. Die ersten beiden sind in vielen Community-gesteuerten Apps universell nützlich, werden jedoch für Token Curated Registries (TCR) und wahrscheinlich für viele DAOs und andere Crypto-Primitive von grundlegender Bedeutung sein.

Diese Prinzipien verdienen eine eigene Analyse und Raum, und dieser Beitrag ist bereits zu lang.
In Zukunft werde ich die Web3-Designprinzipien analysieren für:
- Identität und Ansehen
- Führung
- Geldbörsen
- Austausch
- ICO & Token Sales Mechanics
- Token-Mechanik

Nächste Schritte

Es ist klar, dass die Anforderungen an „extreme Transparenz“, die in diesen Web3 Design-Grundsätzen vorgeschlagen werden, für Dapp-Entwickler, die sich heute mehr auf die Lösung vieler anderer Teile ihrer Projekte konzentrieren, eine ziemliche Belastung darstellen.
 
 - Bootstrap-ähnliche Bibliothek
Es ist daher offensichtlich, dass es ein Standard-Toolset geben sollte, das Entwickler in ihre Dapps einbinden und möglicherweise ihre Aufrufe an die web3-Bibliothek anbinden und all diese Transparenzdienste für ihre Benutzer kostenlos erhalten können.
Ich stelle mir so etwas wie eine Bootstrap-ähnliche Bibliothek für die Web3-Ära vor ("Chainstrap" - ein etwas zu harter Kern, oder?: P)

- Unabhängiges Browser-Plugin
Vielleicht ist es sogar ratsam, dass es ein unabhängiges Tool gibt, das den Benutzern die Vorteile der Web3-Designprinzipien bietet, egal ob der Dapp-Ersteller dies wünscht oder nicht. Eine Art „Transparenz-Erzwinger“, der es ermöglichen könnte, böswillige oder schlampige Dapps anhand ihres Übereinstimmungsgrades mit einigen der Prinzipien zu identifizieren.
In diesem Fall wäre es wahrscheinlich angebracht, ein Browser-Plugin zu erstellen, das seinen Code in das Dapp einfügt und die Chain-View-Funktionalität und möglicherweise sogar eine schnelle Zertifizierung des Grades an Transparenz und Vertrauenswürdigkeit des Dapp bietet.

- Kundendienste
Darüber hinaus gibt es in diesen Grundsätzen viele Potenziale für Dienstleistungen, auch für kommerzielle, die es heute noch nicht gibt.

Viele Optionen. Was denkst du?

Wenn Sie daran interessiert sind, eines der oben genannten zu entwickeln, wenn Sie nur Gedanken und Überlegungen haben,
oder wenn Sie eine Organisation sind, die Stipendien anbietet, und der Meinung sind, dass diese in Ihre derzeitigen Ziele passen könnte,
Bitte wenden Sie sich an b [at] likuidlabs.com oder an twitter @lyricalpolymath

Gestalten und bauen wir gemeinsam die Zukunft der Dezentralisierung!

ANMERKUNGEN

[1] Andere "Blockchain" + Design-Artikel

Unter Anwendung der Entwurfsmethodik habe ich recherchiert, was zu diesem Thema bereits erstellt wurde: nicht viel.

  • Blockchain Design Principles - Design bei IBM
    Dies ist mit Abstand der beste Artikel zu diesem Thema. Geschrieben von Sarah Baker Mills, ehemaliger Designleiter bei IBM und heute Design Director bei Consensys. Sie destilliert einige der Prinzipien, die in den Web3 Design Principles erscheinen, sehr gut, obwohl sie unterschiedliche Namen haben. Sie spricht über Datenexposition, Konsistenz, Feedback, Vorwegnahme von Fehlern und aktive Anleitung.
  • Blockchain und Design - Hacker Noon
     Ein Interview mit Matt Storus, Lead Designer bei 21.co, über die Herausforderungen und einige Ideen, was Designer tun sollten. Leider erlaubt das Interviewformat nicht, viele Lehren zu destillieren, aber er ist definitiv eine interessante Lektüre.
  • Die Benutzererfahrung von Blockchain
    Ein allgemeiner Beitrag, um Designer über die Blockchain und die Designherausforderungen aufzuklären.
  • Wie kann Design Blockchain helfen - The Spark
    Ein paar Makro-Ideen zu einigen Dingen, über die Designer in diesem Bereich nachdenken sollten
  • Entwerfen für die Blockchain: Starten einer Ethereum Smart Contract-App
    Ein Fallbeispiel zur Entwicklung einer besseren Erfahrung für eine Investitionsplattform mit einigen Ideen zur Verbesserung der Teilnahme an ICOs

[2] Ich weiß, dass diese Postulate ein phänomenologischer Irrtum sind, aber ich benutze sie trotzdem, weil sie eine nützliche Vereinfachung darstellen und den Punkt machen: für eine nicht technische Benutzerin, die die Daten nicht auf einfache Weise selbst verifizieren kann, die Informationen sind eindeutig nicht transparent. Transparenz wird dann zu einer schimmernden Illusion, zu einer vertrauensvollen Erwartung.