Principios de diseño de Web3

Un marco de reglas UX para aplicaciones distribuidas basadas en Blockchain (parte 1)

Nota: Esta publicación es bastante larga> salta a la hoja de trucos o a las conclusiones

Los desarrolladores de Blockchain están impulsando la gran visión de un futuro descentralizado, pero la experiencia de esa visión a través de las Aplicaciones Distribuidas (Dapps) que estamos creando todavía se parece a un prototipo torpe de la web2.
 
Probablemente sea apropiado que la mayoría de los usuarios que usarían estos Dapps todavía "vivan" en la web2 y ni siquiera hayan oído hablar de las promesas de la Web3 descentralizada.
Incluso si fueran a ver estas nuevas y brillantes aplicaciones, les costaría mucho trabajo comprender la jerga, el propósito y la dinámica de estos Dapps, incluso distinguirlos visualmente de las aplicaciones web normales.

Hay que decir que hay muchas buenas herramientas (Drizzle, MetaMask) que están saliendo y están atacando algunos de estos problemas. Llegaremos allí.

Estos Principios de diseño quieren proponer algunas ideas sobre cómo solucionar esto, con pautas para ayudar a los diseñadores y desarrolladores, de modo que todos podamos hacer que ese futuro brillante sea más accesible y cercano para todos.

Diseño Web3 vs Diseño Blockchain

Otras personas han escrito sobre "Blockchain Design" [1], al tiempo que presentan soluciones relacionadas con la experiencia del usuario front-end de las aplicaciones descentralizadas (Dapps).

Aunque Sarah Mills, diseñadora principal de Consensys, el artículo es una lectura inspiradora y es claramente la voz principal que llama a los diseñadores en el espacio Blockchain, creo que la redacción "Diseño Blockchain" es más apropiada para definir las propiedades y sus interacciones. , de la construcción Blockchain en sí: cosas como el algoritmo de consenso, la base de suministro, las recompensas de bloque, la integridad de turing, el costo de computación / "gas", los mecanismos de gobierno dentro o fuera de la cadena y muchos más.
 
En este artículo me referiré en cambio al "Diseño Web3", que indica principalmente los principios que deben aplicarse a la creación de partes enfrentadas por el usuario de aplicaciones descentralizadas.

Es tentador usar la palabra "Blockchain" en el título, pero eso sería clickbait

Por qué los principios de diseño de la Web 3

Hoy en día, un usuario puede interactuar con un Smart Contract implementado en Blockchain de varias maneras: directamente a través de la línea de comandos, a través de las interfaces de su billetera digital o navegador Dapp, o tal vez a través de la interfaz más rica que el desarrollador de Smart Contract tiene o se desarrollará.
Es obvio que el camino hacia la adopción masiva de Dapps pasa por este último: proporciona una interfaz de usuario rica unificada con la experiencia de tratar con una aplicación distribuida basada en Blockchain.

Hoy como desarrolladores estamos, justamente, muy ocupados construyendo la infraestructura de Blockchain y los Smart Contracts de nuestros proyectos, por lo que es obvio que no muchos Dapps tienen actualmente un front-end utilizable o, si lo tienen, seguro para el contenido, son principalmente indistinguibles de cualquier otra aplicación web.

Sin embargo, los Dapps son fundamentalmente diferentes de las aplicaciones web o móviles normales porque se basan y deben transmitir con fuerza los poderosos principios habilitados por Blockchain: descentralización, transparencia, falta de confianza, inmutabilidad, censurabilidad, etc.
Estas propiedades de Blockchain, y por reflejo de los Dapps de front-end, son lo que estos Principios de diseño codifican en herramientas utilizables.

El objetivo es que, una vez aplicado correctamente, un usuario que aterriza en un Dapp puede saber de inmediato que está interactuando con uno y, lo que es más importante, tiene acceso a las poderosas propiedades de Blockchain y, por lo tanto, sabe que puede confiar en cada interacción con la aplicación.

Variables a considerar para comprender los principios

  • El objetivo principal en mente es un usuario no técnico, aunque algunos principios también están orientados a usuarios más inteligentes.
  • no todos los Dapps necesitan todos los principios
  • Las soluciones que se muestran en los ejemplos son solo algunas ideas iniciales para comenzar la conversación
  • algunos principios podrían ser implementados de diferentes maneras por cada desarrollador de Dapp
  • Algunos principios de web3 sugieren la necesidad de una herramienta, servicio o biblioteca externa en lugar de imaginar que cada desarrollador implementaría su solución (más sobre esto en los próximos pasos)
  • la mayoría, si no todos, los Principios de diseño web3 se beneficiarían de estar codificados en una biblioteca amigable para desarrolladores como Bootstrap (más sobre esto en los próximos pasos)

Si está interesado en esto, pase a la sección de "próximos pasos" al final para ver cómo podemos trabajar juntos.

Enfoque de diseño

El diseño también se trata de anticipar problemas y ofrecer soluciones. En este caso, intenté "proyectar" (una mejor palabra en mi opinión por su significado etimológico de "lanzarse hacia adelante" en el futuro) las preguntas que un usuario podría tener al interactuar con un Dapp.

Preguntas como:

  • ¿Es seguro hacer esto (action_dapp_asks_me_to_do)?
  • ¿correrá riesgo el dinero si me equivoco?
  • He oído que se supone que la criptografía es más privada ... ¿qué sucede con los datos que envío? ¿Dónde se almacenará? ¿Puedo ser identificado?
  • ¿Quién verá los datos que ingreso? ¿Dónde se está ejecutando el código?
  • ¿Qué pasará después de hacer esto (acción)?
  • ¿Cómo se supone que debo hacer (crypto_action_here)?
  • ¿Qué significa esto (weird_crypto_word)?
  • Supuestamente se puede confiar en Blockchain, pero ¿cómo puedo saber qué datos se pueden confiar en esta aplicación?
  • ¿Qué datos provienen de Blockchain?
  • ¿Cómo puedo verificar que los datos estén realmente almacenados en Blockchain?
    etc.

Los Principios de diseño proporcionan herramientas para que los desarrolladores respondan a estas y más preguntas que los usuarios puedan tener.

Principios de diseño de Web 3 (índice / hoja de referencia)

Esta publicación es bastante larga, por lo que puede usar esta hoja de referencia para tener una visión rápida de los principios y saltar a los que le interesan más.

//// TTT: Confianza a través de principios de diseño de transparencia

1 - (Lectura de datos) Transparencia de procedencia de datos

➤ Aclare qué datos provienen de Blockchain y cuáles no
➤ Aclarar la dirección de los contratos
➤ Enlace todos los datos de Blockchain a exploradores independientes de Blockchain
➤ Aclarar qué datos provienen de oráculos (∞enlace> 5.Transparencia de código)
 - Cómo> ejemplos

2 - (Escritura de datos) Transparencia de transacciones

- Tipos de transacciones (transferencias de valor, llamadas a funciones, generación de contratos)
➤ [Permanencia] aclara acciones que son irreversibles
Value [Valor] aclara acciones que involucran dinero o valor
➤ [Privacidad] aclara acciones que podrían conducir a la identificación del usuario
➤ [Fábrica] aclara acciones que generan nuevos contratos a nombre del usuario
- Directrices para todas las transacciones:
- ➤ aclarar y confirmar de antemano el nuevo Estado futuro
 - ➤ muestra los datos que se están utilizando para una transacción en un formato legible por humanos y en la forma en que Smart Contract lo requiere (∞enlace 5.Transparencia de código)
- ➤ aclara los valores sugeridos para el precio del gas y cómo sobrescribir el Tx (∞enlace 9. Precio del gas y reversiones de transacciones)
 - ➤ gestionar el tiempo de espera de la transacción (∞link> 6.Time / Wait Management)
 - ➤ posiblemente, aclare qué acciones NO son transacciones y, por lo tanto, son seguras
 - Cómo> ejemplos

3 - (Datos introducidos) Transparencia de eventos de contrato inteligente

➤ aclarar y hacer accesibles al usuario final todos los eventos, incluso si son solo para fines de desarrollador
Relevance aplicar relevancia: mostrar mensajes de interrupción solo para información relevante para el usuario actual
➤ permitir a los usuarios suscribirse, cancelar la suscripción o silenciar temporalmente ciertos eventos
 - Cómo> ejemplos

4 - (Historial) Transparencia y accesibilidad del historial de interacción del usuario

➤ proporcionar un historial de todas las transacciones desde una dirección determinada
➤ aclarar dónde se almacena el historial (local o servidor) (∞enlace 5.Transparencia de código)
➤ proporciona herramientas para navegar, buscar, exportar y eliminar el caché del historial
 - Cómo> ejemplos

5 - (Código y Medio Ambiente) Transparencia del Código

➤ aclarar qué Blockchain se está utilizando
➤ aclarar la dirección de los Smart Contract (s) utilizados en las operaciones de lectura / escritura
➤ aclarar qué código es de código abierto (y dónde encontrarlo)
➤ aclarar dónde se está ejecutando el código (servidor local frente a servidor remoto)
➤ aclarar el proveedor web3 / nodo Blockchain (nodo local, nodo controlado por Dapp, MetaMask, Infura, etc.)
➤ aclarar si el Dapp se ejecuta en MainNet o TestNet
➤ aclarar qué datos provienen de oráculos o ha sido influenciado por oráculos (∞link> 1.Transparency of Data Provenance)
➤ permitir la ejecución de código DIY: permite a los usuarios avanzados ver el código que se está ejecutando y ejecutarlo automáticamente a través de la línea de comandos
➤ aclarar las entradas requeridas por los contratos inteligentes
 - Cómo> ejemplos

//// Principios generales de Web3 UX

6 - Gestión de tiempo / espera

➤ (Administre las expectativas del usuario) aclare los tiempos específicos de Blockchain y administre la espera del usuario en varias fases
➤ (Gestionar el tiempo de espera) Mostrar indicadores de vida durante el tiempo de espera
 - Cómo> ejemplos

7 - Formatos de hashes legibles para humanos

➤ muestra una versión compacta de los hashes pero siempre muestra las partes inicial y final

➤ siempre antepone el "0x" para indicar que es un hash
➤ permitir a los usuarios expandir la dirección completa / hash
➤ permitir a los usuarios copiarlo fácilmente
➤ siempre que sea posible, use shorthands como títulos y las direcciones abreviadas como subtítulos
➤ si es posible, permita al usuario asociar fácilmente un nombre o texto legible por humanos personalizado a las direcciones y hashes
Possible si es posible asociar alguna forma de representación visual determinista del hash (es decir, Identicons, blockies et al) junto con la dirección

8 - Modo de Novato Permanente

➤ entretejer información educativa con interacción normal
➤ proporciona 2 o más niveles de contenido educativo: conceptos básicos de Blockchain y jerga específica de Dapp
minimizar y aumentar progresivamente la cantidad de cosas y conceptos nuevos que el usuario necesita aprender
➤ si es posible o relevante, acelerar el aprendizaje proporcionando la "interpretación del experto"
➤ no pierdas contexto
 - Cómo> ejemplos

9 - Precio del gas y reversiones de transacciones

➤ aclarar cuál es el precio de Gas y Gas (al igual que con cualquier otra jerga ∞enlace 8. Modo de novato)
➤ sugerir rangos de precios de la gasolina y aclarar aproximaciones de tiempo para los límites superior e inferior
➤ posiblemente muestre valores de gas convertidos también a FIAT
➤ permitir reversiones de transacciones

//// DDP: Principios de diseño de descentralización

10 - Sentido de comunidad

➤ aclarar cuántos otros miembros hay en la comunidad
➤ aclarar quiénes son los otros miembros (elija las categorías apropiadas)
➤ aclarar la composición de la comunidad (es decir, subgrupos y su poder sobre el proyecto)
compartir la misión mayor del proyecto (si existe) y cómo la participación del usuario contribuye a su logro
 - Cómo> ejemplos

11 - Principios de diseño futuro para investigar (Parte 2)

➤ Identidades y reputación
➤ Gobierno
➤ Carteras
➤ Intercambios
➤ Mecánica de ICO y venta de tokens
➤ Mecánica de fichas

Próximos pasos

TTT: Confianza a través de principios de diseño de transparencia

Postulados de Web3:

- No es transparente si no sabes dónde y cómo mirar
- ¡Si no es transparente, no se puede confiar!

Todos en este espacio, y su madre, hablan acerca de cómo Blockchain es "desconfiado" y "transparente".
Explicar por qué estos dos supuestos son solo parcialmente ciertos tomaría una publicación más larga y haría que este se equivoque.
Es (casi) ciertamente cierto a nivel programático, el software verifica los datos, pero esos dos supuestos se desmoronan cuando los confronta con la experiencia real del usuario final.

Además del hecho de que muchos proyectos criptográficos o front-end de Dapp rara vez le muestran al usuario las direcciones de Smart-Contract con las que está interactuando o de dónde provienen los datos, actualmente es desalentador o imposible para un usuario no técnico comprender la información y el funcionamiento de exploradores independientes de Blockchain como Etherscan.
Lo único que el usuario puede controlar parcialmente hoy en día es cuando las billeteras intermedias registran el hash de la transacción que se puede verificar en los exploradores de Blockchain antes mencionados.

Por lo tanto, si un usuario, especialmente uno no técnico, no puede reconocer mirando la interfaz de usuario si un Dapp es realmente un Dapp o una aplicación web normal, ni puede verificar si el contenido que está viendo o sus interacciones con él en realidad están relacionados con una Blockchain, entonces no se le otorga la falta de confianza y transparencia que se supone que la Blockchain debe entregar.

Los principios de diseño de Web3 en esta categoría (TTT) proponen un enfoque de transparencia radical que permitiría a cualquier usuario front-end de Dapp, incluso a los no técnicos, ser plenamente conscientes de la procedencia de los datos, comprender las implicaciones de las transacciones antes, durante y después de su ejecución, y, en última instancia, poder confiar en el código y el servicio disponibles.

volver a la hoja de trucos

1 - (Lectura de datos) Transparencia de procedencia de datos

Un usuario debe poder decir, posiblemente solo mirando la página, que cierto punto de datos o contenido está realmente almacenado en Blockchain. No es fácil para el usuario dejar que adivinen y no es suficiente para que asuman que "todos" los datos vistos se almacenan en Blockchain.
Este requisito puede sonar complicado para Dapps con uso intensivo de datos, como los intercambios distribuidos, pero hay algunas soluciones que se presentarán en los ejemplos.

Principios

El front-end de Dapp debería:

➤ aclarar qué datos provienen de Blockchain y cuáles no
➤ aclarar la dirección del contrato (s)
➤ enlace todos los datos de Blockchain a exploradores independientes de Blockchain
➤ aclarar qué datos provienen de oráculos (∞enlace> 5.Transparencia de código)

Cómo> Ejemplos

  • use css para cambiar el color / fuente / forma para distinguir claramente los datos de Blockchain Obviamente, trate de ser coherente en su proyecto y use siempre el mismo "color de Blockchain"
Procedencia de datos desactivadaData Provenance ON: colorea los datos que provienen de un contrato específico
  • use referencias expandibles:
    Al pasar el cursor sobre un punto de datos de Blockchain o hacer clic en él, puede proporcionar información sobre herramientas expandida contextual con más información sobre el punto de datos que debería aclarar en qué parte de Blockchain, en qué contratos se pueden encontrar los datos.
ejemplo de una referencia contextual expansible
  • gestionar conflictos de estilo con íconos de enlace
    Si un punto de datos es tanto un "punto de datos de Blockchain" como un enlace a alguna parte de su dapp, hay dos formas de resolver la doble acción:
    1- agregue un ícono de enlace, un ícono que sigue cualquier "punto de datos de Blockchain" que brinde la funcionalidad de referencia expandible mientras deja intacto el funcionamiento normal del enlace.
    2- abra la referencia expandible e inserte un enlace secundario dentro de ella (pero considere que esto crea más fricción porque le está pidiendo al usuario que realice 2 acciones en lugar de una).
Ejemplo de un icono de enlace que abre la referencia contextual. Esto es para agregar la funcionalidad chainView a un enlace que va a algún lugar en su Dapp
  • use un modo de "vista en cadena" y / o panel lateral
    Para las interfaces con uso intensivo de datos, como los intercambios descentralizados o las vistas del mercado, seguir las sugerencias anteriores probablemente significaría diseñar la mayoría de la interfaz, probablemente agregando más confusión. Para resolver esto, puede imaginar un botón de "vista en cadena" que, al pasar el mouse sobre él o al hacer clic en él, estilice temporalmente los datos. Es como poner un filtro sobre la página, un filtro que ayuda al usuario a ver qué datos son un punto de datos Blockchain.
     
    Ampliando esta idea, la "vista en cadena" también podría ser un panel lateral donde se podrían alojar muchas de las funcionalidades descritas en los Principios de diseño de Web3. En este caso, el panel Chain-View podría tener la opción mencionada para activar o desactivar la visibilidad de los puntos de datos de Blockchain. En los siguientes ejemplos veremos muchos más usos del panel Vista en cadena.
Panel lateral de vista de cadena con la opción de procedencia de datos abierta
  • Muestra claramente qué enlaces abren el explorador externo de Blockchain
    Si un enlace va a enviar al usuario a otra página, es mejor controlar el flujo del usuario en la página:
    1 - agregar un botón de aclaración que indique lo que va a suceder: es decir, "abrir en Etherscan"
    2: agregue un ícono de enlace para exploradores de bloques independientes y úselo constantemente en su interfaz de usuario

volver a la hoja de trucos

2 - (Escritura de datos) Transparencia de transacciones

El usuario debe ser consciente de que los datos se escribirán en Blockchain, y especialmente cuando implica el intercambio de un valor económico (criptomonedas o tokens). Aunque las billeteras advierten al usuario acerca de esta intención, el Dapp debe aclarar esto antes de lanzar la solicitud de transacción a la billetera.

Tipos de transacciones

Existen diferentes tipos de transacciones que pueden ocurrir al interactuar con Blockchain y cada una tiene diferentes consecuencias.
El usuario debe poder diferenciar entre ellos a través de la información proporcionada por la interfaz de usuario en diferentes fases, incluso antes de iniciar la transacción.

2.1 - Transferencias de valor
 - 2.1.1 - ETH
 - 2.1.2 - Fichas
 2.2 - Llamadas de función
 - 2.2.1 - métodos de contrato con implicaciones de valor
 - 2.2.2 - métodos de contrato sin transferencias de valor
 2.3 - Fábricas: funciones generadoras de contratos

Datos de transacción y costos

Las transacciones generalmente tienen una "carga útil", algunos datos adjuntos, por ejemplo, pasados ​​a los métodos de contrato, y que generalmente se usan para escribir o calcular qué escribir en Blockchain.

Además, escribir datos en Blockchain generalmente tiene un costo, una "tarifa de gas" para pagar la transacción.
El usuario debe comprender estas dos informaciones y conocer su contenido.

Principios

El front-end de Dapp debería:

➤ (Permanencia) aclara acciones que son irreversibles (todos escriben Txs)

➤ (Valor) aclara acciones que involucran dinero o valor

➤ (Privacidad) aclara acciones que podrían conducir a la identificación del usuario
Este es uno de los principios más difíciles de implementar, ya que potencialmente cualquier escritura de datos puede ayudar a identificar al usuario (hasta ZTKSnarks), y como desarrolladores de contratos inteligentes y web3 podemos desconocer la sofisticación actual y futura de las herramientas forenses, que también son Por lo general, soluciones de código cerrado. Solo tenga en cuenta este principio si la privacidad es una característica principal de su Dapp, y úsela para guiar las opciones de diseño de cuándo aclarar qué acciones son riesgos potenciales para los usuarios que buscan privacidad.

➤ (Fábrica) aclara acciones que generan nuevos contratos en nombre del usuario
Este principio debe aplicarse solo a Dapps que ayudan al usuario a crear contratos con su dirección como creador del mensaje. Aplique esto especialmente si está en MainNet.

Pautas para todas las transacciones:

➤ aclarar y confirmar de antemano el nuevo Estado futuro
muestra los datos que se están utilizando para una transacción en un formato legible por humanos y en la forma en que Smart Contract lo requiere (∞enlace 5.Transparencia de Código)
➤ aclarar los valores sugeridos para el precio del gas y cómo sobrescribir el Tx (∞enlace 9. Reversiones de precio y transacción de gas)
➤ gestionar el tiempo de espera de la transacción (∞link> 6.Time / Wait Management)
➤ Después de registrar la transacción, muestre un resumen relevante de la transacción al usuario y cómo puede acceder al historial (∞enlace 4. Historial de interacción del usuario)
➤ posiblemente, aclare qué acciones NO son transacciones y, por lo tanto, son seguras

Cómo> ejemplos

  • use CSS para indicar todas las acciones irreversibles
    tal vez use un color de advertencia / resaltado como el rojo
  • agregue pequeñas advertencias escritas junto con el botón
    es decir: atención acción irreversible por delante> aprender más
  • usar confirmación doble:
    abra una ventana emergente o una tostada, después de que el usuario presione el botón y antes de llamar a la billetera / MetaMask, donde puede informar al usuario de todas las implicaciones y solicitar una confirmación.
    También ofrezca al usuario:
     - cancelar la acción
     - nunca vuelva a mostrar estas ventanas emergentes (porque es una usuaria experta) y, al hacerlo, dígale al usuario que eventualmente podría reactivar la función en el panel lateral de Chain-View.
  • aclarar y anticipar futuros pasos esperados
    ya sea con pequeñas descripciones escritas, subtítulos de etiquetas o con flujos de asistente que tienen más pasos para llevar a cabo una acción.
    En el caso de los magos:
     - muestre claramente al usuario el número y el título de los siguientes pasos
     - permita que el usuario inspeccione las pantallas futuras para comprender qué está sucediendo y qué sucederá (happenenlace 8. Modo novato), aunque también debe atenuar la funcionalidad para no confundir el hecho de que puede tener un adelanto vista previa con la acción real.
  • Agregar opciones al panel lateral de vista de cadena
    El panel lateral podría ser el lugar para muchas de estas advertencias, además de ofrecer un inspector de las transacciones, definiendo
     - el tipo de transacción
     - los datos asociados con la transacción
     - los costos de gas
     - toda otra información relevante (∞enlace 5.Transparencia de código)

volver a la hoja de trucos

3 - (Datos introducidos) Transparencia de eventos de contrato inteligente

Los eventos son las notificaciones de la era de Web3

(Ethereum) Los contratos inteligentes pueden emitir eventos que se utilizan tanto para almacenar registros en Blockchain como para informar de manera reactiva a los front-end de Dapps a través de Javascript que algo ha sucedido.

Es importante entender que los eventos
 - puede tener parámetros, información agregada a los registros
 - se almacenan permanentemente en Blockchain y, por lo tanto, se pueden buscar
 
Los desarrolladores suelen utilizar los eventos para varias cosas, como la señalización de que se ha cumplido una determinada condición o cuando se ha producido una determinada acción: un nuevo usuario se ha convertido en titular de un token, se ha realizado un depósito o se han recibido datos de un Oráculo, y muchos más.

El hecho de que se puedan buscar eventos es inmensamente útil para registrar el comportamiento de un Dapp específico y comprender qué sucedió y cuándo, a través de los miles o millones de bloques desde la creación del Dapp.

Para comprender mejor por qué esto es tan importante, permíteme contarte rápidamente una historia personal:
Cuando el Dao fue pirateado en 2016, tuve la oportunidad de colaborar con el grupo para resolver una parte del gran problema: entender a quién se le debía qué cantidad de Ether de la cuenta ExtraBalance.
Cuando los usuarios compraron Dao Tokens durante el ICO, de acuerdo con el programa de tarifas, entrarían diferentes cantidades de éter en el ExtraBalance.
Dos de los solucionadores de problemas del grupo, Nick Johnson y Bokky Poobah, usaron el evento "CreatedToken" para rastrear todas las transacciones relacionadas con el DAO ICO, mientras yo seguía la "ruta difícil" imaginando una situación en la que los eventos no se habían implementado y desarrollado un analizador determinista para Blockchain, una herramienta forense muy útil en caso de contratos inteligentes maliciosos o mal planificados. También hice esto porque no había un evento como "ReceivedByExtraBalance" para identificar esa parte de la transacción.
Aquí es donde se pone interesante: mientras que sus guiones tomarían algunas horas, los míos tomarían alrededor de un día o más; eso se debe a que tuve que realizar (volver a ejecutar) cada transacción en Blockchain, mientras que ya tenían acceso a las transacciones (casi) "correctas" gracias a los registros de Eventos.
Aun así, nos tomó a los tres aproximadamente dos meses para conciliar los números y devolver todo el saldo a los propietarios originales.

¿Qué tiene esto que ver con los Principios de diseño de Web3?
Los desarrolladores utilizan los eventos de forma arbitraria: pueden elegir poner o no un evento para indicar algo importante sobre su Dapp. Dar acceso al usuario front-end a los Eventos en el Smart Contract es ser transparente acerca de estas opciones.

Un alto grado de Eventos útiles puede ser un signo de un Smart Contract y Dapp transparente, uno que no tenga miedo de hacerle saber lo que hace internamente. Si bien los eventos pequeños o nulos pueden ser un signo de un contrato inteligente descuidado o incluso malicioso.

Al igual que en la historia DAO anterior, la falta de eventos obligaría a un usuario a desarrollar sus propios analizadores determinísticos de Blockchain para comprender lo que sucede dentro, una tarea prácticamente imposible también porque necesitaría un nodo Archival.

Además, los eventos son útiles para que los desarrolladores creen varios tipos de análisis, notificaciones y fuentes de datos reactivos, incluso independientemente del propietario / creador de Smart Contract. Posiblemente, este poder también debería ser accesible para el usuario front-end sin necesidad de codificar.
 
Postulados de Web3:

- no es transparencia si requiere un esfuerzo enorme para encontrar, ver y verificar los datos
 - No es transparencia si el 99% de los usuarios se disuade de querer mirar [2]

Principios

un front-end Dapp debería:

➤ aclarar y hacer accesibles al usuario final todos los eventos, incluso si son solo para fines de desarrollador

Relevance aplicar relevancia: muestra mensajes de interrupción solo para información relevante para el usuario actual, pero aún permite al usuario inspeccionar todos los eventos en una interfaz separada

➤ permitir al usuario suscribirse, cancelar la suscripción o silenciar temporalmente ciertos eventos

Los eventos son específicos del contrato, por lo que estas son sugerencias simples de posibles implementaciones.
Además, estas ideas se resuelven mejor con una herramienta externa, un servicio, un complemento o una biblioteca, que no requiere que los desarrolladores front-end de Dapp implementen todas estas características "no centrales" en su Dapp.

Cómo> ejemplos

  • tener un centro de notificaciones accesible para el usuario, esta es probablemente una sección en el panel lateral "Vista en cadena"
  • usar tostadas para mensajes importantes
  • cree filtros para seleccionar / deseleccionar solo ciertos eventos o personalizar notificaciones basadas solo en ciertos parámetros.
     Algunos filtros pueden ser:
     - si contiene Ether / tokens
     - basado en la dirección (la mía / el usuario u otra dirección o direcciones)
     - entre timeX y timeY, blockX y blockY
    etc.

volver a la hoja de trucos

4 - (Historial) Historial de interacción con el usuario accesible y transparente

En un futuro en el que interactuamos con cientos o miles de Dapps, tokens y probablemente cadenas, tiene sentido que el usuario tenga un historial claro registrado de sus interacciones con cada uno para referencia futura.
 
Las billeteras ya almacenan el historial de todas las transacciones, lo cual es un comienzo, pero es solo para una cuenta a la vez y, por lo tanto, puede ser difícil averiguar si interactúas con varias de ellas.
Además, las billeteras seguirían siendo difíciles a menos que se construyan características adicionales, para filtrar solo las que pertenecen a un Dapp específico, por ejemplo.

Sin duda, es fácil de usar para un Dapp que lo ayude a recordar cada interacción que haya tenido con él, al igual que puede volver al "historial de compras" en cualquier aplicación normal.

Es aún más importante para los intercambios distribuidos y Dapps que podrían generar cientos o miles de transacciones para cada usuario.

Principios

Un front-end de Dapp debería:

➤ proporcionar un historial de todas las transacciones desde una dirección determinada
Permitir al usuario inspeccionar todas las interacciones que se hayan realizado con el Smart Contract, probablemente principalmente las del tipo 2, que escriben en Blockchain y, por lo tanto, modifican el estado

➤ aclarar dónde se almacena el historial
Proporcionar un historial relativo a un usuario determinado probablemente signifique registrar sus Transaction Hashes en un DB, ya sea en un servidor remoto o mejor en el indexDB local del usuario. Esto es, por supuesto, un riesgo potencial de privacidad, así que tome nota de los principios de privacidad (∞enlace 2.Transparencia de transacciones) y los principios de transparencia del código (∞enlace 5.Transparencia de código) para aclarar al usuario dónde se almacenan estos datos.

➤ dar herramientas para navegar, buscar, exportar y eliminar el caché del historial

Cómo> ejemplos

  • similar al Centro de notificaciones de eventos, tiene una pestaña de Historial de usuario o una página dedicada, probablemente dentro del panel lateral de Vista en cadena
  • Permitir filtrar por diferentes tipos de transacciones (valor-eth, valor-tokens, llamadas a funciones, generar contratos si es pertinente)
  • permitir filtrar por fecha, desde el principio o entre fechas
  • Adición amigable opcional para el usuario: permite a los usuarios agregar un campo de nota que no sea de cadena a la transacción, como un simple recordatorio si desean simplemente tener un texto sin formato legible y con capacidad de búsqueda.
  • opcional: tenga un campo de búsqueda en caso de que haya cientos de interacciones y si es relevante para su Dapp
    es decir: los intercambios descentralizados pueden querer agregar una función para permitir al usuario buscar transacciones relacionadas solo con tokens específicos
  • exportar: permite al usuario exportar opcionalmente los datos en csv y explorarlos a través de otros medios, nuevamente, especialmente apropiado en el caso de grandes conjuntos de datos
  • eliminar: permite al usuario eliminar el historial de la memoria caché local, pero por supuesto aclara que el historial real de transacciones no se elimina ni de su billetera ni de Blockchain
  • importar: tiene sentido agregar una opción de importación solo si el Dapp permite al usuario agregar notas personalizadas a cada transacción; de lo contrario, la información se puede reconstruir simplemente desde Blockchain

volver a la hoja de trucos

5 - (Código y Medio Ambiente) Transparencia del Código

Si se puede confiar en un Dapp también significa que se puede confiar en el código que se está ejecutando.
Para ser confiable, Dapps debe ser lo más transparente posible sobre todos los aspectos de su código.

Web3 Postulados

- para que un Dapp sea confiable, su código debe ser confiable
 - para que el código sea algo confiable, debe ser transparente, ejecutable de forma independiente y verificable

Principios

un front-end Dapp debería:

➤ Aclarar qué Blockchain se está utilizando
parece obvio, pero en un escenario con Dapps en proliferación, muchos pueden ser independientes de Blockchain o ejecutar diferentes versiones en diferentes cadenas. También con Plasma, Polkadot, Cosmos y otras soluciones de escalado, es posible que un Dapp esté rastreando transacciones en su propia subcadena anidada en el fondo de un árbol de otras cadenas de Plasma u otras paracaídas o Zonas o Hubs Cosmos. El usuario debe saber dónde se escriben sus datos y, por lo tanto, conocer las variables técnicas (seguridad, velocidad, etc.) y dónde verificar los datos de forma independiente.

➤ Aclare la dirección de los contratos inteligentes que se utilizan para operaciones de lectura y escritura
y enlace a exploradores independientes de Blockchain (∞enlace 1.Transparencia de procedencia de datos).

➤ Aclare qué código es de código abierto y dónde encontrarlo.

➤ Aclare dónde se está ejecutando el código (servidor local frente a servidor remoto)
Este podría ser uno de los más difíciles y engorrosos de implementar a nivel visual, pero si las partes necesitan ejecutarse en un servidor, tenga al menos una página que explique qué partes y por qué, y señale desde cualquier parte relevante de la interfaz de usuario.
Si se ha implementado el modo "vista en cadena" que se ve en los ejemplos de los primeros principios (∞enlace 1.Transparencia de la procedencia de los datos), ese sería un buen lugar para agregar estas otras vistas.
 
➤ Aclare el proveedor web3 / nodo Blockchain (nodo local, nodo controlado por Dapp, Infura, MetaMask ?, u otro nodo)
¿Por qué? Debido a que los nodos instrumentados pueden registrar datos, como etherscan, y potencialmente podrían ser una fuente de riesgos de privacidad para el usuario.
 
- Si es posible o relevante, permita que los usuarios cambien a su propio nodo
Aunque esto ya se ha ocupado de proveedores como MetaMask, este principio se aplica en caso de que su Dapp web3, por alguna razón, transmita transacciones a nodos específicos. Además, las transacciones que pasan por su propio nodo privado pueden ejecutarse más rápidamente porque evitan las colas potenciales de los nodos públicos, especialmente durante eventos de alta demanda como crowdsales.

➤ Aclare si el Dapp se está ejecutando en MainNet o en TestNet
Aunque el proveedor de web3 se encarga de esto, especialmente asegúrese de que el usuario entienda que las acciones se ejecutan en MainNet si es el caso (recurra también a los otros principios en el enlace 2) Transparencia de las transacciones)

➤ Aclare qué datos leídos de la cadena provienen de los oráculos o han sido influenciados por los oráculos

Adiciones fáciles de usar
➤ Permitir la ejecución de código DIY
Permitir a los usuarios más avanzados ver la llamada a la función de transacción antes de enviarla para que puedan verificarla y reproducir la acción por sí mismos a través de la línea de comandos.
Esto puede parecer una exageración porque el front-end de Dapp está ahí para simplificar al usuario y ocultar ciertos asuntos técnicos, pero un usuario escéptico / paranoico querría verificar incluso transacciones individuales: si Blockchain es como una base de datos distribuida, entonces un usuario debería ser capaz de realizar las operaciones de escritura de forma independiente y el Dapp aún debería funcionar.
En una actitud de transparencia radical hacia el código, un Dapp que permite esta función está indicando "No confíes". Verificar "https://blog.wizsec.jp/2018/02/kleiman-v-craig-wright-bitcoins.html?m=1

Una versión mejorada de Data Provenance donde los usuarios también pueden copiar y pegar el código para recuperar los datos por sí mismos

➤ Aclarar las entradas requeridas por el contrato inteligente:
Los contratos inteligentes requieren a menudo grandes números con muchos ceros, que no son amigables para el usuario, especialmente porque es muy fácil cometer errores costosos. Es normal y aconsejable que la interfaz de usuario de Dapp simplifique este proceso para el usuario, permitiendo números más pequeños en un rango más comprensible y menos propenso a errores, como 0 a 100. Sin embargo, a la luz de la transparencia previa de los principios del código, debe hacerse aclare al usuario dónde la interfaz de usuario está simplificando esas entradas y aclare, especialmente en el inspector de código de bricolaje, la entrada real que espera el contrato inteligente.
Un caso real en el que esto era confuso se planteó en una discusión con Jorge Izquierdo sobre la aplicación de votación de Aragón. Los desarrolladores pueden usar la misma solución presentada para ese caso y aclarar al usuario algunos ejemplos con: el número simple, la notación científica y la entrada real (con todos los ceros) que espera el contrato inteligente.

detalle del ejemplo de la wiki de Aragón

Cómo> ejemplos

  • tener una página de "Transparencia de código" siempre accesible, como las páginas de Términos de servicio o Política de privacidad
  • enlace a sus repositorios de github en varios lugares
  • agregue al panel "vista en cadena" (que se muestra en los ejemplos del capítulo 1. Transparencia de la procedencia de datos) una sección dedicada a la transparencia de código con
    ○ información sobre:
     - la Blockchain en uso,
     - las propiedades de dicha Blockchain, especialmente el tiempo promedio de confirmación de bloque (∞enlace 6.Tiempo / Gestión de espera)
     - Ya sea MainNet o TestNet
     - el proveedor web3 en uso (permitir el cambio),
     - las direcciones del contrato,
     - posiblemente una versión simplificada del ABI del contrato con solo los métodos realmente invocados por el código
     - si hay alguna parte del código que se ejecuta de forma no local (explicación textual y motivación)
     - el enlace a los repositorios de github
    ○ conmutadores, filtros u opciones para:
     - mostrar, con iconos y / o cambiando colores, qué partes / componentes tienen datos que se procesan en un servidor
     - mostrar, con los iconos de enlace (el "oráculo de la nube a la cadena") y / o cambiando los colores, qué datos provienen de los oráculos
     - si es relevante, cambie el proveedor de web3
     - una vista previa de las transacciones que se llaman con las llamadas a funciones que se pueden copiar y ejecutar en la línea de comando
     con notas en las entradas si es relevante.
un ejemplo del panel de Transparencia de Código e información

volver a la hoja de trucos

Principios generales de Web3 UX

Los siguientes principios ya no se relacionan directamente con las propiedades de Transparencia y Confianza, sino que apuntan a resolver un conjunto de otros problemas de UX que surgen del uso general y la implementación de aplicaciones distribuidas basadas en Blockchain.

6 - Gestión de tiempo / espera

Hasta que se resuelvan los problemas de escalabilidad, las transacciones son asíncronas y, de acuerdo con la cadena de bloques subyacente y la congestión actual de la red, podría tomar mucho tiempo procesarlas y confirmarlas por completo.

Un Dapp bien diseñado necesita aclarar esta información y administrar la espera del usuario hasta que se confirme su acción.

Principios

un front-end Dapp debería:

➤ (Administre las expectativas del usuario) Aclare en cada transacción el tiempo promedio de confirmación de bloqueo de Blockchain subyacente y la congestión de red actual

➤ (Gestionar el tiempo de espera) Mostrar indicadores de vida durante el tiempo de espera

Cómo> Ejemplos

Como secuencia de eventos UX, un Dapp debería

  1. explique cómo las elecciones de gas afectarán su tiempo de espera (∞link.9 Precios de gas y reversión de TX)
  2. mostrar advertencia sobre tiempos específicos de la cadena
  3. Mostrar un icono de progreso o de espera hasta que no se resuelva
  4. Si las cosas tardan más de lo normal, muestre una retroalimentación y posibles causas y / o soluciones
    es decir: "está tardando más de lo esperado. La red está actualmente congestionada.
     Aquí están tus opciones:
     -> Espere X segundos / minutos más
     -> agregue más gas para acelerar la transacción
     -> recibir una notificación cuando haya terminado
  5. Informe que en cualquier caso notificará al usuario de la ejecución exitosa
  6. Una vez que se realiza la operación, informe de la ejecución exitosa con un informe de los datos (es decir, el Hash de transacción) que pueden verificar independientemente

volver a la hoja de trucos

7 - Formato de hashes legibles para humanos

Hasta que los registros de nombres se adopten ampliamente, e incluso entonces, tenemos que lidiar con la dificultad de las direcciones largas y los hashes de transacciones.
Estas son solo algunas ideas sobre cómo hacerlas más legibles para los humanos, al mismo tiempo que se mantiene la transparencia de la información completa.

Principios

Dapps front-end debería:

Actualización temporal 2018–07–11 Actualmente hay un debate sobre la seguridad de algunos de estos principios. Regrese en un par de días para obtener una versión mejor y más segura

➤ muestra una versión compacta de los hashes pero siempre muestra las partes inicial y final
es decir: 0xABCD ... EFGH
Sin embargo, tenga en cuenta que esto puede contener problemas de seguridad, ya que los generadores de direcciones personalizadas pueden producir secuencias de 8 caracteres en ≈1 semana,

➤ si necesita una versión aún más corto, ̵ prefieren el principio hasta el final ̵
̵ ̵i̵e̵ ̵u̵s̵e̵ ̵0̵x̵A̵B̵C̵D̵… ̵ ̵r̵a̵t̵h̵e̵r̵ ̵t̵h̵a̵n̵ ̵0̵x̵… ̵E̵F̵G̵ (esto tiene implicaciones de seguridad como lo señaló Tom Nash aquí)> modificado de la siguiente manera:

➤ si necesita una versión aún más corta, prefiera el final al principio
 es decir, use 0x ... EFGH en lugar de 0xABCD ...
(aunque es más legible y tiene mejor aspecto tener los primeros 4 caracteres, en comparación con el 0x ... EFGH, hay un problema de seguridad porque los primeros 4 caracteres son más simples de fuerza bruta y generan como es el caso de las URL de vanidad, pero es astronómicamente difícil generar la coincidencia exacta para los últimos 4 caracteres)

➤ prefiero usar trozos de 4 letras en lugar de 3 letras para cada parte
es decir, use 0xABCD ... en lugar de 0xABC ...

➤ siempre antepone el "0x" para indicar que es un hash

➤ permite una vista opcional donde la dirección completa es visible

➤ permitir a los usuarios copiar fácilmente la dirección

➤ siempre que sea posible, use shorthands como títulos y las direcciones abreviadas como subtítulos

➤ si es posible, cree un sistema que permita al usuario asociar fácilmente un nombre o texto legible por humanos personalizado a las direcciones
estas notas deben almacenarse localmente en la computadora local del usuario, no en un servidor (recurra al 5.enlace 5.Transparencia de los principios del código)
Si existe, recurra a un alias conocido db como el registro ENS o Etherscan para contratos y direcciones conocidos.

volver a la hoja de trucos

8 - Modo de Novato Permanente

Si queremos la adopción masiva de aplicaciones distribuidas, significa que debemos permitir que masas de personas sin ningún conocimiento técnico ni comprensión de Blockchain y su jerga entren al espacio.
 
Esto es más que otros espacios, uno que requiere un poco de educación, tanto por razones de seguridad (manejo de claves privadas), como también para comprender completamente por qué las propiedades de Blockchain son un fenómeno tan revolucionario y cómo Dapps difiere de otras aplicaciones.

También es importante el hecho de que este espacio tiene una faceta tan maravillosa que a menudo requiere nuevos modelos mentales y una comprensión multidisciplinaria: Internet of Value está creando miles de ecosistemas simbólicos influenciados por la dinámica del mercado, que normalmente se estudian en Economía, Finanzas y Teoría de juegos; Es muy poco probable que las masas conozcan o hayan estado expuestas a estas disciplinas.
Por lo tanto, las aplicaciones distribuidas deben hacer un esfuerzo para educar a los usuarios nuevos y establecidos en todos los aspectos de su trabajo.

La mayoría de los principios anteriores tienen un usuario novato en mente, pero hay un par de cosas más que los desarrolladores deberían considerar.

Principios

Un front-end de Dapp debería:

➤ Entretejer información educativa con la interacción normal
Nick Neuman ha resumido excelentemente la tarea principal para Dapp Designer: “Una buena aplicación de usuario final integrará la educación en la experiencia del producto. Esto significa explicar de manera concisa e interesante por qué un usuario está haciendo algo mientras lo está haciendo, y crear el producto para que sea muy difícil para el usuario hacer algo inseguro ".

➤ Proporcione 2 o más niveles de contenido educativo: conceptos básicos de Blockchain y jerga específica de Dapp
Este no es un principio solo para nuestro tiempo en el que los novatos se están incorporando, sería una buena práctica para todas las aplicaciones, especialmente aquellas que tienen una jerga interna o contextual o un mecanismo único, agregar otra capa educativa: es decir. si está creando un administrador de fondos simbólicos, no asuma que sus usuarios conocen las finanzas y lo que significa cada término; en su lugar, eduque a los dos sobre los conceptos básicos de Blockchain y los conceptos básicos de las finanzas, al menos para comprender las palabras que está utilizando.

➤ Minimice y aumente progresivamente la cantidad de cosas y conceptos nuevos que el usuario necesita aprender
Los proyectos de Blockchain, a pesar de los incentivos tokenizados para la adopción, todavía tendrán que enfrentar la fricción y la rotación normales que experimenta cualquier servicio de software: los usuarios elegirán alternativas más simples, especialmente si un Dapp les pide demasiado. Por lo tanto, Dapps, al entregar su contenido educativo a los recién llegados, debe tratar de minimizar el uso de nuevas palabras y conceptos, especialmente en las páginas para el público genérico (es decir, la página de inicio) y mostrar progresivamente más aprendizajes en las páginas para usuarios comprometidos (es decir, Usuario tableros de instrumentos). Esto también se puede lograr usando un lenguaje más simple, evitando jerga y usando analogías para explicar información nueva y compleja con conocimiento con el que el usuario ya podría estar familiarizado. Como ejemplo, vea cómo Spankchain creó el concepto de una tarjeta para evitar tener que explicar los canales de pago.

➤ Si es posible o relevante, acelerar el aprendizaje proporcionando la "interpretación del experto"
Desmitifique los significados de sus funciones Dapps, cómo interactúan y cómo un experto pensaría sobre los efectos.
¿Qué sabría un experto sobre cierta cosa específica? ¿Cómo interpretarían los datos? ¿Cómo actuarían sobre eso? ¿Qué elecciones harían?
Las respuestas a esas preguntas podrían incluirse como sugerencias en la interfaz de usuario de Dapp, si son relevantes.
Los ejemplos van desde anticipar un buen precio del gas ("enlace 9. Precios de gas") hasta indicar si es un buen o mal momento para intercambiar un determinado token (solo un ejemplo).

➤ No pierdas contexto
intente tejer los fragmentos dentro de la interfaz, con ventanas emergentes temporales que se pueden descartar fácilmente que luego podrían abrir información más detallada en otra pestaña. Al aprender, permita que el usuario aprenda rápidamente y "en su lugar", sin cambiar de página y sin perder el rastro de lo que estaba haciendo.

Cómo> ejemplos

  • agregue pequeños subtítulos para los comandos en todo el lugar (y consulte otros principios para anticipar qué transacciones van a hacer ∞enlace 2.Transparencia de transacciones)
  • ajuste del modo de aprendizaje
    agregue a la "vista en cadena" u otras partes de la interfaz de usuario, un interruptor (un botón de "signo de interrogación universal") que se puede activar y desactivar y habilita o deshabilita las funciones de aprendizaje
  • Ventana emergente del glosario
    Cuando use la jerga que está disponible en un diccionario, muestre un ícono de enlace, un ícono después de la palabra, que si hace clic o se desplaza, muestra una ventana emergente contextual con la información especificada
    En algunos casos, la ventana emergente también debería ofrecer la oportunidad de "saber más", lo que abrirá otra pestaña o una barra lateral en la "vista en cadena" abierta en la pestaña del glosario.
  • Página del glosario
    en la vista de cadena o en otra página por completo, el Dapp debe proporcionar una página con todos los términos, Blockchain y Dapp específicos, que se utilizan en el Dapp en sí o que son necesarios para comprender su mecánica. Esta página debe ser redirigida desde la ventana emergente del glosario, no vinculada directamente.
  • en cualquier asistente, sería inteligente habilitar el reenvío rápido a los siguientes pasos para que pueda ver lo que viene, aunque todos sus diseños deben estar atenuados y deshabilitados hasta que complete los pasos anteriores. Este es un buen principio para cualquier interfaz de usuario, no solo de Dapps.

volver a la hoja de trucos

9 - Precios del gas y reversiones de transacciones

El gas es una de las cosas más confusas para los novatos. Incluso si el nombre es revelador, es difícil imaginar el costo de la computación para los servicios que siempre ha tenido de forma gratuita.
Además, cuando los usuarios se encuentran con el gas por primera vez, no saben cómo ponerle precio ni, por lo tanto, cuál sería una buena opción para el precio del gas.

Incluso si hoy en día en prácticamente todos los casos el gas es manejado por billeteras que emiten la transacción, este principio sigue siendo válido, tanto para los diseñadores de billeteras como para todos aquellos que alguna vez requerirán o pedirán a los usuarios que elijan el precio del gas.

Afortunadamente para los desarrolladores hay herramientas como la gasolinera Ethereum que ofrece una API conveniente.

Principios

Dapps front-end debería:

➤ Aclarar cuál es el precio del gas y el gas
(al igual que con cualquier otra jerga ∞link 8.Modo de novato)

➤ Sugerir un buen rango para el precio del gas y aclarar aproximaciones de tiempo para los límites superior e inferior del rango
Estas son funciones de la congestión actual de la red, por lo que la solución óptima sería consultar la API actual de la estación de servicio Ethereum https://ethgasstation.info/json/ethgasAPI.json para sugerir estos límites de rango.
Es importante aclarar al usuario que esta es una sugerencia basada en el tiempo y que los valores propuestos podrían cambiar en el futuro.
 
➤ posiblemente muestre valores de gas convertidos también a FIAT

➤ Permitir la reversión de la transacción: en caso de que el usuario haya enviado un TX con un bajo precio de la gasolina, debe aclararse al usuario
(∞vínculo a 6.Time / Wait Management)
- que el tx no se puede cancelar una vez que se ha lanzado
- que la única solución es transmitir otro tx con el mismo nonce y un precio de gas más alto
> por lo tanto, ofrece la opción de recuperar automáticamente el tx nonce y enviarlo con un precio de gas más alto.

volver a la hoja de trucos

Principios de diseño de descentralización del DDP

La descentralización es una nueva forma poderosa de globalización.
Uno que, por primera vez, está potencialmente liderado por masas de individuos auto soberanos que se unen en torno a ideas sin fronteras, organizaciones autogestionadas y sistemas de mercado distribuidos.

Estos Principios de diseño solo quieren iniciar la conversación pensando en cómo hacer que el usuario se sienta parte de una comunidad y en algo más ambicioso que él.
Son solo una pista para que los desarrolladores comiencen a pensar de manera integral sobre la función de sus Dapps y los nuevos requisitos de UX que surgen, en el contexto más amplio de las sociedades distribuidas que estamos creando.

10 - Sentido de comunidad

Los Dapps son diferentes a las aplicaciones porque se distribuyen de forma nativa: incluso si algunos son servicios dirigidos al individuo y cuya interacción es una experiencia solitaria, todavía están hechos para, y a menudo, para un gran grupo de personas en todo el mundo.
 
El sentido de pertenencia a una comunidad es más importante en estos Dapps ya que los usuarios deberán unirse a una marca y producto descentralizados.
Eso no significa hornear en Dapp una red social, aunque algunos podrían beneficiarse de una integración más estrecha con el chat comunitario elegido por el proyecto.

No hace falta decir que estas ideas son bastante importantes para los DAO.
 
Considere lo siguiente como algunas sugerencias genéricas dentro del objetivo más poco interpretable de hacer que los usuarios se sientan parte de algo más grande que ellos mismos.

Principios

Dapps front-end debería:
 
➤ aclarar cuántos otros miembros hay en la comunidad
➤ aclarar quiénes son los otros miembros (elija las categorías apropiadas)
➤ aclarar la composición de la comunidad (es decir, subgrupos y su poder sobre el proyecto)
➤ la mayor misión del proyecto (si existe) y cómo su participación contribuye a su logro

Cómo> Ejemplos

  • Proporcionar un panel de aterrizaje con estadísticas sobre los poseedores de tokens únicos o el número de miembros de un Dapp o DAO
  • adopte el principio de transparencia y muestre especialmente toda la información que los propios usuarios puedan obtener al analizar Blockchain:
     - distribución de riqueza simbólica,
     - gráficos de tiempo de adopción,
     - titular de token desde el bloque XX y aaaa-mm-dd
     etc.
  • en DAO, considere enriquecer la información con cualquier cosa que pueda ser relevante (si está disponible) como:
     - tipo de miembros (es decir, # de reproductores vs no criadores en Crypto Kitties, o # de músicos y # de oyentes en Music / ART Dapps como UJO Music, stakers vs no-stakers, etc.)
     - estadísticas de distribución de replanteo
     - ¿quizás ubicaciones geográficas / zonas horarias?
     - tal vez sexo, edades? (pero solo si tiene sentido para su comunidad y si no es ofensivo o perjudicial para la adopción de su Dapp)
  • Obviamente, busque las categorías que sean apropiadas y relevantes para su proyecto: por ejemplo, es mi opinión personal que en los DAO el sexo y las edades no son información relevante, incluso contraproducente para la idea de crear sociedades sin permiso e imparciales, pero tal vez sean muy pertinente en proyectos como SpankChain.
  • tal vez permita a los usuarios elegir sus propias etiquetas, categorías, descripciones biográficas, etc .: cada miembro puede tener diferentes identidades en diferentes proyectos. Esto ya sugiere otros principios sobre identidades que se presentarán en el futuro.

volver a la hoja de trucos

11 - Otros principios de diseño futuro

Como habrás entendido, el principio anterior requiere algunas reflexiones más sobre Identidades, Reputación y Gobernanza. Los dos primeros son universalmente útiles en muchas aplicaciones impulsadas por la comunidad, pero serán fundamentales para los Registros curados por tokens (TCR) y, probablemente, para muchos DAO y otras cripto-primitivas.

Estos principios merecen su propio análisis y espacio, y esta publicación ya es demasiado larga.
En el futuro analizaré los Principios de diseño de Web3 para:
- Identidades y reputación
- Gobierno
- Carteras
- Intercambios
- ICO y mecánica de venta de tokens
- Mecánica de fichas

Próximos pasos

Está claro que los requisitos de "transparencia extrema" propuestos en estos principios de diseño de Web3 crean una gran carga para los desarrolladores de Dapp que actualmente están más centrados en resolver muchas otras partes de sus proyectos.
 
 - Bootstrap como biblioteca
Por lo tanto, es obvio que debe haber un conjunto de herramientas estándar que los desarrolladores puedan conectar y reproducir en sus Dapps y tal vez interconectar sus llamadas a la biblioteca web3 y obtener, de forma gratuita, todos estos servicios de transparencia para sus usuarios.
Me estoy imaginando algo así como una biblioteca tipo Bootstrap para la era de Web3 ("Chainstrap"? Es un núcleo demasiado duro, ¿verdad?: P)

- Complemento de navegador independiente
Tal vez incluso sea aconsejable que haya una herramienta independiente que ofrezca a los usuarios las ventajas de los Principios de diseño de Web3 donde el creador de Dapp quiera o no; una especie de "ejecutor de la transparencia" que podría permitir identificar Dapps maliciosos o descuidados por su grado de cumplimiento de algunos de los principios.
En este caso, probablemente sería apropiado crear un complemento de navegador que inyecte su código en el Dapp y proporcione la funcionalidad de vista en cadena y tal vez incluso una certificación rápida del grado de transparencia y confiabilidad del Dapp.

- Servicios personalizados
Además, en estos principios hay muchos potenciales para los servicios, incluso comerciales que aún no existen en la actualidad.

Muchas opciones. ¿Qué piensas?

Si está interesado en desarrollar cualquiera de los anteriores, si solo tiene pensamientos y consideraciones,
o si usted es una organización que ofrece subvenciones y cree que podría encajar en sus objetivos actuales,
póngase en contacto b [at] likuidlabs.com, o en twitter @lyricalpolymath

¡Diseñemos y construyamos juntos el futuro de la descentralización!

NOTAS

[1] Otros "Blockchain" + Artículos de diseño

Aplicando la Metodología de diseño Investigué lo que ya se había creado sobre el tema: no mucho.

  • Principios de diseño de blockchain - Diseño en IBM
    Este es, de lejos, el mejor artículo sobre el tema. Escrito por Sarah Baker Mills, ex directora de diseño de IBM y hoy directora de diseño de Consensys. Ella destila muy bien algunos de los principios que aparecen en los Principios de diseño de Web3, aunque bajo diferentes nombres. Ella habla sobre exposición de datos, consistencia, retroalimentación, anticipación de errores y orientación activa.
  • Blockchain y diseño - Hacker Noon
     Una entrevista con Matt Storus, diseñador principal en 21.co, sobre los desafíos y algunas ideas de lo que deberían hacer los diseñadores. Lamentablemente, el formato de la entrevista no permite extraer muchas enseñanzas, pero definitivamente es una lectura interesante.
  • La experiencia del usuario de Blockchain
    Una publicación genérica para educar a los diseñadores sobre Blockchain y los desafíos de diseño.
  • Cómo puede ayudar el diseño a Blockchain - The Spark
    algunas ideas macro sobre algunas cosas que los diseñadores en este espacio deberían pensar
  • Diseño para Blockchain: lanzamiento de una aplicación Ethereum Smart Contract
    Un caso de estudio sobre el diseño de una mejor experiencia para una plataforma de inversión, con algunas ideas para mejorar la participación en las ICO

[2] Sé que estos postulados son una falacia fenomenológica, pero los uso de todos modos porque son una simplificación útil y hacen el punto: para un usuario no técnico, que no puede verificar los datos por sí mismo de una manera fácil, el la información claramente no es transparente. La transparencia se convierte entonces en un espejismo brillante, una fiel expectativa de confianza.