Web3-designprincipper

En ramme af UX-regler for Blockchain-baserede distribuerede applikationer (del 1)

Bemærk: Dette indlæg er ret langt> hopp til cheatsarket eller til konklusionerne

Blockchain-udviklere skubber frem den storslåede vision om en decentral fremtid, men oplevelsen af ​​denne vision gennem Distribuerede applikationer (Dapps), som vi kasserer, ligner stadig en klodsig prototype af web2.
 
Det er sandsynligvis passende, at de fleste af de brugere, der ville bruge disse Dapps, stadig "lever" på web2 og ikke engang har hørt om løfterne fra den decentrale Web3.
Selv hvis de skulle komme og se disse skinnende nye apps, ville de have svært ved at forstå lingoen, formålet, dynamikken i disse Dapps til endda visuelt at fortælle dem bortset fra normale webapps.

Det må siges, at der er mange gode værktøjer (Drizzle, MetaMask), der kommer ud og angriber nogle af disse problemer. Vi kommer derhen.

Disse designprincipper ønsker at foreslå nogle ideer til, hvordan man løser dette, med retningslinjer, der hjælper designere og udviklere, så vi alle kan gøre denne skinnende fremtid mere tilgængelig og nær, for alle.

Web3 Design vs Blockchain Design

Andre mennesker har skrevet om “Blockchain Design” [1], mens de præsenterede løsninger, der vedrører front-end brugeroplevelsen af ​​Decentraliserede Apps (Dapps).

Selvom Sarah Mills, hoveddesigner hos Consensys, artiklen er en inspirerende læsning, og hun er helt klart den førende stemme, der opfordrer til designere i Blockchain-rummet, synes jeg, at ordlyden “Blockchain Design” er mere passende til at definere egenskaberne og deres interaktion , af Blockchain-konstruktionen i sig selv: ting som konsensusalgoritmen, forsyningsbasen, blokbelønningen, turing fuldstændighed, beregning / ”gas” -omkostninger, til eller fra kædestyringsmekanismer og mange flere.
 
I denne artikel vil jeg i stedet henvise til “Web3 Design”, der hovedsageligt angiver principper, der skal anvendes til oprettelse af brugeren, der står over for dele af decentrale apps.

Det er fristende at bruge ordet “Blockchain” i titlen, men det ville være clickbait

Hvorfor Web 3-designprincipper

I dag kan en bruger interagere med en Smart Contract, der er implementeret på Blockchain på flere måder: enten direkte via kommandolinjen, gennem de formlignende grænseflader i deres digitale tegnebog eller Dapp-browser, eller måske gennem den rigere front-end, som Smart Contract-udvikleren har eller vil udvikle sig.
Det er åbenlyst, at stien til masseoptagelse af Dapps går gennem sidstnævnte: at give en rig brugergrænseflade, der er samlet med oplevelsen af ​​at håndtere en Blockchain-baseret distribueret applikation.

I dag som udviklere er vi, med rette, meget travlt med at bygge infrastrukturen i Blockchain og de smarte kontrakter for vores projekter, så det er åbenlyst, at ikke mange Dapps i øjeblikket har en brugbar frontend, eller, hvis de har en, sikker for indholdet, de kan hovedsageligt ikke skelnes fra enhver anden webapp omkring.

Dapps adskiller sig imidlertid grundlæggende fra normale web- eller mobilapps, fordi de er baseret på og bør kraftigt formidle de magtfulde principper, der er aktiveret af Blockchain: decentralisering, gennemsigtighed, tillid, uforanderlighed, usensurabilitet osv.
Disse egenskaber ved Blockchain og ved reflektion af front-end Dapps er det, disse designprincipper kodificerer til brugbare værktøjer.

Målet er, at når en bruger, der først er anvendt korrekt, en bruger, der lander på en Dapp, straks kan fortælle, at hun interagerer med en, og endnu vigtigere, har adgang til de stærke egenskaber i Blockchain og derfor ved, at hun kan stole på enhver interaktion med applikationen.

Variabler, der skal overvejes for at forstå principperne

  • det vigtigste mål for øje er en ikke-teknisk bruger, selvom nogle principper også er rettet mod mere kyndige brugere
  • ikke alle Dapps har brug for alle principper
  • løsningen vist i eksemplerne er kun nogle indledende ideer til at starte samtalen
  • nogle principper kunne implementeres på forskellige måder af hver Dapp-udvikler
  • nogle web3-principper antyder behovet for et eksternt værktøj, service eller bibliotek snarere end at forestille sig, at hver udvikler ville implementere deres løsning (mere om dette i de næste trin)
  • mest hvis ikke alle web3 designprincipper ville drage fordel af at blive kodificeret i et Bootstrap som udviklervenligt bibliotek (mere om dette i de næste trin)

Hvis du er interesseret i dette, skal du springe til afsnittet "næste trin" i slutningen for at se, hvordan vi kan arbejde sammen.

Fremgangsmåde til design

Design handler også om at foregribe problemer og tilbyde løsninger. I dette tilfælde forsøgte jeg at "projektere" (et bedre ord efter min mening for dets etymologiske betydning at "lancere fremad" ind i fremtiden) de spørgsmål, som en bruger måtte have, når han interagerer med en Dapp.

Spørgsmål som:

  • er det sikkert at gøre dette (action_dapp_asks_me_to_do)?
  • vil penge være i fare, hvis jeg skruer op?
  • Jeg har hørt, at krypto skulle være mere privat… hvad sker der med de data, jeg sender? hvor opbevares det? Kan jeg identificeres?
  • hvem vil se de data, jeg indtaster? hvor køres koden?
  • hvad vil der ske, når jeg gør dette (handling)?
  • hvordan skal jeg gøre (crypto_action_here)?
  • hvad betyder dette (weird_crypto_word)?
  • Det antages, at Blockchain kan stole på, men hvordan kan jeg fortælle, hvilke data der kan stole på denne app?
  • hvilke data kommer fra Blockchain?
  • hvordan kan jeg bekræfte, at dataene virkelig er gemt i Blockchain?
    etc.

Designprincipperne indeholder værktøjer til udviklere til at besvare disse og flere spørgsmål, som brugerne måtte have.

Web 3-designprincipper (indeks / cheatsheet)

Dette indlæg er ret langt, så du kan bruge dette cheatsheet til at få et hurtigt overblik over principperne og hoppe til dem, du er mere interesseret i at forstå

//// TTT: Tillid gennem principper for gennemsigtighedsdesign

1 - (læsning af data) Gennemsigtighed i dataprovenance

➤ Afklar, hvilke data der kommer fra Blockchain, og hvilke ikke
➤ Præciser kontraktens (e) adresse
➤ Link alle Blockchain-data til uafhængige Blockchain-opdagere
➤ Afklar hvilke data der kommer fra orakler (∞link> 5. Transparens for kode)
 - Hvordan> eksempler

2 - (Skrivning af data) Gennemsigtighed i transaktioner

- Typer af transaktioner (værdioverførsler, funktionskald, kontraktgenerering)
➤ [Permanence] klarlægge handlinger, der er irreversible
➤ [Værdi] klarlægge handlinger, der involverer penge eller værdi
➤ [Privatliv] klarlægger handlinger, der potentielt kan føre til brugeridentifikation
➤ [Fabrik] klarlægger handlinger, der genererer nye kontrakter i brugernavnet
- Retningslinjer for alle transaktioner:
- ➤ klarlægge og bekræfte på forhånd den nye fremtidige stat
 - ➤ viser de data, der bruges til en transaktion i et menneskeligt læsbart format, og på den måde, som Smart Contract kræver det (∞link 5. Transparency of Code)
- ➤ klarlægge de foreslåede værdier for gasprisen, og hvordan man overskriver Tx (∞link 9.Gas Price and Transaction Reversals)
 - ➤ administrere ventetid for transaktion (∞link> 6.Time / Wait Management)
 - ➤ muligvis afklare, hvilke handlinger der IKKE er transaktioner og dermed sikre
 - Hvordan> eksempler

3 - (Pushed Data) Gennemsigtighed af smarte kontraktarrangementer

➤ klarlægge og gøre tilgængelig for slutbrugeren alle begivenheder, selvom de kun er beregnet til udviklerformål
➤ anvende relevans: vis kun afbrydende meddelelser til information, der er relevant for den aktuelle bruger
➤ giver brugerne mulighed for at abonnere på, afmelde eller midlertidigt slå af hændelser
 - Hvordan> eksempler

4 - (Historik) Gennemsigtighed og tilgængelighed af brugerens interaktionshistorie

➤ giver en oversigt over alle transaktioner fra en given adresse
➤ klarlægge, hvor er historien gemt (lokal eller server) (∞link 5. Transparency of Code)
➤ giver værktøjer til at navigere, søge, eksportere og slette historikcachen
 - Hvordan> eksempler

5 - (kode og miljø) gennemsigtighed af kode

➤ præciser, hvilken Blockchain der bruges
➤ Angiv adressen på den / de smarte kontrakt (er), der bruges i læse / skrivehandlinger
➤ præciser, hvilken kode der er open source (og hvor man finder den)
➤ klargør, hvor koden køres (lokal vs fjernserver)
➤ klarlægge web3-udbyderen / Blockchain-noden (lokal knude, Dapp-kontrolleret node, MetaMask, Infura osv.)
➤ klargør, om Dapp kører på MainNet eller TestNet
➤ klarlægge, hvilke data der kommer fra orakler eller er blevet påvirket af orakler (∞link> 1.Transparency of Data Provenance)
➤ giver mulighed for udførelse af DIY-kode: lad avancerede brugere se koden, der køres, og selv udføre den via kommandolinjen
➤ klarlægge de input, der kræves af de smarte kontrakter
 - Hvordan> eksempler

//// Generelle Web3 UX-principper

6 - Time / Wait Management

➤ (Administrer brugerens forventning) afklar Blockchain-specifikke tidspunkter og administrer brugernes vent i forskellige faser
➤ (Administrer ventetiden) Vis livlighedsindikatorer i ventetiden
 - Hvordan> eksempler

7 - Human Readable Hashes-formater

➤ viser en kompakt version af hasherne, men viser altid start- og slutdele
➤ i̵f̵ ̵y̵o̵u̵ ̵n̵e̵e̵d̵ ̵a̵n̵ ̵e̵v̵e̵n̵ ̵s̵h̵o̵r̵t̵e̵r̵ ̵v̵e̵r̵s̵i̵o̵n̵ ̵p̵r̵e̵f̵e̵r̵ ̵t̵̵̵̵̵̵̵̵
➤ Afhæng altid “0x” for at indikere, at det er en hash
➤ giver brugerne mulighed for at udvide den fulde adresse / hash
➤ giver brugerne mulighed for let at kopiere det
Brug, hvor det er muligt, korthår som titler og de forkortede adresser som undertekster
➤ allow Tillad brugeren om muligt let at knytte et brugerdefineret menneskeligt læseligt navn eller tekst til adresserne og hasherne
➤ Hvis det er muligt at knytte en eller anden form for deterministisk visuel repræsentation af hasjen (dvs. Identicons, blockies et al) sammen med adressen

8 - Permanent begyndertilstand

➤ væves ind i uddannelsesmæssig information med normal interaktion
➤ giver 2 eller flere niveauer af uddannelsesindhold: Blockchain-grundlæggende og Dapp-specifik lingo
➤ minimere og gradvist øge mængden af ​​nye ting og koncepter, som brugeren har brug for at lære
➤ accelerer læring, hvis det er muligt eller relevant, ved at give "ekspertens fortolkning"
➤ mister ikke kontekst
 - Hvordan> eksempler

9 - Reversering af gaspris og transaktion

➤ klargør, hvad der er gas og gas pris (ligesom med enhver anden lingo ∞link 8.Newbie-tilstand)
foreslå gasprisklasser og afklar tidstilnærmelser for de øvre og nedre grænser
➤ viser muligvis gasværdier, der også er konverteret til FIAT
➤ giver mulighed for tilbageførsel af transaktioner

//// DDP: Decentraliseringsdesignprincipper

10 - Følelse af samfund

➤ præciser, hvor mange andre medlemmer der er i samfundet
➤ klarlægge, hvem der er de andre medlemmer (vælg passende kategorier)
➤ klarlægge sammensætningen af ​​samfundet (dvs. undergrupper og deres magt over projektet)
➤ del projektets større mission (hvis nogen) og hvordan brugerens deltagelse bidrager til dets gennemførelse
 - Hvordan> eksempler

11 - Fremtidige designprincipper, der skal undersøges (Del2)

➤ Identiteter og omdømme
➤ Regeringsførelse
➤ Tegnebøger
➤ Udvekslinger
➤ Salgsmekanik for ICO & token
➤ Token Mechanics

Næste skridt

TTT: Tillid gennem principper for gennemsigtighedsdesign

Web3-postulater:

- Det er ikke gennemsigtigt, hvis du ikke ved, hvor & hvordan man skal se ud
- Hvis det ikke er gennemsigtigt, kan det ikke stole på!

Alle i dette rum, og deres mor, taler om, hvordan Blockchain er "tillidsløs" og "gennemsigtig".
At forklare, hvorfor disse to antagelser kun delvist er sandt, ville tage en længere post og gøre denne ene forkert ud af sporet.
Det er (næsten) bestemt sandt på et programmatisk niveau, software, der bekræfter data, men disse to antagelser falder fra hinanden, når du konfronterer dem med den faktiske slutbrugeroplevelse.

Ud over det faktum, at mange kryptoprojekter eller Dapp-front-endes sjældent viser brugeren, hvor Smart-Contract-adresserne hun interagerer med, eller hvor dataene kommer fra, er det i øjeblikket skræmmende eller umuligt for en ikke-teknisk bruger at forstå informationen og arbejdet af uafhængige Blockchain-opdagere som Etherscan.
Den eneste ting, som i dag delvis kan kontrolleres af brugeren, er, når mellemliggende tegnebøger registrerer transaktionshash, som kan kontrolleres i de førnævnte Blockchain-opdagere.

Derfor, hvis en bruger, især en ikke-teknisk, ikke kan genkende ved at kigge på brugergrænsefladen, hvis en Dapp faktisk er en Dapp eller en normal webapp, og heller ikke kan hun verificere, om det indhold, hun ser, eller hendes interaktion med det er faktisk relateret til en Blockchain, så tildeles hun ikke den tillid og gennemsigtighed, som Blockchain formodes at levere.

Web3 Design-principperne i denne kategori (TTT) foreslår en radikal gennemsigtighedstilgang, der gør det muligt for enhver Dapp-frontbruger, også ikke-tekniske, at være fuldt opmærksom på datapræsentation, forstå implikationer af transaktioner før, under og efter deres udførelse, og i sidste ende være i stand til at stole på den aktuelle kode og service.

tilbage til snydearket

1 - (læsning af data) Gennemsigtighed i dataprovenance

En bruger skal være i stand til at fortælle, muligvis bare ved at se på siden, at et bestemt datapunkt eller indhold faktisk er gemt i Blockchain. Det er ikke brugervenligt at lade dem gætte, og det er ikke nok at lade dem antage, at "alle" data, der er set, er gemt i Blockchain.
Dette krav lyder måske vanskeligt for dataintensive Dapps som Distribuerede udvekslinger, men der er nogle løsninger, der vil blive præsenteret i eksemplerne.

Principper

Dapp-frontenden skal:

➤ præciser, hvilke data der kommer fra Blockchain, og hvilke ikke
➤ afklare kontraktens (e) adresse
➤ forbinder alle Blockchain-data til uafhængige Blockchain-opdagere
➤ præciser, hvilke data der kommer fra orakler (∞link> 5. Transparens for kode)

Hvordan> Eksempler

  • Brug css til at ændre farve / skrifttype / form for klart at skelne Blockchain-data. Selvfølgelig skal du prøve at være konsekvent på tværs af dit projekt og bruge altid den samme "Blockchain-farve"
Dataprovenance FRADataprovenance TIL: farver dataene fra en bestemt kontrakt
  • Brug udvidelige referencer:
    Når du holder musepekeren eller klikker på et Blockchain-datapunkt, kan du give en kontekstuelt udvidet værktøjstip med mere information om datapunktet, der skal gøre det klart, hvor på Blockchain, i hvilke kontrakter kan dataene findes.
eksempel på en kontekstuel udvidelig reference
  • administrere stylingkonflikter med linkikoner
    Hvis et datapunkt både er et "Blockchain-datapunkt" og et link til et sted i din dapp, er der to måder at løse den dobbelte handling:
    1- tilføj et link-ikon, et ikon, der følger ethvert "Blockchain-datapunkt", der giver den udvidelige referencefunktionalitet, mens du forlader intakt den normale funktion af linket.
    2- åbn den udvidelige reference og indsæt et sekundært link inde i det (men overvej, at dette skaber mere friktion, fordi du beder brugeren om at udføre 2 handlinger i stedet for en).
Eksempel på et link-ikon, der åbner den kontekstuelle reference. Dette er til at føje chainView-funktionaliteten til et link, der går et sted i din Dapp
  • Brug en "Chain-view" -tilstand og / eller sidepanel
    For dataintensive grænseflader som decentral udvekslinger eller markedsvisninger efter de foregående forslag ville sandsynligvis betyde styling af størstedelen af ​​grænsefladen, hvilket sandsynligvis tilføjer mere forvirring. For at løse dette kan du forestille dig en "Chain-view" -knap, der, når den er svævet eller klikket, midlertidigt stiler dataene. Det er som at lægge et filter over siden, et filter, der hjælper brugeren med at se, hvilke data der er et Blockchain-datapunkt.
     
    Udvidelse af denne idé kan "Chain-view" også være et sidepanel, hvor mange af de funktionaliteter, der er beskrevet i Web3 Design Principles, kunne være vært. I dette tilfælde kan Chain-View-panelet have den førnævnte mulighed for at slå eller deaktivere synligheden af ​​Blockchain-datapunkterne. I de næste eksempler vil vi se mange flere anvendelser af Chain-View-panelet.
Chain View-sidepanel med Data Provenance-indstillingen åbnes
  • Vis tydeligt, hvilke links der åbner den eksterne Blockchain explorer
    Hvis et link vil sende brugeren til en anden side, er det bedre at kontrollere strømmen af ​​brugeren på siden ved at:
    1 - tilføjelse af en afklaringsknap, der angiver, hvad der vil ske: dvs. "åben i Etherscan"
    2 - annoncer et link-ikon for uafhængige blokforkundere og brug det konsekvent på tværs af dit brugergrænseflade

tilbage til cheatsheet

2 - (Skrivning af data) Gennemsigtighed i transaktioner

Brugeren skal være opmærksom på, at data vil blive skrevet til Blockchain, og især når det indebærer udveksling af en økonomisk værdi (cryptocurrencies eller tokens). Selvom tegnebøger advarer brugeren om denne hensigt, bør Dapp afklare dette, inden transaktionsanmodningen startes i tegnebogen.

Typer af transaktioner

Der er forskellige typer transaktioner, der kan ske, når de interagerer med Blockchain, og som hver har forskellige konsekvenser.
Brugeren skal være i stand til at skelne mellem dem gennem informationen, som UI leverer i forskellige faser, selv før transaktionen startes.

2.1 - Værdioverførsler
 - 2.1.1 - ETH
 - 2.1.2 - Tokens
 2.2 - Funktionsopkald
 - 2.2.1 - Kontraktsmetoder med værdi-implikationer
 - 2.2.2 - Kontraktsmetoder uden værdioverførsler
 2.3 - Fabrikker: kontraktgenererende funktioner

Transaktionsdata og omkostninger

Transaktioner har normalt en "nyttelast", nogle data vedhæftes, for eksempel overført til kontraktmetoderne, og som normalt bruges til at skrive eller beregne, hvad de skal skrive i Blockchain.

Desuden har skrivning af data til Blockchain normalt en omkostning, et "gasgebyr" til at betale for transaktionen.
Brugeren skal forstå disse to informationer og gøres opmærksom på deres indhold.

Principper

Dapp-frontenden skal:

➤ (Permanence) klarlægge handlinger, der er irreversible (alle skriver Tx'er)

➤ (Værdi) klarlægge handlinger, der involverer penge eller værdi

➤ (Privatliv) klarlægger handlinger, der potentielt kan føre til brugeridentifikation
Dette er et af de sværeste principper at implementere, da potentielt alle skrivedata kan hjælpe med at identificere brugeren (indtil ZTKSnarks), og som smart-kontrakt- og web3-udviklere kan vi ikke være opmærksomme på den nuværende og fremtidige sofistikering af kriminaltekniske værktøjer, som også er normalt lukkede kildeløsninger. Bare tag hensyn til dette princip, hvis privatlivets fred er en hovedfunktion i din Dapp, og brug det til at guide designvalgene for, hvornår du skal klarlægge, hvilke handlinger der er potentielle risici for dit privatliv, der søger brugere.

➤ (Fabrik) klarlægger handlinger, der genererer nye kontrakter i brugernavnet
Dette princip skal kun anvendes på Dapps, der hjælper brugeren med at oprette kontrakter med deres adresse som oprettelsen af ​​meddelelsen. Anvend dette især, hvis det er på MainNet.

Retningslinjer for alle transaktioner:

➤ afklare og bekræfte på forhånd den nye fremtidige stat
➤ viser de data, der bruges til en transaktion i et menneskeligt læsbart format, og på den måde, hvor Smart Contract kræver det (∞link 5. Transparency of Code)
➤ klarlægge de foreslåede værdier for gasprisen, og hvordan man overskriver Tx (∞link 9.Gas Price and Transaction Reversals)
➤ administrer ventetid for transaktion (∞link> 6.Time / Wait Management)
➤ Når transaktionen er registreret, viser en relevant oversigt over transaktionen til brugeren, og hvordan hun kan få adgang til historikken (∞link 4. Brugerinteraktionshistorik)
➤ Afklar muligvis, hvilke handlinger der IKKE er transaktioner og dermed sikre

Hvordan> eksempler

  • Brug css til at indikere alle irreversible handlinger
    brug måske en advarsel / fremhæv farve som rød
  • tilføj en lille skriftlig advarsel sammen med knappen
    dvs. opmærksomhed irreversibel handling forude> lære mere
  • Brug dobbelt bekræftelse:
    åbne en pop-up eller toast, når brugeren har trykket på knappen og inden han ringer til tegnebogen / MetaMask, hvor du kan informere brugeren om alle implikationerne og bede om en bekræftelse.
    Tilby også brugeren at:
     - Annuller handlingen
     - Vis aldrig disse pop-ups igen (fordi hun er en ekspertbruger), og når du gør det, fortæl brugeren, at hun til sidst kan genaktivere funktionen i Chain-View-sidepanelet.
  • afklare og forudse fremtidige forventede trin
    enten med bittesmå skriftlige beskrivelser, label undertekster eller med guider som strømme, der har flere trin til at udføre en handling.
    I tilfælde af troldmænd:
     - Vis brugeren tydeligt nummeret og titlen på de næste trin
     - lad brugeren inspicere de fremtidige skærme for at forstå, hvad der foregår, og hvad der sker, (∞link 8.Newbie-tilstand), selvom du også skal grå funktionaliteten for ikke at forveksle det faktum, at hun kan have en sneak peak forhåndsvisning med den faktiske handling.
  • Føj indstillinger til Chainpanel-sidepanelet
    Sidepanelet kan være stedet for mange af disse advarsler samt tilbyde en inspektør til transaktionerne, definerer
     - typen af ​​transaktion
     - de data, der er knyttet til transaktionen
     - gasomkostningerne
     - alle andre relevante oplysninger (∞link 5. Kodens gennemsigtighed)

tilbage til cheatsheet

3 - (Pushed Data) Gennemsigtighed af smarte kontraktarrangementer

Begivenheder er underretningerne om Web3-æraen

(Ethereum) Smart-kontrakter kan udsende begivenheder, der bruges til både at gemme logfiler i Blockchain og til reaktivt at informere Dapps-frontend via Javascript om, at der er sket noget.

Det er vigtigt at forstå, at begivenheder
 - kan have parametre, oplysninger tilføjet til logfilerne
 - opbevares permanent i Blockchain og kan derfor søges efter
 
Begivenheder bruges normalt af udviklere til forskellige ting, såsom signalering, når en bestemt betingelse er opfyldt, eller når en bestemt handling er sket: en ny bruger er blevet en tokenholder, der er foretaget et indskud, eller der er modtaget en data fra en Oracle, og mange flere.

Det faktum, at begivenheder kan søges, er yderst nyttigt til at logge adfærd for en bestemt Dapp og forstå, hvad der skete, og hvornår, på tværs af de tusinder eller millioner af blokke siden Dapp-oprettelsen.

For bedre at forstå, hvorfor dette er så vigtigt, lad mig hurtigt fortælle dig en personlig historie:
Da Dao blev hacket i 2016, havde jeg chancen for at samarbejde med gruppen, der løste en del af det store problem: At forstå, hvem der skyldte, hvor meget Ether fra ExtraBalance-kontoen.
Når brugere købte Dao Tokens i løbet af ICO, i henhold til gebyrplanen, ville forskellige mængder ether gå ind i ExtraBalance.
To af gruppens problemløsere, Nick Johnson og Bokky Poobah, brugte "CreatedToken" -begivenheden til at spore alle transaktioner relateret til DAO ICO, mens jeg gik den "hårde rute" og forestilte mig en situation, hvor begivenheder ikke var blevet implementeret, og udviklet en deterministisk parser til Blockchain, et retsmedicinsk værktøj meget nyttigt i tilfælde af ondsindede eller dårligt planlagte smartkontrakter. Jeg gjorde det også, fordi der ikke var en begivenhed som "ReceiveByExtraBalance" til at præcisere den del af transaktionen.
Her bliver det interessant: mens deres manuskripter ville tage et par timer, ville mine tage ca. en dag eller mere; det skyldes, at jeg var nødt til at gennemgå (genudføre) hver eneste transaktion i Blockchain, mens de allerede havde adgang til (næsten) “rigtige” transaktioner takket være hændelseslogfilerne.
Alligevel tog det os tre ca. to måneder at forene tallene og returnere hele saldoen til de oprindelige ejere.

Hvad har dette at gøre med Web3 Design Principles?
Begivenheder bruges af udviklerne vilkårligt: ​​de kan vælge at placere eller ikke en begivenhed for at signalere noget vigtigt om deres Dapp. At give adgang til den forreste bruger til begivenhederne i den smarte kontrakt er at være gennemsigtig om disse valg.

En høj grad af nyttige begivenheder kan være et tegn på en gennemsigtig Smart Contract og Dapp, en der ikke er bange for at fortælle dig, hvad den gør internt. Mens små eller ingen begivenheder kan være et tegn på en sjusket eller endda ondsindet smart kontrakt.

Som i ovenstående DAO-historie, ville manglen på begivenheder tvinge en bruger til at udvikle deres egne deterministiske Blockchain-parsere til at forstå, hvad der sker indeni, en praktisk umulig opgave, også fordi hun ville have brug for en arkivknude.

Derudover er begivenheder nyttige for udviklere til at oprette flere typer analyser, underretninger og reaktive datakilder, selv uafhængigt af ejeren / skaberen af ​​den smarte kontrakt. Denne strøm bør muligvis gøres tilgængelig for front-end-brugeren uden at skulle kode.
 
Web3-postulater:

- det er ikke gennemsigtighed, hvis det kræver en enorm indsats for at finde, se og verificere dataene
 - Det er ikke gennemsigtighed, hvis 99% af brugerne afskrækkes fra at ønske at se [2]

Principper

en Dapp-frontend skal:

➤ klarlægge og gøre tilgængelig for slutbrugeren alle begivenheder, selvom de kun er beregnet til udviklerformål

➤ anvende relevans: Vis afbrydende meddelelser kun for information, der er relevant for den aktuelle bruger, men lad brugeren stadig inspicere alle begivenheder i en separat grænseflade

➤ giver brugeren mulighed for at abonnere på, afmelde eller midlertidigt slå af hændelser

Begivenheder er kontraktspecifikke, så dette er enkle forslag til mulige implementeringer.
Derudover løses disse ideer bedre med et eksternt værktøj, service, et plugin eller bibliotek, som ikke kræver, at Dapp front-end-udviklere implementerer alle disse "ikke-kernefunktioner" i deres Dapp.

Hvordan> eksempler

  • har et underretningscenter tilgængeligt for brugeren, dette er sandsynligvis et afsnit i “Chain-View” sidepanelet
  • brug skål til vigtige meddelelser
  • oprette filtre for kun at vælge / fravælge bestemte begivenheder eller tilpasse underretninger kun baseret på bestemte parametre.
     Nogle filtre kan være:
     - hvis det indeholder Ether / tokens
     - baseret på adresse (mine / brugerens eller en anden adresse eller adresser)
     - mellem timeX og timeY, blockX og blockY
    etc.

tilbage til cheatsheet

4 - (Historik) Tilgængelig og gennemsigtig Brugerinteraktion Historik

I en fremtid, hvor vi interagerer med hundreder eller tusinder af Dapps, tokens og sandsynligvis kæder, er det fornuftigt for brugeren at have en klar historie logget af hendes interaktioner med hver enkelt til fremtidig reference.
 
Tegnebøger gemmer allerede historikken for alle transaktioner, hvilket er en start, men det er kun for en konto ad gangen, og det kan derfor være svært at finde ud af, om du interagerede på tværs af flere af dem.
Desuden ville tegnebøger stadig være hårde, medmindre yderligere funktioner er bygget, for kun at filtrere dem, der hører til en bestemt Dapp.

Det er bestemt brugervenligt for en Dapp at hjælpe dig med at huske enhver interaktion, du har gjort med det, ligesom du kan gå tilbage til "købshistorik" i enhver normal app.

Det er endnu vigtigere for Distribuerede udvekslinger og Dapps, der kan generere hundreder eller tusinder af transaktioner for hver bruger.

Principper

En Dapp-frontend skal:

➤ giver en oversigt over alle transaktioner fra en given adresse
Tillad brugeren at inspicere alle interaktioner, der nogensinde er foretaget med den smarte kontrakt, sandsynligvis hovedsageligt dem af type 2, der skriver til Blockchain og derfor ændrer staten

➤ præciser, hvor historien er gemt
At give en historie i forhold til en given bruger betyder sandsynligvis at optage hendes Transaction Hashes på en DB, enten på en ekstern server eller bedre i brugerens lokale indeksDB. Dette er naturligvis en potentiel privatlivsrisiko, så vær opmærksom på principperne om beskyttelse af personlige oplysninger (∞link 2. Transparance of Transactions) og kodetransparensprincipper (∞link 5.Transparency of Code) for at afklare for brugeren, hvor disse data er gemt.

➤ give værktøjer til at navigere, søge, eksportere og slette historikcachen

Hvordan> eksempler

  • ligner hændelsesmeddelelsescentret, har en fane Brugerhistorik eller dedikeret side, sandsynligvis inde i Chain-View-sidepanelet
  • tillade at filtrere for forskellige typer transaktioner (value-eth, value-tokens, funktionsopkald, kontraktgenerering, hvis relevant)
  • lad filtrere efter dato, fra begyndelsen eller mellem datoer
  • valgfri brugervenlig tilføjelse: giver brugerne mulighed for at tilføje et ikke-kædenotafelt til transaktionen, f.eks. en simpel påmindelse, hvis de blot ønsker at have en menneskelig læselig og søgbar ren tekst
  • valgfrit: har et søgefelt, hvis der er hundredvis af interaktioner, og hvis det er relevant for din Dapp
    dvs. decentrale udvekslinger ønsker måske at tilføje en sådan funktion, så brugeren kan søge efter transaktioner, der kun vedrører specifikke tokens
  • eksport: giver brugeren mulighed for eventuelt at eksportere dataene i csv og udforske dem på andre måder, igen, især passende i tilfælde af store datasæt
  • slet: lad brugeren slette historikken fra den lokale cache, men selvfølgelig tydeliggør, at den virkelige historie med transaktioner hverken slettes fra deres tegnebog eller fra Blockchain
  • import: det giver mening at tilføje en importindstilling kun, hvis Dapp giver brugeren mulighed for at tilføje brugerdefinerede noter til hver transaktion, ellers kan informationen simpelthen rekonstrueres fra Blockchain

tilbage til cheatsheet

5 - (kode og miljø) gennemsigtighed af kode

Hvis du kan stole på en Dapp, betyder det også, at koden, der udføres, kan være tillid.
For at være tillid skal Dapps være så gennemsigtige som muligt om alle aspekter af deres kode.

Web3-postulater

- for at en Dapp kan stole på, er det nødvendigt at stole på den
 - for at kode skal være lidt betroet, skal den være gennemsigtig, uafhængigt eksekverbar og verificerbar

Principper

en Dapp-frontend skal:

➤ Afklar hvilken Blockchain der bruges
det virker indlysende, men i et scenarie med spredning af Dapps kan mange være Blockchain agnostiske eller køre forskellige versioner på forskellige kæder. Også med Plasma, Polkadot, Cosmos og andre skaleringsløsninger er det muligt, at en Dapp muligvis sporer transaktioner i dets egen underkæde indlejret dybt nede i et træ af andre Plasmakæder eller andre faldskærme eller Cosmos Zones eller Hubs. Brugeren skal gøres opmærksom på, hvor deres data skrives, og derfor være opmærksom på de tekniske variabler (sikkerhed, hastighed osv.), Og hvor han uafhængigt kan verificere dataene.

➤ Afklar adressen på den / de smarte kontrakt (er), der bruges til læse- og skrivehandlinger
og link til uafhængige Blockchain-opdagelsesrejsende (Tlink 1.Transparency of Data Provenance).

➤ Afklar, hvilken kode der er open source, og hvor man finder den.

➤ Afklar, hvor koden køres (lokal vs fjernserver)
Dette er muligvis en af ​​de mest vanskelige og besværlige at implementere på et visuelt niveau, men hvis dele har brug for at køre på en server, har mindst en side, der forklarer, hvilke dele og hvorfor og peger på det fra enhver relevant del af UI.
Hvis “chain-view” -tilstanden, der ses i eksemplerne på de første principper (∞link 1.Transparency of Data Provenance), er implementeret, ville det være et godt sted, hvor man kan tilføje disse andre visninger.
 
➤ Afklar web3-udbyderen / Blockchain-noden (lokal knudepunkt, Dapp-kontrolleret knude, Infura, MetaMask ?, eller anden knude)
Hvorfor? Fordi instrumenterede noder kan registrere data, f.eks. Etherscan, og potentielt kunne være en kilde til privatlivets risiko for brugeren.
 
- Lad brugerne om muligt skifte til deres egen knude, hvis det er muligt eller relevant
Selvom dette allerede er taget pleje af udbydere som MetaMask, gælder dette princip, hvis din web3 Dapp af en eller anden grund udsender transaktioner til specifikke noder. Transaktioner, der gennemgår din egen private knude, kan også være hurtigere at udføre, fordi de undgår de potentielle køer af offentlige knudepunkter, især under begivenheder med stor efterspørgsel som skarer.

➤ Afklar, hvis Dapp kører på MainNet eller på TestNet
Selvom web3-udbyderen tager sig af dette, skal du især sikre dig, at brugeren forstår, at der køres handlinger på MainNet, hvis det er tilfældet (benyt også de andre principper i ∞link 2. Transparance of Transactions)

➤ Afklar hvilke data, der læses fra kæden, kommer fra Oracle eller er blevet påvirket af orakler

Brugervenlige tilføjelser
➤ Tillad udførelse af DIY-kode
give flere avancerede brugere mulighed for at se transaktionsfunktionsopkaldet, før det sendes, så de kan verificere det og gengive handlingen af ​​sig selv via kommandolinjen.
Dette kan virke som en overdrivelse, fordi Dapp front-end er der for at forenkle brugeren og skjule visse tekniske forhold, men en skeptisk / paranoid bruger vil gerne verificere endda enkelttransaktioner: Hvis Blockchain er som en distribueret database, skal en bruger være i stand til at udføre skrivehandlingerne uafhængigt, og Dapp skal stadig arbejde.
I en radikal gennemsigtighedsholdning til koden signaliserer en Dapp, der tillader denne funktion, “Don’t Trust. Bekræft ”https://blog.wizsec.jp/2018/02/kleiman-v-craig-wright-bitcoins.html?m=1

En forbedret version af dataprovencen, hvor brugerne også kan kopiere indsætte koden for at hente dataene selv

➤ Afklar de input, der kræves af Smart Contract:
Smarte kontrakter kræver ofte store tal med mange nuller, som er uvenlige for brugeren, især fordi det er meget let at lave dyre fejl. Det er normalt og tilrådeligt, at Dapp UI forenkler denne proces for brugeren, hvilket tillader mindre tal i et mere forståeligt og mindre fejlagtigt interval, som 0 til 100. I lyset af den tidligere gennemsigtighed af kodeprincipper bør det dog gøres klart for brugeren, hvor disse input forenkles af UI og tydeliggør, især i DIY-kodeinspektøren, det faktiske input, som smartkontrakten forventer.
En reel sag, hvor dette var forvirrende, blev rejst i en diskussion med Jorge Izquierdo om appen Aragon Voting. Udviklere kan bruge den samme løsning, der blev præsenteret for den sag, og afklare for brugeren nogle eksempler med: det enkle nummer, den videnskabelige notation og det faktiske input (med alle nuller), som Smart Contract forventer.

detaljer om eksemplet fra Aragon wiki

Hvordan> eksempler

  • har en side med "kodegennemsigtighed", der altid er tilgængelig som siderne Servicevilkår eller Privatlivspolitik
  • link til dine github-repos flere steder
  • tilføj til "chain-view" -panelet (vist i eksemplerne i kapitel 1. Transparency of Data Provenance) et afsnit dedikeret til kodetransparens med
    ○ oplysninger om:
     - Blockchain i brug
     - egenskaberne for sådan Blockchain, især den gennemsnitlige blokbekræftelsestid (∞link 6.Time / Wait Management)
     - visne det er MainNet eller TestNet
     - web3-udbyderen, der er i brug (muliggør omskiftning)
     - kontraktens adresser
     - muligvis en forenklet version af kontraktens ABI med bare de metoder, der faktisk kaldes af koden
     - hvis der er nogen del af koden, der køres ikke lokalt (tekstlig forklaring og motivation)
     - linket til github-repos
    ○ skifter, filtre eller indstillinger til:
     - vis med ikoner og / eller ved at ændre farver, hvilke dele / komponenter der har data, der behandles på en server
     - vis med (“sky-til-kæde” -Orakel) linkikoner og / eller ved at ændre farver, hvilke data kommer fra orakler
     - skift web3-udbyder, hvis relevant
     - en forhåndsvisning af transaktioner, der kaldes med funktionsopkald, der kunne kopieres og udføres på kommandolinjen
     med bemærkninger om input, hvis relevant.
et eksempel på panelets gennemsigtighedskode og information

tilbage til cheatsheet

Generelle Web3 UX-principper

De følgende principper vedrører ikke mere direkte gennemsigtighed og tillidsløse egenskaber og sigter snarere mod at løse et sæt andre UX-problemer, der opstår som følge af den generelle brug og implementering af Distribuerede applikationer baseret på Blockchain.

6 - Time / Wait Management

Indtil skalerbarhedsproblemerne er løst, er transaktioner asynkrone, og i henhold til den underliggende Blockchain og den aktuelle netværksstopning kan det tage lang tid at behandle og blive fuldt bekræftet.

En veludviklet Dapp er nødt til at afklare disse informationer og styre brugerens ventetid, indtil hendes handling er bekræftet.

Principper

en Dapp-frontend skal:

➤ (Administrer brugerens forventning) Afklar ved hver transaktion den gennemsnitlige blokbekræftelsestid for den underliggende Blockchain og den aktuelle netværksstopning

➤ (Administrer ventetiden) Vis livlighedsindikatorer i ventetiden

Hvordan> Eksempler

Som en række UX-begivenheder skal en Dapp

  1. forklare, hvordan gasvalg vil påvirke deres ventetid (∞link.9 Gaspriser og TX's Reversal)
  2. Vis advarsel om kædespecifikke tidspunkter
  3. Vis et fremskridts- eller venteikon, indtil det ikke er løst
  4. Hvis ting tager længere tid end normalt, skal du vise en feedback og potentielle årsager og / eller løsninger
    dvs.: ”det tager længere tid end forventet. Netværket er i øjeblikket overbelastet.
     Her er dine muligheder:
     -> Vent X sekunder / minutter mere
     -> tilføj mere gas for at fremskynde transaktionen
     -> blive underrettet, når du er færdig
  5. Underret, at du under alle omstændigheder vil underrette brugeren om den vellykkede udførelse
  6. Når operationen er udført, skal du informere om den vellykkede udførelse med en rapport om dataene (dvs. Transaction Hash), som de uafhængigt kan bekræfte

tilbage til cheatsheet

7 - Human Readable Hashes-format

Indtil navneregistreringer er bredt vedtaget, og selv da er vi nødt til at tackle vanskelighederne med lange adresser og transaktionshashes.
Dette er bare nogle ideer til, hvordan man gør dem mere menneskelige læsbare, samtidig med at man opretholder gennemsigtigheden i den fulde information.

Principper

Dapps front-end skal:

Midlertidig opdatering 2018–07–11 Der er i øjeblikket en debat om sikkerheden ved nogle af disse principper. Kom tilbage om et par dage for en bedre og mere sikker version

➤ viser en kompakt version af hasherne, men viser altid start- og slutdele
dvs. 0xABCD… EFGH
pas dog på, at dette kan indeholde sikkerhedsproblemer, fordi forfængelige adressegeneratorer kan producere sekvenser på 8 tegn i ≈1 uge,

➤ Hvis du behøver en endnu kortere udgave, ̵ foretrækker begyndelsen til slutningen ̵
̵ ̵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̵ (dette har sikkerhedsmæssige implikationer som bemærket af Tom Nash her)> ændret som følger:

➤ Hvis du har brug for en endnu kortere version, foretrækker du slutningen til begyndelsen
 dvs. brug 0x ... EFGH snarere end 0xABCD ...
(selvom det er mere læseligt og bedre udseende at have de første 4 tegn, sammenlignet med 0x ... EFGH, er der et sikkerhedsproblem, fordi de første 4 karakterer er mere enkle at brute-force og generere som tilfældet med forfængelighed URL'er, men Det er astronomisk vanskeligt at generere det nøjagtige match for de sidste 4 tegn)

➤ Foretrækker at bruge bunker på 4 bogstaver frem for 3 bogstaver for hver del
dvs. brug 0xABCD ... snarere end 0xABC ...

➤ Afhæng altid “0x” for at indikere, at det er en hash

➤ giver mulighed for en valgfri visning, hvor hele adressen er synlig

➤ giver brugerne mulighed for let at kopiere adressen

Brug, hvor det er muligt, korthår som titler og de forkortede adresser som undertekster

➤ create Opret om muligt et system, der gør det muligt for brugeren let at knytte et brugerdefineret menneskeligt læseligt navn eller tekst til adresserne
disse noter skal gemmes lokalt på brugerens lokale computer ikke på en server (ty til ∞link 5. Transparens i kodeprincipper)
Hvis det eksisterer, skal du henvende dig til en kendt alias db som ENS-registreringsdatabasen eller Etherscan for kendte kontrakter og adresser.

tilbage til cheatsheet

8 - Permanent begyndertilstand

Hvis vi ønsker masseoptagelse af distribuerede applikationer, betyder det, at vi er nødt til at give masser af mennesker uden nogen teknisk viden eller forståelse af Blockchain og dens lingo mulighed for at komme ind i rummet.
 
Dette er mere end andre rum, der kræver lidt uddannelse, både af sikkerhedsmæssige årsager (håndtering af private nøgler), men også for fuldt ud at forstå, hvorfor egenskaberne ved Blockchain er et så revolutionerende fænomen, og hvordan Dapps adskiller sig fra andre apps.

Også vigtigt er det faktum, at dette rum er så vidunderligt facetteret, at det ofte kræver nye mentale modeller og en tværfaglig forståelse: Internettet af værdi skaber tusinder af tokeniserede økosystemer påvirket af markedsdynamik, som normalt studeres i økonomi, finans og spilteori; Det er meget usandsynligt, at masserne vil være bevandrede eller nogensinde har haft eksponering for disse discipliner.
Derfor bør distribuerede applikationer gøre en indsats for at uddanne en ny og etableret bruger til alle aspekter af deres arbejde.

De fleste af de tidligere principper har en newbie-bruger i tankerne, men der er et par flere ting, som udviklere bør overveje.

Principper

En Dapp-frontend skal:

➤ Vævet i pædagogisk information med den normale interaktion
Den vigtigste opgave for Dapp Designer er udmærket opsummeret af Nick Neuman: ”En god slutbrugerapplikation vil bage uddannelse i produktoplevelsen. Det betyder, at man forklarer på en kort og interessant måde, hvorfor en bruger gør noget, mens hun gør det, og bygger produktet, så det er meget svært for brugeren at gøre noget usikkert. ”

➤ ide Giv 2 eller flere niveauer af uddannelsesindhold: Grundlæggende om Blockchain og Dapp-specifik lingo
Dette er ikke et princip bare for vores tid, hvor nybegynder kommer om bord, det ville være en god praksis for alle apps, især dem, der har en intern eller kontekstuel lingo eller en unik mekanisme, til at tilføje et andet uddannelseslag: dvs. Hvis du bygger en token-fondsadministrator, skal du ikke antage, at dine brugere ved finansiering, og hvad hver sigt betyder; i stedet uddanne dem begge til det grundlæggende i Blockchain og det grundlæggende om finansiering, i det mindste for at forstå de ord, du bruger.

➤ Minimer og øg gradvist mængden af ​​nye ting og koncepter, som brugeren har brug for at lære
På trods af de tokeniserede incitamenter til vedtagelse vil Blockchain-projekter stadig være nødt til at møde den normale friktion og churn, som enhver softwaretjeneste oplever: brugere vil vælge enklere alternativer, især hvis en Dapp spørger for meget af dem. Derfor skal Dapps, når de leverer deres pædagogiske indhold til nye, forsøge at minimere brugen af ​​nye ord og koncepter, især på siderne for den generiske offentlighed (dvs. hjemmesiden) og gradvist vise flere indlæringer på sider for engagerede brugere (dvs. bruger betjeningspaneler). Dette kan også opnås ved at bruge enklere sprog, undgå lingo og bruge analogier til at forklare komplekse nye oplysninger med viden, som brugeren muligvis allerede er bekendt med. Se som et eksempel, hvordan Spankchain oprettede begrebet et kort for at undgå at skulle forklare betalingskanaler.

➤ acceler Fremskynd læring, hvis det er muligt eller relevant, ved at give "ekspertens fortolkning"
Afmystificer betydningen af ​​dine Dapps-funktioner, hvordan de interagerer, og hvordan en ekspert vil tænke over effekterne.
Hvad ville en ekspert vide om en bestemt ting? Hvordan ville de fortolke dataene? Hvordan ville de handle efter det? Hvilke valg ville de tage?
Svarene på disse spørgsmål kan væves ind som forslag i Dapp UI, hvis de er relevante.
Eksempler går fra at forudse en god gasprissætning (∞link 9.Gaspriser) til at indikere, at det er et godt eller dårligt øjeblik at udveksle et bestemt token (bare et eksempel).

➤ Tab ikke sammenhæng
prøv at væve tekstuddragene i grænsefladen med midlertidige pop-ups, der let kan afskediges, som derefter kan åbne mere detaljerede oplysninger i en anden fane. Tillad brugeren at lære hurtigt og "på plads", når du lærer, uden at skifte side og miste oversigt over, hvad de gør, hvor de gør.

Hvordan> eksempler

  • tilføj små undertekster til kommandoer overalt (og henvis til andre principper for at forudse, hvad transaktioner vil gøre ∞link 2. Transparency of Transactions)
  • indstilling af læringstilstand
    tilføj til "chain-view" eller andre dele af UI, en switch (en "universal spørgsmålstegn" -knap), der kan tændes og slukkes og aktiverer eller deaktiverer læringsfunktioner
  • Ordliste pop-up
    Når du bruger lingo, der er tilgængeligt i en ordbog, skal du vise et link-ikon, et ikon efter ordet, der, hvis der klikkes eller rulles over, viser en kontekstuel pop-up med de specificerede oplysninger
    I nogle tilfælde bør pop-up-en også give mulighed for at "vide mere", som åbner en anden fane eller en sidebjælke i "chain-view", der åbnes i fanen med ordliste.
  • Ordliste side
    i kædesynet eller på en anden side helt skal Dapp give en side med alle udtryk, Blockchain og Dapp-specifikke, der bruges i selve Dapp'en, eller som er nødvendige for at forstå dens mekanik. Denne side skal omdirigeres fra pop-up-ordlisten og ikke kobles direkte.
  • i en hvilken som helst guide ville det være kyndigt at aktivere hurtig videresendelse til de næste trin, så du kan se, hvad der kommer, selvom alle deres layout skal gråtones og deaktiveres, indtil du har gennemført de foregående trin. Dette er et godt princip for enhver brugergrænseflade, ikke kun for Dapps.

tilbage til cheatsheet

9 - Gaspriser og tilbageførsler af transaktioner

Gas er en af ​​de mest forvirrende ting for nybegynderne. Selvom navnet fortæller, er det vanskeligt at forestille sig udgifterne til beregning af tjenester, som du altid har haft til grundlæggende gratis.
Hvad mere er, når brugere støder på gas for første gang, de ved ikke, hvordan de skal prissætte det, og derfor ikke hvad et godt valg for gasprisen ville være.

Selv hvis i dag i praktisk talt alle tilfælde håndteres gassen af ​​tegnebøger, der udsender transaktionen, er dette princip stadig gyldigt, både for tegnebogdesignere og for alle dem, der nogensinde vil kræve eller bede brugerne om at vælge en gaspris.

Heldigvis er der for udviklere værktøjer som Ethereum Tankstation, der tilbyder et praktisk API.

Principper

Dapps front-end skal:

➤ Afklar, hvad der er gas og gas-pris
(ligesom med enhver anden lingo ∞link 8.Newbie-tilstand)

➤ Foreslå et godt interval for gasprisen, og afklar tidstilnærmelser for de øvre og nedre grænser
dette er funktioner i netværkets nuværende overbelastning, så den optimale løsning ville være at forespørge den nuværende Ethereum Tankstation API https://ethgasstation.info/json/ethgasAPI.json for at foreslå disse intervalgrænser.
Det er vigtigt at præcisere for brugeren, at dette er et tidsbaseret forslag, og at de foreslåede værdier kunne ændres i fremtiden.
 
➤ viser muligvis gasværdier, der også er konverteret til FIAT

➤ Tillad transaktion reversering: i tilfælde af at brugeren har sendt en TX'er med lav gaspris, skal det gøres klart for brugeren
(∞ link til 6.Time / Wait Management)
- at tx'en ikke kan annulleres, når den er lanceret
- at den eneste løsning er at udsende en anden tx med samme nonce og en højere gaspris
> tilbyder derfor muligheden for automatisk at gendanne tx nonce og sende den med en højere gaspris.

tilbage til cheatsheet

DDP-decentraliseringsdesignprincipper

Decentralisering er en ny kraftfuld form for globalisering.
En, der for første gang potentielt ledes af masser af selv suverene individer, der samles sammen omkring grænseløse ideer, selvledende organisationer og distribuerede markedssystemer.

Disse designprincipper ønsker kun at få samtalen i gang i både at tænke på, hvordan man får brugeren til at føle sig del af et samfund og af noget mere ambitiøst større end dem selv.
De er bare et tip for udviklere til at begynde at tænke holistisk over funktionen af ​​deres Dapps og de nye UX-krav, der opstår, i den større sammenhæng med de distribuerede samfund, vi skaber.

10 - Sense of Community

Dapps er forskellige end apps, fordi de er indbygget fordelt: selvom nogle er tjenester, der er målrettet mod den enkelte, og hvis interaktion er en ensom oplevelse, er de stadig skabt til, og ofte af, en stor gruppe mennesker over hele verden.
 
Følelsen af ​​at tilhøre et samfund er vigtigere i disse Dapps, da brugerne bliver nødt til at binde sig til et decentraliseret brand og produkt.
Det betyder ikke, at man i Dapp bager et socialt netværk, selvom nogle muligvis drager fordel af en strammere integration med den communitychat, der er valgt af projektet.

Naturligvis er disse ideer temmelig vigtige for DAO'er.
 
Overvej følgende ligesom nogle generiske forslag inden for det mere løst fortolkelige mål om at få brugere til at føle sig en del af noget større end dem selv.

Principper

Dapps front-end skal:
 
➤ præciser, hvor mange andre medlemmer der er i samfundet
➤ klarlægge, hvem der er de andre medlemmer (vælg passende kategorier)
➤ klarlægge sammensætningen af ​​samfundet (dvs. undergrupper og deres magt over projektet)
➤ projektets større mission (hvis nogen) og hvordan deres deltagelse bidrager til dets gennemførelse

Hvordan> Eksempler

  • give et landingspanel med statistik om unikke tokenholdere eller antal medlemmer af en Dapp eller DAO
  • vedtage gennemsigtighedsprincippet og viser især al information, som brugerne selv kan udlede ved at analysere Blockchain:
     - token formuefordeling
     - tidsplaner for vedtagelse
     - tokenholder siden blok XX og åååå-mm-dd
     etc
  • i DAOs overveje at berige informationen med alt, hvad der kan være relevant (hvis tilgængeligt) som:
     - slags medlemmer (dvs. # opdrættere vs ikke-opdrættere i Crypto Kitties, eller # musikere og # lyttere i Musik / ART Dapps som UJO Musik, stakers vs ikke-stakers osv.)
     - udarbejdelse af distributionsstatistikker
     - måske geografiske placeringer / tidszoner ?,
     - måske sex, aldre? (men kun hvis det giver mening for dit samfund, og hvis det ikke er stødende eller skadeligt for vedtagelsen af ​​din Dapp)
  • Naturligvis søg efter de kategorier, der er passende og relevante for dit projekt: det er for eksempel min personlige mening, at i DAO'er er køn og aldre ikke relevant information, endda kontraproduktiv til tanken om at skabe tilladelsesløse og uvildige samfund, men måske er de meget relevant i projekter som SpankChain.
  • måske give brugerne mulighed for at vælge deres egne tags, kategorier, biobeskrivelse osv.: hvert medlem kan have forskellige identiteter i forskellige projekter. Dette antyder allerede andre principper om identiteter, der vil blive præsenteret i fremtiden.

tilbage til cheatsheet

11 - Andre fremtidige designprincipper

Som du måske har forstået, kræver det forrige princip nogle flere tanker omkring identiteter, omdømme og regeringsførelse. De første to er universelt nyttige i mange samfundsdrevne apps, men de vil være grundlæggende for Token Curated Registries (TCR) og sandsynligvis for mange DAO'er og andre kryptoprioriteter.

Disse principper fortjener deres egen analyse og plads, og dette indlæg er allerede for langt.
I fremtiden vil jeg analysere Web3 Design Principper for:
- Identiteter og omdømme
- Regeringsførelse
- Tegnebøger
- Udvekslinger
- ICO & token salgsmekanik
- Token Mechanics

Næste skridt

Det er tydeligt, at kravene til "ekstrem gennemsigtighed", der foreslås i disse Web3 Design-principper, skaber en ganske byrde for Dapp-udviklere, der i dag er mere fokuseret på at løse mange andre dele af deres projekter.
 
 - Bootstrap som bibliotek
Det er derfor åbenlyst, at der skulle være et standardværktøjssæt, som udviklere kunne tilslutte og spille i deres Dapps og måske interface deres opkald til web3-biblioteket og få gratis alle disse gennemsigtighedstjenester til deres brugere.
Jeg forestiller mig noget som et Bootstrap-lignende bibliotek til Web3-æraen ("Chainstrap"? Det er en smule for hård kerne, ikke?: P)

- Uafhængigt browser plugin
Måske er det endda tilrådeligt, at der skal være et uafhængigt værktøj, der giver brugerne fordelene ved Web3 Design Principles, som Dapp-skaberen ønsker eller ikke; en “gennemsigtighedshåndhæver” af slags, der kunne gøre det muligt at identificere ondsindede eller slurvede Dapps ved deres grad af overensstemmelse med nogle af principperne.
I dette tilfælde ville det sandsynligvis være passende at oprette et browser-plugin, der indsprøjter sin kode i Dapp og giver kædesynsfunktionaliteten og måske endda en hurtig certificering af graden af ​​gennemsigtighed og pålidelighed af Dapp.

- Tilpassede tjenester
Desuden er der i disse principper mange potentialer for tjenester, også kommercielle dem, der endnu ikke findes i dag.

Mange muligheder. Hvad synes du?

Hvis du er interesseret i at udvikle noget af ovenstående, hvis du bare har tanker og overvejelser,
eller hvis du er en organisation, der tilbyder tilskud, og mener, at den kan passe til dine nuværende mål,
Kontakt venligst b [at] likuidlabs.com eller på twitter @lyricalpolymath

Lad os designe og opbygge fremtiden for decentralisering sammen!

NOTER

[1] Andre “Blockchain” + designartikler

Ved at anvende designmetodologien undersøgte jeg, hvad der allerede var skabt til emnet: ikke meget.

  • Blockchain Design Principles - Design hos IBM
    Dette er langt den bedste artikel om emnet. Skrevet af Sarah Baker Mills, tidligere designleder hos IBM og i dag Design Director hos Consensys. Hun destillerer meget godt nogle af de principper, der vises i Web3 Design Principles, skønt under forskellige navne. Hun taler om dataeksponering, konsistens, feedback, foregribe fejl og aktiv vejledning.
  • Blockchain og design - Hacker Noon
     Et interview med Matt Storus, Lead Designer på 21.co, om udfordringerne og nogle ideer om, hvad designere skal gøre. Desværre tillader ikke interviewformatet at destillere mange læresætninger, men han er bestemt en interessant læsning.
  • Brugeroplevelsen af ​​Blockchain
    en generisk post for at uddanne designere om Blockchain og designudfordringerne.
  • Hvordan kan Design hjælpe Blockchain - The Spark
    et par makroideer om nogle ting designere i dette rum bør tænke på
  • Design til Blockchain: lancering af en ethereum Smart Contract-app
    En undersøgelsessag omkring design af en bedre oplevelse for en investeringsplatform med nogle ideer til at forbedre deltagelsen i ICO'er

[2] Jeg ved, at disse postulater er en fænomenologisk fejl, men jeg bruger dem alligevel, fordi de er en nyttig forenkling og gør pointen: til en ikke-teknisk bruger, som ikke er i stand til at verificere dataene på en nem måde, information er tydeligvis ikke gennemsigtig. Gennemsigtighed bliver derefter et skinnende mirage, en tro forventning om tillid.