1. Personal Finance10 Designprincipper for distribuerede Blockchain-apps
Ethereum For Dummies

Af Michael Solomon

Blockchain-teknologi er en forstyrrende, transformativ tilgang til den måde, vi administrerer data på. Det lover at radikalt ændre, hvordan vi udfører opgaver, der håndterer følsom information i delte miljøer. Kritiske operationer på følsomme data krævede historisk en stærk central myndighed for at overbevise datalejere til at stole på miljøet nok til at det kan administrere deres data.

En af de vanskeligere hindringer, som enhver blockchain-app skal overvinde, er at opbygge tillid. Brugere er nødt til at stole på, at softwaren, der kører på blockchain, indeholder solide foranstaltninger til at yde sikkerhed og beskytte privatliv, før de leverer følsomme personlige og forretningsdata.

Du kan gå langt mod at opbygge denne tillid ved at overholde flere grundlæggende designretningslinjer. Hvis du følger de ti designmål for blockchain-applikationer, som du finder her, hjælper du dine brugere til at stole på din applikation nok til at bruge den og stole på den.

Design blockchain-apps til tillid

En af de primære årsager til, at de fleste organisationer bevæger sig mod blockchain-løsninger, er dens evne til at dele data mellem noder, der ikke har tillid til hinanden. Hvis du tænker over det, sætter det virkelig en høj bjælke for dApp-udviklere. For at udvikle en vellykket dApp skal du overbevise dine brugere om at stole på din software med deres data, når du sender dem til et stort antal andre noder, som du ikke har tillid til (og de heller ikke har tillid til).

Tillid er normalt (men ikke altid) transitive. (Ja, du er på vej tilbage til matematikklasse. Hvis A = B og B = C, så er A = C. Du er velkommen.) Dette er den mest almindelige måde, vi som mennesker håndterer tillid på.

Hvis du stoler på Mary, og Joe stoler på dig, er Joe sandsynligvis i orden med at have tillid til Mary. Lad os antage, at du er madkritiker. Joe stoler på, at du anbefaler god mad. Hvis du lægger ud af, at du virkelig kan lide Marias ferskenkage, vil Joe være mere tilbøjelig til at prøve hendes ferskenkage, da Joe stoler på din smag i mad. Men det sporer ikke med et tillidsløst miljø. I tilfælde af blockchain dApps har dine brugere tillid til dig, men du har ikke tillid til andre i dit eget blockchain-netværk.

Dit første designmål er et mål på højt niveau, som du skal holde som en top-of-mind motivator for alle beslutninger. Mange af de efterfølgende designmål understøtter dette: Design dine dApps til tillid. Dette mål betyder, at du vil overveje, hvad dine brugere går ned, og hvad der får dem til at føle, at de kan stole på din dApp.

Brugere skal vide, at du tager sig af deres data. Din dApp bør ikke skjule noget og skal gøre det nemt at kontrollere, hvad der sker. Det skal klart kommunikere god og dårlig information og give en generel følelse af velvære. Selvom det er en stor ordre for software, er det nødvendigt at opbygge tillid.

Det vigtigste aspekt ved at designe for tillid er at forstå, hvem dine brugere er, og hvad der får dem til at føle sig godt tilpas. Kort sagt, kend dine brugere. Ved hvad de vil, og hvordan du kan overbevise dem om, at du ikke kommer til at spilde deres tid eller drage fordel af deres tillid til dig.

Håndhæv konsistensen i blockchain-apps

En af de nemmeste måder at undgå forvirring er at begrænse mulighederne og modstridende oplevelser i dine dApps. Microsoft lærte for længe siden magten i konsistens. De udviklede standarder for, hvordan man interagerer med brugerne, og udforskede og definerede alle aspekter ved at skabe en brugergrænseflade. Det er grunden til, at Microsoft-applikationer føler sig ligner hinanden.

Hvis du har brugt et Microsoft-program, genkender du mindst den generelle brugergrænseflade i andre Microsoft-applikationer. (Og hvis du har brugt Microsoft-produkter i et stykke tid, vil du huske den enorme forstyrrelse, Microsoft forårsagede, da de konverterede til en flisebaseret brugergrænseflade - stort set fordi alle var så behagelige med den gamle Microsoft-grænseflade.)

Hvis du f.eks. Vil finde den aktuelle version af et Windows-program, du kører, kan du næsten altid klikke på eller trykke på Hjælp og derefter klikke på eller trykke på menupunktet Om i menuen Hjælp.

Billedet herunder viser menupunktet Om i VS-kode. Menupunktet Om findes i stort set alle Windows-applikationer og viser grundlæggende oplysninger, inklusive versionnummeret, af det program, du kører. Det enkle eksempel på brugergrænseflade konsistens gør det nemt for alle at finde applikationsinformation uden at skulle jage efter dem.

VS-kode Ethereum

Følgende billede viser dialogboksen Om i VS-kode. Du finder udgivelsesoplysninger til de fleste Windows-applikationer ved at klikke eller tappe Hjælp → Om. Det er kraften i konsistens.

VS-kode om dialogboks

Dine apper skal definere klare standarder for enhver brugerinteraktion. Når du beder dine brugere om at give input, skal du gøre det på samme måde i hele din dApp. Når en bruger indtaster et produkt-ID flere steder, skal inputfeltet se det samme ud på hvert sted. Brug de samme farver, skrifttyper og inputmetode for at give din dApp et ensartet udseende.

Et andet område, hvor du finder konsistens i GUI-apps, er tastaturgenveje. Du kan næsten altid bruge Ctrl-C til at kopiere fremhævet tekst og Ctrl-V til at indsætte teksten på et nyt sted. Konsekvente tastaturgenveje gør det endnu lettere at lære og bruge ny software.

Standardiserer alle output på samme måde. Fejlmeddelelser og alarmer er de vigtigste områder til standardisering. Brug muligt, når det er muligt, almindelige input- og output-lag, så al input og output bruger det samme sæt funktioner. Hele dApp vil se mere ensartet ud.

Du prøver at opmuntre dine brugere til at fortsætte med at bruge din dApp. En dApp, der præsenterer en konsistent brugergrænseflade, er en, der skaber tillid. Konsistens gør det også lettere for dine brugere at lære at bruge din software, og en applikation, der er let at lære, er en, som brugerne sandsynligvis foretrækker og accepterer.

Fjern tvivl fra blockchain-apps med gennemsigtighed

En af grundene til, at brugere mistroer en applikation, er, at de ikke rigtig forstår det. Brugerne leverer deres data, men er ikke sikre på, hvad der sker derpå. De ved ikke, hvor deres data går, og om de endda stadig er et sted i systemet. Denne følelse af at sætte data i en sort boks kan være endnu stærkere med blockchain dApps.

Efterhånden som blockchain-teknologien bliver mere populær, øges den samlede bevidsthed om dens funktioner. Det betyder, at mange af dine brugere vil vide, at din dApp sender deres data til mange andre computere, potentielt over hele verden. En af de forhindringer, du bliver nødt til at overvinde, er at overbevise dine brugere om, at du beskytter deres følsomme data.

Kommuniker klart, hvilke data din dApp har brug for, hvorfor den har brug for hver type data, og hvad du gør med dem. Du behøver ikke at videregive disse oplysninger, hver gang du beder om data, men de skal være tilgængelig første gang du interagerer med en ny bruger og derefter på efterspørgsel.

Du skal også gøre det let for brugerne at se, hvad de har gjort (og hvad din dApp har gjort med deres data.) At give gennemsigtighed på hvert trin giver brugerne en følelse af tillid.

Gør det nemt for dine brugere at bore ned og få bekræftet handlinger. Dette gennemsigtighedsniveau giver brugerne tilliden til, at din dApp gør, hvad den hævder at gøre, og kan reducere bekymringen for, at din dApp skjuler noget. Afhængig af brugerens bekymring og dine egne designretningslinjer, kan du opbygge gennemsigtighed i hver arbejdsgang eller i efterspørgselsfunktioner for at give strømbrugerne mulighed for at bore efter ønske.

Giv feedback, vejledning og indstil forventninger til dine blockchain-apps

Det næste designmål, du har brug for din blockchain-app, er at give feedback og vejledning og indstille forventninger. Dette mål er en logisk udvidelse af gennemsigtighed. Mens gennemsigtighed gør transaktions- og arbejdsgange detaljer let tilgængelige for brugere, sætter feedback, vejledning og forventning indstilling gennemsigtighed i den normale arbejdsgang. I stedet for bare at give brugerne mulighed for at se, hvad der skete, skal du give dem informativ feedback på hvert vigtigt arbejdsgangstrin.

For eksempel, hvis du er en producent og lige har overført ejerskabet af en ny traktor til en afsender, kan din nye forsyningskæde dApp muligvis give dig en meddelelse “Du har netop overført traktor med serienummer ABC-12345 til Unified Shipping - Transaction number 456778 . ”Selvfølgelig vil du sandsynligvis få flere detaljer til en kapitaloverførsel, men du får ideen. DApp leverede feedback, der i det væsentlige siger ”Hej, godt job. Dette er, hvad du gjorde. ”Informativ feedback er det første skridt i at overbevise brugerne om at stole på din dApp. Feedbacken giver dem forsikringen om, at de bruger softwaren korrekt.

Du kan også udvide feedbackeksemplet til også at informere brugerne om det næste trin. I traktoreksemplet kan din feedbackmeddelelse også indeholde en meddelelse "Vil du frigive titlen nu?" Med mulighed for at klikke på eller trykke på en knap for at gå til næste trin. Sluttopgaver som denne hjælper med at sikre, at brugerne forstår den rigtige arbejdsgang og giver dem indtryk af, at softwaren hjælper dem med at udføre deres job korrekt. Når software gør brugerne mere effektive, går det langt mod opbygning af tillid. Alle elsker software, der får dem til at se godt ud!

Håndter fejl i din blockchain-app med klassen

Face det, der sker fejl. Og nogle gange er disse fejl store. Forhåbentlig har du fundet alle de store fejl i din software under test. (Du testede udtømmende, ikke?) Hvis du gjorde det, vil de fleste af de fejl, du støder på i produktionen, være brugerfejl.

Når du håndterer brugerfejl, kan du prøve at undgå meddelelser, der med subtile ord ”Du har rodet sammen!” Fokuser på at løse situationen og ikke lægge skylden.

Du husker sandsynligvis brugen af ​​din første GPS-enhed i en bil. I de tidlige dage af GPS, hvis du afviger fra den foreslåede rute, hørte du en temmelig streng "Omlægning" -meddelelse. Stemmen kunne lige så godt have sagt ”Du går ikke hen, som jeg fortalte dig. Vent, jeg fortæller dig, hvordan du kommer tilbage til det, jeg fortalte dig i første omgang. ”Fejlmeddelelser skal informere brugerne om, hvad der er sket, men fokusere på, hvad de skal gøre næste. Ja, GPS'en gjorde det, men det var generelt efter en subtil skændelse. Skæld ikke dine brugere.

På den anden side skal du ikke bruge for meget tid på at fokusere på fejl. For vidtgående fejlmeddelelser kan være forvirrende og tage for lang tid at læse. Kom til sagen. Design altid fejlhåndtering fra brugerperspektiv. Giv brugerne alt hvad de har brug for for at reagere hurtigt og beslutsomt på fejl og ikke mere.

Fejlmeddelelser hjælper slutbrugere med at forstå, hvad der sker, og hjælper også supportpersonale, når de fejlfinding. Design dit fejlmeddelelsessystem, så det leverer nødvendige brugermeddelelser såvel som flere ordrette meddelelser efter behov for fejlfinding og undersøgelser.

Husk, at blockchain er uforanderlig, så alle fejl, der gør det til en blok, vil altid være der. Din dApp skal løse brugerproblemer med data, før du gemmer disse data i blockchain. Kunsten at håndtere fejl er at guide brugerne til den rigtige løsning uden at bremse dem. Det kræver opmærksomhed på, hvem dine brugere er, hvordan de bruger din dApp, og hvad de har brug for for at løse et problem. Et af dine designmål skal være at levere fejlhåndtering, der imødekommer dine brugers behov i alle tilfælde.

Designfunktioner i din blockchain-app, der fokuserer på brugerhandlinger, ikke data

Funktioner giver handlingen i dine smarte kontrakter. En måde at se på smarte kontrakter på er at de består af data (navneord) og handlinger (verb). At indramme smarte kontrakter på denne måde gør det lettere at beskrive og designe dem og resulterer generelt i en applikation, der flyder godt fra et brugerperspektiv.

Da alle applikationer findes for at imødekomme nogle brugers krav, er det fornuftigt at designe software i lyset af brugeren. Hvis en bruger ønsker at oprette en ny ordre på det højeste niveau, skal du starte med en funktion, der hedder createNewOrder (). Du kan muligvis ændre ting, mens du forfine dit design, men at starte med et brugerperspektiv hjælper med at bevare ægtheden med softwarens mål. At designe tekniske komponenter, der opfylder brugermål, hjælper også med at undgå at afvige for langt fra høje funktionsmål.

Mange af dagens softwareudviklingsorganisationer er afhængige af metoder, der starter med brugerhistorier. Som udvikler bliver du bedt om at fremstille software, der opfylder et krav, der ligner "Som bruger vil jeg ____." Start din smarte kontrakt med en funktion, der svarer til det, brugerne vil gøre (det vil sige den udfyldte -i tom fra den foregående erklæring), er en god designstrategi til fremstilling af brugervenlig software.

Hver funktion behøver ikke at kortlægge direkte til brugerhandlinger, men dine funktioner på højt niveau skal se ud som om de tilfredsstiller brugerhistorier. Du har altid brug for opgaveorienterede eller dataorienterede funktioner på lavere niveau for at udføre de tekniske trin i enhver opgave. Det er okay, hvis disse funktioner ikke kortlægger direkte til brugerhistorier. Men dine lavere niveau-funktioner skal alle spille dele i de funktioner, som brugerne interagerer med. Som en meget generel tommelfingerregel skal dine offentlige funktioner ligner meget brugerhistoriske svar.

Gem blockchain-appdata baseret på brugerhandlinger, ikke datastrukturer

Brugere interagerer muligvis ikke direkte med data, men du skal stadig forsøge at organisere data baseret på brugerkrav. Dette generelle mål er mere en tommelfingerregel. Brug dette mål, når du oprindeligt designer dine smarte kontraktdatakrav. Du bliver sandsynligvis nødt til at forfine designet og ændre det, men hvis du starter med data, der er kortlagt til brugeranmodninger, hjælper din software med at være tro mod brugerkrav.

Hvis du f.eks. Designer software til at oprette og vedligeholde ordrer, skal du starte med en soliditetsstrukturopgørelse, der definerer en ordre, som en bruger ser den. En ordre kan være en samling af felter, der beskriver den, såsom ordrenummer, ordredato, kundeordre, instruktioner og en liste over ordrelinjer. Ordrelinjer indeholder felter som produktnummer, pris og mængde. Du kan definere dette som en struktur af variabler og en liste over ordrelinjestrukturer.

Uanset de tekniske detaljer om, hvordan du definerer data, er hovedformålet med dette mål at overveje, hvordan brugere vil bruge data, og forsøge at præsentere dataene på den måde. Hvis du stiller ordrer direkte til rådighed for brugerne for at fremme gennemsigtighed i din software, vil du gøre ordrene så let tilgængelige som muligt. Du ønsker ikke at fremme gennemsigtighed og derefter få brugerne til at arbejde hårdt for at finde ud af, hvad dine data betyder. At gøre data nemme at få adgang til og forstå vil skabe endnu større tillid.

Hold din blockchain-app enkel

Du har mange ting at overveje, når du designer en dApp. Selvom fokusering på brugere skal hjælpe med at dirigere designbeslutninger, er tendensen at forsøge at imødekomme ethvert brugerbehov. Hvis du ikke tjekker det, vil dette ønske om at gøre det hele gøre din software alt for kompliceret og vanskelig at bruge. At give brugerne masser af valg lyder som et godt mål i starten, men en overvældet bruger vil ikke lide (eller bruge) din software.

Den almindelige ordsprog “holde det enkelt, dumt” er stadig relevant. Det er en streng påmindelse om, at enkelhed er langt smartere end kompleksitet. Du har muligvis hørt, at "et forvirret sind altid siger nej", men du vil have, at dine brugere skal acceptere og bruge din dApp. Du vil have dem til at finde ud af, at din software gør dem mere effektive og effektive. For at nå disse mål er du nødt til at gøre forståelsen og brugen af ​​din software let og klar.

Enkelheden starter med brugergrænsefladen, men den stopper ikke der. Hvert aspekt af din applikations funktionelle og datadesign skal være så enkel som muligt. Forsøg ikke at gøre for meget. I stedet for skal du bestemme, hvad dine brugere har brug for og ønsker mest, og gør det. Prioriter den funktionalitet, der får din software til at skille sig ud. At holde det enkelt tager mere arbejde, men resulterer ofte i et fokuseret, konsistent produkt, som brugerne vil bruge.

Forvent at blockchain-adgang bliver dyr

Et andet praktisk designmål, der vil hjælpe dig med at undgå omarbejdning efter udvikling er at foregive fra starten af ​​at lagre data på blockchain er dyrt. For i virkeligheden er det det. For mange, der begyndte at programmere langt tilbage, da Y2K var langt fremover, er opbevaring meget billigere i dag, end det plejede at være. De fleste udviklere i dag behøver ikke at bekymre sig om datastørrelse eller hvor de skal opbevares. Blockchain ændrer alt det. I stedet for at have masser af billig og hurtig opbevaring tilgængelig, skal du betale, mens du går.

Dyrt lager er ikke en ny ting i blockchain, men det kan være let at glemme. Hvis du minder dig selv om, at lager tidligt er dyrt, er du mere tilbøjelige til at overveje lagerindstillinger mere grundigt.

Har du for eksempel brug for at gemme byen og oplyse, hvor et produkt vil blive sendt? By og stat er begge afhængige af postnummer (eller postnummer i mere generiske indstillinger.) Du kan gemme postnummeret i forsendelsesadressen og derefter bare slå den tilsvarende by og stat op ved hjælp af en online API under kørsel.

Adskillelse af data, som f.eks. Postnummereksemplet, giver muligvis ikke mening til din ansøgning, men du vil altid drage fordel af at tænke igennem dine datalagringsindstillinger. De dyreste opbevaringsmuligheder er næsten altid et resultat af dårlig designplanlægning. Design ikke blockchain dApps på samme måde som du designer traditionelle databaseapplikationer. De er bare ikke de samme. Design med et andet tankesæt, og du ender med et bedre softwareprodukt.

Hold dig ude af blockchain-app-brugerens måde

En god blockchain-applikation imødekommer de vigtigste brugerbehov på en måde, der hjælper dem med at være mere effektive og effektive. Dog skal dit design ikke kun overveje, hvad din applikation gør, men også, hvad den ikke gør.

Hver applikation har begrænsninger og begrænsninger. Dette designmål fokuserer på en anden ting, som din applikation ikke gør: Den kommer ikke på brugerens måde. Kort sagt, din applikation skal hjælpe brugere og ikke nedsætte dem. Din brugergrænseflade skal hjælpe brugerne med at udføre deres job, og overgangene mellem brugergrænsefladelementerne skal være intuitive og lærerige, når det er nødvendigt.

Nogle gange bliver du nødt til at tage data fra brugere og derefter gemme dem på blockchain. (Du kan huske, at dette er dyrt, ikke?) Fordi du ved, at du vil få brugere til at betale for at gemme data på blockchain, skal du ikke få dem til at vente på det også. Når det er muligt, lad dine brugere gøre noget produktivt, mens funktionen, der håndterer deres data, fungerer i baggrunden. Dette kan være et godt sted i din kode til at bruge begivenheder.

Gør alt hvad du kan for at undgå at blive en hindring for dine brugere. Ingen kan lide at vente. Design med tanke og dit produkt har en meget bedre chance for at imødekomme dine brugers behov.