1. Személyes pénzügy10 Tervezési alapelvek az elosztott blokklánc-alkalmazásokhoz
Ethereum a bábukhoz

Michael Solomon készítette

A Blockchain technológia az adatok kezelésének zavaró, átalakító megközelítése. Ez ígéretet fog hozni radikális változásnak arra, hogy hogyan hajtjuk végre olyan feladatokat, amelyek érzékeny információkat kezelnek megosztott környezetben. Az érzékeny adatokkal kapcsolatos kritikus műveletek történelmileg egy erős központi hatóságot igényeltek, hogy meggyőzzék az adattulajdonosokat arról, hogy bízzanak a környezetben ahhoz, hogy adatkezelésük lehetővé tegye.

Az egyik legnehezebb akadály, amelyet minden blokkláncú dApp-nak át kell küzdenie, a bizalom építése. A felhasználóknak bízniuk kell abban, hogy a blokkláncon futó szoftver szilárd intézkedéseket tartalmaz a biztonság biztosítása és a magánélet védelme érdekében, mielőtt érzékeny személyes és üzleti adatokat szolgáltatnának.

Több alapvető tervezési iránymutatás betartásával nagy előrelépés lehet a bizalom kiépítésében. Ha követi az itt található tíz tervezési célt a blokklánc-alkalmazásokban, akkor ösztönözni fogja a felhasználókat, hogy bízzanak az alkalmazásában eléggé, hogy felhasználhassák, és támaszkodjanak rajta.

Tervezze meg a blokklánc-alkalmazásokat a bizalom érdekében

Az egyik elsődleges ok, amiért a legtöbb szervezet a blokklánc-megoldások felé mozog, az a képessége, hogy megosszák az adatokat egymással nem megbízható csomópontok között. Ha erre gondolsz, ez valóban magas sávot jelent a dApp fejlesztõi számára. A sikeres dApp kifejlesztéséhez meg kell győznie a felhasználókat, hogy bíznak a szoftverükben adataikkal, amikor nagyszámú más csomópontnak küldi el, amelyekben nem bíznak (és ők sem bíznak benne).

A bizalom általában (de nem mindig) tranzitív. (Igen, visszatértél a matematikai osztályhoz. Ha A = B és B = C, akkor A = C. Üdvözlettel várjuk.) Ez a leggyakoribb módszer, amikor emberekként foglalkozunk a bizalommal.

Ha bízik Máriában, és Joe bízik benne, akkor valószínűleg Joe-val minden bizonnyal bízik Mary-ben. Tegyük fel, hogy élelmiszerkritikus vagy. Joe bíz abban, hogy ajánljon jó ételt. Ha azt mondod, hogy igazán szereted Mary őszibarackpitejét, akkor Joe nagyobb valószínűséggel próbálja meg őszibarackpitejét, mivel Joe az ízlésedben bízik az ételben. De ez nem követi a megbízhatatlan környezetet. A blockchain dApp-ok esetén a felhasználók bíznak benne, de nem bíznak másokban a saját blockchain-hálózatában.

Az első tervezési célja egy magas szintű cél, amelyet minden döntésnél szem előtt tartva kell ösztönöznie. A későbbi tervezési célok közül sok támogatja ezt: DApp-ok tervezése a bizalom érdekében. Ez a cél azt jelenti, hogy azt szeretné mérlegelni, hogy a felhasználók mi vágynak, és mi érzi őket úgy, hogy bízhatnak a dApp-ban.

A felhasználóknak tudniuk kell, hogy ügyelni fog az adataikra. A dApp-jának nem szabad semmit elrejtenie, és meg kell könnyítenie a történések ellenőrzését. Világosan közölnie kell a jó és a rossz információkat, és általános jó közérzetet kell adnia. Noha ez a szoftver magas megrendelése, a bizalom kiépítésére van szükség.

A bizalom megtervezésének legfontosabb szempontja annak megértése, hogy kik a felhasználók és mi teszi őket kényelmesebbé. Röviden: ismerje meg felhasználóit. Tudja meg, mit akarnak, és hogyan tudja meggyőzni őket arról, hogy nem pazarolja idejét, vagy kihasználja az ön iránti bizalmát.

A konzisztencia érvényesítése a blokklánc-alkalmazásokban

A zavar elkerülésének egyik legegyszerűbb módja a lehetőségek és az ütköző tapasztalatok korlátozása a dApp-okban. A Microsoft régen megtanulta a konzisztencia hatalmát. Kidolgozták a felhasználókkal való interakció szabványait, felfedezték és meghatározták a felhasználói felület létrehozásának minden szempontját. Ezért érzik magukat a Microsoft alkalmazások egymáshoz hasonlóan.

Ha egy Microsoft-alkalmazást használ, akkor legalább a Microsoft egyéb alkalmazásai általános felhasználói felületét felismeri. (És ha egy ideje használta a Microsoft termékeit, akkor emlékezni fog a Microsoft által okozott hatalmas zavarokra, amikor átalakultak lapkás alapú felhasználói felületre - főleg azért, mert mindenki annyira tetszett a régi Microsoft felületről.)

Például, ha meg akarja találni a futó Windows program aktuális verzióját, akkor szinte mindig rákattinthat vagy megérintheti a Súgót, majd rákattinthat vagy megérintheti a Súgó menü Névjegy menüpontját.

Az alábbi kép a Névjegy menüpontot mutatja a VS kódban. A Névjegy menüpont szinte minden Windows alkalmazásban létezik, és az futtatott program alapvető adatait, beleértve a verziószámot is mutatja. A felhasználói felület következetességének ilyen egyszerű példája megkönnyíti bárki számára az alkalmazásokkal kapcsolatos információk megtalálását anélkül, hogy vadászni kellene.

VS kód Ethereum

Az alábbi kép a Névjegy párbeszédpanelt mutatja a VS kódban. A legtöbb Windows alkalmazás kiadási információit a Súgó → Névjegy elemre kattintással vagy megérintésével találhatja meg. Ez a következetesség hatalma.

VS Code About párbeszédpanel

A dApp-oknak egyértelmű szabványokat kell meghatározniuk minden felhasználói interakcióhoz. Amikor felkéri a felhasználókat, hogy adjanak meg adatot, akkor ezt ugyanúgy tegyék meg a dApp-ban. Amikor a felhasználó több helyre írja be a termékazonosítót, a beviteli mezőnek minden helyszínen azonosnak kell lennie. Ugyanazokat a színeket, betűkészleteket és beviteli módot használva adjon a dApp-nak egységes megjelenést.

Egy másik terület, ahol a GUI-alkalmazásokban következetességet találhat, a billentyűparancsok. Szinte mindig a Ctrl-C segítségével másolhatja a kiemelt szöveget, a Ctrl-V pedig a szöveg új helyre való beillesztéséhez. A következetes billentyűparancsok még egyszerűbbé teszik az új szoftverek megtanulását és használatát.

Ugyanígy szabványosítsa az összes kimenetet. A hibaüzenetek és riasztások a szabványosítás fő területei. Ha lehetséges, használjon általános bemeneti és kimeneti rétegeket, hogy minden bemenet és kimenet ugyanazt a funkciót használja. A teljes dApp következetesebbnek tűnik.

Megpróbálja ösztönözni a felhasználókat, hogy továbbra is használják a dApp-ot. A dApp, amely következetes felhasználói felületet mutat, az építi a bizalmat. A következetesség azt is megkönnyíti a felhasználók számára, hogy megtanulják a szoftver használatát, és egy könnyen megtanulható alkalmazás az, amelyet a felhasználók valószínűleg inkább szeretnének elfogadni és elfogadni.

Távolítsa el a kételyeket a blockchain-alkalmazások átláthatóságától

Az egyik ok, amiért a felhasználók nem bíznak egy alkalmazásban, az az, hogy nem igazán értik azt. A felhasználók megadják adataikat, de nem tudják, mi történik utána. Nem tudják, hová tartják adataikat, és hogy még mindig ott vannak-e a rendszerben. Az az érzés, hogy az adatokat fekete dobozba helyezzük, még erősebb lehet a blockchain dApps esetén.

Ahogy a blockchain technológia egyre népszerűbbé válik, jellemzőinek általános ismerete növekszik. Ez azt jelenti, hogy sok felhasználó tudni fogja, hogy a dApp sok más számítógépre küldi adataikat, potenciálisan az egész világon. Az egyik akadály, amelyet meg kell küzdenie, a felhasználók meggyőzése, hogy védi az érzékeny adataikat.

Világosan közölje, milyen adatokra van szüksége a dApp-ban, miért van szüksége az egyes típusú adatokra, és mit csinál vele. Ezt az információt nem kell minden alkalommal továbbítania, amikor adatot kér, de ennek az első alkalommal elérhetőnek kell lennie, amikor új felhasználóval lép kapcsolatba, és ezt követően igény van.

Azt is meg kell könnyítenie a felhasználók számára, hogy megnézhessék, mit tettek (és mit tettek a dApp az adataikkal.) Az áttekinthetőség biztosítása minden egyes lépés során bizalommal jár a felhasználók számára.

Megkönnyíti a felhasználók számára a műveletek ellenőrzését és lefolytatását. Ez az átláthatósági szint biztosítja a felhasználók számára a bizalmat, hogy a dApp azt csinálja, amit állít, és csökkentheti az aggodalmát, hogy a dApp valamit elrejt. A felhasználói aggodalom szintjétől és a saját tervezési irányelveitől függően beépítheti az átláthatóságot az egyes munkafolyamatokba vagy igény szerinti funkciókba, hogy az energiafelhasználók az igényeik szerint fúrhassanak.

Visszajelzést, útmutatást és elvárásokat meghatározhat a blokklánc-alkalmazásokhoz

A blokklánc-alkalmazás számára a következő tervezési cél, amely visszajelzéseket és útmutatásokat nyújt, valamint az elvárások meghatározását szolgálja. Ez a cél az átláthatóság logikus kiterjesztése. Míg az átláthatóság teszi a tranzakciók és a munkafolyamatok részleteit a felhasználók számára elérhetővé, a visszajelzés, az útmutatások és az elvárások beállítása átláthatóságot tesz a normál munkafolyamatba. Ahelyett, hogy csak a felhasználók láthatnák, mi történt, informatív visszajelzést kell adnia nekik minden jelentős munkafolyamat-lépésnél.

Például, ha Ön gyártó, és az új traktor tulajdonjogát éppen átruházta egy feladóra, az új ellátási lánc dApp üzenetét jelenítheti meg: „Az ABC-12345 sorszámú traktort éppen átruházta a Unified Shipping - 456778 tranzakciós számra. . ”Természetesen valószínűleg további részletekhez jutna a tőkeelemek átruházásához, de megkapod az ötletet. A dApp visszajelzést adott, amely lényegében azt mondja: „Hé, jó munka. Íme, amit tettél. ”Az informatív visszacsatolás az első lépés, hogy meggyőzzük a felhasználókat, hogy bízzanak a dApp-ban. A visszajelzés biztosítja számukra, hogy helyesen használják a szoftvert.

A visszajelzési példát kibővítheti, hogy a felhasználót a következő lépésről is tájékoztassa. A traktor példájában a visszajelző üzenet tartalmazhat egy „Szeretné most kiadni a címet is?” Üzenetet, azzal a lehetőséggel, hogy rákattinthat vagy megérinthet egy gombot a következő lépéshez lépéshez. A feladat befejezése felszólítja ezt a segítséget annak biztosítására, hogy a felhasználók megértsék a megfelelő munkafolyamatot, és azt a benyomást keltik számukra, hogy a szoftver segít nekik a munkájuk helyes elvégzésében. Amikor a szoftver hatékonyabbá teszi a felhasználókat, akkor nagy a hatalom a bizalomépítés felé. Mindenki szereti a szoftvert, amely jól néz ki őket!

Kezelje a hibákat a blokklánc-alkalmazásban az osztálytal

Figyelembe véve, hibák történnek. És néha ezek a hibák nagyok. Remélhetőleg a tesztelés során megtalálta a szoftver összes nagy hibáját. (Teljesen teszteltél, ugye?) Ha igen, akkor a gyártás során felmerült hibák többsége felhasználói hibák lesz.

A felhasználói hibák kezelésekor kerülje el az olyan értesítéseket, amelyek finoman azt mondják: „Összezavarodtál!” A helyzet megoldására összpontosítson, és ne hibáztasson.

Valószínűleg emlékszel arra, hogy az első GPS-készüléket egy autóban használja. A GPS korai napjaiban, ha eltérött a javasolt útvonaltól, meglehetősen szigorú „Útváltás” üzenetet hallott. Lehet, hogy a hang azt mondta: „Nem mész oda, ahogy mondtam. Várj, elmondom neked, hogyan kell visszatérni ahhoz, amit elmondtam neked. ”A hibaüzeneteknek tájékoztatniuk kell a felhasználókat arról, hogy mi történt, de arra kell összpontosítaniuk, hogy mit tegyenek a következőkben. Igen, a GPS ezt tette, de általában finom szidás után. Ne szidja a felhasználókat.

Másrészt, ne töltsön túl sok időt a hibákra koncentrálva. A túlságosan szóbeszédű hibaüzenetek zavaróak lehetnek, és az olvasás túl sokáig tarthat. Térjen a tárgyra. A hibakezelést mindig a felhasználói szempontból tervezze. Adjon meg minden felhasználót, amire gyorsan és határozottan reagálhat a hibákra, és semmi több.

A hibaüzenetek segítenek a végfelhasználóknak megérteni, mi történik, és segítséget nyújtanak a személyzetnek a hibaelhárítás során. Tervezze meg a hibaüzenet-rendszerét úgy, hogy biztosítsa a szükséges felhasználói üzeneteket, valamint szükség esetén sokkal pontosabb üzeneteket a hibaelhárításhoz és a vizsgálatokhoz.

Ne felejtse el, hogy a blokklánc változatlan, tehát minden olyan hibát, amely blokkossá teszi, mindig ott lesznek. A dApp-nak meg kell oldania az adatokkal kapcsolatos felhasználói problémákat, mielőtt ezeket az adatokat a blokkláncba tárolja. A hibák kezelésének trükk az, hogy a felhasználókat a megfelelő megoldáshoz vezessék anélkül, hogy lelassítanák őket. Ehhez figyelmet kell fordítani arra, hogy kik a felhasználók, hogyan használják a dApp-ot, és mire van szükségük a probléma megoldásához. Az egyik tervezési célja annak a hibakezelésnek a biztosítása, amely minden esetben megfelel a felhasználói igényeknek.

A blokklánc-alkalmazásban a felhasználói műveletekre, és nem az adatokra összpontosító tervezési funkciók

A funkciók biztosítják az intelligens szerződések műveleteit. Az intelligens szerződések megnézésének egyik módja az, hogy adatokból (főnevekből) és műveletekből (igék) állnak. Az intelligens szerződések ilyen módon történő megfogalmazása megkönnyíti azok leírását és megtervezését, és általában olyan alkalmazást eredményez, amely a felhasználó szempontjából jól folyik.

Mivel az összes alkalmazás létezik, hogy megfeleljen egyes felhasználók igényeinek, érdemes a szoftvert a felhasználó fényében megtervezni. A legmagasabb szinten, ha a felhasználó új megrendelést akar létrehozni, akkor az a createNewOrder () elnevezésű funkcióval kezdődik. Megváltozhatnak a dolgok, amikor finomítja a tervezést, de a felhasználói szemlélettel kezdve segít megőrizni a szoftver céljainak megfelelő hitelességet. A felhasználói célokat teljesítő műszaki alkatrészek tervezése szintén segít elkerülni a magas szintű funkcionális céloktól való messze eltérést.

A mai szoftverfejlesztő szervezetek nagy része a felhasználói történetekkel kezdődő módszerektől függ. Fejlesztőként felkérést kap arra, hogy készítsen olyan szoftvert, amely teljesíti a következő követelményt, amely így néz ki: „Felhasználóként akarok ____.” - az előző nyilatkozatból üresen), egy jó tervezési stratégia a felhasználóbarát szoftverek készítéséhez.

Minden funkciónak nem kell közvetlenül a felhasználói műveletekhez igazodnia, de a magas szintű funkcióinak úgy kell kinézniük, hogy kielégítik a felhasználói történeteket. Minden feladat műszaki lépéseinek elvégzéséhez mindig alacsonyabb szintű feladat-orientált vagy adat-orientált funkciókra lesz szüksége. Rendben, ha ezek a funkciók nem térképeznek közvetlenül a felhasználói történetekhez. De az alsóbb szintű funkcióinak mindegyikének meg kell játszania azokat a funkciókat, amelyekkel a felhasználók kölcsönhatásba lépnek. Nagyon általános hüvelykujjszabályként a nyilvános funkcióknak nagyon hasonlónak kell lenniük a felhasználói történetre adott válaszoknak.

Tárolja a blockchain alkalmazás adatait a felhasználói műveletek alapján, és nem az adatszerkezetek alapján

Lehet, hogy a felhasználók nem lépnek közvetlenül kapcsolatba az adatokkal, de meg kell próbálnia az adatokat a felhasználói igények alapján rendszerezni. Ez az általános cél inkább a hüvelykujjszabály. Ezt a célt használja az intelligens szerződéses adatszolgáltatási követelmények kezdeti megtervezésekor. Valószínűleg finomítania kell a kialakítást és meg kell változtatnia, de a felhasználói kérésekhez leképezett adatokkal kezdve elősegíti, hogy szoftvere hű maradjon a felhasználói igényeknek.

Például, ha szoftvert tervez megrendelések létrehozására és fenntartására, akkor kezdje el a Solidity struct utasítással, amely meghatározza a megrendelést, ahogy a felhasználó látja. A megrendelés lehet mezőket leíró mezők gyűjteménye, például rendelési szám, megrendelés dátuma, vevői megrendelés, utasítások és a megrendelési sorok listája. A rendelési sorok mezőket tartalmaznak, például termékszám, ár és mennyiség. Ezt meghatározhatja változók struktúrájaként és sorrend sorok felsorolásaként.

Az adatok meghatározásának technikai részleteitől függetlenül e cél fő célja annak mérlegelése, hogy a felhasználók hogyan fogják használni az adatokat, és megpróbálják az adatokat ilyen módon bemutatni. Ha közvetlenül a felhasználók rendelkezésére bocsátja a szoftver átláthatóságának elősegítése érdekében, akkor a megrendeléseket a lehető legkönnyebben elérhetővé teszi. Nem akarja előmozdítani az átláthatóságot, majd arra készteti a felhasználókat, hogy keményen dolgozzanak annak érdekében, hogy kitalálják, mit jelent az Ön adatai. Az adatok egyszerű hozzáférhetősége és megértése még nagyobb bizalmat teremt.

Tartsa egyszerűen a blokklánc-alkalmazását

Sok dologra van szüksége, amelyeket figyelembe kell vennie a dApp tervezésekor. Bár a felhasználókra való összpontosításnak segítenie kell a tervezési döntések közvetlen irányítását, a tendencia az, hogy minden felhasználói igényt kielégítsen. Ha nem hagyja figyelmen kívül, az a vágy, hogy mindent megtegyen, a szoftvert túlságosan összetetté és bonyolultbbá teszi. A felhasználók számára sok választási lehetőség eleinte jó célnak tűnik, ám egy túlterhelteknek a felhasználó nem fog tetszeni (vagy használni) a szoftvert.

Az „egyszerű, hülye” általános célú mondás továbbra is releváns. Szigorú emlékeztető arra, hogy az egyszerűség sokkal okosabb, mint a bonyolult. Lehet, hogy hallotta, hogy „a zavart elme mindig nemmet mond”, de azt akarja, hogy a felhasználók elfogadják és használják a dApp-ot. Azt szeretné, ha rájönnek, hogy szoftvere hatékonyabbá és hatékonyabbá teszi őket. E célok eléréséhez a szoftver megértését és használatát egyszerűvé és érthetővé kell tennie.

Az egyszerűség a felhasználói felülettel kezdődik, de ezzel nem ér véget. Az alkalmazás funkcionális és adattervezésének minden szempontjának a lehető legegyszerűbbnek kell lennie. Ne próbáljon túl sokat tenni. Ehelyett határozza meg, hogy mire van szüksége és mit akar a felhasználó a legjobban, és tegye ezt. Prioritásként kezelje azt a funkcionalitást, amely kiemeli a szoftvert. Az egyszerűség több munkát igényel, de gyakran egy célzott, következetes terméket eredményez, amelyet a felhasználók használnak.

Várható, hogy a blockchain hozzáférés drága

Egy másik praktikus tervezési cél, amely segít elkerülni a fejlesztés utáni átdolgozást, az elejétől azt állítja, hogy az adatok tárolása a blokkláncon drága. Mert a valóságban így van. Sokak számára, akik már akkor kezdtek programozni, amikor a Y2K messze volt a jövőben, a tárolás manapság sokkal olcsóbb, mint régen. Manapság a legtöbb fejlesztőnek nem kell aggódnia az adatméret vagy a tárolási hely miatt. A Blockchain mindent megváltoztat. Most ahelyett, hogy rengeteg olcsó és gyors tárolóhely állna rendelkezésre, fizetnie kell, ahogy megy.

A drága tárolás nem újdonság a blokkláncban, de könnyen elfelejthető. Ha emlékezteti magát, hogy a tárolás már korán drága, akkor valószínűbb, hogy alaposabban átgondolja a tárolási lehetőségeket.

Például tárolnia kell azt a várost és államot, ahol egy terméket szállítanak? A város és az állam egyaránt a irányítószámtól (vagy irányítószámtól általánosabb beállításokban.) Tárolhatja a irányítószámot a szállítási címben, majd csak online API segítségével keresheti meg a megfelelő várost és államot futási idő alatt.

Az adatok szétválasztása, például a irányítószám-példa lehet, hogy nincs értelme az alkalmazásának, ám mindig hasznos lesz, ha átgondolja az adattárolási lehetőségeket. A legdrágább tárolási lehetőségek szinte mindig a rossz tervezés eredményei. Ne tervezzen blokklánc-dApp-okat ugyanúgy, mint a hagyományos adatbázis-alkalmazásokat. Csak nem ugyanazok. Tervezze meg más gondolkodásmódot, és jobb szoftvertermék lesz a végén.

Maradjon távol a blockchain alkalmazás felhasználói útjától

Egy jó blokklánc-alkalmazás kielégíti a legfontosabb felhasználói igényeket oly módon, hogy elősegítsék számukra a hatékonyságot. A tervezésnek azonban nemcsak azt kell figyelembe vennie, hogy mit tesz az alkalmazás, hanem azt is, amit nem.

Minden alkalmazás korlátozásokkal és korlátozásokkal rendelkezik. Ez a tervezési cél egy másik dologra összpontosít, amelyet az alkalmazás nem tesz: Ez nem a felhasználói módon történik. Egyszerűen fogalmazva: az alkalmazásnak segítenie kell a felhasználókat, nem pedig lassítania kell őket. A felhasználói felületnek segítenie kell a felhasználót a munkájuk elvégzésében, és a felhasználói felület elemei közötti átmeneteknek intuitív és oktató jellegűeknek kell lenniük, ha szükséges.

Időnként adatot kell vennie a felhasználóktól, és aztán a blokkláncban kell tárolnia. (Emlékszel, hogy ez drága, ugye?) Mivel tudod, hogy fizetni fogja a felhasználókat az adatok tárolásával a blokkláncon, ne erőltesse őket is. Ha csak lehetséges, hagyja, hogy a felhasználók valami produktív tevékenységet végezzenek, míg az adataikat kezelő funkció a háttérben működik. Lehet, hogy ez egy jó hely a kódban az események felhasználásához.

Tegyen meg mindent, hogy ne akadályozza meg a felhasználókat. Senki sem szereti várni. Tervezzen elgondolkodva, és a termékének sokkal nagyobb esélye lesz arra, hogy kielégítse felhasználói igényeit.