Web3-suunnittelun periaatteet

Kehys Blockchain-pohjaisiin hajautettuihin sovelluksiin liittyviin UX-sääntöihin (osa 1)

Huomaa: Tämä viesti on melko pitkä> hyppää cheatsheet tai johtopäätöksiin

Blockchain-kehittäjät ajavat eteenpäin hajautettua tulevaisuutta koskevaa suurta näkemystä, mutta kokemuksemme siitä visiosta hajautettujen sovellusten (Dapps) kautta muistuttaa edelleen web2: n näppärää prototyyppiä.
 
On luultavasti sopivaa, että suurin osa käyttäjistä, jotka käyttävät näitä Dapp-tiedostoja, elävät edelleen web2: ssä eivätkä ole edes kuulleet hajautetun Web3: n lupauksista.
Vaikka heidän tulisi tulla näkemään nämä kiiltävät uudet sovellukset, heillä olisi vaikea ymmärtää näiden Dappien lingoa, tarkoitusta ja dynamiikkaa edes visuaalisesti kertoa heille tavallisten verkkosovellusten lisäksi.

On sanottava, että on olemassa paljon hyviä työkaluja (Drizzle, MetaMask), jotka ovat tulossa ja hyökkäävät joihinkin näistä aiheista. Me pääsemme sinne.

Nämä suunnitteluperiaatteet haluavat ehdottaa ideoita tämän korjaamiseksi ohjeineen, jotka auttavat suunnittelijoita ja kehittäjiä, jotta voimme kaikki tehdä siitä kiiltävästä tulevaisuudesta kaikkien tavoitettavissa ja lähempänä.

Web3-suunnittelu vs Blockchain-suunnittelu

Muut ihmiset ovat kirjoittaneet aiheesta “Blockchain Design” [1] esittäessään samalla ratkaisuja hajautettujen sovellusten (Dapps) etukäyttäjäkokemukseen.

Vaikka Consensysin pääsuunnittelija Sarah Millsin artikkeli on inspiroiva lukema ja hän on selvästi johtava suunnittelijoiden äänipuhelu Blockchain-tilassa, mielestäni sanamuoto “Blockchain Design” sopii paremmin ominaisuuksien ja niiden vuorovaikutusten määrittelemiseen. , itse Blockchain-konstruktiosta: muun muassa konsensusalgoritmi, toimituspohja, lohkohyödyt, täydentävyys, laskenta- / ”kaasukustannukset”, ketjunhallintamekanismit tai niiden ulkopuolella ja paljon muuta.
 
Tässä artikkelissa viittaan sen sijaan ”Web3-suunnitteluun”, jossa mainitaan pääasiassa periaatteet, joita tulisi noudattaa hajautettujen sovellusten käyttäjäkohtaisten osien luomisessa.

On houkuttelevaa käyttää sanassa ”Blockchain” otsikossa, mutta se olisi clickbait

Miksi Web 3 -suunnitteluperiaatteet

Nykyään käyttäjä voi olla vuorovaikutuksessa Blockchainiin sijoitetun älykkään sopimuksen kanssa monella tavalla: joko suoraan komentorivin kautta, digitaalisen lompakonsa tai Dapp-selaimen lomakemuotoisten rajapintojen kautta tai ehkä Smart Contract -kehittäjän rikkaamman käyttöliittymän kautta. on tai tulee kehittymään.
On selvää, että tie Dappien massalliseen käyttöönottoon kulkee viimeksi mainitun kautta: tarjoamalla rikas käyttöliittymä, joka yhdistää kokemukseen käsitellä Blockchain-pohjaista hajautettua sovellusta.

Nykyään kehittäjinä olemme vanhurskaasti erittäin kiireisiä rakentamalla Blockchain-infrastruktuuria ja projektiidemme älykkäitä sopimuksia, joten on selvää, että tällä hetkellä monilla Dapp-laitteilla ei ole käyttökelpoista käyttötapaa tai, jos heillä on sellainen, turvallista sisällölle, ne eroavat pääasiassa muista ympärillä olevista verkkosovelluksista.

Dapp-ohjelmat eroavat kuitenkin pohjimmiltaan tavanomaisista verkko- tai mobiilisovelluksista, koska ne perustuvat Blockchain-järjestelmän sallimiin vahvoihin periaatteisiin ja niiden pitäisi välittää ne voimakkaasti: hajauttaminen, läpinäkyvyys, epäluotettavuus, muuttumattomuus, luovuttamattomuus jne.
Nämä Blockchain-ominaisuudet ja etupuolen Dapp-elementtien heijastuksen ansiosta nämä suunnitteluperiaatteet koodaavat käyttökelpoisiksi työkaluiksi.

Tavoitteena on, että oikein sovellettuna Dappiin laskeutuva käyttäjä voi heti kertoa olevansa vuorovaikutuksessa yhden kanssa ja mikä tärkeintä, hänellä on pääsy Blockchainin voimakkaisiin ominaisuuksiin, ja siksi hän tietää, että hän voi luottaa jokaiseen vuorovaikutukseen sovelluksen kanssa.

Periaatteiden ymmärtämiseksi huomioon otettavat muuttujat

  • päätavoite on mielessä ei-tekninen käyttäjä, vaikka jotkut periaatteet on suunnattu myös tajuisemmille käyttäjille
  • kaikki Dappit eivät tarvitse kaikkia periaatteita
  • esimerkeissä esitetyt ratkaisut ovat vain joitain alkuideoita keskustelun aloittamiseksi
  • Jokainen Dapp-kehittäjä voi toteuttaa joitain periaatteita eri tavoin
  • Jotkut web3-periaatteet viittaavat ulkoisen työkalun, palvelun tai kirjaston tarpeeseen sen sijaan, että kuvitteleisi, että kukin kehittäjä toteuttaisi ratkaisunsa (lisää tästä seuraavissa vaiheissa)
  • eniten, elleivät kaikki web3: n suunnitteluperiaatteet hyötyisivät kodifioinnista Bootstrap-tapaiseen, kuten kehittäjäystävälliseen kirjastoon (lisää tästä seuraavissa vaiheissa)

Jos olet kiinnostunut tästä, siirry lopussa olevaan seuraavaan vaiheeseen -osaan nähdäksesi kuinka voimme toimia yhdessä.

Lähestymistapa suunnitteluun

Suunnittelu tarkoittaa myös ongelmien ennakointia ja ratkaisujen tarjoamista. Yritin tässä tapauksessa ”projisoida” (mielestäni parempi sana sen etymologiselle merkitykselle “eteenpäin vieminen” tulevaisuuteen) kysymyksiä, joita käyttäjällä voi olla vuorovaikutuksessa Dappin kanssa.

Kysymyksiä, kuten:

  • onko turvallista tehdä tämä (action_dapp_asks_me_to_do)?
  • onko rahaa vaarassa, jos huijaan?
  • Olen kuullut, että salauksen on tarkoitus olla yksityisempiä ... mitä tapahtuu lähetetylle tiedolle? missä se varastoidaan? Voinko tunnistaa?
  • kuka näkee syöttämäni tiedot? missä koodia ajetaan?
  • mitä tapahtuu sen jälkeen kun teen tämän (toiminta)?
  • Kuinka minun pitää tehdä (crypto_action_here)?
  • mitä tämä (outo_krypto_sana) tarkoittaa?
  • Väitetään, että lohkoketjuun voi luottaa, mutta miten voin kertoa, mihin tietoihin tämän sovelluksen luottamus voi luottaa?
  • mitkä tiedot tulevat Blockchainista?
  • Kuinka voin tarkistaa, että tiedot todella tallennetaan Blockchainiin?
    jne.

Suunnitteluperiaatteet tarjoavat kehittäjille työkaluja vastaamaan näihin ja useampiin käyttäjiä koskeviin kysymyksiin.

Web 3 -suunnitteluperiaatteet (hakemisto / cheatsheet)

Tämä viesti on melko pitkä, joten voit käyttää tätä cheatsheet saadaksesi nopean kuvan periaatteista ja siirtyäksesi niihin, joista olet kiinnostuneempi ymmärtämään

//// TTT: Luottamus läpinäkyvyyden suunnitteluperiaatteiden kautta

1 - (Lukeminen) Tietojen esiintymisen läpinäkyvyys

➤ Selvitä, mitkä tiedot tulevat Blockchainista ja mitkä eivät
➤ Selvitä sopimuksen (sopimusten) osoite
➤ Linkitä kaikki Blockchain-tiedot riippumattomiin Blockchain-tutkijoihin
➤ Selvitä, mitkä tiedot tulevat oraakkeista (∞link> 5.Koodin läpinäkyvyys)
 - Kuinka> esimerkkejä

2 - (Tietojen kirjoittaminen) Transaktioiden läpinäkyvyys

- Transaktiotyypit (arvonsiirrot, toimintopuhelut, sopimusten luominen)
➤ [Pysyvyys] selventää peruuttamattomia toimia
➤ [Arvo] selventää toimia, joihin liittyy rahaa tai arvoa
➤ [Tietosuoja] selventää toimia, jotka voivat johtaa käyttäjän tunnistamiseen
➤ [Tehdas] selventää toimia, jotka luovat uusia sopimuksia käyttäjän nimessä
- Kaikkien tapahtumien ohjeet:
- ➤ selkeytetään ja vahvistetaan etukäteen uusi tuleva valtio
 - ➤ näyttää liiketoimessa käytettävät tiedot ihmisluettavassa muodossa ja älykkäässä sopimuksessa edellytetyllä tavalla (∞ link 5.Transparency of code)
- ➤ selkiyttää kaasun hinnan ehdotetut arvot ja kuinka korvata Tx (∞link 9.Gas Price and Transaction Reversals)
 - ➤ hallitse tapahtuman odotusaikaa (∞link> 6.Time / Wait Management)
 - ➤ mahdollisesti selventää, mitkä toimet eivät ole tapahtumia ja siten turvallisia
 - Kuinka> esimerkkejä

3 - (Tietojen siirtäminen) Älykkäiden sopimustapahtumien läpinäkyvyys

➤ selventää ja antaa loppukäyttäjälle kaikkien tapahtumien saataville, vaikka ne olisivat vain kehittäjän tarkoituksia varten
➤ soveltaa relevanssia: näytä keskeyttävät viestit vain nykyisen käyttäjän kannalta merkityksellisistä tiedoista
➤ antaa käyttäjän tilata, tilata tai tilapäisesti mykistää tiettyjä tapahtumia
 - Kuinka esimerkkejä

4 - (Historia) Käyttäjän vuorovaikutushistorian läpinäkyvyys ja saatavuus

➤ antaa historian kaikista tietystä osoitteesta suoritetuista tapahtumista
➤ selvitä missä historia on tallennettu (paikallinen tai palvelin) (∞ link 5.Transparency of code)
➤ tarjoaa työkaluja navigointiin, hakuun, vientiin ja poistamiseen historiavälimuistissa
 - Kuinka> esimerkkejä

5 - (Code & Environment) Koodin läpinäkyvyys

➤ Selvitä, mitä Blockchainia käytetään
➤ Selvitä luku / kirjoitustoiminnoissa käytettyjen älykkäiden sopimusten osoite
➤ selvitä mikä koodi on avoimen lähdekoodin (ja mistä se löytyy)
➤ Selvitä, missä koodia ajetaan (paikallinen vs. etäpalvelin)
➤ Selvitä web3-palveluntarjoaja / Blockchain-solmu (paikallinen solmu, Dapp-ohjattu solmu, MetaMask, Infura jne.)
➤ selvitä, onko Dapp käynnissä MainNetissä tai TestNetissä
➤ selventää, mitkä tiedot tulevat oraakkeista tai mihin oraakkeihin on vaikuttanut (∞link> 1.Tietojen esiintymisen läpinäkyvyys)
salli DIY-koodin suorittaminen: anna edistyneiden käyttäjien nähdä käynnissä oleva koodi ja suorittaa se itse komentorivin kautta
➤ Selvitä älykkäiden sopimusten edellyttämät tulot
 - Kuinka> esimerkkejä

//// Yleiset Web3 UX -periaatteet

6 - Ajan / odotuksen hallinta

➤ (Hallitse käyttäjän odotuksia) selventää Blockchain-ajankohtaisia ​​aikoja ja hallitse käyttäjän odotuksia eri vaiheissa
➤ (Hallitse odotusaikaa) Näytä elävyysindikaattorit odotusajan aikana
 - Kuinka> esimerkkejä

7 - Ihmiselle luettavat hajautusmuodot

➤ näyttää tiivistetyt tiivistelmät, mutta näytä aina alku- ja loppuosat
➤ 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̵̵̵̵̵̵̵̵̵
Pend pend edeltää aina numeroa 0x osoittaaksesi, että kyseessä on hash
➤ antaa käyttäjille mahdollisuuden laajentaa koko osoitetta / tiivistettä
antaa käyttäjien kopioida sen helposti
➤ Jos mahdollista, käytä lyhenteitä nimikkeinä ja lyhennettyjä osoitteita tekstityksenä
➤ salli käyttäjän mahdollisuuksien mukaan helposti liittää räätälöity henkilökohtainen nimi tai teksti osoitteisiin ja hash-tiedostoihin
➤ Jos mahdollista, liitetään hash-muodon deterministinen visuaalinen esitysmuoto (ts. Identicons, blockies et al) osoitteen mukana

8 - Pysyvä aloittelija -tila

➤ kutistuvat opetustietoihin normaalin vuorovaikutuksen kanssa
➤ Tarjoa vähintään 2 koulutustasoa: Blockchain-perusteet ja Dapp-erityinen lingo
➤ minimoi ja lisää asteittain uusien asioiden ja käsitteiden määrää, jotka käyttäjän on opittava
➤ kiihdytä oppimista, mikäli mahdollista tai tarkoituksenmukaista tarjoamalla ”asiantuntijan tulkinta”
➤ eivät löysä konteksti
 - Kuinka> esimerkkejä

9 - kaasun hinta ja transaktioiden peruutukset

➤ selventää, mikä on kaasu ja kaasun hinta (kuten minkä tahansa muun lingo ∞link 8.Newbie-moodin kanssa)
ehdottaa kaasun hinta-alueita ja selventää aika-arvioita ylä- ja alarajoille
➤ Mahdollisesti näyttää kaasun arvot muunnettuna myös FIAT: ksi
➤ salli tapahtumien peruutukset

//// DDP: Hajauttamisen suunnitteluperiaatteet

10 - yhteisöllisyys

➤ Selvitä, kuinka monta muuta jäsentä yhteisössä on
➤ selvennä, ketkä ovat muita jäseniä (valitse sopivat luokat)
➤ Selvitä yhteisön kokoonpano (ts. Alaryhmät ja niiden vaikutusvalta hankkeessa)
➤ jakaa projektin suurempi tehtävä (jos sellainen on) ja kuinka käyttäjän osallistuminen edistää projektin saavuttamista
 - Kuinka> esimerkkejä

11 - Tutkittavan suunnittelun tulevaisuuden periaatteet (osa2)

➤ Identiteetit ja maine
➤ Hallinto
➤ Lompakot
➤ Vaihdot
➤ ICO & Token Sales Mechanics
➤ Tokenin mekaniikka

Seuraavat vaiheet

TTT: Luottamus läpinäkyvyyden suunnitteluperiaatteiden kautta

Web3-postimulaatit:

- Se ei ole avointa, jos et tiedä mistä ja miten etsiä
- Jos se ei ole läpinäkyvä, siihen ei voida luottaa!

Kaikki tämän tilan ja heidän äitinsä puhuvat siitä, kuinka Blockchain on ”luoton” ja “läpinäkyvä”.
Selittämään, miksi nämä kaksi olettamusta ovat vain osittain totta, vieisi pidempi viesti ja tekisi tämän virheellisestä.
Se on (melkein) varmasti totta ohjelmistotasolla, ohjelmisto tarkistaa tiedot, mutta nämä kaksi olettamusta hajoavat, kun kohtaat ne todelliseen loppukäyttäjäkokemukseen.

Sen lisäksi, että monet salausprojektit tai Dapp-käyttöliittymät näyttävät käyttäjälle harvoin Smart-Contract-osoitteet, joiden kanssa hän on vuorovaikutuksessa tai mistä tiedot tulevat, ei-teknisen käyttäjän on tällä hetkellä pelottavaa tai mahdotonta ymmärtää tietoja ja toimintaa riippumattomia Blockchain-tutkijoita, kuten Etherscan.
Ainoa asia, jota käyttäjä voi tänään osittain hallita, on kun lompakot välittävät tallentaa tapahtumahajasteen, joka voidaan tarkistaa edellä mainituilla Blockchain-tutkijoilla.

Siksi, jos käyttäjä, etenkin ei-tekninen, ei voi tunnistaa katsomalla käyttöliittymää, onko Dapp todella Dapp tai tavallinen verkkosovellus, hän ei voi myöskään tarkistaa, onko hänen näkemänsä sisältö vai vuorovaikutus sen kanssa liittyvät tosiasiallisesti lohkoketjuun, niin hänelle ei myönnetä sitä epäluotettavuutta ja läpinäkyvyyttä, jonka lohkoketjun on tarkoitus tuottaa.

Tämän luokan Web3-suunnittelun periaatteissa (TTT) ehdotetaan radikaalia avoimuutta, joka mahdollistaisi kaikkien Dapp-käyttöoikeuksien loppukäyttäjien, myös teknisten käyttäjien, olevan täysin tietoisia tietolähteistä, ymmärtävän liiketoimien vaikutukset ennen niiden toteuttamista, sen aikana ja sen jälkeen, ja viime kädessä voitava luottaa käsillä olevaan koodiin ja palveluun.

takaisin cheatsheet

1 - (Lukeminen) Tietojen esiintymisen läpinäkyvyys

Käyttäjän on voitava kertoa, mahdollisesti vain katsomalla sivua, että tietty datapiste tai sisältö on todella tallennettu Blockchain-verkkoon. Ei ole käyttäjäystävällistä antaa heidän arvata, ja ei riitä, että annetaan olettaa, että "kaikki" nähdyt tiedot tallennetaan Blockchainiin.
Tämä vaatimus voi kuulostaa hankalilta dataintensiivisiltä Dapps-yhtiöiltä, ​​kuten Työntekijät-vaihto, mutta on joitain ratkaisuja, jotka esitetään esimerkeissä.

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ Selvitä, mitkä tiedot tulevat Blockchainista ja mitkä eivät
➤ selvitä sopimuksen (sopimusten) osoite
linkittää kaikki Blockchain-tiedot riippumattomiin Blockchain-tutkijoihin
➤ Selvitä, mitkä tiedot tulevat oraakkeista (∞link> 5.Koodin läpinäkyvyys)

Kuinka> Esimerkkejä

  • käytä css-näppäintä värin / fontin / muodon muuttamiseksi erottaaksesi Blockchain-tiedot selvästi. Yritä selvästi olla johdonmukaisia ​​koko projektissa ja käyttää aina samaa “Blockchain-väriä”
Tiedonsiirto pois päältäData Provenance ON: värittää tietyn sopimuksen tulokset
  • käytä laajennettavia viitteitä:
    Kun hiiri tai napsautetaan Blockchain-datapistettä, voit antaa asiayhteyteen laajennetun työkaluvihjeen lisätietoja datapisteestä, jonka pitäisi tehdä selväksi missä Blockchain-kohdassa on, missä sopimuksissa tiedot löytyvät.
esimerkki kontekstuaalisesti laajennettavasta viitteestä
  • hallitse tyyliristiriitoja linkkikuvakkeilla
    Jos datapiste on sekä “Blockchain datapoint” että linkki johonkin dapp-pisteeseen, kaksinkertainen toiminta voidaan ratkaista kahdella tavalla:
    1- Lisää linkkikuvake, kuvake, joka seuraa mitä tahansa "Blockchain data-point" -kohtaa, joka antaa laajennettavan referenssitoiminnon, samalla kun linkki toimii normaalisti.
    2 - Avaa laajennettava viite ja aseta toissijainen linkki sen sisälle (mutta ota huomioon, että tämä aiheuttaa enemmän kitkaa, koska pyydät käyttäjää tekemään kaksi toimintoa yhden sijaan).
Esimerkki linkki-kuvakkeesta, joka avaa kontekstiviitteen. Tämä on tarkoitettu lisäämään chainView-toiminnot linkkiin, joka menee jonnekin Dapp-laitteeseesi
  • käytä “ketjunäkymä” -tilaa ja / tai sivupaneelia
    Tietointensiivisissä rajapinnoissa, kuten hajautetussa pörssissä tai aiempien ehdotusten mukaisissa markkina-näkymissä, tarkoitetaan todennäköisesti valtaosan rajapinnan muotoilemista, lisäämällä todennäköisesti enemmän sekaannusta. Tämän ratkaisemiseksi voit harkita “Ketju-näkymä” -painiketta, joka hiiren osoittaessa tai napsautettaessa muotoilee tietoja väliaikaisesti. Se on kuin suodattimen asettaminen sivulle, suodatin, joka auttaa käyttäjää näkemään, mitkä tiedot ovat Blockchain-datapiste.
     
    Laajentamalla tätä ajatusta, ”ketjunäkymä” voisi olla myös sivupaneeli, jossa voidaan ylläpitää monia Web3-suunnittelun periaatteissa kuvattuja toimintoja. Tässä tapauksessa Chain-View-paneelilla voisi olla edellä mainittu vaihtoehto kytkeä Blockchain-tietopisteiden näkyvyys päälle tai pois päältä. Seuraavissa esimerkeissä näemme vielä useita Ketju-näkymä-paneelin käyttötapoja.
Ketjunäkymän sivupaneeli, kun Data Provenance Option on avattu
  • Näytä selvästi, mitkä linkit avaavat ulkoisen Blockchain-tutkijan
    Jos linkki lähettää käyttäjän toiselle sivulle, on parempi hallita käyttäjän virtausta sivulla:
    1 - lisätään selkeyttävä painike, joka kertoo mitä tapahtuu: ts. “Avoin Etherscanissa”
    2 - mainosta linkkikuvake riippumattomille lohkotutkijoille ja käytä sitä johdonmukaisesti käyttöliittymässäsi

takaisin cheatsheet

2 - (Tietojen kirjoittaminen) Transaktioiden läpinäkyvyys

Käyttäjän on oltava tietoinen siitä, että tiedot kirjoitetaan lohkoketjuun, ja etenkin, kun se edellyttää taloudellisen arvon vaihtoa (salausvaluutat tai rahakkeet). Vaikka lompakot varoittavat käyttäjää tästä aikomuksesta, Dappin tulisi selvittää tämä ennen kuin se käynnistää transaktiopyynnön lompakkoon.

Transaktiotyypit

On olemassa erityyppisiä tapahtumia, joita voi tapahtua vuorovaikutuksessa Blockchainin kanssa, ja jokaisella on erilaiset vaikutukset.
Käyttäjän pitäisi voida erottaa toisistaan ​​käyttöliittymän tarjoamien tietojen avulla eri vaiheissa, jo ennen kaupan aloittamista.

2.1 - arvonsiirrot
 - 2.1.1 - ETH
 - 2.1.2 - rahakkeet
 2.2 - Toimintapuhelut
 - 2.2.1 - sopimusmenetelmät, joilla on vaikutuksia arvoon
 - 2.2.2 - sopimusmenetelmät ilman arvonsiirtoja
 2.3 - Tehtaat: sopimuksia tuottavat toiminnot

Tapahtumatiedot ja kustannukset

Tapahtumissa on yleensä ”hyötykuorma”, osa tiedoista on liitetty, esimerkiksi siirretty sopimusmenetelmiin, ja sitä käytetään yleensä kirjoittamaan tai laskemaan, mitä Blockchainissa kirjoitetaan.

Lisäksi tietojen kirjoittamisella Blockchain-palveluun on yleensä kustannus, ”kaasumaksu” maksaa tapahtuma.
Käyttäjän tulisi ymmärtää nämä kaksi informaatiota ja olla tietoinen niiden sisällöstä.

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ (Pysyvyys) selventää peruuttamattomia toimia (kaikki kirjoittavat tekstit)

➤ (arvo) selventää toimia, joihin liittyy rahaa tai arvoa

➤ (Yksityisyys) selventää toimia, jotka voivat johtaa käyttäjän tunnistamiseen
Tämä on yksi vaikeimmista toteuttamisperiaatteista, koska mahdollisesti mikä tahansa kirjoitustieto voi auttaa tunnistamaan käyttäjän (ZTKSnarksiin saakka), ja älykkäiden sopimusten ja web3-kehittäjinä voimme olla tietämättömiä rikosteknisten työkalujen nykyisestä ja tulevasta hienostuneisuudesta, jotka ovat myös yleensä suljetun lähdekoodin ratkaisut. Ota vain huomioon tämä periaate, jos yksityisyys on Dapp-laitteesi pääpiirteitä, ja käytä sitä opastamaan suunnitteluvaihtoehtojasi milloin selventää, mitkä toimet ovat potentiaalisia riskejä yksityisyyttä hakeville käyttäjille.

➤ (Tehdas) selventää toimia, jotka tuottavat uusia sopimuksia käyttäjän nimessä
Tätä periaatetta tulee soveltaa vain Dapp-sovelluksiin, jotka auttavat käyttäjää luomaan sopimuksia, joiden osoite on viestin luoja. Käytä tätä etenkin, jos se on MainNetissä.

Kaikkien tapahtumien ohjeet:

selventää ja vahvistaa etukäteen uusi tuleva valtio
➤ näytä tiedot, joita käytetään tapahtumaan ihmisluettavassa muodossa ja älykkäässä sopimuksessa vaaditulla tavalla (∞ link 5.Transparency of code)
➤ Selvitä kaasun hinnan ehdotetut arvot ja kuinka korvata Tx (∞link 9.Gas Price and Transaction Reversals)
➤ hallitse tapahtuman odotusaikaa (∞link> 6.Time / Wait Management)
➤ Kun tapahtuma on tallennettu, näytä käyttäjän kannalta merkityksellinen yhteenveto tapahtumasta ja siitä, miten hän voi käyttää historiaa (∞link 4.Käyttäjän vuorovaikutushistoria)
➤ Mahdollisesti selvennä, mitkä toimet eivät ole tapahtumia ja siten turvallisia

Miten> esimerkkejä

  • Käytä css-osoittaa kaikki peruuttamattomat toimet
    Ehkä käytä varoitus- / korostusväriä kuten punainen
  • lisää pieni kirjallinen varoitus painikkeen mukana
    eli huomion peruuttamaton toiminta eteenpäin> oppia lisää
  • käytä kaksinkertaista vahvistusta:
    avaa ponnahdusikkuna tai paahtoleipä käyttäjän painettaessa painiketta ja ennen kuin soitat lompakkoon / MetaMaskiin, jossa voit ilmoittaa käyttäjälle kaikista vaikutuksista ja pyytää vahvistusta.
    Tarjoa myös käyttäjälle:
     - peruuta toimenpide
     - Älä koskaan näytä näitä ponnahdusikkunoita uudestaan ​​(koska hän on asiantuntijakäyttäjä), ja kerro tätä tehdessään käyttäjälle, että hän voi lopulta aktivoida ominaisuuden uudelleen Ketju-näkymän sivupaneelissa.
  • selventää ja ennakoida tulevia odotettuja vaiheita
    joko pienillä kirjallisilla kuvauksilla, otsikkotekstillä tai ohjatulla tavalla, kuten vuoilla, joilla on enemmän vaiheita toiminnon suorittamiseksi.
    Velhojen tapauksessa:
     - näytä käyttäjän selkeästi seuraavien vaiheiden numero ja otsikko
     - Anna käyttäjän tarkastaa tulevat näytöt ymmärtääksesi mitä tapahtuu ja mitä tapahtuu (∞link 8.Newbie-tila), vaikka sinun tulisi myös harkita toiminnallisuus, jotta et voi sekoittaa sitä tosiasiaa, että hänellä voi olla hiippihuippu esikatselu todellisen toiminnan kanssa.
  • Lisää vaihtoehtoja Chain-View-sivupaneeliin
    Sivupaneeli voisi olla paikka monille näistä varoituksista sekä tarjota tarkastaja toimintoihin, määrittelevät
     - tapahtuman tyyppi
     - tapahtumaan liittyvät tiedot
     - kaasukustannukset
     - kaikki muut asiaankuuluvat tiedot (linkki 5.Koodin läpinäkyvyys)

takaisin cheatsheet

3 - (Tietojen siirtäminen) Älykkäiden sopimustapahtumien läpinäkyvyys

Tapahtumat ovat Web3-aikakauden ilmoituksia

(Ethereum) Älykkäät sopimukset voivat lähettää tapahtumia, joita käytetään sekä tallentamaan lokit Blockchainissa että ilmoittamaan Dappsin käyttöliittymiin Javascriptin välityksellä reaktiivisesti, että jotain on tapahtunut.

On tärkeää ymmärtää nämä tapahtumat
 - voi olla parametreja, tietoja lisätty lokiin
 - tallennetaan pysyvästi Blockchain-alueelle, joten niitä voidaan etsiä
 
Kehittäjät käyttävät tapahtumia yleensä erilaisiin asioihin, kuten signalointiin, kun tietty ehto on täytetty tai kun tietty toimenpide on tapahtunut: uudesta käyttäjästä on tullut kuvakkeen haltija, talletus on tehty tai tieto on vastaanotettu Oracle ja monet muut.

Se, että tapahtumia voidaan hakea, on erittäin hyödyllistä kirjata yhden tietyn Dappin käyttäytyminen ja ymmärtää, mitä tapahtui ja milloin tuhansien tai miljoonien lohkojen läpi Dapp-luomisen jälkeen.

Ymmärtääksesi paremmin, miksi tämä on niin tärkeää, anna minun kertoa sinulle nopeasti henkilökohtaisen tarinan:
Kun Dao hakkeroitiin vuonna 2016, minulla oli mahdollisuus tehdä yhteistyötä ryhmän kanssa ratkaistaksesi yksi osa suurta ongelmaa: ymmärtää kuka oli velkaa kuinka paljon eetteriä ExtraBalance-tililtä.
Kun käyttäjät ostivat Dao Tokenit ICO: n aikana, maksuaikataulun mukaan, eri määrät eetteriä menisivät ExtraBalance-arvoon.
Kaksi ryhmän ongelmanratkaisijaa, Nick Johnson ja Bokky Poobah, käyttivät ”CreatedToken” -tapahtumaa jäljittääksesi kaikki DAO ICO: han liittyvät tapahtumat, samalla kun menin “kovalle reitille” kuvitellessani tilannetta, jossa tapahtumia ei ollut toteutettu, ja kehittynyt deterministinen jäsentäjä Blockchainille, oikeuslääketieteen työkalulle, joka on erittäin hyödyllinen tapauksissa, joissa on tehty haitallisia tai huonosti suunniteltuja älykkäitä sopimuksia. Tein tämän myös siksi, että tapahtumaa, kuten ”ReceivedByExtraBalance”, ei ollut tapahtuman kyseisen osan määrittämiseksi.
Täältä on kiinnostavaa: vaikka heidän käsikirjoituksensa kestäisivät muutaman tunnin, minun vievät noin yhden päivän tai enemmän; johtuu siitä, että minun piti käydä läpi (suorittaa uudelleen) kaikki yksittäiset tapahtumat Blockchainissa, kun taas heillä oli jo pääsy (melkein) "oikeisiin" tapahtumiin tapahtumalokien ansiosta.
Silti meillä kolmella kesti noin kaksi kuukautta numeroiden täsmäyttämiseen ja koko saldo palauttamiseen alkuperäisille omistajille.

Mitä tekemistä tällä on Web3: n suunnitteluprosessien kanssa?
Kehittäjät käyttävät tapahtumia mielivaltaisesti: he voivat halutessaan asettaa tapahtuman tai jättää sen ilmoittamaan jotain tärkeätä Dappistaan. Älykkään sopimuksen tapahtumien käyttöoikeuden myöntäminen loppukäyttäjälle on avointa näistä valinnoista.

Hyödylliset tapahtumat voivat olla merkki avoimesta älykkäästä sopimuksesta ja Dappista, joka ei uskalla kertoa sinulle, mitä se tekee sisäisesti. Vaikka tapahtumia on vähän tai ei ollenkaan, ne voivat olla merkki huolimatonta tai jopa haitallista Smart-sopimusta.

Kuten yllä olevassa DAO-tarinassa, tapahtumien puuttuminen pakottaisi käyttäjän kehittämään omia deterministisiä Blockchain-jäsentäjiään ymmärtämään, mitä tapahtuu sisällä, käytännössä mahdotonta tehtävää myös siksi, että hän tarvitsee arkistosolmun.

Lisäksi tapahtumat ovat hyödyllisiä kehittäjille, jotta ne voivat luoda monentyyppisiä analysointeja, ilmoituksia ja reaktiivisia tietolähteitä, jopa riippumattomasti Smart Contractin omistajasta / luojasta. Tämän virran pitäisi mahdollisesti olla myös loppukäyttäjän käytettävissä, ilman että sitä tarvitse koodata.
 
Web3-postimulaatit:

- se ei ole läpinäkyvyyttä, jos se vaatii hienoa työtä tietojen löytämiseksi, näkemiseksi ja todentamiseksi
 - Ei ole läpinäkyvyyttä, jos 99% käyttäjistä estyy haluamasta katsoa [2]

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ selventää ja antaa loppukäyttäjälle kaikkien tapahtumien saataville, vaikka ne olisivat vain kehittäjän tarkoituksia varten

➤ soveltaa relevanssia: näytä keskeyttävät viestit vain nykyiselle käyttäjälle tärkeillä tiedoilla, mutta anna käyttäjän silti tarkistaa kaikki tapahtumat erillisessä käyttöliittymässä

➤ antaa käyttäjän tilata, tilata tai tilapäisesti mykistää tiettyjä tapahtumia

Tapahtumat ovat sopimuskohtaisia, joten nämä ovat yksinkertaisia ​​ehdotuksia mahdollisista toteutuksista.
Lisäksi nämä ideat ratkaistaan ​​paremmin ulkoisella työkalulla, palvelulla, laajennuksella tai kirjastolla, joka ei vaadi Dapp-käyttöliittymäkehittäjiä ottamaan kaikki nämä "ytimen ulkopuolella olevat" ominaisuudet käyttöön Dappiin.

Miten> esimerkkejä

  • Jos sinulla on ilmoituskeskus, joka on käyttäjän käytettävissä, tämä on luultavasti osa Ketju-näkymä-sivupaneelissa
  • käytä paahtoleipää tärkeisiin viesteihin
  • luo suodattimia vain tiettyjen tapahtumien valitsemiseksi / poistamiseksi tai mukauta ilmoituksia vain tiettyjen parametrien perusteella.
     Jotkut suodattimet voivat olla:
     - jos se sisältää eetteriä / merkkejä
     - osoitteen perusteella (minun / käyttäjän tai muu osoite tai osoitteet)
     - välillä timeX ja timeY, blockX ja blockY
    jne.

takaisin cheatsheet

4 - (Historia) Saatavilla oleva ja läpinäkyvä käyttäjän vuorovaikutushistoria

Tulevaisuudessa, jossa olemme vuorovaikutuksessa satojen tai tuhansien Dapp-tiedostojen, rahakkeiden ja luultavasti ketjujen kanssa, on järkevää, että käyttäjällä on selkeä historia kirjattuna hänen vuorovaikutuksestaan ​​jokaisen kanssa tulevaa käyttöä varten.
 
Lompakot tallentavat jo kaikkien tapahtumien historian, joka on alku, mutta se on vain yhdelle tilille kerrallaan, ja siksi saattaa olla vaikea selvittää, olisitko tekemisissä useiden kanssa.
Lisäksi lompakot olisivat edelleen vaikeita, ellei rakenneta lisäominaisuuksia, jotta suodatetaan vain esimerkiksi tiettyyn Dappiin kuuluvat.

Dappin avulla on varmasti käyttäjäystävällistä auttaa sinua muistamaan kaikki sen kanssa tekemäsi vuorovaikutukset, aivan kuten voit palata takaisin ostohistoriaan missä tahansa normaalissa sovelluksessa.

Vielä tärkeämpää on hajautettu pörssi ja dapps, joka voi luoda satoja tai tuhansia tapahtumia kullekin käyttäjälle.

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ antaa historian kaikista tietystä osoitteesta suoritetuista tapahtumista
Anna käyttäjän tarkastaa kaikki älykkään sopimuksen kanssa mahdollisesti tehdyt vuorovaikutukset, luultavasti lähinnä tyypin 2 vuorovaikutukset, jotka kirjoittavat Blockchainille ja muokkaavat sen vuoksi tilaa

➤ selvitä missä historia on tallennettu
Antaaksesi historian tietylle käyttäjälle, tarkoittaa todennäköisesti hänen Transaction hashes -tallenteen tallentamista tietokantaan, joko etäpalvelimelle tai paremmin käyttäjän paikalliselle hakemistolle. Tämä on tietysti mahdollinen yksityisyyden riski, joten ota huomioon yksityisyyden suojaa koskevat periaatteet (linkki 2.Transaktioiden läpinäkyvyys) ja koodin läpinäkyvyysperiaatteet (∞linkki 5.Koodin läpinäkyvyys) selventääksesi käyttäjälle, missä nämä tiedot tallennetaan.

➤ antaa työkaluja navigointiin, hakuun, vientiin ja poistamiseen historiavälimuistissa

Miten> esimerkkejä

  • kuten tapahtumailmoituskeskuksessa, omaa Käyttäjähistoria-välilehti tai omistettu sivu, todennäköisesti Ketju-näkymän sivupaneelin sisällä
  • anna suodattaa erityyppisiä tapahtumia (arvo-eth, arvo-tunnukset, funktiokutsu, sopimuksen luominen tarvittaessa)
  • anna suodattaa päivämäärän perusteella, alusta tai päivämäärien välillä
  • valinnainen käyttäjäystävällinen lisäys: salli käyttäjien lisätä ei-ketjullinen muistilaatikko tapahtumaan, kuten yksinkertainen muistutus, jos he haluavat yksinkertaisesti ihmiselle luettavan ja haettavan selkeän tekstin
  • valinnainen: pidä hakukenttä siinä tapauksessa, että vuorovaikutuksia on satoja ja jos se on Dapp-sovelluksesi kannalta merkityksellinen
    eli: Hajautetut pörssit saattavat haluta lisätä tällaisen ominaisuuden, jotta käyttäjä voi etsiä vain tiettyihin rahakkeisiin liittyviä tapahtumia
  • vienti: salli käyttäjän valinnaisesti viedä tiedot csv-muodossa ja tutkia sitä muilla tavoilla, erityisen sopiva suurten tietojoukkojen tapauksessa
  • poista: antaa käyttäjän poistaa historian paikallisesta välimuistista, mutta selvennä tietysti, että tapahtumien todellista historiaa ei poisteta heidän lompakostaan ​​tai Blockchainista
  • tuonti: tuontivaihtoehdon lisääminen on järkevää vain, jos Dapp antaa käyttäjän lisätä mukautettuja muistiinpanoja jokaiseen tapahtumaan, muuten tiedot voidaan yksinkertaisesti rekonstruoida Blockchainista

takaisin cheatsheet

5 - (Code & Environment) Koodin läpinäkyvyys

Jos Dappiin voi luottaa, tarkoittaa myös sitä, voidaanko suoritettavaan koodiin luottaa.
Luotettavaksi Dappien tulee olla mahdollisimman avoimia kaikista koodinsa puolista.

Web3 Postulaatit

- Jotta Dappiin voidaan luottaa, sen koodiin täytyy luottaa
 - Jotta koodiin voidaan luottaa, sen on oltava läpinäkyvä, itsenäisesti suoritettava ja todennettavissa

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ Selvitä, mitä Blockchainia käytetään
se näyttää itsestään selvältä, mutta skenaariossa, jossa Dapps leviää, monet voivat olla Blockchain-agnostisia tai käyttää erilaisia ​​versioita eri ketjuissa. Myös Plasman, Polkadotin, Cosmosin ja muiden skaalausratkaisujen kanssa on mahdollista, että Dapp voi seurata tapahtumia sen omassa alaketjussa, joka on sijoitettu syvälle muiden plasmaketjujen tai muiden parahainien tai kosmosvyöhykkeiden tai napojen puuhun. Käyttäjälle tulisi tehdä tieto siitä, mihin heidän tietojaan kirjoitetaan, ja siksi hänen on oltava tietoinen teknisistä muuttujista (turvallisuus, nopeus jne.) Ja mistä tiedot on itsenäisesti todennettava.

➤ Selvitä älykkäiden sopimusten osoite, joita käytetään lukemiseen ja kirjoittamiseen
ja linkki riippumattomiin Blockchain-tutkijoihin (∞link 1.Tietojen läpinäkyvyys).

➤ Selvitä, mikä koodi on avoimen lähdekoodin ja mistä se löytyy.

➤ Selvitä, missä koodia käytetään (paikallinen vs. etäpalvelin)
Tämä saattaa olla yksi vaikeimmista ja hankalimmista toteuttaa visuaalisella tasolla, mutta jos osien on suoritettava palvelimella, on ainakin sivu, jossa selitetään mitkä osat ja miksi, ja osoita siihen mistä tahansa käyttöliittymän osasta.
Jos ensimmäisten periaatteiden (∞ link 1.Tietojen läpinäkyvyys) esimerkeissä näkyvä ”ketjunäkymä” -tila on otettu käyttöön, se olisi hyvä paikka lisätä nämä muut näkymät.
 
➤ Selvitä web3-palveluntarjoajan / Blockchain-solmu (paikallinen solmu, Dapp-ohjattu solmu, Infura, MetaMask? Tai muu solmu)
Miksi? Koska instrumentoidut solmut voivat tallentaa tietoja, kuten eterscan, ja voivat mahdollisesti aiheuttaa tietosuojariskejä käyttäjälle.
 
- Salli käyttäjien vaihtaa omaan solmuunsa, mikäli mahdollista tai asiaankuuluvaa
Vaikka MetaMaskin kaltaiset palveluntarjoajat jo huolehtivat tästä, tätä periaatetta sovelletaan, jos web3 Dapp lähettää jostain syystä tapahtumia tietyille solmuille. Oman yksityisen solmun läpi kulkevat tapahtumat voidaan myös suorittaa nopeammin, koska niillä vältetään julkisten solmujen mahdolliset jonot etenkin suuren kysynnän tapahtumien, kuten joukkotietojen, aikana.

➤ Selvitä, onko Dapp käynnissä MainNetissä tai TestNetissä
Vaikka web3-palveluntarjoaja huolehtii tästä, varmista erityisesti, että käyttäjä ymmärtää, että MainNetissä ajetaan toimintoja, jos kyse on (turvaudu myös muihin periaatteisiin 2.link 2.Tapahtumien läpinäkyvyys).

➤ Selvitä, mitkä ketjulta luetut tiedot tulevat oraakkeista tai mihin oraaklit ovat vaikuttaneet niihin

Käyttäjäystävälliset lisäykset
➤ Salli DIY-koodin suorittaminen
anna edistyneempien käyttäjien nähdä tapahtumatoiminnon puhelun ennen sen lähettämistä, jotta he voisivat vahvistaa sen ja toistaa toiminnon itse komentorivin kautta.
Tämä saattaa tuntua liioittelulta, koska Dapp-käyttöliittymä on olemassa yksinkertaistamaan käyttäjää ja piilottamaan tiettyjä teknisiä asioita, mutta skeptinen / vainoharhainen käyttäjä haluaa tarkistaa jopa yksittäiset tapahtumat: jos Blockchain on kuin hajautettu tietokanta, käyttäjän tulisi pystyä suorittamaan kirjoitustoimenpiteet itsenäisesti, ja Dappin tulisi silti toimia.
Radikaalin läpinäkyvän asenteen suhteen koodiin Dapp, joka sallii tämän ominaisuuden, osoittaa ”älä luota. Vahvista ”https://blog.wizsec.jp/2018/02/kleiman-v-craig-wright-bitcoins.html?m=1

Parannettu versio Data Provenance -sovelluksesta, jossa käyttäjät voivat myös kopioida liitä koodin ja hakea tiedot itse

➤ Selvitä älykkäässä sopimuksessa vaadittavat tulot:
Älykkäät sopimukset vaativat usein suuria numeroita, joissa on paljon nollia, jotka ovat käyttäjälle epäystävällisiä etenkin siksi, että on erittäin helppoa tehdä kalliita virheitä. On normaalia ja suositeltavaa, että Dapp-käyttöliittymä yksinkertaistaa tätä prosessia käyttäjälle, sallimalla pienemmät numerot ymmärrettävämmällä ja vähemmän virhealttiilla alueilla, kuten 0 - 100. Koodin periaatteiden aiemman avoimuuden vuoksi se olisi kuitenkin tehtävä. Selvitä käyttäjälle, missä käyttöliittymä yksinkertaistaa näitä syöttöjä, ja selventä varsinkin DIY-koodin tarkastajassa todellista tuloa, jota älykäs sopimus odottaa.
Todellinen tapaus, jossa tämä oli hämmentävää, nostettiin esiin keskustelussa Jorge Izquierdon kanssa Aragonin äänestyssovelluksesta. Kehittäjät voivat käyttää samaa tapaukseen esitettyä ratkaisua ja selventää käyttäjälle joitain esimerkkejä: yksinkertaisella numerolla, tieteellisellä merkinnällä ja todellisella syötteellä (kaikilla nolla-arvoilla), jota älykäs sopimus odottaa.

yksityiskohta esimerkistä Aragonin wikistä

Miten> esimerkkejä

  • sinulla on ”Koodin läpinäkyvyys” -sivu, joka on aina saatavissa, kuten käyttöehdot tai tietosuojakäytännösivut
  • linkki github-repoteesi useissa paikoissa
  • lisää "ketjunäkymä" -paneeliin (näytetään luvun 1.Tietojen esiintymisen läpinäkyvyys) esimerkeissä, joka on omistettu koodin läpinäkyvyyteen
    ○ tietoa:
     - käytössä oleva Blockchain,
     - tällaisen Blockchain-ominaisuudet, erityisesti keskimääräinen lohkon vahvistusaika (∞ link 6.Time / Wait Management)
     - onko se MainNet tai TestNet
     - käytössä oleva web3-palveluntarjoaja (salli vaihto)
     - sopimuksen osoitteet,
     - mahdollisesti yksinkertaistettu versio sopimuksen ABI: stä vain menetelmillä, joita koodi todella vaatii
     - jos jotakin koodin osaa ei käytetä paikallisesti (tekstinkäsittely ja motivaatio)
     - linkki github-repoihin
    ○ kytkimet, suodattimet tai vaihtoehdot:
     - näyttää kuvakkeilla ja / tai värejä vaihtamalla, millä osilla / komponenteilla on palvelimella käsiteltyä tietoa
     - näyttää ("pilvi-ketju" -orackelilla) linkkikuvakkeilla ja / tai muuttamalla värejä, mikä tieto tulee oraakkeista
     - vaihda tarvittaessa web3-palveluntarjoajaa
     - esikatselu operaatioista, joita kutsutaan funktion kutsuilla, jotka voidaan kopioida ja suorittaa komentorivillä
     tarvittaessa merkinnät syötteistä.
esimerkki Code Transparency -paneelista ja tiedoista

takaisin cheatsheet

Web3: n yleiset UX-periaatteet

Seuraavat periaatteet eivät liity enää suoraan Läpinäkyvyys- ja Luottamattomiin ominaisuuksiin, ja niiden tarkoituksena on pikemminkin ratkaista joukko muita UX-ongelmia, jotka johtuvat Blockchain-pohjaisten hajautettujen sovellusten yleisestä käytöstä ja toteuttamisesta.

6 - Ajan / odotuksen hallinta

Ennen kuin skaalautuvuusongelmat on ratkaistu, transaktiot ovat asynkronisia, ja niiden taustalla olevan Blockchainin ja nykyisen verkon ruuhkien mukaan prosessointi voi viedä kauan ja olla vahvistettu täysin.

Hyvin suunnitellun Dappin on selvitettävä nämä tiedot ja hallittava käyttäjän odotuksia, kunnes käyttäjän toiminta vahvistetaan.

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ (Hallitse käyttäjän odotuksia) Selvitä jokaisessa tapahtumassa taustalla olevan Blockchain-palvelun keskimääräinen lohkovahvistusaika ja nykyinen verkon ruuhka

➤ (Hallitse odotusaikaa) Näytä elävyysindikaattorit odotusajan aikana

Kuinka> Esimerkkejä

UX-tapahtumien sekvenssinä Dappin tulisi

  1. selitä, miten kaasuvalinnat vaikuttavat odotusaikaan (∞link.9 kaasun hinnat ja lähetysten kääntö)
  2. näytä varoitus ketjukohtaisista ajoista
  3. Näytä edistymis- tai odotuskuvake, kunnes se ei ole ratkaistu
  4. Jos asiat vievät normaalia pidempään, näytä palaute ja mahdolliset syyt ja / tai ratkaisut
    eli: "se vie odotettua kauemmin. Verkko on tällä hetkellä ruuhkainen.
     Tässä on vaihtoehtosi:
     -> Odota vielä X sekuntia / minuutteja
     -> lisää lisää kaasua nopeuttaaksesi kauppaa
     -> saat ilmoituksen, kun se on valmis
  5. Ilmoita, että ilmoitat käyttäjälle joka tapauksessa onnistuneesta suorituksesta
  6. Kun toimenpide on suoritettu, ilmoita onnistuneesta suorituksesta raportilla tiedoista (ts. Transaction Hash), jonka he voivat itsenäisesti todentaa

takaisin cheatsheet

7 - Ihmiselle luettavissa oleva hashes-muoto

Kunnes nimirekisterit ovat laajalti hyväksyttyjä, ja silloinkin joudumme käsittelemään pitkien osoitteiden ja tapahtumahajautusten vaikeuksia.
Nämä ovat vain joitain ideoita siitä, kuinka tehdä niistä enemmän ihmisille luettavia, samalla kun säilytetään täydellisen tiedon läpinäkyvyys.

Periaatteet

Dappien käyttöliittymän tulisi:

Väliaikainen päivitys 2018–07–11 Parhaillaan keskustellaan joidenkin näiden periaatteiden turvallisuudesta. Palaa parin päivän sisällä saadaksesi paremman ja turvallisemman version

➤ näyttää tiivistetyt tiivistelmät, mutta näytä aina alku- ja loppuosat
eli 0xABCD… EFGH
Varo kuitenkin, että tämä saattaa sisältää tietoturvaongelmia, koska turhamaisuusosoitegeneraattorit voivat tuottaa 8 merkkiä sekvenssejä ≈1 viikossa,

➤ Jos tarvitset vielä lyhyemmän version, ̵ mieluummin alusta päättyneen ̵
̵I̵e̵ ̵u̵s̵e̵ ̵0̵x̵A̵B̵C̵D̵… ̵ ̵r̵a̵t̵h̵e̵r̵ ̵t̵h̵a̵n this ̵0̵x̵… ̵E̵F̵G̵ (tällä on turvallisuusvaikutuksia, kuten Tom Nash huomauttaa tässä)> muutettu seuraavasti:

➤ Jos tarvitset vielä lyhyemmän version, mieluummin loppua alkuun
 eli käytä 0x… EFGH kuin 0xABCD…
(vaikkakin se on luettavampaa ja näyttää paremmalta, että neljä ensimmäistä merkkiä on, verrattuna 0x… EFGH: hon, kyseessä on turvallisuusongelma, koska ensimmäiset 4 merkkiä ovat yksinkertaisempia bruttovoimaan ja generoida kuten turhamaisuus-URL-osoitteiden tapauksessa, mutta on tähtitieteellisesti vaikea luoda tarkkaa hakua neljälle viimeiselle merkille)

mieluummin käyttää 4 kirjaimen palasia kolmen kirjaimen sijasta jokaisesta osasta
eli käytä 0xABCD… eikä 0xABC…

Pend pend edeltää aina numeroa 0x osoittaaksesi, että kyseessä on hash

➤ sallii valinnaisen näkymän, jossa koko osoite on näkyvissä

➤ antaa käyttäjille mahdollisuuden kopioida osoite helposti

➤ Jos mahdollista, käytä lyhenteitä nimikkeinä ja lyhennettyjä osoitteita tekstityksenä

➤ Luo mahdollisuuksien mukaan järjestelmä, jonka avulla käyttäjä voi helposti liittää mukautetun ihmisille luettavan nimen tai tekstin osoitteisiin
nämä muistiinpanot olisi tallennettava paikallisesti käyttäjän paikalliselle tietokoneelle, ei palvelimelle (turvaudu ∞link 5.Koodin periaatteiden läpinäkyvyys)
Jos se on olemassa, turvaudu tunnettuihin aliaksiin db, kuten ENS-rekisteriin tai Etherscaniin tunnettuja sopimuksia ja osoitteita varten.

takaisin cheatsheet

8 - Pysyvä aloittelija -tila

Jos haluamme hajautettujen sovellusten massan käyttöönoton, se tarkoittaa, että meidän on sallittava joukko ihmisiä, joilla ei ole teknistä tietoa tai ymmärrystä Blockchainista ja sen kielestä, pääsemään avaruuteen.
 
Tämä on enemmän kuin muut tilat, joka vaatii vähän koulutusta, sekä turvallisuussyistä (yksityisten avainten käsitteleminen), mutta myös ymmärtää täysin, miksi Blockchain-ominaisuudet ovat niin vallankumouksellinen ilmiö ja miten Dapps eroaa muista sovelluksista.

Tärkeää on myös se, että tämä tila on niin ihanan kasvot, että se vaatii usein uusia mielentilamalleja ja monitieteistä ymmärrystä: Arvo-Internet luo tuhansia markkinoiden dynamiikan vaikutteisiin merkittyjä ekosysteemejä, joita yleensä tutkitaan taloustieteessä, rahoituksessa ja peliteoriassa; On hyvin epätodennäköistä, että joukot perehtyvät tai ovatko koskaan saaneet altistua näille tieteenaloille.
Siksi hajautettujen sovellusten tulisi pyrkiä kouluttamaan uusi ja vakiintunut käyttäjä kaikille heidän työskentelynsä näkökohdille.

Suurimmassa osassa aikaisemmista periaatteista on aloittelijan käyttäjä mielessä, mutta on vielä muutama asia, jotka kehittäjien tulisi harkita.

Periaatteet

Dapp-käyttöliittymän tulisi:

➤ Kudota koulutustietoja normaalin vuorovaikutuksen kanssa
Nick Neuman on tiivistänyt Dapp Designerin päätehtävän erinomaisesti: ”Hyvä loppukäyttäjäsovellus muuttaa koulutuksen tuotekokemukseksi. Tämä tarkoittaa selittämistä tiiviisti ja mielenkiintoisella tavalla, miksi käyttäjä tekee jotain tekeessään sitä, ja tuotteen rakentamista, jotta käyttäjän on erittäin vaikea tehdä jotain vaarallista. "

➤ Tarjoa vähintään 2 koulutustasoa: Blockchain-perusteet ja Dapp-erityinen lingo
Tämä ei ole vain meidän aikamme periaate, jonka aikana aloittelijoita ilmaantuu. Kaikille sovelluksille, etenkin niille, joilla on sisäinen tai asiayhteydessä oleva lingo tai ainutlaatuinen mekanismi, olisi hyvä käytäntö lisätä uusi koulutuskerros: ts. Jos rakennat tokenista rahastonhoitajaa, älä oleta käyttäjien tietävän rahoitusta ja sitä, mitä kukin termi tarkoittaa; Sen sijaan kouluta heidät molemmat Blockchainin ja rahoituksen perusteisiin ainakin ymmärtääksesi käyttämiäsi sanoja.

➤ Minimoi ja lisää asteittain uusia asioita ja käsitteitä, jotka käyttäjän on opittava
Blockchain-projektien on huolimatta tunnustetuista adoptiokannustimista jouduttava silti kohtaamaan normaali kitka ja vaiva, joka tapahtuu ohjelmistopalvelussa: käyttäjät valitsevat yksinkertaisempia vaihtoehtoja, varsinkin jos Dapp kysyy liikaa heiltä. Siksi Dappien tulisi toimittaessaan koulutussisältöään uusille tulokkaille yrittää minimoida uusien sanojen ja käsitteiden käytön, etenkin yleisölle tarkoitetuilla sivuilla (ts. Kotisivu), ja näyttää asteittain lisää opiskelua kiinnostuneille käyttäjille (eli käyttäjä mittaristot). Tämä voidaan saavuttaa myös käyttämällä yksinkertaisempaa kieltä, välttämällä kielekkeitä ja käyttämällä analogioita selittämään monimutkaisia ​​uusia tietoja sellaisella tiedolla, jonka käyttäjä voi jo tuntea. Esimerkiksi näet kuinka Spankchain loi kortin käsitteen välttääkseen maksukanavien selittämistä.

➤ Nopeuta oppimista, mikäli mahdollista tai tarkoituksenmukaista tarjoamalla ”asiantuntijan tulkinta”
Demystifioi Dapps-toimintojen merkitykset, kuinka ne ovat vuorovaikutuksessa ja kuinka asiantuntija ajattelee vaikutuksia.
Mitä asiantuntija tietäisi tietystä tietystä asiasta? Kuinka he tulkitsevat tietoja? Kuinka he toimisivat sen suhteen? Mitä valintoja he tekisivät?
Näihin kysymyksiin annettavat vastaukset voitaisiin yhdistää Dapp-käyttöliittymän ehdotuksiksi, jos ne ovat merkityksellisiä.
Esimerkkejä menee hyvän kaasun hinnoittelun ennakoinnista (∞ link 9.Gas hinnat) ilmoittamiseen, onko hyvä tai huono hetki vaihtaa tietty merkki (vain esimerkki).

➤ Älä mene kontekstiin
yritä kutoa katkelmiin rajapinnan sisällä väliaikaisilla ponnahdusikkunoilla, jotka voidaan helposti hylätä ja jotka voisivat sitten avata tarkempia tietoja toisella välilehdellä. Salli käyttäjän oppiessa oppia nopeasti ja “paikoillaan” muuttamatta sivua ja menettämättä jälkeä mitä he tekevät.

Miten> esimerkkejä

  • lisää pienet tekstitykset komennoille kaikkialla (ja viitaa muihin periaatteisiin ennakoida, mitä tapahtumia aiotaan tehdä ∞link 2.Tapahtumien läpinäkyvyys)
  • oppimistilan asetus
    lisää “ketjunäkymään” tai muihin käyttöliittymän osiin kytkin (“yleinen kysymysmerkki” -painike), joka voidaan kytkeä päälle ja pois päältä ja joka mahdollistaa tai poistaa käytöstä oppimisominaisuudet
  • Sanaston ponnahdusikkuna
    Kun käytät sanakirjasta saatavilla olevaa lingoa, näytä linkkikuvake, sanan jälkeen oleva kuvake, joka napsautetaan tai vieritetään, esiin kontekstuaalisen ponnahdusikkunan, jossa on määritellyt tiedot
    Joissain tapauksissa ponnahdusikkunan tulisi myös tarjota mahdollisuus "tietää enemmän", joka avaa toisen välilehden tai sivupalkin sanastovälilehden avatussa "ketjunäkymässä".
  • Sanasto
    ketjunäkymässä tai jollakin muulla sivulla Dappin tulisi tarjota sivu kaikilla termeillä, Blockchain- ja Dapp-spesifisillä, joita käytetään itse Dappissa tai joita tarvitaan sen mekaniikan ymmärtämiseen. Tämä sivu on ohjattava sanastojen ponnahdusvalikosta, eikä sitä tarvitse linkittää suoraan.
  • missä tahansa ohjatussa toiminnassa olisi taitava ottaa nopea eteenpäin siirtäminen seuraaviin vaiheisiin, jotta näet mitä on tulossa, vaikka niiden kaikki asettelut tulisi olla harmaana ja poistaa käytöstä, kunnes olet suorittanut edelliset vaiheet. Tämä on hyvä periaate kaikille käyttöliittymille, ei vain Dappsille.

takaisin cheatsheet

9 - kaasun hinnat ja transaktioiden peruutukset

Kaasu on yksi hämmentävä asia aloittelijoille. Vaikka nimi kertoo, on vaikea kuvitella kustannuksia laskennallisista palveluista, jotka sinulla on aina ollut ilmaiseksi.
Lisäksi, kun käyttäjät kohtaavat kaasua ensimmäistä kertaa, he eivät tiedä miten sitä hinnoitella, eivätkä siksi mikä olisi hyvä valinta kaasun hinnasta.

Vaikka nykyään käytännössä kaikissa tapauksissa kaasua hoitavat kauppaa luovuttavat lompakot, tämä periaate on edelleen voimassa sekä lompakkosuunnittelijoille että kaikille niille, jotka vaativat tai pyytävät käyttäjiä valitsemaan kaasunhinta.

onneksi kehittäjille on olemassa työkaluja, kuten Ethereum-huoltoasema, joka tarjoaa kätevän sovellusliittymän.

Periaatteet

Dappien käyttöliittymän tulisi:

➤ Selvitä, mikä on kaasu ja kaasun hinta
(aivan kuten minkä tahansa muun lingo ∞link 8.Newbie-moodin kanssa)

➤ Ehdota hyvää kaasunhinta-aluetta ja selventää aika-arvioita ylä- ja alarajoille
nämä ovat verkon nykyisen ruuhkan toimintoja, joten optimaalinen ratkaisu olisi kysyä nykyiseltä Ethereum-huoltoaseman sovellusliittymältä https://ethgasstation.info/json/ethgasAPI.json ehdottaakseen näitä etäisyysrajoja.
On tärkeää selventää käyttäjälle, että tämä on aikapohjainen ehdotus ja että ehdotetut arvot voivat muuttua tulevaisuudessa.
 
➤ Mahdollisesti näyttää kaasun arvot muunnettuna myös FIAT: ksi

➤ Salli transaktion peruuttaminen: jos käyttäjä on lähettänyt lähetystekstin, jolla on alhainen kaasun hinta, se tulisi tehdä käyttäjälle selväksi
(∞linkki kohtaan 6.Time / Wait Management)
- että tx-tiedostoa ei voi peruuttaa sen käynnistämisen jälkeen
- että ainoa ratkaisu on lähettää toinen tx samalla nokkisella ja korkeammalla kaasunhinnalla
> siksi tarjoavat mahdollisuuden palauttaa tx-nonce automaattisesti ja lähettää sen korkeammalla kaasuhinnalla.

takaisin cheatsheet

DDP-hajauttamissuunnitteluperiaatteet

Hajauttaminen on uusi voimakas globalisaation muoto.
Yksi, jota ensimmäistä kertaa johtavat mahdollisesti joukot itsenäisiä itsenäisiä yksilöitä, jotka yhdistyvät rajattomien ideoiden, itsehallinnollisten organisaatioiden ja hajautettujen markkinajärjestelmien ympärille.

Nämä suunnitteluperiaatteet haluavat vain saada keskustelun alkamaan ajattelemalla, kuinka saada käyttäjä tuntemaan olevansa osa yhteisöä ja jotain, joka on itsestään toiveellisesti suurempi.
Ne ovat vain vihje kehittäjille, jotka alkavat ajatella kokonaisvaltaisesti Dapp-ohjelmiensa toimintaa ja esiin nousevia uusia UX-vaatimuksia laajemmassa hajautettujen yhteiskuntien yhteydessä.

10 - yhteisöllisyys

Dappit ovat erilaisia ​​kuin sovellukset, koska ne ovat luontaisesti jaettuja: vaikka jotkut olisivatkin yksilölle suunnattuja palveluita, joiden vuorovaikutus on yksinäinen kokemus, niitä tehdään yhä suurelle ihmisryhmälle, ja usein heidän työnsä on kaikkialla maailmassa.
 
Yhteisöön kuulumisen tunne on tärkeämpää näissä Dapp-ohjelmissa, koska käyttäjien on liityttävä hajautettuun tuotemerkkiin ja tuotteisiin.
Tämä ei tarkoita Dappissa leipomista sosiaalisessa verkostossa, vaikka jotkut saattavat hyötyä tiiviimmästä integroitumisesta projektin valitsemaan yhteisökeskusteluun.

Lienee tarpeetonta sanoa, että nämä ideat ovat melko tärkeitä DAO: ille.
 
Harkitse seuraavaa aivan kuten joitain yleisiä ehdotuksia vapaammin tulkittavissa olevassa tavoitteessa saada käyttäjät saamaan tuntemaan olevansa osa jotain itseään suurempaa.

Periaatteet

Dappien käyttöliittymän tulisi:
 
➤ Selvitä, kuinka monta muuta jäsentä yhteisössä on
➤ selvennä, ketkä ovat muita jäseniä (valitse sopivat luokat)
➤ Selvitä yhteisön kokoonpano (eli alaryhmät ja niiden vaikutusvalta hankkeessa)
hankkeen suurempi tehtävä (jos sellainen on) ja kuinka heidän osallistuminen edistää hankkeen saavuttamista

Kuinka> Esimerkkejä

  • tarjoa laskeutuva kojetaulu tilastoineen yksilöllisistä merkkien haltijoista tai Dapp- tai DAO-jäsenten lukumäärästä
  • omaksumaan avoimuusperiaatteen ja näyttämään erityisesti kaikki tiedot, jotka käyttäjät itse voivat saada analysoimalla lohkoketjua:
     - rahallinen varallisuudenjakelu
     - hyväksymisaikataulut,
     - merkinnän haltija lohkosta XX lähtien ja vvv-kk-pp
     jne
  • harkitse DAO: ssa tietojen rikastamista kaikilla, joilla voi olla merkitystä (jos saatavilla), kuten:
     - jäsenten tyyppi (ts. # Kasvattajia vs. ei-kasvattajia Crypto Kittiesissä tai # muusikoita ja # kuuntelijoita musiikki / ART Dappsissa, kuten UJO Music, stäkkarit vs.
     - panosjakelutilastot
     - Ehkä maantieteelliset sijainnit / aikavyöhykkeet ?,
     - Ehkä sukupuoli, ikä? (mutta vain jos se on järkevää yhteisöllesi ja jos se ei ole loukkaavaa tai haitallista Dapp-sovelluksen käyttöönotolle)
  • Ehdottomasti etsiä kategorioita, jotka ovat sopivia ja merkityksellisiä projektillesi: esimerkiksi henkilökohtainen mielipiteeni on, että DAO: ssa sukupuoli ja ikä eivät ole merkityksellisiä tietoja, jopa haitallisia ajatukselle luoda luvaton ja puolueeton yhteiskunta, mutta ehkä ne ovat hyvin soveltuu hankkeisiin, kuten SpankChain.
  • Ehkä antaa käyttäjille mahdollisuuden valita omat tunnisteensa, luokkansa, biokuvauksensa jne .: Jokaisella jäsenellä voi olla erilaiset identiteetit eri projekteissa. Tämä vihjaa jo muihin identiteettien periaatteisiin, jotka esitetään tulevaisuudessa.

takaisin cheatsheet

11 - Muut tulevaisuuden suunnittelun periaatteet

Kuten olet ehkä ymmärtänyt, edellinen periaate vaatii lisää ajatuksia identiteettien, maineen ja hallintotavan suhteen. Kaksi ensimmäistä ovat yleisesti hyödyllisiä monissa yhteisöpohjaisissa sovelluksissa, mutta ne ovat perustavanlaatuisia TCR: lle (Token Curated Registry) ja todennäköisesti monille DAO: ille ja muille krypto-primitiiville.

Nämä periaatteet ansaitsevat oman analyysinsa ja tilansa, ja tämä viesti on jo liian pitkä.
Jatkossa analysoin Web3: n suunnitteluperiaatteita:
- Identiteetit ja maine
- Hallinto
- Lompakot
- Vaihdot
- ICO & Token Sales Mechanics
- Tokenin mekaniikka

Seuraavat vaiheet

On selvää, että näissä Web3-suunnittelun periaatteissa ehdotetut ”äärimmäisen avoimuuden” vaatimukset aiheuttavat melkoisen taakan Dapp-kehittäjille, jotka ovat nykyään keskittyneet enemmän monien muiden projektien osiensa ratkaisemiseen.
 
 - Bootstrap kuten kirjasto
Siksi on selvää, että siellä olisi oltava vakio työkalusarja, jonka kehittäjät voisivat kytkeä ja pelata Dapp-tiedostoihinsa ja ehkä liittää puhelut web3-kirjastoon ja saada ilmaiseksi kaikki nämä läpinäkyvyyspalvelut käyttäjilleen.
Kuvittelen jotain Bootstrap-kaltaista kirjastoa Web3-aikakaudelle (“Chainstrap”? Se on vähän liian kova ydin, eikö?: P)

- Itsenäinen selaimen laajennus
Ehkä on jopa suositeltavaa, että on olemassa riippumaton työkalu, joka tarjoaa käyttäjille Web3-suunnitteluperiaatteiden etuja Dappin luoja haluaa tai ei; eräänlainen ”läpinäkyvyyden valvoja”, jonka avulla voidaan tunnistaa haitalliset tai huolimattomat Dappit sen mukaan, kuinka paljon ne noudattavat joitain periaatteita.
Tässä tapauksessa olisi todennäköisesti tarkoituksenmukaista luoda selainlaajennus, joka ruiskuttaa koodinsa Dappiin ja tarjoaa ketjunäkymän toiminnot ja ehkä jopa nopean varmennuksen Dappin läpinäkyvyyden ja luotettavuuden asteesta.

- Mukautetut palvelut
Lisäksi näissä periaatteissa on monia palvelujen mahdollisuuksia, jopa kaupallisia, joita ei vielä ole olemassa.

Monia vaihtoehtoja. Mitä mieltä sinä olet?

Jos olet kiinnostunut jonkin edellä mainitun kehittämisestä, jos sinulla on vain ajatuksia ja huomioita,
tai jos olet apurahoja tarjoava organisaatio ja uskot, että se voisi sopia nykyisiin tavoitteisiisi,
ota yhteyttä b [at] likuidlabs.com tai twitterissä @lyricalpolymath

Suunnitellaan ja rakennetaan hajauttamisen tulevaisuus yhdessä!

LIITETIEDOT

[1] Muut ”Blockchain” + suunnitteluartikkelit

Suunnittelumenetelmää soveltaen tutkin, mitä aiheesta oli jo luotu: ei paljon.

  • Blockchain-suunnittelun periaatteet - Suunnittelu IBM: llä
    Tämä on ylivoimaisesti paras artikkeli aiheesta. Kirjoittanut Sarah Baker Mills, entinen suunnittelupäällikkö IBM: ssä ja nykyään suunnittelujohtaja Consensysissa. Hän tislaa erittäin hyvin joitain Web3-suunnittelun periaatteissa esiintyviä periaatteita, vaikkakin eri nimillä. Hän puhuu tietojen altistumisesta, johdonmukaisuudesta, palautteesta, virheiden ennakoinnista ja aktiivisesta ohjauksesta.
  • Blockchain and Design - Hacker keskipäivä
     Haastattelu Mattcoksen kanssa, johtava suunnittelija, klo 21.co, haasteista ja ideoista mitä suunnittelijoiden tulisi tehdä. Valitettavasti haastattelu ei salli tislata monia opetuksia, mutta hän on ehdottomasti mielenkiintoinen luku.
  • Blockchainin käyttäjäkokemus
    yleinen viesti suunnittelijoiden kouluttamiseksi Blockchainista ja suunnittelun haasteista.
  • Kuinka Suunnittelu voi auttaa Blockchain - The Spark
    muutama makroidea eräistä asioista, joita tämän tilan suunnittelijoiden tulisi ajatella
  • Suunnittelu Blockchainille: ethereum Smart Contract -sovelluksen käynnistäminen
    Tutkimustapaus parempien kokemusten suunnittelusta sijoitusalustalle, ja siinä on ideoita ICO: hon osallistumisen parantamiseksi

[2] Tiedän, että nämä postulatit ovat fenomenologisia virheitä, mutta käytän niitä joka tapauksessa, koska ne ovat hyödyllinen yksinkertaistaminen ja tuovat esiin asian: muulle kuin tekniselle käyttäjälle, joka ei pysty tarkistamaan tietoja yksin helposti, Tiedot eivät selvästikään ole avoimia. Läpinäkyvyydestä tulee sitten hohtava mirage, uskollinen luottamuksen odotus.