Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Interfaces en aplicaciones web

Posted by josempelaez en Sábado, 13 septiembre 2008

Opino que Google usa el navegador Chrome como medio para fortalecer el empleo de aplicaciones en la web. Las interfaces de usuario tienen una papel relevante en esta práctica, pero me parece que ciertas propuestas para su "enriquecimiento" se deben más a intereses comerciales que a mejorar las «experiencias de uso».

En las dos entradas precedentes anoté varias reflexiones y potenciales consecuencias del lanzamiento del navegador de Google en relación con la competitividad, la diferenciación, los terminales y la ubicuidad. En ésta me refiero más a las implicaciones que Chrome puede tener en las interfaces de los contenidos y aplicaciones de la web. Los programas que gobiernan su comportamiento se presentan ante el usuario a través de sus interfaces, y no debemos olvidarlo.

Interfaces en aplicaciones web

cloud_services_examples

Ejemplos de la oferta de «servicios en la nube» (Forrester Research)

Hay analistas que han llegado a comparar esta nueva herramienta con un sistema operativo. Algunos técnicos han criticado este enfoque basándose en la teoría convencional sobre los SO, además de recordar que Chrome requiere trabajar sobre un Windows, Linux, Mac OS X…, que son los que manejan los recursos de máquina. La realidad es que, con independencia de lo que piensen y digan los expertos en informática, “el sistema” se reduce a la interfaz para una inmensa mayoría de los usuarios.

Centrándome en este caso considero que, parafraseando a Nicholas Carr, el navegador es el medio y las aplicaciones el mensaje. ¿Por qué? Google —y otros promotores del empleo del software como servicio (SaaS, on-demand, cloud computing)— necesita una herramienta estándar, robusta, potente y multiaplicación en el lado de una red que ocupa el terminal que suministra servicios a los clientes particulares y empresariales como son Search, News, Books, Maps, Gmail, Reader, Docs, Sites, Apps Engine… Además de los ejemplos de Google, hay otros muchos proponentes de aplicaciones y servicios en la web, como muestran el esquema visual del blog de Peter Laird y el repositorio en SaaS Showplace de Jeff Kaplan.

Microsoft decidió sumarse a ese enfoque a finales de 2005, con el famoso memo de Ray Ozzie. Lanzó en 2007 su mensaje de «software-plus-services», para cuya materialización promueve su plug-in Silverlight para navegadores. Es una parte de la plataforma WPF, que desplaza el protagonismo de Windows hacia otra capa sobre este sistema operativo: .NET. Añadiendo un marco de trabajo bajo el navegador quiere competir con la tecnología Flash, predominante en el campo de las RIA. Estas aplicaciones de internet, con una interfaz más “rica” en prestaciones y aspecto, lucen más en el streaming de imágenes, audio y en las animaciones visuales de la interfaz.

Adobe adquirió la tecnología dominante en este terreno al integrar Macromedia. Actualmente defiende la posición y ventajas del plug-in Flash para los navegadores con su entorno Adobe Flex para desarrollar aplicaciones, y con el AIR para poder ejecutar en el escritorio bajo el navegador. Es el antiguo proyecto Apollo, concebido a final de 2005, que es multiplataforma operativa y se basa en los estándares de la web. Sun Microsystems, que desarrolló inicialmente Java, el lenguaje más usado en las aplicaciones web corporativas, está ofreciendo su nueva herramienta de scripting JavaFX para enriquecer las interfaces.

En este campo de las RIA —acrónimo que también se ha empleado para acortar “rich interface app“, y donde el rich se ha opuesto al thin client—, Google propone usar las técnicas clásicas y estándar de la web, que Adaptive Path bautizó como Ajax en 2005. El precio parece ser el de ir por detrás en las capacidades mediáticas hasta que se extiendan los estándares Canvas y SVG de HTML5.

Lo que pasa es que no todas las aplicaciones necesitan una interfaz e interacción muy “rica” desde el lado del usuario, aunque muchos desarrolladores opinen diferente escudándose en la usabilidad. No hay que olvidar que uno de los principales argumentos que emplean Adobe, Microsoft y Sun para promover sus enfoques es el de que los desarrolladores y creadores de contenido puedan reutilizar las capacidades adquiridas trabajando con sus herramientas privativas anteriores. En diciembre de 2006, citando a Larry Dignant, el CEO de Adobe pidió a los

«[financial] analysts to think about Apollo the same way they would characterize Adobe Reader or Flash Player, it’s a client that can be used to help others build unique applications and allow Adobe to sell more tools.» [negrita mía]

google-map-madrid

Imagen de Google Maps con sitios recomendados en Madrid

En Maps y Suggest, Google había empleado el enfoque de no usar otra cosa que el navegador para dialogar con el usuario sin tener que ir siempre a buscar información al servidor, pero el lanzamiento de Gmail en abril de 2004 marcó un hito significativo en este tipo de interacción. La confirmación durante 2005 de que, con la interfaz web canónica, se podían hacer más cosas de las que muchos creían relanzó a final de 2006 los esfuerzos del resto para controlar esa parte de la plataforma web. En el caso de Google, pienso que el uso de extensiones del navegador o de aplicaciones de escritorio para el empleo de YouTube, Earth, Picasa, SketchUp, Lively… bien podrían considerarse situaciones transitorias mientras progresa el establecimiento y uso en el cliente (escritorio y móvil) de estándares más avanzados.

También sucede que, aunque las interfaces sean muy “ricas”, pueden no ser efectivas para un usuario normal. Esto tiene mucha más importancia en el mercado empresarial que en el de particulares. Por consiguiente, creo que Chrome representa otro paso importante de Google en el campo de las RIA, especialmente si recordamos su mantra actualizado de «search, ads and apps».

Considerando las aplicaciones, en The Sunday Times está escrito que «With Chrome, Google is hoping to hasten a new world where customers will no longer have to buy a boxed-up computer program in order to upgrade.» Esto no debe de hacer muy feliz a ciertos fabricantes de informatica. Citando a Gianluca Brugnoli, analista de diseño de frog design:

«The pure online web application model based on Chrome, with few local components installed on your hardware, is certainly the most promising one: truly open, flexible, and easy to upgrade. But for now, Chrome is still a web browser, and its dependency from the web browser’s user experience could be a soft spot, or at least a strong constraint for the web application’s evolution.»

En resumen, me parece que hemos asistido a un movimiento muy relevante en el tablero de la partida que se “juega” entre los que defienden más potencia en el cliente frente al protagonismo de la red, sin sacrificar la «experiencia de usuario». Continuaré en una próxima ocasión argumentando sobre las opciones de los contendientes.

Entradas relacionadas: Terminales ubicuos para navegar, Navegar por las aplicaciones, Computadoras sin margen, Interfaces para gestión

2 comentarios to “Interfaces en aplicaciones web”

  1. Muy buenos artículos los tres últimos que has escrito.

    Solo hacer notar algo, y es que la mayoría no ha dado toda la importancia que creo que tiene al nuevo motor Javascript. V8 es realmente el salto que necesitaba google para poder hacer aplicaciones realmente grandes sobre un navegador que sean “indexables”.

    Hay que recordar que Google basa su apuesta RIA sobre GWT, que no es mas que un compilador Java -> Javascript. Y Javascript no es un lenguaje pensado para estas tareas. Anteriormente, la velocidad de los equipos duplicada cada 18 meses permitía que el javascript fuese cada vez más rápido. Pero en los últimos años la apuesta no es por velocidad en serie, si no en paralelo para ser más eficiente energéticamente. Así que Google necesitaba un cambio de paradigma para permitir la progresión de sus aplicaciones. El cambio de paradigma es V8.

    Google vive de la búsqueda (adsense usa sus algoritmos de búsqueda…), y la búsqueda en aplicaciones flash, javaFx y silverligth es muy complicada. Pero javascript manipulando un documento… es indexable.

  2. Diego, muchas gracias por aclararnos la importancia del nuevo V8 dada su relación con el GWT y sus mejores posibilidades a la hora de indexar los contenidos. No estaba teniendo en cuenta esta relación en mi análisis. Veo que tendré que intentar profundizar lo que pueda en cuestiones más técnicas para entender las implicaciones potenciales.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: