Nando Quintana

El jueves a media tarde, nos hemos juntado unos cuantos programadores en la sede de Google en Madrid. La sesión estuvo guiada por un pequeño equipo de programadores de Google. En concreto, el principal ponente venía de la sede Inglesa de la compañía.

El tono fué siempre muy cordial y el ambiente muy distendido. Los contenidos no fueron demasiado técnicos, se trataba de una introducción a los aspectos más significativos del nuevo API de youtube.

A lo largo de la exposición pudimos ver y tocar unas pocas demos. Los ejemplos fueron fáciles de seguir, no nos entretuvimos en florituras programáticas. El repaso que hicimos de las características del nuevo API, nos permite intuir la potencia del nuevo juguete que Google ha liberado.

El API de Youtube descansa sobre el concepto GData, que es la forma que google ha elegido para representar los datos intercambiados y que está basado en el conocido ATOM.

Google ha cuidado el aspecto de la confianza. Es posible autorizar a una aplicación desarrollada por un tercero, de forma que tenga accesso a tus datos de google (contactos, videos, etc.) Ya no es necesario, por tanto, revelar tu nombre de usuario y contraseña a una aplicación.

Ahora Youtube puede ser utilizado como un mero contenedor de videos: una aplicación sube un video a youtube y solo esa misma aplicación lo puede mostrar. Es decir, no aparece en las búsquedas del portal Youtube.

Las posibilidades de personalización del reproductor flash son ilimitadas. Ahora ya no hay que incrustar el reproductor en forma de tag “object”, sino que es posible utilizar el api mediante javascript. El reproductor por defecto no tiene branding (chromeless, en inglés), es decir, que el aspecto es neutro y se va construyendo componente a componente.

Además, es posible incluir código action script (swf) al player, lo que amplia enormemente las posibilidades de personalización del reproductor.

En las siguientes demos, se utilizan diferentes recursos del api de Youtube, empleando el lenguaje javascript.

Las librerías necesarias están en el siguiente fichero que todo desarrollador debería descargarse e incluir como referencis en su web:

http://swfobject.googlecode.com/svn/tags/rc3/swfobject/src/swfobject.js

Para una información más extensa sobre esta librería, visitar esta sección de la referencia del API:

http://code.google.com/apis/youtube/js_api_reference.html

demo 1(código fuente)

demo 2(código fuente)

demo 3(código fuente)

demo 4http://kelpi.com/script/fa798f

Este otro ejemplo, está extraido de la referencia del API y recoge y resume las demos anteriores.

Puedes echar un vistazo a otrasreacciones…

Son famosos los originales logos con que Google nos deleita con motivo de ciertas efemérides y festividades.

Hoy, día de San Valentín, no iba a ser menos y la segunda ‘o’ de google se ha convertido en una sugerente fresa untada de chocolate.

¿Por qué la búsqueda asociada a cada logo no está internacionalizada?

Sería mucho más sexy que cuando estoy en mi Google en Español, el enlace del logo llevase a una búsqueda como: día de san valentín, en lugar de la original inglesa.

Bueno, ahí queda mi granito de arena al brainstorming de Goolge.

¿Y tú? ¿Qué mejorarías en Google?

Da un poco de impresión ver que una de las gigantes de Internet cierra temporalmente por mantenimiento. Me imagino las gotas de sudor de los sysadmins y programadores que están haciendole el upgrade a la web.

Aquí teneis un pantallazo de la páginade mantenimiento de YouTube:

¿Es más simpático el tipo este o el fontanero de BlogLines?

Cuando escribimos un anuncio por palabras (claro, cómo si no) en un periódico apenas albergamos dudas sobre los términos lingüísticos a utilizar. La situación cambia si es una web donde irán a parar nuestras palabras.

Me refiero sobre todo a las dicotomías pragmáticas como comprar y vender, alquilar y ¿alquilar?, emplear y buscar empleo, etc.

La información en Internet es más valiosa cuanto más recuperable es. Es decir, cuando alguien busca información acude a buscadores, favoritos compartidos, directorios, etc. De toda esta información recuperada, encuentra valiosa la información relevante y desprecia la información no relevante. Obvio. También desprecia la que no encuentra. Evidentemente.

Utilizo el término relevancia, no como el orden en importancia de los resultados sino como el grado de relación con los términos de la búsqueda. O como utilidad para completar el propósito del que busca.

Es común escribir y publicar contenidos en la Web con el deseo de que sean recuperados y además de que sean relevantes para quien busca y los recupera. Esto exige unas buenas prácticas de programación xhtml resumidas en cualquier manual de SERP (search engine resulst positioning).

Por otro lado se requieren cierta dosis de ingeniería social para empatizar con el potencial lector. Es necesario ponerse en el lugar del lector y pronosticar la forma en que este buscará información.

Por ejemplo, si estamos publicando fotos sobre nuestras últimas creaciones artísticas basadas en papel doblado, podemos construir una galería de fotos bajo el título de “cocotología” o “papirofléxia”. Si embargo podemos intuir que mucha gente, sencillamente utlizará los términos “pajarita de papel” o “barco de papel”.

Mientras que en un periódico es razonable escribir “se vende coche”, en la web nos damos cuenta de que los usuarios buscan mediante los términos “comprar coche”.

Ya existen aplicaciones que recopilan y resumen la forma en que los usuarios buscan. En la siguiente imagen aparece representada la cantidad de veces en las que se utiliza el término “comprar” (en rojo) frente a las veces en que el usuario prefirió “se vende” (en azul):

google trends

Esta costumbre podría llegar a influir en la forma en que evoluciona el lenguaje, premiando la oralidad y coloquialidad del lenguaje, haciendo frecuentes frases como “¿quieres comprar coche?”, o al menos más frecuentes que “se vende coche”.