Aplicaciones web BIM: del visor a la revisión del proyecto

«Solo queremos ver el modelo en el navegador». El solo dura hasta que alguien pide consultar superficies, comentar una puerta y comprobar una corrección. Todas las peticiones caben en la misma ventana; el trabajo para resolverlas no cabe necesariamente en la estimación del visor. El botón de orbitar no tiene competencias para aprobar entregas, por mucho que le pongamos al lado un icono de colaboración. Vamos a definir la tarea antes de convertir una demostración gráfica en una aplicación por aclamación.

Las aplicaciones web BIM acercan geometría e información a personas que no trabajan con la herramienta de autor. Para que esa apertura resulte útil, conviene diseñar el recorrido completo: qué necesita comprobar el usuario, sobre qué versión, con qué datos y qué ocurre después de su decisión. Vamos a seguir un caso hipotético de revisión de una biblioteca pública. Nos permitirá distinguir qué aporta un visor y qué hay que construir alrededor para que el navegador participe de verdad en el proyecto.

Empezar por la revisión que alguien necesita terminar

Imaginemos que la responsable de la biblioteca quiere revisar la distribución antes de una reunión. Necesita localizar la sala infantil, entender su relación con el acceso y consultar una superficie. No pretende aprender un programa de modelado ni encontrar un panel escondido detrás de tres iconos. Su tarea tiene un principio y un final: abrir la entrega correcta, reconocer los espacios y preparar una observación que el equipo pueda atender. Ese recorrido ofrece una definición de alcance mucho más útil que «hacer una plataforma BIM en la nube», expresión capaz de alojar varios presupuestos dentro de una sola frase.

Para esa primera revisión puede bastar con un visor, una navegación comprensible y unas propiedades seleccionadas. El proyecto debería abrirse en una vista reconocible, mostrar el nombre de la entrega y permitir volver al punto inicial cuando alguien se pierda. Un buscador de espacios o una lista por plantas puede ayudar más que una colección de herramientas geométricas avanzadas. Elegir qué dejar fuera también es diseñar: si una propiedad interna no ayuda a tomar ninguna decisión, enseñarla añade ruido y puede dar una falsa impresión de transparencia.

La situación cambia cuando la responsable quiere dejar una observación y saber si se ha resuelto. Ahora hay que identificarla, guardar el comentario, vincularlo con el modelo y permitir que alguien responda. Si además puede aceptar una solución, habrá que definir qué significa esa aceptación y quién está autorizado para registrarla. Dibujar una chincheta sobre una pared es una interacción visual; mantener el compromiso que representa exige estado, responsabilidad e historia. El requisito debería describir ambas cosas antes de elegir la librería del visor.

Una forma prudente de empezar sería entregar primero la consulta de una versión y, después, incorporar el ciclo de revisión. Cada fase necesita su propio criterio de aceptación. Para la primera, una persona ajena al modelado debería poder localizar la sala y reconocer la fecha de la entrega. Para la segunda, el comentario tendría que llegar al responsable con contexto suficiente y reaparecer al abrir la misma revisión. Son comprobaciones que se pueden observar. «El cliente puede colaborar» queda estupendo en una diapositiva y resulta menos preciso el día que falta un comentario.

Preparar el modelo para verlo sin confundirlo con validarlo

El archivo con el que se produce un edificio y la representación que conviene enviar a un navegador responden a necesidades diferentes. La herramienta de autor necesita conservar su capacidad de edición; la revisión web necesita ofrecer geometría y datos de forma manejable. Por eso puede existir un procesamiento previo que genere una representación de visualización. Como ejemplo concreto, Model Derivative de Autodesk transforma diseños a formatos como SVF y SVF2 y permite extraer jerarquías y propiedades para su uso con Viewer. Esa conversión facilita el acceso; no certifica la información del proyecto.

En un recorrido basado en IFC también habrá que decidir cómo cargar el archivo, qué información conservar y si conviene preparar una representación optimizada antes de abrirla. No todos los usuarios necesitan descargar todas las propiedades de todos los objetos al empezar. La aplicación podría solicitar los datos de la sala seleccionada cuando hagan falta, mientras mantiene un índice específico para las búsquedas habituales. La estrategia depende del tamaño y de la tecnología elegida. Afirmar que «el navegador ya puede con todo» es una manera muy económica de trasladar el problema al portátil de otra persona.

En nuestra biblioteca, el criterio debería ser cuánto tarda la responsable en comenzar una revisión útil, no cuánto tarda en terminar una barra de progreso. ¿Puede reconocer la planta antes de que aparezcan detalles secundarios? ¿La consulta de propiedades bloquea la navegación? ¿Qué ocurre con la memoria al cambiar varias veces de entrega? Estas preguntas se comprueban con archivos representativos, dispositivos habituales y condiciones de red razonables para el uso previsto. Una cifra obtenida con un modelo pequeño en el ordenador del desarrollador no describe, por cortesía estadística, todos los edificios.

Además, «listo para visualizar» y «válido para esta comprobación» deben ser estados diferentes. La sala podría verse perfectamente y tener la superficie en blanco, una clasificación equivocada o una unidad mal interpretada. Si la aplicación presenta una suma de superficies, necesita definir qué espacios entran, qué propiedad utiliza y con qué criterio trata los valores ausentes. Un total con dos decimales transmite una seguridad conmovedora. Conviene que proceda de una regla que alguien pueda explicar, además de una operación que el ordenador sepa ejecutar.

Conservar la versión y el significado de cada observación

Supongamos que la responsable señala una puerta porque invade el recorrido de acceso. El comentario necesita conservar algo más que una imagen: proyecto, modelo, versión, objeto cuando pueda identificarse y una vista que permita entender la situación. La captura ayuda a reconocer el problema, pero no permite por sí sola volver al elemento ni comprobar una corrección. Tampoco basta con guardar «modelo actual». Ese nombre cambia de significado justo cuando empieza a interesarnos saber qué ocurrió.

La aplicación debería distinguir entre la entrega sobre la que nació la observación y la entrega en la que se revisa su resolución. Si el arquitecto modifica la puerta, podremos consultar la versión anterior para entender el comentario y abrir la nueva para comprobar la respuesta. Si la sustituye o la elimina, la referencia podría dejar de resolverse automáticamente. La interfaz tiene que explicar ese caso y permitir una revisión consciente. Saltar a un objeto parecido y presentar la asociación como cierta sería automatizar una suposición, con la tranquilidad gráfica de un enlace azul.

Los identificadores merecen especial atención porque una referencia interna de visualización no tiene por qué ser una identidad persistente entre conversiones. La guía de preparación de modelos de Autodesk distingue el identificador externo preservado desde el origen en los formatos compatibles. Aun así, conservar un identificador no garantiza que el objeto siga existiendo en la entrega siguiente. El diseño de la aplicación debe contemplar continuidad, sustitución y ausencia, y evitar prometer una comparación automática que los archivos reales no permiten sostener.

Esa misma disciplina sirve para los informes. Una tabla de superficies debería registrar de qué entrega salió y qué criterio de cálculo utilizó. Si la responsable descarga un informe y lo comenta una semana después, el equipo necesita reconstruir el contexto sin pedirle que describa de memoria el color de la fachada. Mantener esa trazabilidad puede requerir conservar resultados, reglas y referencias de versión. El historial no es un adorno para cuando llegue una auditoría: evita que dos personas discutan datos distintos creyendo que hablan del mismo edificio.

Decidir en el servidor quién puede hacer cada cosa

El navegador se ocupa de presentar información y recoger acciones. La aplicación necesita, además, un lugar donde aplicar sus reglas: quién pertenece al proyecto, qué puede consultar y qué operaciones puede realizar. Esa responsabilidad suele recaer en una API propia o en servicios de plataforma que cubran el alcance. Los procesos prolongados, como preparar una representación del modelo, pueden ejecutarse aparte para que una ventana abierta no tenga que dirigir toda la operación. Separar esas responsabilidades facilita entender los fallos y cambiar una pieza sin rehacer el producto entero.

La identidad y el permiso son preguntas distintas. Reconocer a la responsable de la biblioteca no implica que pueda acceder a cualquier otro proyecto, publicar modelos o administrar usuarios. La guía de autorización de OWASP recomienda verificar los permisos en cada petición. Aplicado a nuestro caso, el servidor debe comprobar el proyecto y la acción solicitada, también cuando se pide directamente un archivo o una propiedad. Ocultar el botón de descarga organiza la interfaz; la decisión de entregar el archivo necesita su propia comprobación.

Los secretos de aplicación deben custodiarse fuera del navegador. Los mecanismos que sí requieran credenciales temporales en el cliente necesitan un alcance ajustado al recurso y al uso. No existe una prohibición genérica de que el navegador reciba un token: existe la obligación de entender qué permite y durante cuánto tiempo. La distinción importa porque copiar una credencial con más permisos de los necesarios puede funcionar durante la demostración y seguir funcionando para quien nunca debía recibirla. Aquí la claridad técnica tiene consecuencias bastante más importantes que la estética del panel de acceso.

También hay decisiones que conviene fijar antes de invitar a usuarios: qué datos se guardan, quién puede descargarlos y qué ocurre cuando alguien deja el proyecto. Si se ofrece consulta sin conexión, habrá que explicar qué queda almacenado en el dispositivo y qué información puede estar desactualizada. Permitir editar comentarios sin red añade un problema de sincronización y conflictos que no desaparece por llamarlo «experiencia fluida». Se puede empezar con un alcance menor y explicarlo bien. Es una cortesía muy apreciada por quienes tendrán que utilizarlo en obra.

Elegir una base que puedas mantener después de la demostración

Construir una aplicación propia tiene sentido cuando resuelve un recorrido que las herramientas disponibles cubren mal o cuando integra datos y decisiones que necesitan un tratamiento específico. Si el objetivo es consultar de vez en cuando un modelo y una plataforma existente ya lo permite con los permisos adecuados, utilizarla puede ser una decisión excelente. El mérito de un equipo no se mide por la cantidad de infraestructura que consigue adjudicarse. También se demuestra evitando crear una obligación de mantenimiento sin una ventaja que la justifique.

Cuando sí haga falta desarrollar, una biblioteca abierta puede ofrecer control sobre la interfaz y el tratamiento de los datos. Los servicios gestionados pueden resolver otras partes del recorrido, con sus condiciones, costes y dependencias. La comparación debería incluir procesamiento, almacenamiento, operación, soporte y capacidad del equipo, además de la licencia. Por ejemplo, That Open Components aporta piezas para construir el entorno de visualización; convertirlas en un portal de revisión exige todavía definir las reglas del producto. Tener buenos materiales ayuda mucho. El edificio sigue necesitando proyecto.

Antes de dar por terminada nuestra biblioteca web, propondría recorrer casos deliberadamente incómodos: un usuario sin acceso, una propiedad ausente, una conversión fallida, un elemento eliminado y un comentario sobre una versión anterior. La aplicación debería explicar qué ocurre y conservar el trabajo que pueda conservar. Un estado «procesando» necesita distinguirse de un error que requiere intervención. Si alguien comunica que «el modelo no abre», poder relacionar la petición con una entrega y un proceso concreto ayuda a investigar sin convertir la asistencia en una sesión de adivinación.

La revisión también necesita alternativas al recorrido tridimensional: búsqueda, listas de elementos y controles comprensibles para quien no domina una cámara 3D. El éxito se parece a una persona que termina una tarea y sabe qué ha dejado registrado. La biblioteca habrá salido del escritorio cuando su información llegue con contexto a quien debe decidir, aunque la parte más espectacular siga siendo girar el edificio. El giro es entretenido; que el comentario llegue a la puerta correcta suele resultar bastante más rentable.

Elige un recorrido que otra persona pueda completar: abrir la entrega correcta, localizar algo, tomar una decisión y conservar su contexto. Comprueba permisos y versiones en ese mismo recorrido. Si termina pidiendo por correo los datos que la aplicación debía relacionar, ya sabes qué falta. Añadir más geometría al navegador será vistoso; resolver esa interrupción será útil.