Implementar un sistema robusto de deshacer y rehacer (undo/redo) en una aplicación colaborativa es una tarea compleja que atraviesa toda la arquitectura del software. Aunque los usuarios la dan por sentada —porque les permite corregir errores, experimentar y retroceder sin coste—, los desarrolladores se enfrentan a retos poco conocidos: la falta de bibliotecas que soporten el caso multijugador, las dificultades que incluso grandes equipos (como el de un editor WYSIWYG) han reportado, y la ausencia de esta función en apps colaborativas populares, desde pizarras tipo Figma hasta herramientas como Jira.
El artículo explica los comportamientos cotidianos que revelan lo extraña que resulta esta función: la típica secuencia de deshacer, copiar y rehacer; la frustración cuando al escribir un carácter se desactiva el botón 'rehacer'; la pérdida del historial al cerrar la ventana o cambiar de pestaña; y los conflictos que aparecen cuando varias personas editan el mismo elemento en momentos distintos.
Para modelar estos problemas, el autor introduce dos formas de representar el estado. La primera, basada en nodos que representan estados únicos (como Google Slides), provoca ansiedad porque basta con una nueva edición tras un deshacer para perder la rama anterior. La segunda, conocida como 'History Undo' —introducida por Emacs y documentada en literatura académica—, representa puntos en el tiempo y permite recorrer todo el historial sin perder cambios. Esta variante ofrece una experiencia más intuitiva y evita la sensación de irreversibilidad. La conclusión parcial es que identificar los problemas del undo/redo es más sencillo que proponer soluciones de calidad.