Pregunta de UX: es mejor tener "eliminación grave" o tener "basura"

Question

Estoy desarrollando una aplicación que permite a un usuario administrar algunos puntos de datos individuales. Una de las cosas que mis usuarios querrán hacer es "eliminar", pero ¿qué significa eso?

Para una aplicación web, ¿es mejor presentarle a un usuario la opción de eliminar en serio o utilizar un sistema "basura"?

En "eliminación grave" (me gustaría saber si hay un nombre mejor para esto ...), haga clic en "eliminar" y luego se advierte al usuario "esta es una acción final y trágica. Una vez que hace esto, no podrá obtener -introducir aquí el nombre del punto de datos, incluso si está llorando ... " Luego, si hacen clic en eliminar ... bueno, realmente se ha ido para siempre.

Bajo el modelo "basura", nunca confías en que el usuario realmente quiera eliminar ... en su lugar, eliminas el punto de datos de la "pantalla principal" y lo colocas en un cubo llamado "la basura". Esto lo saca del camino de los usuarios, que es lo que generalmente quieren, pero pueden recuperarlo si se equivocan. Obviamente, esta es la forma en que se han ido la mayoría de los sistemas operativos.

Las ventajas de "grave borrado" son:

• fácil de implementar
• fácil de explicar a los usuarios

Las desventajas de "grave borrado" son:

• puede ser trágicamente final
• veces , Gatos caminan sobre los teclados

Las ventajas del sistema de "basura" son:

• usuario está a salvo de ellos mismos
• métodos a granel como "borrar un par a la vez" más sentido
• ahorra dolores de cabeza de apoyo

las desventajas del sistema de "basura" son ":

• Para datos confidenciales, crea una ilusión de destrucción. Los usuarios piensan que algo se ha ido, pero no es así.
• Muchas distinciones sutiles dificultan la implementación
• ¿Borra "eventualmente" el contenido de la papelera?

Mi pregunta es ¿cuál es el patrón de diseño correcto para las aplicaciones web modernas? ¿Cómo funciona una función de "archivo" en esto? Así es como gmail works. Dé suficiente discusión para justificar su respuesta ... Me encantaría que me señalaran alguna investigación relevante.

-FT

Answer 1

creo que bastante bien resumió los pros y los contras para el modelo de la basura:

• Pro: En general, mejor para el usuario.

• Con: En general, más fácil para el desarrollador.

Para un especialista en usabilidad como yo, es una obviedad. En lo que a mí respecta, se supone que los desarrolladores deben trabajar duro para hacer la vida más fácil para los usuarios. Francamente, hasta que las aplicaciones web tengan capacidades de deshacer como la basura, no creo que podamos considerarlas utilizables. Tiempo que las aplicaciones web alcanzan hasta 1984.

algunos otros detalles:

• Otra ventaja del modelo de la basura es la capacidad de eliminar la necesidad de que el mensaje de confirmación en la mayoría de los casos. En la gran mayoría de los casos, el usuario está borrando algo intencionalmente, por lo que dar un paso adicional con un mensaje de confirmación suele agregarles trabajo. Peor aún, adquieren el hábito de golpear rápido, lo que generaliza a otras confirmaciones que realmente leen mejor. Ver http://alistapart.com/articles/neveruseawarning.

• Parte de la belleza de la metáfora de la basura es que sugiere al usuario que eliminar es no permanente. Al igual que una basura física, los objetos se pueden recuperar. Si muestra la papelera con la suficiente claridad en su página (para que los usuarios se den cuenta de que pueden abrirla), e incluye una imagen de la papelera como un ícono al lado del ítem Eliminar, eso debería ser suficiente para indicar que borrar no lo hace destruir, sino que mueve las cosas a la basura.

• Probablemente sea aceptable destruir las eliminaciones más antiguas en la basura si hay consideraciones de rendimiento. Una vez más, esto es consistente con la metáfora de la papelera: los usuarios pueden anticipar que, tarde o temprano, "alguien" va a vaciar la basura. No creo que a los usuarios les importe si la basura nunca se vacía. Si realmente necesitan destruir algo sensible, puede proporcionar un procedimiento explícito para ello (por ejemplo, borrar algo que ya está en la papelera).

Answer 2

Totalmente dependiente del contexto.

• Si se trata de una acción fácilmente reversible, simplemente eliminarlo, puede que ni siquiera necesita una confirmación
• Si que puede haber perdido una gran cantidad de datos, una "elementos de memoria borrado temporal" bien podría estar en su lugar

Answer 3

No veo que la presentación de la aplicación (aplicación web o no) sea un factor importante para esta decisión. Me preocuparía más el valor de los datos, su facilidad de recreación y los costos de mantenimiento y limpieza.

Mi sensación es que cuando su aplicación actúa como un depósito de datos valiosos, es preferible eliminar-por-basura.

Answer 4

Mi opinión es que realmente no hay ninguna razón para eliminar todo lo que pueda ser importante para alguien. En mi experiencia, el dolor de tener que hacer una copia de seguridad en cinta porque un usuario se dio cuenta de que borraron algo la semana pasada que necesitaban se resuelve fácilmente mediante el uso de una bandera 'IsActive' o 'IsDeleted' en registros que un usuario podría borrar.

Answer 5

En mi opinión personal idiosincrásica, cada acción irreversible es un grave error de diseño. Estos cuadros de mensaje de "¿Estás REALMENTE ABSOLUTAMENTE, POSITIVAMENTE seguro?" Son pura basura porque el usuario está muy condicionado a simplemente hacer clic en "Aceptar" y terminar con eso. De hecho, he perdido datos importantes a pesar de tales diálogos en varias ocasiones.

En otras palabras: estos cuadros de diálogo no agregan una barrera de seguridad funcional, solo una barrera de usabilidad.

Incluso los sistemas de basura tienen este problema (simplemente posponen el momento); la mejor solución desde el punto de vista de la usabilidad es una historia infinita. Por supuesto, implementar esto puede acarrear costos prohibitivos (por ejemplo, en términos de uso de memoria).

La eliminación permanente de datos confidenciales puede (y debe) ser implementada por todos los medios como una acción mucho más complicada: rara vez es necesaria. El único problema es dejar en claro al usuario que los datos normalmente no se pierden. Usar una historia en lugar de la papelera puede ayudar aquí: la papelera podría malinterpretarse como una eliminación permanente mientras que un historial (visible) de acciones no da esta ilusión de seguridad.

Answer 6

Aquí hay un artículo relevante que te puede gustar. Está más enfocado en escenarios de negocios, pero puede aplicarse en cualquier lugar.

Don't Delete, Just Don't.