convergencia entre la web y la tv

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.

qué esperar de html5

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.

twitter, twitter

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.

processing.js

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.

más sobre el debate de html5

Un estudio concluye que el futuro de las aplicaciones móviles está en las aplicaciones móviles web adaptadas a los interfaces táctiles. El estudio viene de una empresa que se dedica a las búsquedas en la web para terminales táctiles, así que no es extraño que hayan llegado a esa conclusión.

Sin embargo el estudio apoya con cifras la idea de que los juegos y las aplicaciones de entretenimiento se distribuyen más como aplicaciones nativas mientras que las apliaciones sociales y las aplicaciones para compras y servicios se distribuyen más como aplicaciones web.

En cualquier caso existe la duda técnica de si las aplicaciones basadas en web serán tan rápidas como las aplicaciones de escritorio. Muchas aplicaciones son lo suficientemente buenas, pero probablemente los juegos más exigentes no sean adaptables a la web.

Un ejemplo que me he encontrtado es el de freeciv un juego de escritorio para el que han desarrollado un frontend en html5 y por ahora la experiencia no me ha parecido demasiado buena. Se puede jugar, pero no tiene una interfaz demasiado buena comparado con el juego de escritorio.

Por otro lado está la duda económica. Las aplicaciones web generan ingresos principalmente por medio de la publicidad y las suscripciones. Las aplicaciones nativas lo hacen mayoritariamente a través del cobro por descarga. Aunque técnicamente sea viable desarrollar juegos completamente html5, es posible que generen más ingresos con el modelo de cobro por descarga, por lo que quizá no sea rentable desarrollar juegos html5.