es-robot.com

Estoy demasiado influenciado por la idea de la web cómo plataforma de desarrollo. Es debido a que trabajo con esta tecnología y tengo la sensación de que cualquier cosa se puede hacer con la web. Aunque soy consciente de que hay cosas que son imposibles, creo que la tendencia a integrar todo en la web es más fuerte (entendiendo la web en un sentido amplio, cómo plataforma que comprende navegador, http, servidores, etc).

Mi último invento es adaptar el antiguo emobot para que funcione directamente desde el navegador. En la versión anterior, había un programa escrito en ruby ejecutando en el ordenador y un programa ejecutando en el robot en arduino. La idea original era integrarlo con la web a través de http y que se pudieran descargar “personalidades” en el robot.

Pero haciendo pruebas desarrollando una extensión para firefox, estoy probando con una  nueva versión, en la que reutilizo el robot con arduino con un nuevo programa basado en un plugin sobre firefox para leer/escribir en el puerto serie, combinado con html5 y web workers. el objetivo es crear una página web desde la que se puede interactuar directamente con el robot a través de usb. El conjunto completo sería convertible en aplicación de escritorio a través de prism.

Que yo sepa, podría ser uno de los primeros robots programados en javascript, aunque reconozco que es difícil llamar “robot” a un servo con unos leds. En algún momento revisaré la parte mecánica, para que se le pueda llamar robot de verdad (más servos, algunos sensores, etc).

En readwriteweb he leido las nuevas características de firefox 3.6 beta. Entre las novedades de la nueva versión, hay una funcionalidad pequeña que puede ser importante para el futuro: la posibilidad de hacer drag & drop de ficheros locales. Esta característica permitirá arrastrar directamente ficheros de video a youtube o fotos a flickr sin necesidad de usar plugins java o flash como hasta ahora. Así que se cerrará un poco más la separación entre aplicaciones web y aplicaciones de escritorio.

Otra hecho interesante es que el proyecto personas se incorpora a firefox. Así que es posible y deseable que prism finalmente se base en completamente en firefox en vez de xulrunner y termine incorporándose a firefox al igual que personas. De la misma forma que chrome permite crear aplicaciones a partir de sitios web y además se podrán reutilizar todos los plugins existentes sin esfuerzo.

Recopilando un poco, en la siguiente versión de firefox tendremos video nativo con posibilidad de ejecutar a pantalla completa, drag & drop de ficheros locales, almacenamiento local e hilos de ejecución paralela gracias a html5 y, a través de prism, conversión de aplicaciones web en aplicaciones de escritorio y alertas en el área de notificación del escritorio.

En TechCrunch además de presentar las últimas novedades de Chrome, se han dedicado a rastrear las listas de correo del proyecto Chrome para buscar las pistas de por dónde puede ir el desarrollo de Chrome OS. Parece ser que Chrome integrará una barra de estado que muestre la carga de la batería (al estilo de las barras de notificación de los escritorios actuales) y un modo de navegación compacto, me imagino que para darle un aspecto más parecido a aplicación de escritorio a las aplicaciones web.

Por mi parte, he hecho una modificación similar a uno de los scripts de Prism, para ocultar completamente la barra de navegación inferior. Es un cambio relativamente sencillo, sólo hay que editar el fichero webrunner.js (aquí está mi versión de webrunner.js, por si alguien se atreve a trastear). Aunque es algo sencillo, ahora mis aplicaciones web están todavía más integradas en el escritorio, aunque la solución óptima sería mostrar la barra en algunos momentos (cuando una página está cargando por ejemplo), con alguna combinación de teclas, o con un menú en la ventana de la aplicación.

Este pequeño hack puede ser muy útil para los usuarios de netbooks mientras no llega Chrome OS. La barra inferior de prism ocupa bastante y normalmente no aporta demasiada información y por ahora no se puede ocultar con la configuración de Prism. La solución definitiva sería hacer algo parecido a lo que tiene Chrome OS: ocultar la barra excepto cuando se está cargando una página,  o bien permitir que se pueda habilitar la visualización de la barra desde una opción del menu de la ventana o mediante una combinación de teclas.

Por cierto, con este parche se consigue otro efecto que es el sueño de muchos desarrolladores de aplicaciones: una aplicación web a pantalla completa. Con la tecla F11 se maximiza la ventana y cómo tenemos oculta la barra de estado, sólo se muestra la aplicación web a pantalla completa.

Finalmente se ha publicado la primera versión beta de prism, con un sitio web nuevo, por lo que parece que el proyecto sigue vivo. Al hilo de esta nueva versión, Matthew Gertner, responsable del proyecto, explica en su blog una idea interesante ¿quién se encargará de la integración la integración de las aplicaciones web actuales con el escritorio?

Lo explica con un ejemplo sencillo: la notificación de mensajes nuevos de correo electrónico en una ventana pop-up. Un usuario “normal” no tiene acceso al nivel de detalle necesario para realizar este cambio, hacen falta usuarios avanzados o desarrolladores de aplicaciones. El desarrollador de la aplicación web tiene la posibilidad de notificar eventos a través de un api, pero Matthew piensa que a corto plazo los desarrolladores web no van a hacer el esfuerzo y yo creo que si no se hace con cuidado se acoplaria demasiado la aplicacion web con la integración en el escritorio.

La opción que promueven en prism (y que me parece bastante correcta) es el desarrollo de un fichero que contenga el código específico de integración, lo que llaman un bundle. La opinión de Matthew es que a partir de ésta versión aparecerán más desarrolladores de bundles que personalicen el comportamiento de una aplicación web.

Esa personalización o integración con el escritorio deberían hacerla los responsables del sitio web, ya que son los que tienen el conocimiento de cómo funciona la aplicación: cuando generar eventos, qué uri’s maneja la aplicación o cualquier otro detalle de la aplicación. Pero debería ser opcional: si se utiliza un cliente integrado en el escritorio cómo prism, se cargan los scripts de integración y si no se ignoran. Por eso se podría estandarizar el uso de una etiqueta al estilo de los iconos de aplicación o de flujos rss:


<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />



<link rel="alternate" type="application/rss+xml" title="RSS Feed" href="/rss.xml"/>


Con una etiqueta meta al estilo de:

<link rel="desktop integration" type="application/desktop" title="Desktop integration" href="app.webapp" />

El cliente podría utilizar los scripts de integración con el escritorio en caso de que la soporte. Es decir si el cliente es prism (o un cliente con integración con el escritorio) es usa el fichero webapp y si no se ignora.

De está forma se podría promover un api común a varios navegadores, al estilo de lo que está haciendo google con gears, y se podría generalizar la integración de aplicaciones web en el escritorio.

Por este camino, puede que la “web 3.0″ sea desaparición de las aplicaciones web, que se convertirán en aplicaciones integradas en el escritorio.

Acabo de leer un artículo interesante de Enrique Dans sobre el navegador cómo sistema operativo. Estaba escribiendo un comentario, pero al final he escrito un artículo. Comparto la idea general: google no quiere reemplazar al sistema operativo técnicamente hablando, sino capturar la experiencia de usuario.

Aunque esto probablemente marque la estrategia de google, no creo que sea el objetivo de chrome. La prioridad de google para capturar la experiencia de usuario es llevar las aplicaciones a su terreno, la web, y sacarlas del escritorio (o del sistema operativo). Pero a pesar de chrome, google podría usar firefox para conseguir ese objetivo.

Lo más razonable es que el navegador termine desapareciendo, pero a largo plazo. Creo que no es más que una herencia de la época de windows 98 y actualmente no es más que un proxy a las aplicaciones web que debería ser sustituido directamente por éstas: búsquedas en internet, aplicaciones sociales para gestionar nuestros contactos, calendarios, procesadores de texto, lectores de noticias, etc. Casi todo ya está on-line y si alguien hiciese una estadística, la mayoría de páginas web que visitamos pertenecen a verdaderas aplicaciones web y a páginas web sueltas.

Pero hay elementos que se escapan (por ahora) del control de los navegadores. Por ejemplo, algo tan tonto cómo las notificaciones de escritorio no se pueden hacer con una aplicación web. Tampoco arrastrar ficheros ó gestionar las aplicaciones instaladas en un ordenador. Y si el objetivo es construir un sistema operativo sobre internet, estas operaciones tienen que funcionar. Hay plataformas que están intentando la integración del escritorio y la web en esta línea: prism de mozilla, air de adobe y silverlight de microsoft.

Así que tal cómo está planteado chrome actualmente, si bien mejora el acceso a las aplicaciones web, necesitará algo más para reemplazar al sistema operativo. Si google desarrolla un producto en esta línea, con soporte de múltiples sistemas operativos, entonces microsoft debería asustarse. Y yo creo que terminarán haciéndolo (o están ya en ello), pero necesitarán algo más que chrome.

A corto plazo, google tiene más opciones en los netbooks, se está empezando a hablar de usar android en estos aparatos. Quien sabe, lo mismo antes de lo que pensamos terminamos usando un sistema operativo de google.

Actualización: acabo de ver que Google Gears tiene un api para integración en el escritorio. Así que Google sí que está desarrollando ese algo más necesario. De momento no tiene una integración fuerte con el escritorio, pero probablemente la terminará teniendo.