Tractis estrena un nuevo motor de edición de contratos

Hasta ahora, para crear un contrato en Tractis había que utilizar unos botones contextuales (“Añadir sección”, “Añadir clausula”) que aparecían al pasar el cursor sobre el texto. Esta solución nos gustaba porque forzaba al usuario a identificar/semantizar el tipo de elemento antes de añadirlo. Para cada elemento (título, sección, clausula, etc.) utilizabamos un textarea distinto, lo que nos permitía aplicar comportamientos diferentes a cada párrafo (fondo gris para edición, amarillo para hoover, etc). Gracias al uso de CSS el usuario no tenía la sensación de estar editando un formulario lleno de textareas sino que parecía un único documento. En teoría era la solución perfecta. Pero solo en teoría:

• Cada textarea era un compartimento estanco. A diferencia de un Word que sí lo permite, los usuarios no podían navegar el contrato de arriba a abajo solo con la ayuda de los cursores. Lo creais o no, no nos dimos cuenta de esto hasta que lo probamos. Podríamos haberlo solucionado con más javascript pero sabíamos que ya estabamos abusando.
• El usuario no podía cortar y pegar un contrato desde su procesador de textos favorito sino que tenía que hacerlo párrafo a párrafo (crear clausula, pegar párrafo, crear clausula, pegar…). De nuevo, no caímos en la cuenta de esto.
• Cuando el contrato aumentaba de tamaño, el editor se volvía extremadamente lento e inestable (recorríamos el DOM del documento continuamente en tiempo de ejecución para averiguar donde se encontraba el cursor o donde se habían producido cambios).
• La aparición de menús al mover el cursor distraía bastante y tanto javascript generaba problemas serios de compatibilidad entre los distintos navegadores.

Los usuarios se quejaban de que la edición daba una “sensación rara”. No sabían explicarlo pero no era a lo que estaban acostumbrados. Nuestro objetivo era que pudiesen editar contratos 100% online olvidándose de su procesador de textos. Si el editor daba una sensacián “rara”, nos arriesgabamos a que no utilizasen Tractis o que siguiesen utilizando Word u OpenOffice y luego cortasen y pegasen el texto en Tractis. Inaceptable. Teníamos que cambiar el enfoque y hacer cambios importantes. Aunque eso supusiese tirar código y horas de trabajo.

Lo que nos estaba ocurriendo era un ejemplo perfecto de porqué la iteración continua (desarrollar, probar, repetir) en el desarrollo es mil veces mejor que la estrategia “big bang” (un año desarrollando y probar al final). Hasta que no pruebas tus ideas, nunca sabes si funcionarán realmente o no.

Hemos decidido utilizar un editor WYSWYG existente. Tras analizar varias alternativas, nos hemos decantado por Dojo Editor. Lo hemos modificado para integrarlo con nuestra comparación de versiones, para que produzca XHTML limpio cuyo significado podemos interpretar y para restringir la entrada (corta&pega) de etiquetas no-permitidas. Ahora, en vez de pedir al usuario que nos indique el significado de cada elemento, deducimos el significado de la estructura del documento. Con el nuevo motor de edición:

• El documento es editable de una manera más tradicional e intuitiva.
• No hay necesidad de apretar botones para añadir elementos. Un retorno de carro basta para crear un párrafo.
• La edición es más rápida (en vez de muchas textareas, utilizamos una única iframe).
• Los usuarios pueden cortar y pegar contratos desde su procesador de textos a Tractis en un segundo.
• Nos evita probar gran cantidad de código javascript en cada navegador (la gente de Dojo se encarga de esto).

Personalmente, estoy muy contento con el resultado. Es rápido, muy rápido. Incluso en documentos grandes. Tienes la sensación de utilizar el editor desktop al que todos estamos acostumbrados y es mucho más estable y compatible con navegadores que lo que teníamos antes. Si eres un beta-tester, tránquilo: ningún documento se ha perdido en la transición .

Pruébalo. Nos encantará saber tu opinión.

Por David Blanco
Guardado en: Anuncios, Programación, Tractis | 10 comentarios » | 6 de Septiembre de 2006