Como diseñador por primera vez en el espacio de , llevé un poco de sesgo y preacondicionamiento a las prácticas estándar de UX y UI. Si bien los beneficios y las nuevas oportunidades que proporciona están bien documentados, los desafíos de la plataforma eran nuevos para mí. Al diseñar la plataforma Solidificada, fue necesario abordar uno de estos problemas que se siente muy similar a los problemas clásicos de una Internet temprana.
Uno de los problemas centrales que siempre se deben tener en cuenta al interactuar con la cadena de bloques es la velocidad de transacción. Los usuarios actuales de aplicaciones y servicios web esperan velocidad. Se ha escrito mucho sobre las prácticas modernas de UX para ocultar los tiempos de carga y gestionar las expectativas de los usuarios. Sin embargo, estas prácticas a menudo pretenden ocultar algunos segundos, no los minutos que demoran algunas transacciones. Además del desafío incorporado de simplemente trabajar con el libro de contabilidad, también existen problemas de seguridad que ocasionalmente dictan un ritmo de interacción más lento para evitar el spam. Para Solidified, nos enfrentamos a estos desafíos de dos formas principales: ejecutar transacciones en segundo plano y proporcionar retroalimentación por niveles.
El método preferido para tratar con los tiempos de transacción es ejecutarlos en segundo plano. La ocultación de las transacciones funciona bien cuando el final de un flujo implica una espera pasiva. Un ejemplo de ello en Solidified es publicar un nuevo contrato inteligente para su revisión. La publicación de un contrato finaliza con el usuario, un desarrollador, que espera que los revisores revisen el contrato. Esto también puede actuar como un momento para que las transacciones tengan lugar. En este caso, el desarrollador puede seguir los pasos para configurar el contrato y se publicará automáticamente al público cuando se complete la transferencia de fondo.
La salsa secreta de cuándo ejecutar transacciones en segundo plano son ajustadas. El ingrediente más importante es que el usuario no debería estar presente cuando se activa el resultado de la transacción. Esto a menudo aparece cuando la transacción desencadena un resultado dirigido principalmente a otro usuario, en nuestro caso un revisor. Otros ingredientes clave son apuestas bajas para errores, la capacidad de guardar un borrador del trabajo y la capacidad de proporcionar notificaciones cuando se completa la transacción de los usuarios. El mayor riesgo con este método es que cuando una transacción falla, podría haber traicionado la confianza del usuario. Esta es la razón por la cual las notificaciones, borradores y apuestas bajas son importantes. En aquellos casos en que la transacción falla, el usuario debe ser notificado y no perder nada del trabajo que ya ha realizado, y tener la capacidad de intentar la transacción nuevamente sin impedimentos.
La alternativa al procesamiento en segundo plano es reducir el número de transacciones y proporcionar la máxima retroalimentación disponible. En Solidified, nuestro compromiso con la seguridad y la confianza requiere que todas las partes involucradas tengan algo en juego. Debe transferirse cierta cantidad de tokens para un envío, contrato, error o disputa. Esto significa que el usuario debe realizar las transacciones antes de continuar y, por lo tanto, la plataforma debe respaldar al usuario a través de estos pasos más lentos.
Cuando el usuario debe detenerse, ¡dile que estás trabajando para él!
La heurística más importante a seguir en estos casos es "Reconocimiento sobre recuperación" y "Visibilidad del estado del sistema". El usuario no debería tener que adivinar qué tan grande es una transacción necesaria para completar su tarea, proporcione esta información en ese momento. de la acción. Del mismo modo, el usuario no debería tener que adivinar si su transacción va bien. La cadena de bloques no devolverá una notificación, por lo que la plataforma requiere un cronograma agresivo para hacer ping en el libro mayor para asegurarse de que el usuario lo sepa tan pronto como haya logrado su objetivo. También proporcione cualquier comentario intermedio que reciba el sistema, por ejemplo: cuando se envía una transacción, una anticipación de tiempo (según las pruebas) y una clara señal de éxito cuando se publica la transacción.
Celebre el éxito y sea informativo
Aunque a veces es necesario, primero intentamos mitigar la necesidad de transacciones de usuario a plataforma haciendo que el proceso más lento de la transferencia de la cadena de bloques se realice fuera de nuestros flujos primarios. Le damos a cada usuario una cuenta de plataforma desde la cual se extraen las transacciones diarias. De esta manera, el usuario puede realizar menos transacciones, pero más grandes, y no interrumpirla cuando tiene un momento de emoción al encontrar ese error crítico. También nos integramos con herramientas estándar del espacio, como Metamask. Estas herramientas nos permiten compilar previamente las transacciones en la interfaz de usuario de la plataforma para que podamos brindar al usuario un comentario crítico sobre lo que es necesario para continuar. Luego, alimentamos solo la información crítica de la transacción a la herramienta.
Solidified presenta otra situación que crea una IU lenta: herramientas de terceros e internas. Para maximizar la experiencia de los usuarios en nuestra plataforma, necesitamos procesar una gran cantidad de código. Especialmente para contratos complejos hay un largo período de ejecución del código a través de herramientas. Queremos ocultar estos procesos lentos, pero en este caso lo estamos abordando de una manera diferente.
Resolvemos este desafío ejecutando el código al comienzo de un flujo y realizando un proceso en segundo plano, ya que el usuario está completando el formulario necesario. Para ejecutar esto correctamente, es necesario planificar cuándo será absolutamente necesaria la transacción, y luego generar una pequeña fricción para que el usuario los detenga. En Solidified tenemos al usuario que carga su contrato como uno de los primeros pasos en nuestro proceso de envío de contratos. Esto nos permite hacer el trabajo necesario para preparar el contrato para publicación pública sin mostrar al usuario una barra de carga.
Esta técnica no funciona para transacciones. Las transacciones son una barrera de seguridad importante para evitar el spam y mantener la honestidad. En teoría, se podría solicitar una transacción al comienzo de un flujo, pero esto crea una condición para un riesgo muy alto. ¿Qué pasa si el usuario es interrumpido o no puede terminar el flujo necesario, pero la transacción aún se realiza? Hemos robado esencialmente de este usuario. Comenzar un proceso en segundo plano al comienzo de un flujo puede parecer muy conveniente, pero es necesario considerar siempre los estados de falla y sus consecuencias.
La razón por la que este flujo funciona para el procesamiento del contrato es la falta de riesgo. Sabremos si la carga funcionó antes de que comiencen los otros pasos, y podemos interrumpir al usuario en cualquier momento si hay un error. El usuario también pierde muy poco en caso de error. Podemos reiniciar su flujo fácilmente, sin que ella pierda mucho, si es que trabaja. Una transacción criptográfica falla en todas estas casillas de verificación, por lo tanto, una transferencia de fondo siempre debe realizarse al final de un flujo.
Las blockchains son cada vez más rápidas, pero como diseñadores todavía tenemos que compensar claramente el ritmo de la plataforma en comparación con otros servicios. Actualmente, la mayoría de los usuarios en nuestra plataforma están altamente motivados. Sin embargo, para capturar a la población más grande, es fundamental que nuestras aplicaciones cumplan o superen las expectativas del ecosistema tecnológico más grande. Esperamos que estos pocos pensamientos le ayuden a reducir la fricción para sus usuarios y permitan una interacción más suave con esta nueva tecnología.
