es-robot.com

Chris Anderson (famoso por su teoría de la larga cola) y Michael Wolff han levantado la polémica entre los bloggers con un artículo en wired en el que declaran que la web ha muerto. Según su punto de vista, la web ha muerto básicamente porque cada vez se accede menos a las aplicaciones online a través de un navegador y cada vez se usan más aplicaciones específicas para iPhone o iPad.

Uno de los problemas del artículo es haber utilizado un gráfico de Cisco para apoyar su teoría, por lo que se les ha criticado duramente:

• El gráfico muestra la cantidad de tráfico, el video consume mucho más tráfico que la web.
• En la etiqueta video está incluido el video a través de la web (video a través de flash en sitios cómo youtube). Técnicamente se usa un navegador web para acceder a ese video.
• La medida en tráfico no es comparable a la medida en tiempo de uso. La gráfica mide ancho de banda consumido porque a Cisco es un dato que le interesa para optimizar sus routers, pero es complicado extrapolar que la web ha muerto a partir de éste gráfico.
• En su razonamiento exageran el peso de las aplicaciones de iPhone y iPad. Comparado con el total de consumo de datos no creo que sean muy relevantes, aunque probablemente dominen en sus respectivos mercados.

Sin embargo sus comentarios tienen cierto sentido, puede que se esté iniciando un cambio de tendencia:

• Las aplicaciones en iPhone y iPad son (en general) más fáciles de usar que las páginas web. El navegador supone un añadido sobre las aplicaciones web  que complica su uso.
• Google va a abrir una tienda de aplicaciones, cada vez más usuarios utilizan esta forma para buscar e instalar aplicaciones nativas y a partir de que google abrá su tienda también web. Es una forma de ocultar el navegador y esconder su complejidad, ya que permitirá instalar aplicaciones web.
• Para los desarrolladores es una forma más fácil de monetizar una aplicación que la publicidad, por lo que habrá dinero corriendo y negocio, al igual que la App Store de Apple.

Creo que no han tenido en cuenta en escenario que en mi opinión más probable: el navegador es cada vez más un elemento que no aporta nada al usuario, que quiere acceder a aplicaciones web. Sin embargo es un elemento casi imprescindible para la arquitectura actual de aplicaciones web, así que lo más probable es que el navegador se integre en el sistema operativo. Google va a tratar de conseguirlo a través de Chrome OS. Uno de los principios descritos en The Laws of Simplicity de Jonh Maeda es el de ocultar la complejidad. Así cómo google es una caja de búsqueda sencilla que oculta miles de servidores y protocolos complejos, el navegador es un elemento complejo que, cada vez más, sólo sirve para acceder a aplicaciones web.

Por otra parte la web se apoya en el protocolo HTTP y muchos aplicaciones aunque sean nativas seguiran usando el protocolo de la web para acceder a la información. Así que  técnicamente la web sigue funcionando aunque sea por detrás. Por ejemplo TeetDeck, es una aplicación nativa, pero se apoya en el api de twitter basado en http.

En definitiva, a los usuarios les dará igual cómo acceder a internet, sea a través de un navegador o una aplicación nativa. En un estudio de hace tiempo, la mayoría de usuarios ni si quiera sabían lo que era un navegador. Las aplicaciones que usen internet se construirán a base de aplicaciones web ó nativas pero en cualquier caso la web no morirá sino que probablemente se transformará y el navegador quedará oculto en la tripas del sistema operativo.

Desde hace mucho, mucho tiempo se espera la convergencia entre la tv y la web. Sin embargo no ha terminado de funcionar, a pesar de que existe la tecnología y se han creado muchos dispositivos con este objetivo.

Un estudio de nielsen puede haber encontrado la clave para comprender porqué no termina de funcionar. Segun Nielsen, la integración ya ha comenzado, pero no en la forma que se esperaba: en vez de utilizar la televisión para acceder a la web, se utiliza un ordenador a la vez que la televisión. Mac Slocum explica que la experiencia de ver la tele y acceder a la web es muy distinta. La web es una tecnología que requiere mucha más atención, participación y es más absorbente que la tv. Empezando por los periféricos de entrada, no es lo mismo un teclado  que un mando a distancia, están pensados para usos muy diferentes.

La navegación en la web es una experiencia más personal, que requiere más atención comparado con ver la tv, que es una experiencia más social y compartida. Por eso es posible que la convergencia no se produzca permitiendo  ver la web en la televisión, sino que puede que aparezca una web específica para la televisión, que permita interaccionar desde un ordenador o telefono móvil, mientras se han elegido unos programas para ver en la tv de forma más social, una web con dos modos de interacción que englobe a la actual tv y a la web actual.

Un artículo más sobre html5: expectativas, novedades, cambios, etc. Nada interesante para los que sigan la evolución de html5, excepto que explica porqué se han integrado dos tipos de cambios en la nueva versión de html. Por un lado tenemos al W3C que ha incorporado cambios relacionados con la estructura documental y semántica de html con nuevas etiquetas (header, footer, dialog, aside, etc) y por otro el WHATWG que ha incluido aspectos más relacionados con el desarrollo de aplicaciones (etiquetas canvas, video, audio y nuevos apis web workers y local storage). Creo que esta parte es la que tendrá más peso en el futuro, convirtiendo a la web en una plataforma de desarrollo.

En lo que no estoy de acuerdo es en el ámbito temporal. Aunque microsoft tiene mucho peso, el soporte en navegadores no-microsoft es muy amplio y generalizado y no debería quedarse atrás. Aunque el W3C espera que hasta 2022 no haya una versión estandarizada, probablemente haya un estándar de facto implementado (incluyendo a microsoft) antes de 2-3 años (con la excepción del vídeo, dónde los codecs son un problema importante, que no tiene solución a corto plazo).

PD: he añadido la etiqueta web2.0, aunque ya suena anticuado y pasado de moda. Aún así han quedado los cambios más “estructurales” de la web2.0: la web cómo plataforma social, los interfaces ajax, etc.

Primero, debido a una metedura de pata configurando feedburner (con el que publico a través de twitterfeed) había dejado de funcionar la publicación en twitter. Debería estar resuelto, espero que este post sirva de prueba.

Segundo que la metedura de pata vino porque he cambiado la fuente rss para que llegue a través de feedburner y me sorprende que haya alrededor de 50 suscriptores por RSS! Ya sé que es una misería, pero es mucho más de lo que me esperaba, gracias por seguir leyendo.

Y tercero, voy a hacer un breve comentario de mi escasa experiencia con twitter. Al principio, me parecía que twitter era cómo un histórico del estado de messenger: al igual que mucha gente va actualizando su estado en messenger, twitter era cómo un log de este tipo de mensajes de estado: “Estoy en casa”, “Leyendo choque de reyes”, “Viendo el partido del Real Madrid”, etc. Personalmente, no le veía mucha utilidad a escribir públicamente este tipo de mensajes.

Pero creo que esa función inicial se ha visto sustituida por una función nueva: el retweet. Un retweet sirve para reenviar un tweet publicado por otra persona. Algo sencillo, pero que cambia la filosofía de twitter. La gente publica sus artículos, noticias, etc. en twitter y si son buenas son “retweeteadas”, con lo que twitter se ha convertido en un medio de difusión social. Al contrario que los filtros sociales cómo digg o meneame, en los que la finalidad es que los artículos aparezcan en una portada común, twitter no tiene más objetivo que comunicar los artículos publicados de contacto en contacto, con lo que cumple mejor la función de difusión social.

Me imagino un grafo social, en el que en un punto se publica un artículo y por medio de retweets, el artículo se difunde a través del grafo. Si es bueno, llega a muchos nodos y si no, apenas se difunde. Es sólo la impresión de un novato en twitter que quería compartir con todos, podéis comentar, retweetear o lo que queráis.

Para los que trabajen con arduino, sabrán que es un proyecto basado en Processing, un lenguaje y entorno de programación para aplicaciones multimedia e instalaciones interactivas. Lo que quizá no sepan es que processing se ha portado a javascript utilizando la nueva etiqueta canvas de html5: processing.js. En el estado actual, soporta muchas de las instrucciones de processing, excepto las instrucciones 3D, que esperan poder implementarlas cuando se desarrolle una etiqueta canvas 3D (para firefox ya hay un intento de implementación). Además processing.js fue portado por John Resig, creador entre otros proyectos de la librería jquery. Igualmente sorprendente para mí es que muchos de los ejemplos de chrome experiments están hechos con processing.js.

Una ventaja de processing.js sobre processing es que además de ejecutarse en navegadores recientes y aceptables sin ningún plugin (explorer no entra en esta categoría todavía) se integra fácilmente con el entorno web y se pueden agregar otras librerías javascript (jquery, por ejemplo) para realizar experimentos muy visuales.

El lado negativo está en el rendimiento, que no es nada bueno. En mi ordenador con 4 cores, se me quedaba bloqueado porque sólo tiraba de una cpu. Si alguien diseña un proyecto complejo, debería implementar parte de la lógica con web workers.