8 cosas que hicimos mal (y cómo hicieron a ONLYOFFICE mejor)

Dieciséis años es mucho tiempo para desarrollar software. Y siendo honestos, no hicimos todo bien a la primera.

Como parte de nuestra serie de entradas del blog sobre el 16.º aniversario, queremos compartir algo un poco diferente. No una lista de logros, sino una lista de los errores que cometimos en el camino, y cómo cada uno nos impulsó a construir un mejor producto. Porque aquí está la verdad: ONLYOFFICE se creó desde cero, internamente, por un equipo que aprendió sobre la marcha. Cada giro equivocado nos enseñó algo que ahora beneficia a nuestros más de 21 millones de usuarios.

1. Comenzar con una experiencia de edición basada en plugins

En los primeros días, alrededor de 2010, nuestra primera experiencia de edición de documentos se ejecutaba en OpenOffice. Para editar un documento, tenías que descargar un plugin, abrir el archivo y luego guardarlo de nuevo en el portal.

Funcionó. Más o menos. Pero cargar tomaba una eternidad, los resultados eran impredecibles y se sentía más como una solución alternativa que como un producto real. Cada usuario necesitaba software adicional en su máquina solo para comenzar.

Lo que aprendimos: Una gran experiencia de edición debe ocurrir directamente en el navegador, sin pasos engorrosos de por medio. Esa realización estableció la dirección para todo lo que vino después.

2. Construir los editores con CKEditor y renderizado DOM

A continuación, intentamos construir nuestros editores utilizando CKEditor y renderizado DOM, incluyendo el editor de hojas de cálculo. ¿El problema? Cada navegador representa las cosas de manera diferente. Lo que veías en la pantalla no siempre coincidía con lo que obtenías al imprimir. Los archivos grandes ralentizaban todo, y los límites de memoria hacían que el trabajo serio fuera casi imposible.

Lo que aprendimos: Necesitábamos control total sobre cómo se visualizan e imprimen los documentos, a través de cada navegador y dispositivo. Esto nos impulsó a ser los primeros en crear editores en línea utilizando el elemento HTML5 Canvas, brindando a los usuarios resultados consistentes y fiables sin importar dónde trabajen.

3. Calcular fórmulas de hojas de cálculo en el servidor

Aquí hay otro. En nuestro temprano editor de hojas de cálculo calculamos fórmulas en el servidor y solo mostramos los resultados en el navegador del usuario. Sobre el papel, parecía eficaz. En la práctica, provocaba retrasos y limitaba el grado de interactividad de la experiencia.

Lo que aprendimos: Los usuarios esperan retroalimentación instantánea cuando trabajan con números. Mover los cálculos más cerca del usuario hizo que el editor fuera más rápido y mucho más receptivo, exactamente lo que las personas necesitan para el trabajo diario.

4. Usar .NET y C# en el servidor

Este fue uno de los mayores puntos de inflexión para nosotros. En los primeros días, elegimos una configuración de .NET y C# para nuestros editores simplemente porque aún no teníamos suficiente experiencia para saber qué funcionaría mejor.

Rápidamente se hizo evidente que este enfoque no era el adecuado. No funcionaba en Linux, el rendimiento era lento incluso en Windows, y manejar muchas conexiones simultáneas era difícil.

Así que tomamos una decisión audaz y reescribimos el servidor en Node.js. En ese momento, aún era una tecnología muy nueva y experimental, y no todos pensaban que era la decisión correcta. Pero nuestra propia investigación y pruebas nos dijeron lo contrario. Al final, reconstruimos todo el servidor desde cero.

Lo que aprendimos: A veces, la decisión más valiente es empezar de nuevo. Reconstruir el servidor le dio a ONLYOFFICE la velocidad, estabilidad y flexibilidad multiplataforma de la que nuestros usuarios dependen hoy en día. Igualmente importante, esa experiencia nos ayudó a tomar mejores decisiones arquitectónicas más adelante al construir DocSpace, para que pudiéramos evitar repetir los mismos errores.

5. Apostar por nuestros propios formatos DOCXF y OFORM

Para manejar formularios rellenables, introdujimos nuestros propios formatos en 2022: DOCXF y OFORM. La idea tenía sentido en aquel momento, pero cambiar los hábitos de las personas es difícil. Pedir a los usuarios que adopten formatos no familiares añadió fricción donde queríamos simplicidad.

Así que hicimos el cambio al formato PDF, un formato que todos ya conocen y en el que confían.

Lo que aprendimos: Encontrarse con los usuarios donde ya están es mejor que pedirles que se adapten a nosotros. Ahora puedes crear y rellenar formularios PDF con herramientas que se sienten instantáneamente familiares.

6. Lanzar sin una aplicación móvil nativa

Durante un tiempo, ONLYOFFICE no tuvo aplicaciones móviles nativas. Teníamos un diseño receptivo, claro, pero eso no era suficiente. La gente quería una experiencia real, diseñada específicamente para sus teléfonos y tabletas.

Lo que aprendimos: El diseño adaptativo es un inicio, pero una verdadera aplicación nativa es lo que las personas realmente quieren en movimiento. Hoy en día, puedes usar nuestras aplicaciones gratuitas para iOS y Android para trabajar en documentos en cualquier lugar y en cualquier momento.

7. No ofrecer una API pública desde el principio

No ofrecimos una API pública de inmediato. Mirando hacia atrás, esa fue una oportunidad perdida. Una API amigable hace que sea fácil para cualquiera conectar ONLYOFFICE a las herramientas que ya usan, y las integraciones juegan un papel enorme en nuestro ecosistema.

Lo que aprendimos: La apertura invita al crecimiento. Una vez que construimos una API accesible, los desarrolladores y plataformas pudieron integrar ONLYOFFICE con facilidad. Seguimos expandiéndola y haciéndola más conveniente con cada lanzamiento.

8. No planear las integraciones lo suficientemente temprano

Nuestra última lección está estrechamente relacionada con la anterior. Para permitir que otras aplicaciones se conecten a tu producto y expandan lo que puede hacer, necesitas planificar esas capacidades de «plataforma» con anticipación. En nuestros primeros años, no siempre hicimos eso.

Lo que aprendimos: Construir para la integración desde el primer día ahorra un esfuerzo enorme más adelante. Esa es exactamente la mentalidad que llevamos a ONLYOFFICE DocSpace hoy, diseñándolo para conectarse sin problemas a las herramientas de las que los equipos ya dependen.

Lo que todos estos errores nos enseñaron

Mirando hacia atrás, existe un patrón claro. Cada uno de estos pasos en falso provino del mismo lugar: un equipo construyendo todo desde cero, sin atajos y sin el manual de otra persona a seguir.

Esto es lo que aquellos años de prueba y error nos dieron:

• el coraje para reconstruir cuando algo no era lo suficientemente bueno;
• un compromiso con la experiencia primero en el navegador que nuestros usuarios aman;
• un enfoque abierto y amigable para desarrolladores que impulsa más de 40 integraciones;
• un hábito de escuchar y adaptarse a lo que las personas realmente necesitan.

No llegamos allí siendo perfectos. Llegamos allí estando dispuestos a aprender.

El viaje continúa

Dieciséis años y más de 21 millones de usuarios después, estamos orgullosos de hasta dónde ha llegado ONLYOFFICE, y somos honestos sobre los errores en el camino. Cada error nos hizo mejor, y cada solución nos acercó al producto que nuestros usuarios merecen. Ese impulso por seguir mejorando no ha disminuido ni un poco.

¿Quieres ver dónde nos llevó todo ese aprendizaje? Explora la completa serie de entradas del blog sobre el 16.º aniversario de ONLYOFFICE y descubre los hitos, decisiones y momentos que moldearon quiénes somos hoy.