Web3 ontwerpprincipes

Een raamwerk van UX-regels voor op Blockchain gebaseerde gedistribueerde applicaties (deel 1)

Opmerking: dit bericht is vrij lang> spring naar het cheatsheet of naar de conclusies

Blockchain-ontwikkelaars duwen de grootse visie van een gedecentraliseerde toekomst vooruit, maar de ervaring van die visie via de Distributed Applications (Dapps) die we maken lijkt nog steeds op een onhandig prototype van het web2.
 
Het is waarschijnlijk passend dat de meeste gebruikers die deze Dapps zouden gebruiken nog steeds 'live' zijn in het web2 en nog niet eens gehoord hebben van de beloften van het gedecentraliseerde Web3.
Zelfs als ze zouden komen om deze glimmende nieuwe apps te zien, zouden ze het moeilijk hebben, van het begrijpen van de lingo, het doel, de dynamiek van deze Dapps, om ze zelfs visueel te onderscheiden van normale web-apps.

Het moet gezegd worden dat er veel goede tools (Drizzle, MetaMask) uitkomen die sommige van deze problemen aanpakken. We zullen er komen.

Deze ontwerpprincipes willen enkele ideeën voorstellen om dit op te lossen, met richtlijnen om ontwerpers en ontwikkelaars te helpen, zodat we allemaal die glanzende toekomst voor iedereen toegankelijker en dichterbij kunnen maken.

Web3-ontwerp versus Blockchain-ontwerp

Andere mensen hebben geschreven over "Blockchain Design" [1], terwijl ze oplossingen presenteerden met betrekking tot de front-end gebruikerservaring van Decentralized Apps (Dapps).

Hoewel het artikel van Sarah Mills, hoofdontwerpster bij Consensys, een inspirerend artikel is en zij duidelijk de leidende stem is voor ontwerpers in de Blockchain-ruimte, denk ik dat de formulering "Blockchain-ontwerp" geschikter is om de eigenschappen en hun interacties te definiëren , van het Blockchain-construct zelf: dingen zoals het consensus-algoritme, de supply base, de block-rewards, turing-volledigheid, berekening / "gas" -kosten, aan of uit chain governance-mechanismen en nog veel meer.
 
In dit artikel zal ik in plaats daarvan verwijzen naar "Web3 Design", waarbij ik hoofdzakelijk principes aanwijs die moeten worden toegepast op de creatie van de gebruikersgerichte delen van gedecentraliseerde apps.

Het is verleidelijk om het woord "Blockchain" in de titel te gebruiken, maar dat zou clickbait zijn

Waarom Web 3 ontwerpprincipes

Tegenwoordig kan een gebruiker op verschillende manieren communiceren met een Smart Contract dat op de Blockchain is geïmplementeerd: hetzij rechtstreeks via de opdrachtregel, via de vormachtige interfaces van hun digitale portemonnee of Dapp-browser, of misschien via de rijkere front-end die de Smart Contract-ontwikkelaar heeft heeft of zal zich ontwikkelen.
Het is duidelijk dat het pad naar massale acceptatie van Dapps door het laatste gaat: het bieden van een rijke gebruikersinterface verenigd met de ervaring van het omgaan met een Blockchain-gebaseerde Gedistribueerde Applicatie.

Tegenwoordig zijn we, als ontwikkelaars, terecht bezig de infrastructuur van de Blockchain en de Smart Contracts van onze projecten te bouwen, dus het is duidelijk dat niet veel Dapps momenteel een bruikbare front-end hebben of, als ze die hebben, veilig voor de inhoud, ze zijn voornamelijk niet van andere webapps te onderscheiden.

Dapps verschillen echter fundamenteel van normale web- of mobiele apps omdat ze gebaseerd zijn op en krachtig moeten worden overgebracht door de krachtige principes die de Blockchain mogelijk maakt: decentralisatie, transparantie, vertrouwen, onveranderlijkheid, ongevoeligheid enz.
Deze eigenschappen van de Blockchain, en door weerspiegeling van de front-end Dapps, zijn wat deze Design Principles codificeren in bruikbare tools.

Het doel is dat, zodra correct toegepast, een gebruiker die op een Dapp belandt, onmiddellijk kan zien dat ze ermee communiceert en, nog belangrijker, toegang heeft tot de krachtige eigenschappen van de Blockchain en daarom weet dat ze elke interactie met de applicatie kan vertrouwen.

Variabelen om te overwegen om de principes te begrijpen

  • het hoofddoel is een niet-technische gebruiker, hoewel sommige principes ook gericht zijn op meer slimme gebruikers
  • niet alle Dapps hebben alle principes nodig
  • de oplossingen in de voorbeelden zijn slechts enkele eerste ideeën om het gesprek te starten
  • sommige principes kunnen op verschillende manieren door elke Dapp-ontwikkelaar worden geïmplementeerd
  • sommige web3-principes suggereren de behoefte aan een externe tool, service of bibliotheek in plaats van te veronderstellen dat elke ontwikkelaar zijn oplossing zou implementeren (meer hierover in de volgende stappen)
  • de meeste, zo niet alle web3-ontwerpprincipes zouden gebaat zijn bij codering in een Bootstrap-achtige ontwikkelaarvriendelijke bibliotheek (meer hierover in de volgende stappen)

Als u hierin geïnteresseerd bent, gaat u aan het einde naar de sectie 'Volgende stappen' om te zien hoe we kunnen samenwerken.

Aanpak van ontwerp

Design gaat ook over het anticiperen op problemen en het aanbieden van oplossingen. In dit geval probeerde ik de vragen die een gebruiker zou kunnen hebben bij de interactie met een Dapp, te 'projecteren' (naar mijn mening een beter woord voor de etymologische betekenis van 'in de toekomst lanceren').

Vragen als:

  • is het veilig om dit te doen (action_dapp_asks_me_to_do)?
  • loopt het geld gevaar als ik het verpest?
  • Ik heb gehoord dat crypto privé zou zijn ... wat gebeurt er met de gegevens die ik verzend? waar wordt het opgeslagen? Kan ik worden geïdentificeerd?
  • wie zal de gegevens zien die ik heb ingevoerd? waar wordt de code uitgevoerd?
  • wat gebeurt er nadat ik dit (actie) heb gedaan?
  • hoe moet ik het doen (crypto cialis_here)?
  • wat betekent dit (weird_crypto_word)?
  • Vermoedelijk kan de Blockchain worden vertrouwd, maar hoe weet ik welke gegevens op deze app kunnen worden vertrouwd?
  • welke gegevens komen van de Blockchain?
  • hoe kan ik controleren of de gegevens echt zijn opgeslagen in de Blockchain?
    enz.

De ontwerpprincipes bieden tools voor ontwikkelaars om deze en meer vragen van gebruikers te beantwoorden.

Web 3 Design Principles (index / cheatsheet)

Dit bericht is vrij lang, dus je kunt dit cheatsheet gebruiken om een ​​snel overzicht van de principes te krijgen en naar degenen te gaan die je meer wilt begrijpen

//// TTT: Vertrouwen door ontwerpprincipes van transparantie

1 - (Gegevens lezen) Transparantie van gegevensherkomst

➤ Maak duidelijk welke gegevens afkomstig zijn van de Blockchain en welke niet
➤ Verduidelijk het adres van de overeenkomst (en)
➤ Koppel alle Blockchain-gegevens aan onafhankelijke Blockchain-ontdekkingsreizigers
➤ Verduidelijken welke gegevens afkomstig zijn van orakels (∞link> 5.Transparantie van code)
 - Hoe> voorbeelden

2 - (Gegevens schrijven) Transparantie van transacties

- Soorten transacties (waardeoverdrachten, functieoproepen, contractgeneratie)
➤ [Permanence] verduidelijk acties die onomkeerbaar zijn
➤ [Waarde] verduidelijk acties die geld of waarde met zich meebrengen
➤ [Privacy] verduidelijkt acties die mogelijk kunnen leiden tot gebruikersidentificatie
➤ [Fabriek] verduidelijkt acties die nieuwe contracten genereren in de gebruikersnaam
- Richtlijnen voor alle transacties:
- ➤ verduidelijken en vooraf de nieuwe toekomstige staat bevestigen
 - ➤ toont de gegevens die worden gebruikt voor een transactie in een voor mensen leesbaar formaat en op de manier waarop het Smart Contract dit vereist (∞link 5.Transparency of Code)
- ➤ verduidelijken voorgestelde waarden voor gasprijs en hoe de Tx te overschrijven (∞link 9.Gas Prijs en Transactieomzettingen)
 - ➤ Transactie wachttijd beheren (∞link> 6.Time / Wait Management)
 - ➤ mogelijk, verduidelijken welke acties GEEN transacties zijn en dus veilig
 - Hoe> voorbeelden

3 - (Pushed Data) Transparantie van slimme contractgebeurtenissen

➤ alle evenementen verduidelijken en toegankelijk maken voor de eindgebruiker, zelfs als ze alleen voor ontwikkelaars zijn bedoeld
Relev relevantie toepassen: toon onderbrekende berichten alleen voor informatie die relevant is voor de huidige gebruiker
sta gebruikers toe zich te abonneren op, af te melden bij of bepaalde evenementen tijdelijk te dempen
 - Hoe> voorbeelden

4 - (Geschiedenis) Transparantie en toegankelijkheid van de interactiegeschiedenis van de gebruiker

➤ biedt een geschiedenis van alle transacties vanaf een bepaald adres
➤ verduidelijk waar de geschiedenis is opgeslagen (lokaal of server) (∞link 5.Transparency of Code)
bieden hulpmiddelen voor het navigeren, zoeken, exporteren en verwijderen van de geschiedeniscache
 - Hoe> voorbeelden

5 - (Code en omgeving) Transparantie van code

➤ verduidelijken welke Blockchain wordt gebruikt
Lar verduidelijk het adres van de Smart Contract (s) die worden gebruikt bij lees- / schrijfbewerkingen
verduidelijken welke code open source is (en waar deze te vinden is)
verduidelijken waar code wordt uitgevoerd (lokale versus externe server)
verduidelijk de web3-provider / Blockchain-knooppunt (lokaal knooppunt, Dapp-bestuurd knooppunt, MetaMask, Infura, enz.)
verduidelijken of de Dapp wordt uitgevoerd op MainNet of TestNet
➤ verduidelijken welke gegevens afkomstig zijn van orakels of beïnvloed zijn door orakels (∞link> 1.Transparantie van gegevensherkomst)
staat het uitvoeren van DIY-code toe: laat geavanceerde gebruikers zien dat de code wordt uitgevoerd en deze zelf uitvoeren via de opdrachtregel
➤ verduidelijk de ingangen die vereist zijn voor de Smart Contracts
 - Hoe> voorbeelden

//// Algemene Web3 UX-principes

6 - Beheer van tijd / wachten

➤ (Beheer de verwachting van de gebruiker) verduidelijk de specifieke tijden van Blockchain en beheer het wachten van de gebruiker in verschillende fasen
➤ (Beheer de wachttijd) Toon levendheidsindicatoren tijdens de wachttijd
 - Hoe> voorbeelden

7 - Door mensen leesbare hashformaten

➤ tonen een compacte versie van de hashes maar tonen altijd de begin- en einddelen
➤ i̵f̵ ̵y̵o̵u̵ ̵n̵e̵d̵ ̵a̵n̵ ̵e̵v̵e̵n̵ ̵s̵h̵o̵r̵t̵e̵r̵s̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵̵
➤ plaats altijd de "0x" om aan te geven dat het een hash is
Met kunnen gebruikers het volledige adres / hash uitbreiden
Met kunnen gebruikers het gemakkelijk kopiëren
gebruik waar mogelijk afkortingen als titels en de afgekorte adressen als ondertitels
➤ laat de gebruiker indien mogelijk eenvoudig een aangepaste, door mensen leesbare naam of tekst aan de adressen en hashes koppelen
Indien mogelijk associëren een vorm van deterministische visuele weergave van de hash (dwz Identicons, blockies et al) samen met het adres

8 - Permanente nieuwkomermodus

➤ weven in educatieve informatie met normale interactie
bieden 2 of meer niveaus van educatieve inhoud: Blockchain basics en Dapp-specifieke lingo
minimaliseer en verhoog geleidelijk de hoeveelheid nieuwe dingen en concepten die de gebruiker moet leren
➤ indien mogelijk of relevant, het leren versnellen door de "interpretatie van de expert" te geven
➤ laat geen context los
 - Hoe> voorbeelden

9 - Terugboekingen van gasprijzen en transacties

➤ verduidelijk wat Gas en Gas prijs is (net als bij elke andere lingo ∞link 8.Newbie-modus)
➤ suggereren gasprijzen en verduidelijken tijdsschattingen voor de boven- en ondergrenzen
➤ tonen mogelijk ook gaswaarden die zijn geconverteerd naar FIAT
➤ toestaan ​​voor Transactieomzettingen

//// DDP: Decentralisatie-ontwerpprincipes

10 - Gevoel van gemeenschap

verduidelijken hoeveel andere leden er in de community zijn
verduidelijken wie de andere leden zijn (kies de juiste categorieën)
➤ verduidelijk de samenstelling van de gemeenschap (d.w.z. subgroepen en hun macht over het project)
➤ deelt de grotere missie van het project (indien aanwezig) en hoe de deelname van de gebruiker bijdraagt ​​aan de realisatie ervan
 - Hoe> voorbeelden

11 - Toekomstige ontwerpprincipes om te onderzoeken (deel 2)

➤ Identiteiten en reputatie
➤ Governance
➤ Portefeuilles
➤ Ruilen
➤ Verkoopmechanica voor ICO & Token
➤ Tokenmechanica

Volgende stappen

TTT: Vertrouwen door ontwerpprincipes van transparantie

Web3 postuleert:

- Het is niet transparant als u niet weet waar en hoe u moet zoeken
- Als het niet transparant is, kan het niet worden vertrouwd!

Iedereen in deze ruimte, en hun moeder, praat over hoe de Blockchain "vertrouweloos" en "transparant" is.
Om uit te leggen waarom deze twee veronderstellingen slechts gedeeltelijk waar zijn, zou een langere post in beslag nemen en deze fout maken.
Het is (bijna) zeker waar op een programmatisch niveau, software die gegevens verifieert, maar die twee veronderstellingen vallen uit elkaar wanneer u ze confronteert met de werkelijke eindgebruikerservaring.

Naast het feit dat veel cryptoprojecten of Dapp-frontends de gebruiker zelden het Smart-Contract-adres laten zien waarmee ze interacteert of waar de gegevens vandaan komen, is het momenteel ontmoedigend of onmogelijk voor een niet-technische gebruiker om de informatie en de werking te begrijpen van onafhankelijke Blockchain-ontdekkingsreizigers zoals Etherscan.
Het enige dat vandaag gedeeltelijk door de gebruiker kan worden bestuurd, is wanneer tussenliggende portefeuilles de transactiehash registreren die kan worden gecontroleerd in de eerder genoemde Blockchain-ontdekkingsreizigers.

Daarom kan een gebruiker, vooral een niet-technische gebruiker, door in de gebruikersinterface te kijken niet zien of een Dapp eigenlijk een Dapp of een normale web-app is, noch kan ze verifiëren of de inhoud die ze ziet, of haar interacties ermee zijn eigenlijk gerelateerd aan een Blockchain, dan krijgt ze niet de betrouwbaarheid en transparantie die de Blockchain zou moeten leveren.

De Web3 Design-principes in deze categorie (TTT) stellen een radicale transparantiebenadering voor die elke Dapp-front-endgebruiker, zelfs niet-technische, in staat zou stellen zich volledig bewust te zijn van de herkomst van gegevens, de implicaties van transacties voor, tijdens en na de uitvoering ervan te begrijpen, en uiteindelijk in staat zijn om de code en de service bij de hand te vertrouwen.

terug naar cheatsheet

1 - (Gegevens lezen) Transparantie van gegevensherkomst

Een gebruiker moet kunnen vertellen, mogelijk alleen door naar de pagina te kijken, dat een bepaald datapunt of inhoud daadwerkelijk is opgeslagen in de Blockchain. Het is niet gebruiksvriendelijk om ze te laten raden en het is niet voldoende om hen te laten aannemen dat "alle" gegevens die worden gezien, zijn opgeslagen in de Blockchain.
Deze vereiste klinkt misschien lastig voor data-intensieve Dapps zoals Distributed Exchanges, maar er zijn enkele oplossingen die in de voorbeelden worden gepresenteerd.

Principes

De front-end van Dapp moet:

verduidelijken welke gegevens afkomstig zijn van de Blockchain en welke niet
➤ verduidelijk het adres van de overeenkomst (en)
➤ koppel alle Blockchain-gegevens aan onafhankelijke Blockchain-ontdekkingsreizigers
➤ verduidelijken welke gegevens afkomstig zijn van orakels (∞link> 5.Transparantie van code)

Hoe> Voorbeelden

  • gebruik css om de kleur / het lettertype / de vorm te wijzigen om duidelijk onderscheid te maken tussen Blockchain-gegevens Probeer uiteraard consistent te zijn in uw project en gebruik altijd dezelfde "Blockchain-kleur"
Data Provenance UITData Provenance ON: kleurt de gegevens afkomstig van een specifiek contract
  • gebruik uitbreidbare referenties:
    Wanneer u zweeft of klikt op een Blockchain-gegevenspunt, kunt u een contextuele uitgebreide tooltip bieden met meer informatie over het datapunt dat duidelijk moet maken waar op de Blockchain, in welke contracten de gegevens kunnen worden gevonden.
voorbeeld van een contextuele uitbreidbare referentie
  • stijlconflicten beheren met koppelingspictogrammen
    als een gegevenspunt zowel een "Blockchain-datapunt" als een link naar ergens in uw dapp is, zijn er twee manieren om de dubbele actie op te lossen:
    1- voeg een link-pictogram toe, een pictogram dat elk "Blockchain-datapunt" volgt dat de uitbreidbare referentiefunctionaliteit geeft terwijl de normale werking van de link intact blijft.
    2- open de uitvouwbare referentie en voeg een secundaire link erin in (maar bedenk dat dit meer wrijving veroorzaakt omdat u de gebruiker vraagt ​​om 2 acties te doen in plaats van één).
Voorbeeld van een link-pictogram dat de contextuele referentie opent. Dit is voor het toevoegen van de chainView-functionaliteit aan een link die ergens in uw Dapp staat
  • gebruik een "Chain-view" -modus en / of zijpaneel
    Voor data-intensieve interfaces zoals gedecentraliseerde uitwisselingen of marktbeelden zou het volgen van de vorige suggesties waarschijnlijk betekenen dat het grootste deel van de interface wordt gestileerd, waarschijnlijk meer verwarring toevoegend. Om dit op te lossen, kunt u zich voorstellen aan een knop "Kettingweergave" die de gegevens tijdelijk stileert wanneer u erover zweeft of erop klikt. Het is alsof je een filter op de pagina plaatst, een filter dat de gebruiker helpt te zien welke gegevens een Blockchain-datapunt zijn.
     
    Als uitbreiding van dit idee, zou de "Chain-view" ook een zijpaneel kunnen zijn waar veel van de functies beschreven in de Web3 Design Principles zouden kunnen worden gehost. In dit geval kan het Chain-View-paneel de bovengenoemde optie hebben om de zichtbaarheid van de Blockchain-datapunten in of uit te schakelen. In de volgende voorbeelden zullen we nog veel meer toepassingen van het Chain-View-paneel zien.
Chain View zijpaneel met de Data Provenance Option geopend
  • Laat duidelijk zien welke links de externe Blockchain-verkenner openen
    Als een link de gebruiker naar een andere pagina gaat sturen, is het beter om de stroom van de gebruiker op de pagina te regelen door:
    1 - een verduidelijkende knop toevoegen die aangeeft wat er gaat gebeuren: "open in Etherscan"
    2 - voeg een link-pictogram toe voor onafhankelijke block explorers en gebruik het consistent in uw gebruikersinterface

terug naar cheatsheet

2 - (Gegevens schrijven) Transparantie van transacties

De gebruiker moet zich ervan bewust zijn dat gegevens naar de Blockchain worden geschreven, en met name wanneer deze een economische waarde (cryptocurrencies of tokens) met zich meebrengt. Hoewel Wallets de gebruiker waarschuwen voor deze intentie, moet de Dapp dit verduidelijken voordat het transactieverzoek naar de wallet wordt gestart.

Typen transacties

Er zijn verschillende soorten transacties die kunnen plaatsvinden tijdens interactie met de Blockchain en elk heeft verschillende gevolgen.
De gebruiker moet in staat zijn om onderscheid te maken via de informatie die door de gebruikersinterface in verschillende fasen wordt verstrekt, zelfs voordat de transactie wordt gestart.

2.1 - Waardeoverdrachten
 - 2.1.1 - ETH
 - 2.1.2 - Tokens
 2.2 - Functieoproepen
 - 2.2.1 - contractmethoden met waarde-implicaties
 - 2.2.2 - contractmethoden zonder waardeoverdracht
 2.3 - Fabrieken: contractgenererende functies

Transactiegegevens en kosten

Transacties hebben meestal een 'payload', sommige gegevens zijn bijgevoegd, bijvoorbeeld doorgegeven aan de contractmethoden, en die wordt meestal gebruikt om te schrijven of te berekenen wat te schrijven in de Blockchain.

Bovendien kost het schrijven van gegevens naar de Blockchain meestal een kost, een "gasvergoeding" om de transactie te betalen.
De gebruiker moet deze twee informatie begrijpen en bewust worden gemaakt van hun inhoud.

Principes

De front-end van Dapp moet:

➤ (Permanence) verduidelijk acties die onomkeerbaar zijn (alle schrijf-Tx's)

➤ (Waarde) acties verduidelijken die geld of waarde met zich meebrengen

➤ (Privacy) verduidelijkt acties die mogelijk kunnen leiden tot gebruikersidentificatie
Dit is een van de moeilijkste principes om te implementeren, aangezien mogelijk alle schrijfgegevens kunnen helpen bij het identificeren van de gebruiker (tot ZTKSnarks), en als smart-contract en web3-ontwikkelaars zijn we ons niet bewust van de huidige en toekomstige verfijning van forensische tools, die ook meestal closed source-oplossingen. Houd gewoon rekening met dit principe als privacy een hoofdkenmerk van uw Dapp is, en gebruik het als leidraad bij de ontwerpkeuzes wanneer u wilt verduidelijken welke acties potentiële risico's zijn voor uw gebruikers die privacy zoeken.

➤ (fabriek) verduidelijkt acties die nieuwe contracten genereren in de gebruikersnaam
Dit principe moet alleen worden toegepast op Dapps die de gebruiker helpen contracten te maken met hun adres als de maker van het bericht. Pas dit vooral toe als het op MainNet staat.

Richtlijnen voor alle transacties:

➤ verduidelijken en vooraf de nieuwe toekomstige staat bevestigen
tonen de gegevens die worden gebruikt voor een transactie in een voor mensen leesbaar formaat en op de manier waarop het Smart Contract dit vereist (∞link 5.Transparency of Code)
➤ verduidelijken voorgestelde waarden voor gasprijs en hoe de Tx te overschrijven (∞link 9.Gas Prijs en Transactieomzettingen)
Transactie wachttijd beheren (∞link> 6.Time / Wait Management)
➤ Nadat de transactie is geregistreerd, toont u een relevante samenvatting van de transactie aan de gebruiker en hoe deze toegang kan krijgen tot de geschiedenis (∞link 4.Gebruikersinteractiegeschiedenis)
mogelijk, verduidelijken welke acties GEEN transacties zijn en dus veilig

Hoe> voorbeelden

  • gebruik css om alle onomkeerbare acties aan te geven
    gebruik misschien een waarschuwings- / markeerkleur zoals rood
  • voeg een kleine schriftelijke waarschuwing toe samen met de knop
    dat wil zeggen: aandacht onomkeerbare actie vooruit> meer informatie
  • gebruik dubbele bevestiging:
    open een pop-up of toast, nadat de gebruiker op de knop heeft gedrukt en voordat u de portefeuille / MetaMask oproept, waar u de gebruiker kunt informeren over alle implicaties en om een ​​bevestiging kunt vragen.
    Bied de gebruiker ook het volgende aan:
     - annuleer de actie
     - toon deze pop-ups nooit meer (omdat ze een ervaren gebruiker is) en vertel de gebruiker dat ze uiteindelijk de functie in het zijpaneel van Chain-View opnieuw kan activeren.
  • verduidelijken en anticiperen op toekomstige verwachte stappen
    met kleine beschrijvingen, label-ondertitels of met wizardachtige stromen die meer stappen hebben om een ​​actie te volbrengen.
    In het geval van tovenaars:
     - laat de gebruiker duidelijk het nummer en de titel van de volgende stappen zien
     - laat de gebruiker de toekomstige schermen inspecteren om te begrijpen wat er aan de hand is en wat er gaat gebeuren (link 8. Nieuwe modus), hoewel je de functionaliteit ook grijs moet maken om niet te verwarren met het feit dat ze een sneak peak kan hebben voorbeeld met de daadwerkelijke actie.
  • Voeg opties toe aan het Chain-View zijpaneel
    Het zijpaneel kan de plaats zijn voor veel van deze waarschuwingen en biedt een inspecteur bij het definiëren van de transacties
     - het type transactie
     - de gegevens in verband met de transactie
     - de gaskosten
     - alle andere relevante informatie (∞link 5. Transparantie van de code)

terug naar cheatsheet

3 - (Pushed Data) Transparantie van slimme contractgebeurtenissen

Evenementen zijn de meldingen van het Web3-tijdperk

(Ethereum) Smart-Contracts kunnen gebeurtenissen uitzenden die worden gebruikt om logs in de Blockchain op te slaan en om Dapps front-ends via Javascript reactief te informeren dat er iets is gebeurd.

Het is belangrijk om die gebeurtenissen te begrijpen
 - kan parameters, informatie toegevoegd aan de logs hebben
 - worden permanent opgeslagen in de Blockchain en kunnen daarom worden gezocht
 
Gebeurtenissen worden normaal gesproken door ontwikkelaars gebruikt voor verschillende dingen, zoals signalering wanneer aan een bepaalde voorwaarde is voldaan of wanneer een bepaalde actie is gebeurd: een nieuwe gebruiker is tokenhouder geworden, er is een aanbetaling gedaan of er zijn gegevens ontvangen van een Oracle en nog veel meer.

Het feit dat evenementen kunnen worden doorzocht, is enorm nuttig om het gedrag van een specifieke Dapp te registreren en te begrijpen wat er is gebeurd en wanneer, over de duizenden of miljoenen blokken sinds de oprichting van de Dapp.

Om beter te begrijpen waarom dit zo belangrijk is, wil ik je snel een persoonlijk verhaal vertellen:
Toen de Dao in 2016 werd gehackt, kreeg ik de kans om samen te werken met de groep die een deel van het grote probleem oploste: weten wie de hoeveelheid Ether verschuldigd was van het ExtraBalance-account.
Wanneer gebruikers tijdens de ICO Dao Tokens kochten, zouden volgens het tariefschema verschillende hoeveelheden ether in de ExtraBalance terechtkomen.
Twee van de probleemoplossers van de groep, Nick Johnson en Bokky Poobah, gebruikten het "CreatedToken" -evenement om alle transacties met betrekking tot de DAO ICO te traceren, terwijl ik de "harde route" aflegde waarbij ik me een situatie voorstelde waarin geen gebeurtenissen waren geïmplementeerd en ontwikkeld een deterministische parser voor de Blockchain, een forensisch hulpmiddel dat erg handig is in geval van kwaadaardige of slecht geplande smart-contracten. Ik deed dit ook omdat er geen Evenement als "ReceivedByExtraBalance" was om dat deel van de transactie vast te stellen.
Hier wordt het interessant: hoewel hun scripts een paar uur zouden duren, zou de mijne ongeveer een dag of langer duren; dat komt omdat ik elke afzonderlijke transactie in de Blockchain moest doorlopen (opnieuw uitvoeren), terwijl ze dankzij de gebeurtenissenlogboeken al toegang hadden tot de (bijna) 'juiste' transacties.
Toch kostte het ons drieën ongeveer twee maanden om de cijfers met elkaar te verzoenen en het hele saldo terug te geven aan de oorspronkelijke eigenaren.

Wat heeft dit te maken met Web3 Design Principles?
Evenementen worden willekeurig door de ontwikkelaars gebruikt: ze kunnen ervoor kiezen om een ​​evenement te plaatsen of niet om iets belangrijks over hun Dapp aan te geven. Om de front-end gebruiker toegang te geven tot de Evenementen in het Smart Contract is transparant over deze keuzes.

Een hoge mate van nuttige gebeurtenissen kan een teken zijn van een transparant Smart Contract en Dapp, een die niet bang is om u te laten weten wat het intern doet. Hoewel weinig tot geen evenementen een teken kunnen zijn van een slordig of zelfs kwaadaardig Smart Contract.

Zoals in het bovenstaande DAO-verhaal, zou het gebrek aan gebeurtenissen een gebruiker dwingen om hun eigen deterministische Blockchain-parsers te ontwikkelen om te begrijpen wat er binnen gebeurt, een praktisch onmogelijke taak ook omdat ze een archiveringsknooppunt nodig zou hebben.

Bovendien zijn evenementen nuttig voor ontwikkelaars om verschillende soorten analyses, meldingen en reactieve gegevensbronnen te maken, zelfs onafhankelijk van de eigenaar / maker van Smart Contract. Mogelijk moet deze kracht ook toegankelijk worden gemaakt voor de front-end gebruiker zonder te hoeven coderen.
 
Web3 postuleert:

- het is geen transparantie als het een enorme inspanning vereist om de gegevens te vinden, te bekijken en te verifiëren
 - Het is geen transparantie als 99% van de gebruikers ervan wordt afgeschrikt te willen kijken [2]

Principes

een Dapp front-end moet:

➤ alle evenementen verduidelijken en toegankelijk maken voor de eindgebruiker, zelfs als ze alleen voor ontwikkelaars zijn bedoeld

Relev pas relevantie toe: toon onderbrekende berichten alleen voor informatie die relevant is voor de huidige gebruiker, maar laat de gebruiker nog steeds alle gebeurtenissen in een aparte interface inspecteren

staat de gebruiker toe om zich te abonneren op bepaalde evenementen of deze af te melden of tijdelijk te dempen

Evenementen zijn contractspecifiek, dus dit zijn eenvoudige suggesties voor mogelijke implementaties.
Bovendien worden deze ideeën beter opgelost door een externe tool, service, een plug-in of bibliotheek, waarvoor de frontapp-ontwikkelaars van Dapp niet al deze "niet-kern" -functies in hun Dapp hoeven te implementeren.

Hoe> voorbeelden

  • een meldingscentrum hebben dat toegankelijk is voor de gebruiker, dit is waarschijnlijk een sectie in het zijpaneel "Chain-View"
  • gebruik toasts voor belangrijke berichten
  • filters maken om alleen bepaalde gebeurtenissen te selecteren / deselecteren of meldingen aan te passen op basis van alleen bepaalde parameters.
     Sommige filters kunnen zijn:
     - als deze Ether / tokens bevat
     - gebaseerd op adres (het mijne / het adres van de gebruiker of een ander adres of adressen)
     - tussen timeX en timeY, blockX en blockY
    enz.

terug naar cheatsheet

4 - (Geschiedenis) Toegankelijke en transparante geschiedenis van gebruikersinteractie

In een toekomst waarin we omgaan met honderden of duizenden Dapps, tokens en waarschijnlijk ketens, is het logisch voor de gebruiker om een ​​duidelijke geschiedenis te hebben vastgelegd van haar interacties met elke voor toekomstige referentie.
 
Portefeuilles slaan al de geschiedenis van alle transacties op, wat een begin is, maar het is slechts voor één account tegelijk, en het kan daarom moeilijk zijn om erachter te komen of u op meerdere transacties hebt gereageerd.
Bovendien zouden portefeuilles nog steeds moeilijk zijn, tenzij er extra functies worden gebouwd, om bijvoorbeeld alleen die uit een specifieke Dapp te filteren.

Het is zeker gebruiksvriendelijk voor een Dapp om je te helpen elke interactie die je ermee hebt gedaan te onthouden, net zoals je in elke normale app terug kunt gaan naar 'aankoopgeschiedenis'.

Het is zelfs nog belangrijker voor gedistribueerde uitwisselingen en Dapps die honderden of duizenden transacties voor elke gebruiker kunnen genereren.

Principes

Een Dapp front-end moet:

➤ biedt een geschiedenis van alle transacties vanaf een bepaald adres
Laat de gebruiker alle interacties inspecteren die ooit met het Smart Contract zijn gemaakt, waarschijnlijk voornamelijk die van type 2, die naar de Blockchain schrijven en dus de status wijzigen

➤ verduidelijk waar de geschiedenis is opgeslagen
Als u een geschiedenis van een bepaalde gebruiker wilt opgeven, betekent dit waarschijnlijk dat u haar Transactiehashes op een DB moet opnemen, op een externe server of beter in de lokale indexDB van de gebruiker. Dit is natuurlijk een potentieel privacyrisico, dus houd rekening met de privacyprincipes (∞link 2.Transparency of Transactions) en code transparantieprincipes (∞link 5.Transparency of Code) om de gebruiker duidelijk te maken waar deze gegevens worden opgeslagen.

geven hulpmiddelen om te navigeren, zoeken, exporteren en de geschiedeniscache te verwijderen

Hoe> voorbeelden

  • vergelijkbaar met het gebeurtenismeldingscentrum, een tabblad Gebruikersgeschiedenis of een speciale pagina hebben, waarschijnlijk in het zijpaneel van Chain-View
  • toestaan ​​om te filteren op verschillende soorten transacties (waarde-eth, waarde-tokens, functieaanroepen, contract genereren indien relevant)
  • toestaan ​​om te filteren op datum, vanaf het begin of tussen datums
  • optionele gebruikersvriendelijke toevoeging: laat gebruikers toe een niet-kettingnotaveld aan de transactie toe te voegen, zoals een eenvoudige herinnering als ze gewoon een voor mensen leesbare en doorzoekbare platte tekst willen hebben
  • optioneel: gebruik een zoekveld voor het geval er honderden interacties zijn en als dit relevant is voor uw Dapp
    dat wil zeggen: gedecentraliseerde uitwisselingen willen misschien een dergelijke functie toevoegen om de gebruiker in staat te stellen transacties te zoeken die alleen betrekking hebben op specifieke tokens
  • exporteren: laat de gebruiker optioneel de gegevens in csv exporteren en op andere manieren verkennen, opnieuw, vooral geschikt in het geval van grote gegevenssets
  • delete: laat de gebruiker de geschiedenis verwijderen uit de lokale cache, maar verduidelijk natuurlijk dat de echte transactiegeschiedenis niet wordt verwijderd, noch uit hun portemonnee, noch uit de Blockchain
  • importeren: het is zinvol om een ​​importoptie alleen toe te voegen als de Dapp de gebruiker toestaat aangepaste notities toe te voegen aan elke transactie, anders kan de informatie eenvoudig worden gereconstrueerd uit de Blockchain

terug naar cheatsheet

5 - (Code en omgeving) Transparantie van code

Als een Dapp kan worden vertrouwd, betekent dit ook dat de code die wordt uitgevoerd, kan worden vertrouwd.
Om vertrouwd te worden, moeten Dapps zo transparant mogelijk zijn over alle aspecten van hun code.

Web3 postuleert

- om een ​​Dapp te kunnen vertrouwen, moet de code vertrouwd zijn
 - om code enigszins vertrouwd te maken, moet deze transparant, onafhankelijk uitvoerbaar en verifieerbaar zijn

Principes

een Dapp front-end moet:

➤ Maak duidelijk welke Blockchain wordt gebruikt
het lijkt vanzelfsprekend, maar in een scenario met prolifererende Dapps kunnen veel Blockchain-agnostisch zijn of verschillende versies op verschillende ketens uitvoeren. Ook met Plasma, Polkadot, Cosmos en andere schaaloplossingen is het mogelijk dat een Dapp transacties volgt in zijn eigen subketen diep in een boom van andere plasmaketens of andere parachains of Cosmos-zones of hubs. De gebruiker moet erop worden gewezen waar zijn gegevens worden geschreven en daarom op de hoogte zijn van de technische variabelen (beveiliging, snelheid, enz.) En waar de gegevens onafhankelijk kunnen worden geverifieerd.

➤ Verduidelijk het adres van de Smart Contract (s) die worden gebruikt voor lees- en schrijfbewerkingen
en link naar onafhankelijke Blockchain-ontdekkingsreizigers (∞link 1.Transparency of Data Provenance).

➤ Maak duidelijk welke code open source is en waar deze te vinden is.

Verduidelijk waar code wordt uitgevoerd (lokaal versus externe server)
Dit is misschien een van de moeilijkste en omslachtig om op visueel niveau te implementeren, maar als onderdelen op een server moeten worden uitgevoerd, moet u ten minste een pagina hebben met uitleg over welke onderdelen en waarom en hiernaar verwijzen vanuit een relevant onderdeel van de gebruikersinterface.
Als de "kettingweergave" -modus in de voorbeelden van de eerste principes (∞link 1.Transparantie van gegevensherkenning) is geïmplementeerd, zou dat een goede plek zijn om deze andere weergaven toe te voegen.
 
De web3-provider / Blockchain-knooppunt verduidelijken (lokaal knooppunt, Dapp-bestuurd knooppunt, Infura, MetaMask? Of ander knooppunt)
Waarom? Omdat geïnstrumenteerde knooppunten gegevens kunnen registreren, zoals etherscan, en mogelijk een bron van privacyrisico's voor de gebruiker kunnen zijn.
 
- Sta indien mogelijk of relevant toe dat gebruikers overschakelen naar hun eigen knooppunt
Hoewel dit al wordt verzorgd door providers zoals MetaMask, is dit principe van toepassing in het geval dat uw web3 Dapp om welke reden dan ook transacties naar specifieke knooppunten uitzendt. Ook transacties die door uw eigen privéknooppunt gaan, kunnen sneller worden uitgevoerd omdat ze de potentiële wachtrijen van openbare knooppunten vermijden, vooral tijdens evenementen met veel vraag, zoals crowdsales.

Maak duidelijk of de Dapp wordt uitgevoerd op MainNet of op TestNet
Hoewel de web3-provider hiervoor zorgt, moet u er vooral voor zorgen dat de gebruiker begrijpt dat acties op het MainNet worden uitgevoerd als dit het geval is (gebruik ook de andere principes in 2.link 2. Transparantie van transacties)

➤ Maak duidelijk welke gegevens uit de keten van Oracles komen of door orakels zijn beïnvloed

Gebruiksvriendelijke toevoegingen
➤ Uitvoering van DIY-code toestaan
Sta meer gevorderde gebruikers toe de transactiefunctie-oproep te zien voordat deze wordt verzonden, zodat zij deze kunnen verifiëren en de actie zelf kunnen reproduceren via de opdrachtregel.
Dit lijkt misschien overdreven omdat de front-end van Dapp er is om de gebruiker te vereenvoudigen en bepaalde technische zaken te verbergen, maar een sceptische / paranoïde gebruiker zou zelfs afzonderlijke transacties willen verifiëren: als de Blockchain als een gedistribueerde database is, moet een gebruiker in staat zijn om de schrijfhandelingen onafhankelijk uit te voeren en de Dapp zou nog moeten werken.
In een radicale transparantie ten opzichte van de code, geeft een Dapp die deze functie toestaat aan: 'Vertrouw niet. Verifiëren ”https://blog.wizsec.jp/2018/02/kleiman-v-craig-wright-bitcoins.html?m=1

Een verbeterde versie van de Data Provenance waar de gebruikers de code ook kunnen kopiëren en plakken om de gegevens zelf op te halen

➤ Verduidelijk de invoer die vereist is voor het Smart Contract:
Slimme contracten vereisen vaak grote aantallen met veel nullen, die onvriendelijk zijn voor de gebruiker, vooral omdat het erg gemakkelijk is om dure fouten te maken. Het is normaal en raadzaam dat de gebruikersinterface van Dapp dit proces vereenvoudigt voor de gebruiker, waardoor kleinere getallen binnen een begrijpelijker en minder foutgevoelig bereik, zoals 0 tot 100, mogelijk zijn. In het licht van de eerdere transparantie van codeprincipes moet dit echter worden duidelijk voor de gebruiker waar die invoer wordt vereenvoudigd door de gebruikersinterface en verduidelijk, vooral in de doe-het-zelf-code-inspecteur, de daadwerkelijke invoer die het Smart Contract verwacht.
Een echt geval waarin dit verwarrend was, werd aan de orde gesteld in een discussie met Jorge Izquierdo over de Aragon Voting-app. Ontwikkelaars kunnen dezelfde oplossing gebruiken die voor die case wordt gepresenteerd en de gebruiker enkele voorbeelden verduidelijken met: het eenvoudige nummer, de wetenschappelijke notatie en de daadwerkelijke invoer (met alle nullen) die het Smart Contract verwacht.

detail van het voorbeeld uit de Aragon-wiki

Hoe> voorbeelden

  • hebben een pagina “Codetransparantie” die altijd toegankelijk is, zoals de Servicevoorwaarden of de Privacybeleidpagina's
  • link naar uw github-repo's op verschillende plaatsen
  • voeg aan het paneel "kettingweergave" (getoond in de voorbeelden van hoofdstuk 1.Transparantie van gegevensherkomst) een sectie gewijd aan codetransparantie
    ○ informatie over:
     - de gebruikte Blockchain,
     - de eigenschappen van een dergelijke Blockchain, met name de gemiddelde bloktbevestigingstijd (∞link 6.Time / Wait Management)
     - of het nu MainNet of TestNet is
     - de gebruikte web3-provider (overschakeling toestaan),
     - de contractadressen,
     - mogelijk een vereenvoudigde versie van de ABI van het contract met alleen de methoden die daadwerkelijk door de code worden genoemd
     - als een deel van de code niet-lokaal wordt uitgevoerd (tekstuele uitleg en motivatie)
     - de link naar de github-repo's
    ○ schakelaars, filters of opties om:
     - weergeven, met pictogrammen en / of door kleuren te wijzigen, welke onderdelen / componenten gegevens bevatten die op een server worden verwerkt
     - weergave, met (het "cloud-to-chain" orakel) linkpictogrammen en / of door kleuren te wijzigen, welke gegevens afkomstig zijn van orakels
     - indien relevant, de web3-provider wijzigen
     - een voorbeeld van transacties die worden aangeroepen met de functieaanroepen die kunnen worden gekopieerd en uitgevoerd op de opdrachtregel
     met opmerkingen over de ingangen, indien relevant.
een voorbeeld van het paneel Code transparantie en informatie

terug naar cheatsheet

Algemene Web3 UX-principes

De volgende principes hebben geen direct verband meer met de eigenschappen Transparantie en Vertrouwen en zijn eerder gericht op het oplossen van een aantal andere UX-problemen die voortvloeien uit het algemene gebruik en de implementatie van Gedistribueerde Toepassingen op basis van de Blockchain.

6 - Beheer van tijd / wachten

Totdat de schaalbaarheidsproblemen zijn opgelost, zijn transacties asynchroon en kan het volgens de onderliggende Blockchain en de huidige netwerkcongestie lang duren om te worden verwerkt en volledig te worden bevestigd.

Een goed ontworpen Dapp moet deze informatie verduidelijken en het wachten van de gebruiker beheren totdat haar actie is bevestigd.

Principes

een Dapp front-end moet:

➤ (Beheer de verwachting van de gebruiker) Verduidelijk bij elke transactie de gemiddelde blokbevestigingstijd van de onderliggende Blockchain en de huidige netwerkcongestie

➤ (Beheer de wachttijd) Toon levendheidsindicatoren tijdens de wachttijd

Hoe> Voorbeelden

Als een reeks UX-evenementen zou een Dapp moeten

  1. leg uit hoe gaskeuzes hun wachttijd beïnvloeden (∞link.9 Gasprijzen en TX's omkering)
  2. waarschuwing weergeven over ketenspecifieke tijden
  3. Toon een voortgangs- of wachtpictogram totdat het niet is opgelost
  4. Als het langer duurt dan normaal, toon dan feedback en mogelijke oorzaken en / of oplossingen
    dat wil zeggen: “het duurt langer dan verwacht. Het netwerk is momenteel overbelast.
     Dit zijn uw opties:
     -> Wacht X seconden / minuten meer
     -> voeg meer gas toe om de transactie te versnellen
     -> ontvang een melding wanneer u klaar bent
  5. Laat in elk geval weten dat u de gebruiker op de hoogte stelt van de succesvolle uitvoering
  6. Zodra de bewerking is voltooid, informeert u over de succesvolle uitvoering met een rapport van de gegevens (dat wil zeggen de Transactiehash) die ze onafhankelijk kunnen verifiëren

terug naar cheatsheet

7 - Door mensen leesbaar hashformaat

Totdat Naamregisters op grote schaal worden aangenomen, en zelfs dan hebben we te maken met de moeilijkheid van lange adressen en transactiehashes.
Dit zijn slechts enkele ideeën om ze leesbaarder te maken voor mensen, terwijl tegelijkertijd de transparantie van de volledige informatie behouden blijft.

Principes

Dapps front-end moet:

Tijdelijke update 2018–07–11 Er is momenteel een debat gaande over de beveiliging van sommige van deze principes. Kom over een paar dagen terug voor een betere en veiligere versie

➤ tonen een compacte versie van de hashes maar tonen altijd de begin- en einddelen
dat wil zeggen: 0xABCD ... EFGH
pas echter op dat dit beveiligingsproblemen kan bevatten, omdat ijdelheid-adresgenerators reeksen van 8 tekens in ≈1 week kunnen produceren,

➤ als je nodig hebt zelfs een kortere versie, ̵ de voorkeur aan het begin tot het einde ̵
̵ ̵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̵ (dit heeft beveiligingsimplicaties zoals opgemerkt door Tom Nash hier)> gewijzigd als volgt:

➤ Als u een nog kortere versie nodig hebt, geeft u de voorkeur aan het einde boven het begin
 dwz gebruik 0x ... EFGH in plaats van 0xABCD ...
(hoewel het beter leesbaar is en er beter uitziet om de eerste 4 tekens te hebben in vergelijking met de 0x ... EFGH, is er een beveiligingsprobleem omdat de eerste 4 tekens eenvoudiger zijn om bruut te forceren en genereren zoals in het geval van ijdelheid-URL's, maar het is astronomisch moeilijk om de exacte match voor de laatste 4 tekens te genereren)

geeft de voorkeur aan het gebruik van blokken van 4 letters in plaats van 3 letters voor elk deel
dwz gebruik 0xABCD ... in plaats van 0xABC ...

➤ plaats altijd de "0x" om aan te geven dat het een hash is

➤ zorgen voor een optionele weergave waar het hele adres zichtbaar is

Met kunnen gebruikers het adres gemakkelijk kopiëren

gebruik waar mogelijk afkortingen als titels en de afgekorte adressen als ondertitels

maak indien mogelijk een systeem waarmee de gebruiker eenvoudig een aangepaste, door mensen leesbare naam of tekst aan de adressen kan koppelen
deze opmerkingen moeten lokaal worden opgeslagen op de lokale computer van de gebruiker en niet op een server (gebruik ∞link 5.Transparantie van codeprincipes)
Als het bestaat, neem dan contact op met een bekende aliassen db zoals het ENS-register of Etherscan voor bekende contracten en adressen.

terug naar cheatsheet

8 - Permanente nieuwkomermodus

Als we massale acceptatie van gedistribueerde applicaties willen, betekent dit dat we massa's mensen zonder enige technische kennis of begrip van de Blockchain en zijn taalgebruik in staat moeten stellen om de ruimte in te gaan.
 
Dit is meer dan andere ruimtes die een beetje opleiding vereisen, zowel om veiligheidsredenen (omgaan met privésleutels), maar ook om volledig te begrijpen waarom de eigenschappen van de Blockchain zo'n revolutionair fenomeen zijn en hoe Dapps verschillen van andere apps.

Ook belangrijk is het feit dat deze ruimte zo prachtig is gefacetteerd dat vaak nieuwe mentale modellen en een multidisciplinair begrip vereist: het internet van waarde creëert duizenden tokenized ecosystemen beïnvloed door marktdynamiek, die normaal worden bestudeerd in economie, financiën en speltheorie; Het is zeer onwaarschijnlijk dat de massa op de hoogte is van of ooit blootgesteld is geweest aan deze disciplines.
Daarom moeten gedistribueerde applicaties een inspanning leveren om nieuwe en gevestigde gebruikers te informeren over alle aspecten van hun werk.

De meeste eerdere principes hebben een newbie-gebruiker in gedachten, maar er zijn nog een paar dingen waar ontwikkelaars rekening mee moeten houden.

Principes

Een Dapp front-end moet:

➤ Weven in educatieve informatie met de normale interactie
De belangrijkste taak voor Dapp Designer is uitstekend samengevat door Nick Neuman: “Een goede eindgebruikerstoepassing zal voorlichting geven over de productervaring. Dit betekent op een beknopte en interessante manier uitleggen waarom een ​​gebruiker iets doet terwijl ze het doet, en het product zo bouwen dat het voor de gebruiker heel moeilijk is om iets onveiligs te doen. "

➤ Bieden 2 of meer niveaus van educatieve inhoud: Blockchain basics en Dapp-specifieke lingo
Dit is niet alleen een principe voor onze tijd waarin nieuwkomers aan boord komen, het zou een goede gewoonte zijn voor alle apps, met name die met een interne of contextuele lingo of een uniek mechanisme, om een ​​andere educatieve laag toe te voegen: dat wil zeggen. als u een tokenfondsbeheerder bouwt, ga er dan niet vanuit dat uw gebruikers financiën kennen en wat elke term betekent; leer ze in plaats daarvan zowel de basis van Blockchain als de basis van financiën, op zijn minst om de woorden die u gebruikt te begrijpen.

➤ Minimaliseer en verhoog geleidelijk het aantal nieuwe dingen en concepten die de gebruiker moet leren
Blockchain-projecten zullen, ondanks de tokenized prikkels tot acceptatie, nog steeds te maken krijgen met de normale wrijving en verandering die elke softwareservice ervaart: gebruikers zullen eenvoudiger alternatieven kiezen, vooral als een Dapp er teveel van vraagt. Daarom moet Dapps bij het aanbieden van hun educatieve inhoud aan nieuwkomers proberen het gebruik van nieuwe woorden en concepten te minimaliseren, met name op de pagina's voor het generieke publiek (bijv. De startpagina) en geleidelijk meer leerresultaten tonen op pagina's voor betrokken gebruikers (bijv. Gebruiker dashboards). Dit kan ook worden bereikt door eenvoudiger taal te gebruiken, lingo te vermijden en analogieën te gebruiken om complexe nieuwe informatie uit te leggen met kennis waar de gebruiker misschien al bekend mee is. Zie bijvoorbeeld hoe Spankchain het concept van een kaart heeft gemaakt om te voorkomen dat betaalkanalen moeten worden uitgelegd.

➤ Versnel indien mogelijk of relevant het verstrekken van de "interpretatie door de expert"
Demystify de betekenissen van uw Dapps-functies, hoe ze samenwerken en hoe een expert zou denken over de effecten.
Wat zou een expert weten over een bepaald specifiek ding? Hoe zouden ze de gegevens interpreteren? Hoe zouden ze daarop reageren? Welke keuzes zouden ze maken?
De antwoorden op die vragen kunnen worden verwerkt als suggesties in de gebruikersinterface van Dapp, als ze relevant zijn.
Voorbeelden gaan van het anticiperen op goede gasprijzen (∞link 9.Gasprijzen) tot het aangeven dat het een goed of slecht moment is om een ​​bepaald token te ruilen (slechts een voorbeeld).

➤ Verlies de context niet
probeer de fragmenten in de interface te weven, met tijdelijke pop-ups die gemakkelijk kunnen worden genegeerd en die vervolgens meer gedetailleerde informatie op een ander tabblad kunnen openen. Laat de gebruiker tijdens het leren snel en 'op zijn plaats' leren, zonder van pagina te veranderen en uit het oog te verliezen wat hij aan het doen was.

Hoe> voorbeelden

  • kleine ondertiteling toevoegen voor opdrachten overal (en verwijzen naar andere principes om te anticiperen op wat transacties gaan doen ∞link 2.Transparency of Transactions)
  • leermodus instelling
    voeg aan de "kettingweergave" of andere delen van de gebruikersinterface een schakelaar (een "universeel vraagteken" -knop) toe die kan worden in- en uitgeschakeld en leerfuncties in- of uitschakelt
  • Pop-up woordenlijst
    Bij gebruik van lingo dat beschikbaar is in een woordenboek, geeft u een koppelingspictogram weer, een pictogram achter het woord, dat, als erop wordt geklikt of omgedraaid, een contextuele pop-up met de opgegeven informatie wordt weergegeven
    In sommige gevallen moet de pop-up ook de mogelijkheid bieden om "meer te weten", waardoor een ander tabblad of een zijbalk wordt geopend in de "kettingweergave" op het tabblad met de woordenlijst.
  • Woordenlijst pagina
    in de ketenweergave of op een andere pagina moet de Dapp een pagina bieden met alle voorwaarden, specifiek voor Blockchain en Dapp, die in de Dapp zelf worden gebruikt of die nodig zijn om de werking ervan te begrijpen. Deze pagina moet worden omgeleid vanuit de pop-up van de woordenlijst en niet rechtstreeks worden gekoppeld.
  • in elke wizard zou het handig zijn om snel door te schakelen naar de volgende stappen, zodat u kunt zien wat er aankomt, hoewel al hun lay-outs grijs moeten zijn en uitgeschakeld totdat u de vorige stappen hebt voltooid. Dit is een goed principe voor elke ui, niet alleen voor Dapps.

terug naar cheatsheet

9 - Gasprijzen en omkeringen van transacties

Gas is een van de meest verwarrende dingen voor nieuwkomers. Zelfs als de naam veelzeggend is, is het moeilijk om je de kosten voor de berekening voor te stellen voor services die je in principe altijd gratis hebt gehad.
Bovendien weten gebruikers, wanneer ze voor het eerst gas tegenkomen, niet hoe ze het moeten prijzen, noch wat een goede keuze voor de gasprijs zou zijn.

Zelfs als tegenwoordig in vrijwel alle gevallen het gas wordt verwerkt door portefeuilles die de transactie uitzenden, is dit principe nog steeds geldig, zowel voor portemonneeontwerpers als voor al diegenen die de gebruikers ooit zullen vragen of vragen om een ​​gasprijs te kiezen.

gelukkig voor ontwikkelaars zijn er tools zoals het Ethereum-tankstation dat een handige API biedt.

Principes

Dapps front-end moet:

➤ Verduidelijk wat Gas en Gasprijs is
(net als bij elke andere lingo ∞link 8. Nieuwe modus)

➤ Stel een goed bereik voor de gasprijs voor en verduidelijk tijdsschattingen voor de bovenste en onderste bereiklimieten
dit zijn functies van de huidige congestie van het netwerk, dus de optimale oplossing zou zijn om de huidige Ethereum Tankstation API https://ethgasstation.info/json/ethgasAPI.json op te vragen om deze bereikgrenzen voor te stellen.
Het is belangrijk om de gebruiker duidelijk te maken dat dit een op tijd gebaseerde suggestie is en dat de voorgestelde waarden in de toekomst kunnen veranderen.
 
➤ tonen mogelijk ook gaswaarden die zijn geconverteerd naar FIAT

➤ Transactieomkering toestaan: in het geval dat de gebruiker een TX heeft verzonden met een lage gasprijs, moet dit duidelijk worden gemaakt aan de gebruiker
(∞link naar 6.Time / Wait Management)
- dat de tx niet meer kan worden geannuleerd nadat deze is gelanceerd
- dat de enige oplossing is om nog een tx uit te zenden met dezelfde nonce en een hogere gasprijs
> bied daarom de optie om de tx nonce automatisch te recupereren en te verzenden met een hogere gasprijs.

terug naar cheatsheet

DDP Decentralisatie ontwerpprincipes

Decentralisatie is een nieuwe krachtige vorm van globalisering.
Een die voor het eerst mogelijk wordt geleid door massa's zelf-soevereine individuen die zich samenvoegen rond ideeën zonder grenzen, zelfsturende organisaties en gedistribueerde marktsystemen.

Deze ontwerpprincipes willen alleen het gesprek op gang brengen door te denken hoe de gebruiker zich deel kan laten uitmaken van een gemeenschap en van iets dat ambitieuzer is dan zijzelf.
Ze zijn slechts een hint voor ontwikkelaars om holistisch te gaan nadenken over de functie van hun Dapps, en de nieuwe UX-vereisten die ontstaan, in de grotere context van de gedistribueerde samenlevingen die we creëren.

10 - Sense of Community

Dapps zijn anders dan apps omdat ze native worden gedistribueerd: zelfs als sommige diensten gericht zijn op het individu en wiens interactie een eenzame ervaring is, zijn ze nog steeds gemaakt voor, en vaak door, een grote groep mensen over de hele wereld.
 
Het gevoel bij een gemeenschap te horen is belangrijker in deze Dapps, omdat gebruikers zich moeten hechten aan een gedecentraliseerd merk en product.
Dat betekent niet dat je in de Dapp een sociaal netwerk moet bakken, hoewel sommigen misschien profiteren van een nauwere integratie met de communitychat die door het project is gekozen.

Onnodig te zeggen dat deze ideeën behoorlijk belangrijk zijn voor DAO's.
 
Overweeg het volgende, net als enkele generieke suggesties binnen het meer vrij interpreteerbare doel om gebruikers deel te laten uitmaken van iets dat groter is dan zijzelf.

Principes

Dapps front-end moet:
 
verduidelijken hoeveel andere leden er in de community zijn
verduidelijken wie de andere leden zijn (kies de juiste categorieën)
➤ verduidelijking van de samenstelling van de gemeenschap (dwz subgroepen en hun macht over het project)
➤ de grotere missie van het project (indien aanwezig) en hoe hun deelname bijdraagt ​​aan de realisatie ervan

Hoe> Voorbeelden

  • bieden een landingsdashboard met statistieken over unieke tokenhouders of het aantal leden van een Dapp of DAO
  • gebruik het transparantieprincipe en toon vooral alle informatie die door de gebruikers zelf kan worden verkregen door de Blockchain te analyseren:
     - token vermogensverdeling,
     - tijdgrafieken voor adoptie,
     - tokenhouder sinds blok XX en jjjj-mm-dd
     enz
  • overweeg in DAO's om de informatie te verrijken met alles wat relevant kan zijn (indien beschikbaar) zoals:
     - soort leden (dwz # fokkers versus niet-fokkers in Crypto Kitties, of # muzikanten en # luisteraars in Music / ART Dapps zoals UJO Music, stakers versus niet-stakers enz.)
     - uitzetten van distributiestatistieken
     - misschien geografische locaties / tijdzones ?,
     - misschien seks, leeftijden? (maar alleen als het zinvol is voor uw gemeenschap en als het niet aanstootgevend of schadelijk is voor de goedkeuring van uw Dapp)
  • Zoek duidelijk naar de categorieën die geschikt en relevant zijn voor uw project: het is bijvoorbeeld mijn persoonlijke mening dat in DAO's het geslacht en de leeftijden geen relevante informatie zijn, zelfs contraproductief voor het idee van het creëren van rechtenloze en onbevooroordeelde samenlevingen, maar misschien zijn ze erg relevant in projecten zoals SpankChain.
  • misschien kunnen gebruikers hun eigen tags, categorieën, biobeschrijving enz. kiezen: elk lid kan verschillende identiteiten hebben in verschillende projecten. Dit verwijst al naar andere principes over identiteiten die in de toekomst zullen worden gepresenteerd.

terug naar cheatsheet

11 - Andere toekomstige ontwerpprincipes

Zoals u misschien wel hebt begrepen, vereist het vorige principe wat meer gedachten over Identiteiten, Reputatie en Governance. De eerste twee zijn universeel bruikbaar in veel community-gestuurde apps, maar ze zullen van fundamenteel belang zijn voor Token Curated Registries (TCR) en, waarschijnlijk, voor veel DAO's en andere crypto-primitieven.

Deze principes verdienen hun eigen analyse en ruimte, en deze post is al te lang.
In de toekomst zal ik Web3 Design Principles analyseren voor:
- Identiteiten en reputatie
- Governance
- Portefeuilles
- Uitwisselingen
- Verkoopmechanica voor ICO & Token
- Token mechanica

Volgende stappen

Het is duidelijk dat de vereisten van "extreme transparantie" zoals voorgesteld in deze Web3 Design-principes, een behoorlijke last vormen voor Dapp-ontwikkelaars die tegenwoordig meer gericht zijn op het oplossen van vele andere delen van hun projecten.
 
 - Bootstrap-achtige bibliotheek
Het is daarom duidelijk dat er een standaardtoolset moet zijn die ontwikkelaars kunnen aansluiten op hun Dapps en misschien hun oproepen naar de web3-bibliotheek kunnen koppelen en gratis al deze transparantiediensten voor hun gebruikers kunnen krijgen.
Ik stel me zoiets voor als een Bootstrap-achtige bibliotheek voor het Web3-tijdperk ("Chainstrap"? Het is een beetje een te harde kern, toch?: P)

- Onafhankelijke browser plug-in
Misschien is het zelfs raadzaam dat er een onafhankelijke tool bestaat die gebruikers de voordelen van de Web3 Design Principles biedt, al dan niet die de Dapp-maker wil of niet; een soort 'transparantie-handhaver', die het mogelijk zou kunnen maken om kwaadaardige of slordige Dapps te identificeren door hun mate van overeenstemming met sommige van de principes.
In dit geval zou het waarschijnlijk gepast zijn om een ​​browserplug-in te maken die de code in de Dapp injecteert en de kettingweergavefunctionaliteit biedt en misschien zelfs een snelle certificering van de mate van transparantie en betrouwbaarheid van de Dapp.

- Aangepaste services
Bovendien zijn er in deze principes veel mogelijkheden voor diensten, zelfs commerciële die vandaag nog niet bestaan.

Vele opties. Wat denk je?

Als u geïnteresseerd bent in het ontwikkelen van een van de bovenstaande, als u gewoon gedachten en overwegingen heeft,
of als u een subsidieverlenende organisatie bent en denkt dat het zou kunnen passen in uw huidige doelstellingen,
Neem contact op met b [at] likuidlabs.com of op Twitter @lyricalpolymath

Laten we samen de toekomst van decentralisatie ontwerpen en bouwen!

OPMERKINGEN

[1] Andere "Blockchain" + ontwerpartikelen

Toepassing van de ontwerpmethodiek heb ik onderzocht wat er al over het onderwerp was gecreëerd: niet veel.

  • Blockchain Design Principles - Ontwerp bij IBM
    Dit is veruit het beste artikel over het onderwerp. Geschreven door Sarah Baker Mills, voormalig ontwerpleider bij IBM en vandaag Design Director bij Consensys. Ze distilleert heel goed enkele van de principes die voorkomen in de Web3 Design Principles, hoewel onder verschillende namen. Ze praat over gegevensblootstelling, consistentie, feedback, anticiperen op fouten en actieve begeleiding.
  • Blockchain en Design - Hacker Noon
     Een interview met Matt Storus, hoofdontwerper op 21.co, over de uitdagingen en enkele ideeën over wat ontwerpers moeten doen. Helaas laat het interview-formaat niet toe om veel leringen te destilleren, maar hij is absoluut een interessant boek.
  • De gebruikerservaring van Blockchain
    een generiek bericht om ontwerpers te informeren over de Blockchain en de ontwerpuitdagingen.
  • Hoe kan Design Blockchain - The Spark helpen?
    een paar macro-ideeën over sommige dingen waaraan ontwerpers in deze ruimte moeten denken
  • Ontwerpen voor de Blockchain: lancering van een ethereum Smart Contract-app
    Een studie over het ontwerpen van een betere ervaring voor een investeringsplatform, met enkele ideeën om de deelname aan ICO's te verbeteren

[2] Ik weet dat deze postulaten een fenomenologische denkfout zijn, maar ik gebruik ze sowieso omdat ze een nuttige vereenvoudiging zijn en het punt duidelijk maken: voor een niet-technische gebruiker, die de gegevens niet op een eenvoudige manier zelf kan verifiëren, de informatie is duidelijk niet transparant. Transparantie wordt dan een glinsterende luchtspiegeling, een getrouwe verwachting van vertrouwen.