¿Facebook y Twitter reemplazarán a los lectores de feeds?, difícilmente…
¿Facebook y Twitter reemplazarán a los lectores de feeds?, difícilmente…: “
En vista del reciente declive de servicios como el otrora popular lector de feeds Bloglines, o la empresa Six Apart, antes dedicada al desarrollo de la plataforma Movable Type para blogs (la misma que Genbeta ocupaba en sus orígenes), muchas han empezado ya a augurar el declive de los lectores RSS, asegurando que estos se encuentran en retirada para dar paso a servicios sociales como Facebook y Twitter, que pueden ser usados como fuentes de información.
Justamente a raíz de esto, los de Google Reader han sacado a la luz unas cifras bastante esclarecedoras sobre el tema. Se trata de las estadísticas de uso de este lector de feeds desde su lanzamiento, las cuales desmienten que el uso de servicios como este esté decayendo. Muy por el contrario, la cantidad de usuarios activos de Google Reader ha aumentado de forma constante en ese periodo. De hecho, en el gráfico se aprecia que 2009 fue un año de crecimiento récord, donde el uso estuvo cerca de duplicarse (perdonadme la insensatez de aseverar esto sin las cifras exactas en mano).
Que cierre Bloglines no debe ser interpretado como un síntoma de la salud de los agregadores de feeds en general, solo es síntoma de una alta concentración por parte de Google, lo cual no es necesariamente malo, ya que alternativas no faltan (FeedDemon el escritorio, montones de lectores de feeds para móviles, otros en la web como NewsBlur o Feedlook, etc), solo que ninguno ha sido capaz de ofrecerle a los usuarios un servicio del nivel del de GReader. Y en el caso específico de Bloglines, ya sabemos que este lector venía de capa caída desde hace tiempo.
Por supuesto que nos gustaría que existiera más descentralización en este mercado. Pero decir que el cierre Bloglines significa que la lectura de feeds RSS se viene abajo es ir demasiado rápido.
Redes sociales y lectores de feeds: complementos antes que competidores
¿Pero cómo interpretamos la explosiva popularización de Facebook y Twitter como fuentes de noticias? Lo que ocurre simplemente es que estas herramientas han acercado el consumo de contenidos digitales al “gran público”, sólo eso. El usuario avanzado sigue prefiriendo la comodidad y versatilidad de un lector de feeds RSS, ya sea web o de escritorio. ¿O alguno de ustedes ha dejado de usar un lector de feeds para “pasarse” a Twitter como lector de noticias? Creo que muy pocos.
De hecho, es probable que muchos usuarios, al descubrir esta nueva forma de acceder a los contenidos, distinta de los medios tradicionales, hayan querido dar “un paso adelante” y hacer upgrade desde informarse vía Twitter, a agregar a un lector de feeds sus medios online favoritos.
Esto explicaría el explosivo aumento del uso de Google Reader que ocurre casi a la par con la popularización de Facebook/Twitter. No son sustitutos, sino que complementos. No se trata de usar uno y el otro. Cada uno cumple una función específica, con Google Reader recibimos contenidos, con Twitter iniciamos una conversación sobre estos.
El salto desde usar “Twitter para todo”, a ocupar un lector RSS especializado está dado por un aumento del tiempo que el usuario dedica a los medios online. Cuando este tiempo se reparte entre radio, televisión, diarios en papel, etc, solo quedan unos minutos al día para leer en la web.
En este escenario, es obvio que las redes sociales son un canal más conveniente para informarse, ya que funcionan más como la televisión o el diario: son un flujo constante de información que circula en cada momento, que podemos dejar semanas o incluso meses sin atender, para luego echar un vistazo solo a lo más reciente (del mismo modo como cuando volvemos de vacaciones la televisión no nos dice “tienes no-se-cuántos noticieros pendientes por ver”).
En tanto, Google Reader funciona más como el correo electrónico: nos suscribimos a los feeds que nos interesan y en cierto modo se nos obliga a seguirles el rastro, a enterarnos de todo lo que se publica. Existe una pequeña presión para permanecer al día con todo lo que sale.
Pero cuando el usuario va migrando desde los medios tradicionales hacia el contenido web, dispone más tiempo para recibir información online, y es natural que migre a una herramienta más especializada como Reader (que es lo que de hecho ocurre).
Además, Google ha sabido integrar en su lector las funciones sociales que tanto se le alaban a Twitter y Facebook, de forma tal que sean de utilidad para sus usuarios. Personalmente, muchas veces me ha pasado que cuando no tengo tiempo de ponerme al día con todas las suscripciones, simplemente me pongo a revisar lo que han compartido las personas a las que sigo, dejando que el criterio de ellos funcione como un auténtico filtro que separe lo que vale la pena leer de lo irrelevante.
También se nos permite comentar los posts e iniciar conversaciones en el mismo lector, y se nos sugieren feeds acordes a nuestros gustos. Incluso, Reader va más allá de lo que ofrecen las redes sociales tradicionales, y ofrece un algoritmo que ordena los artículos no por antigüedad, sino que por los temas que nos interesan.
Los lectores de feeds tampoco son perfectos: el problema de la “infoxicación”
Hay ciertos elementos que caracterizan a que caracterizan a Twitter y Facebook como fuentes de información y que han sido causantes de su fuerte aceptación entre la gente. Los lectores de feeds bien podrían aprender de esto e incorporar estos elementos, para así acercar más los agregadores RSS al “usuario de a pie”, pero sin perder las ventajas que ya poseen.
Como dije arriba, los lectores RSS tienden a esclavizarnos a “un estilo de vida” de sobreinformación. Esto puede ser aceptable para los “power users” y los llamados nativos digitales, pero no para el usuario común.
Por esto, sería espectacular si Google Reader y otro lectores agregan un “modo de lectura” ad-hoc para los lectores ocasionales. Que en vez de ofrecerse la opción de “marcar como leído lo que sea anterior a 48 horas”, se muestre como pendiente por leer sólo lo publicado en las últimas horas, sin que el usuario tenga usar la opción de “marcar como leído”.
Por supuesto, de implementarse esta función, tendría que estar desactivada por defecto, pero ser sugerida de forma automática a quienes ingresen a su cuenta de Google Reader cada 1 semana o menos. De ese modo, Reader se estaría adaptando a las necesidades de cada tipo de usuario.
El futuro de los blogs
Para ir cerrando este artículo, no niego que estamos presencia de la retirada de los blogs como fenómeno masivo donde todos publiquen contenidos, de la utopía de 1 blog por persona. Ahora existen formas mucho más efectivas de compartir y difundir información personal, ideas, comentarios, opiniones, etc.
Pero como medios de comunicación, los blogs todavía van en alza, y a un ritmo envidiable. Por ejemplo, la red de blogs Gawker ya ha superado en número de lectores a la mayoría de los diarios online de Estados Unidos, y por otras latitudes la tendencia es la misma. Y mientras haya blogs, habrá lectores RSS, ya que es la forma más efectiva y cómoda de acceder a los contenidos de estos.
Imágenes (Flickr) | Latte Blog, Google Reader Mobile, RSS flow
 |
 |
Destripando OAuth en Twitter
Destripando OAuth en Twitter: “
Avisados estábamos de que a partir del 1 de Septiembre en Twitter se dejaba de permitir la autenticación básica en sus aplicaciones. A partir de ese momento, a todos aquellos que éramos amiguitos de desarrollar scripts en perl o python por ejemplo para comunicarse con Twitter, nos surgió una traba nueva, o como se ha denominado en Internet: el OAuthcalipsis. Así pues, la versión anterior de Tweetme.pl, herramienta de la que os hablamos hace tiempo, también dejó de funcionar!Anteriormente, con proveer un par usuario/contraseña de una cuenta válida de Twitter, en el desarrollo y la ejecución, todo era maravilloso de sencillo, aunque más inseguro, puesto que los ingredientes de la receta de la autenticación viajaban en claro (cuántas y cuántas veces habremos dejado de utilizar twitter en eventos con redes compartidas/peligrosas) a través de la red.
OAuth llega a solucionarle a Twitter este problema… y a generarnos otros tantos a los desarrolladores ‘amateur’. Me explicaré un poco mejor. Para la autenticación mediante OAuth, es necesario proveer 4 elementos a Twitter:
- Consumer Key -> El desarrollador ha de registrar, a nombre de una cuenta twitter, la aplicación que desee. Así se generará este identificador único de aplicación.
- Consumer Secret -> Para evitar suplantar diferentes identificadores de aplicación (mediante un ataque de fuerza bruta, pero que muy muy bruta, 21 caracteres alfanuméricos con mayúsculas y minúsuculas), se complementa el par con una clave denominada Consumer Secret.
- Access Token Key -> Para cada usuario, será necesario asociar un identificativo de token que permita suplantar para esa aplicación, a ese usuario mediante ese token para operar en Twitter (de hecho es posible definir la aplicación como de ‘sólo lectura’ o ‘lectura/escritura’ según las necesidades)
- Access Secret -> Como par asociado al Token Key se establece un Token secret.
De esta manera, cuando un usuario requiera la utilización de una aplicación/script que use Twitter, será necesario proveer los cuatro elementos descritos.
Si somos los desarrolladores de la aplicación/script y sólo lo vamos a utilizar nosotros, no hay problema en obtener esos cuatro datos directamente y ‘hardcodearlo’ en el código. El problema viene en el momento en el que se comparte/distribuye esa aplicación a terceros, ya sea como software libre o como software comercial.
Y es que resulta que Twitter no ve con buenos ojos el distribuir el consumer key y consumer secret de una aplicación determinada, de forma masiva. Twitter comunicó que, una vez que un par consumer key/secret son de dominio público, las revocarían (en su propia Revocation List) y la aplicación queda inutilizada.
Por otra parte, el par Access Token Key/secret es único para cada usuario que quiera hacer uso de esa aplicación. En el caso que N usuarios quieran utilizar una aplicación twitter con OAuth, deberán permitir a su usuario twitter que la aplicación identificada por $consumer_key y $consumer_secret lea/escriba en twitter con su identidad.
Para ello es necesario generar un par de Token key/secret distintos para cada cuenta, manteniéndose fijo el par Consumer key/secret que identifican a la aplicación. Para generar los access token key/secret es necesario haber hecho login vía web en Twitter con la cuenta que queramos y, al ejecutar la aplicación, ésta nos deberá proveer de una URL a la que acceder, que nos indicará que la aplicación X requiere nuestra aprobación para ser usada con nuestra cuenta. Después de aceptar, aparecerá un PIN que habrá que introducir en la aplicación para poder obtener el par token key/secret también necesarios para la aplicación.
Algunos lectores diréis: ‘No me cuadra esto que dicen en SbD porque yo no he actualizado mi cliente Twitter (como Tweetdeck por ejemplo) y todo me sigue funcionando igual y sin problemas. Además no he tenido que hacer cosas raras con los tokens y los consumer keys ni nada de esto’. Pues efectivamente, tenéis razón. Y es que es posible, para algunas aplicaciones, utilizar xAuth, otra forma de autenticación que requiere que Twitter manualmente verifique y apruebe ese tipo de autenticación para dicha aplicación en concreto. Me recuerda un poco al procedimiento para añadir una aplicación en la appstore de Apple. Para ello hay que proporcionar, entre otras cosas el ‘consumer key’ de la aplicación, pero que en el fondo son peticiones con POST vía HTTPS a Twitter.
En aplicaciones no ‘reconocidas’ por Twitter o FOSS, aún no se ha solucionado el problema de la distribución del consumer key/secret en formato texto. Debido al concepto Open Source y al tener que poner a disposición de cualquiera el código fuente completo de la aplicación, y que si Twitter descubre un par consumer key/secret éstas serán deshabilitadas, me gustaría proponer un par de opciones, que por supuesto no son la panacea, puesto que son fácilmente bypasseables, pero al menos Twitter no podrá invalidar el par consumer key/secret porque no van en la propia aplicación en modo texto:
- Ofuscar tanto el valor como el nombre del parámetro a la autenticación con OAuth mediante un ROT13 o cualquier otro mecanismo de cifrado. (Método propuesto por Marc Mims, mantenedor del módulo Net::Twitter para Perl)
De esta manera:
Net::Twitter->new(
traits => [qw/API::REST OAuth RetryOnError/],
decode_entities => 1,
(
grep tr/a-zA-Z/n-za-mN-ZA-M/, map $_,
pbafhzre_xrl => 'ZlPbafhzreXrl',
pbahfzre_frperg => 'ZlFrperg',
),
);
En tiempo de ejecución se sustituye por:
Net::Twitter->new(
traits => [qw/API::REST OAuth RetryOnError/],
decode_entities => 1,
consumer_key => 'MyConsumerKey',
consumer_secret => 'MySecret',
);
Lo cual no es publicarlos en claro en el código.
- Otra opción sería forzar que los valores de ambas variables estén en una ubicación remota. Puesto que para acceder a Twitter, es necesario que haya conectividad con Internet, antes de acceder a la autenticación, es obtener consumer_key y consumer_secret previamente y utilizarlos en la autenticación. Si Twitter bloquea dicho par, con generar uno nuevo, no es necesario bajar una nueva versión de la aplicación y ‘hardcodearlos’ (que puede generar retrasos de semanas si nos referimos a una aplicación que esté en la AppStore de Apple por ejemplo) sino hacer un cambio en el servidor únicamente.
Para Tweetme.pl he implementado una mezcla de ambas, que no incumpla las exigencias de Twitter, pero que permita no tener que entregar un programa compilado y ofuscado (que finalmente sería comprometido igualmente por gente con capacidades de reversing), ni que utilice xAuth, por el papeleo y trámite que ello permite con Twitter (siempre y cuando aprueben xAuth en una aplicación Open Source, claro está). Además, en esta nueva versión se provee de un script para que sea sencillo obtener los tokens y personalizarlo para cada usuario.
Probando Adium como cliente de Twitter
Probando Adium como cliente de Twitter: “
El uso que casi todo maquero le ha dado a Adium desde que lo utiliza es para el MSN Messenger, pero la gran ventaja de tener un cliente multiprotocolo es que le podemos sacar muchísimo partido con otras plataformas.
Yo personalmente conecto siempre mi cuenta de Facebook y ahora también la de Twitter, ya que actualizar el Timeline y ver rápidamente algún Tweet desde Adium la verdad es que hace que agilice bastante mis tiempos de ejecución en el ordenador.
Está claro que no es la solución más bonita ni la más elegante, y posiblemente tampoco es la más funcional, pero se trata de un recurso para los que no utilizamos mucho Twitter que nos permite no tener que abrir otra aplicación y hacer las tareas básicas en un momento.
Artículos relacionados
- Un cliente de Twitter elegante y gratuíto (0)
- Twitter compra Tweetie y la hace gratuíta (1)
- Twitpocalypse: qué fue y qué sucedió (0)
- Tweetie para Mac sigue siendo Tweetie (1)
- TweetDeck se actualiza a la versión 0.33 (0)
Hibari, más minimalismo aplicado a Twitter
Hibari, más minimalismo aplicado a Twitter: “
La cantidad de clientes que hay de Twitter para Mac OS X es realmente estremecedora, pero cada vez que se lanza uno nuevo hay que estar atento para ver que es lo que nos puede ofrecer con diferencia al resto.
Hibari no ofrece ninguna opción que no hayamos visto ya pero sí que hace algo muy bien: utiliza la sencillez como base para el uso, así que para la gente que no se complique mucho puede resultar ideal.
Yo lo he probado y no me ha gustado, y si a eso le sumamos que vale más de 10 euros creo que descartado del todo.
Enlace | Hibari
Fuente | Applesfera
Tags: aplicaciones, Apple, Descarga, Mac OS X
Artículos relacionados
- WindowIconSizeMBI, un Menulet interesante (0)
- Web Snapper te permite capturar páginas web (0)
- Watts: con un ojo en la batería (4)
- VLC 1.10 ya disponible (1)
- VirtualBox se actualiza a la versión 3.2.4 (8)
“
Systems Computers U.S.A. Inc.© 