Seis años después del lanzamiento de GMail, por fin Microsoft se atrevió a renovar a fondo Hotmail en un intento de que su servicio de correo dejara de ser sinónimo de usuario que se quedó en los años 90. Por aquí hemos hablado un par de veces del "síndrome de Hotmail" (y 2): la parálisis por no modificar la experiencia de los usuarios actuales que se quejarían convertida en oportunidad para que terceros (Yahoo y GMail en este caso) sean capaces de ofrecer innovaciones para llevarse a aquellos predispuestos a lidiar con la migración y con probar cosas nuevas.

Sé que llego tarde a comentar el "caso Gmail", ampliamente discutido en blogs, foros y publicaciones tecnológicas, pero creo que resultan hasta más interesante las reacciones que la caída en sí. El hecho de que el acceso web a Gmail no fucionase durante varias horas ayer ha provocado un debate interesante sobre si GMail y su modelo de software como servicio son para la empresa. Al respecto creo que hay algunos puntos interesantes:

Casi dos años después de lanzar Gears, Google integra su servicio de correo electrónico GMail al que añade la posibilidad de funcionar sin conexión. Lo explican en el blog oficial, donde comentan que irán activando la posibilidad poco a poco y como un elemento de "Gmail Labs" al ser todavía "experimental".

El funcionamiento de Gears como caché local facilita que aplicaciones como Gmail puedan ser utilizadas "offline" y volver a sincronizarse en la siguiente conexión a internet. El objetivo es reforzar la idea de que las aplicaciones web pueden competir en experiencia de uso con las de escritorio, aunque no deja de extrañar la baja prioridad que ha dado Google a este factor, llegan meses después incluso que otros clientes de correo como el de Zoho. El uso de Gears implica también una estrategia simple de sincronización, válida siempre y cuando después de trabajar offline, no utilicemos otro dispositivo para acceder a Gmail antes de sincronizar.

Un pasito más de Google para reforzar su línea de aplicaciones web, que poco a poco se mueven desde el "gratis pero funcionalmente pobres" hacia el "freemium, barato y suficientemente potentes" que es el perfil de producto que están definiendo. Al menos en el correo hay que reconocer que la porpuesta de valor de Gmail empieza a resultar más que suficiente comparada con otras soluciones tanto para sector consumo como profesional.

Merece la pena leer a Paul Buchheit: "Overnight success takes a long time". Buchheit es uno de los fundadores de Friendfeed y estaba en el equipo que desarrolló Gmail. En su post describe la travesía del desierto que necesitó el servicio de correo de Google para vencer las resistencias internas y el escepticismo de una parte de los analistas tecnológicos. Comenzaron en 2001 y hasta 2004 Gmail no vio la luz, con mucho esfuerzo y a pesar de las voces que, desde dentro, apuntaban a que era un proyecto mal enfocado. Los que siguieron el lanzamiento recordarán el boom del lanzamiento entre los bloggers y "early-adopters" y, para quienes pensaron que se iba a quedar allí, los datos de 2008: Gmail sube un 40% con 100 millones de usuarios y Hotmail, aun siendo todavía más del doble de grande, desciende un 3% en cuota de mercado.

Buchheit concluye que una empresa de internet también necesita tiempo para llegar al éxito, como necesitaron Google o Facebook y, reclama, precisa Friendfeed. Y, aunque hoy por hoy estoy convencido que Friendfeed necesita evolucionar y aportar más valor para llegar al gran público, me ha impresionado la visión de Buchheit de ser consciente de que necesitan orientarse mucho más a lo que le piden los usuarios por un lado y tiempo sin obsesionarse con el éxito fulgurante, por otro.

¿El problema? Que el tiempo se compra con músculo financiero y que esa paciencia en tiempos de crisis es muy muy escasa. Además, claro está, de que también es tan probable fracasar en un año que en cinco. En todo caso, una síntesis que me ha parecido muy "sana" entre lo que supone creer en tu proyecto y perseverar a pesar de las críticas y, al mismo tiempo, saber recoger el valor que hay en ellas. Relacionado, hace poco Godin ejemplificaba por qué a veces merece la pena no hacer un producto que los demás considerarían "bueno".

Desde Google cuentan que van a comenzar a ofrecer videoconferencia y conversaciones de audio en Gmail, no ya desde el cliente de escritorio (que sí soporta voz), sino desde la aplicación web. Para ello van a seguir la misma estrategia que cuando llevaron Google Earth al navegador, hará falta instalar un software que sólo funcionará, de entrada, en los sistemas operativos de Microsoft y Apple. Se puede descargar el plugin en mail.google.com/videochat.

La videoconferencia en Gmail se presenta como una funcionalidad muy interesante a añadir a ese "completo centro de comunicaciones" (hace poco anunciaban envío y recepción de SMS) que va siendo el correo de Google. Respecto a la forma de implmentarlo, aspectos muy positivos como el uso de estándares como XMPP (del que tenemos pendiente hablar mucho más en profundidad) y H.264, lo que lo diferencia de la propuesta cerrada de Skype, permitiendo a servicios de terceros comunicarse con los usuarios de Gmail. Por otro, merece tomar nota de como está abordando Google las aplicaciones ricas en internet, obviando complementando en este caso el uso de tecnologías como Flash con extensiones instalables que de momento dejan fuera a Linux (aunque acabará llegando).

Un último apunte. Obviando que está muy lejos de lo que puede ofrecer Skype, como explica Jorge, más interesante puede ponerse el tema cuando decidan llevar esto al móvil con Android, terreno en el que Google más tarde o más temprano, acabará chocando con las operadoras.

GMail es probablemente la herramienta en la que más horas paso. Gran parte de mi peculiar profesión consiste en comunicaciones asíncronas con equipos distribuidos por España y Latinoamérica, clientes y resto del equipo de gestión de weblogssl. Traducido, paso horas en Gmail, donde tengo integrado tanto el correo personal como el profesional. Por eso me interesa tanto cada vez que añaden una funcionalidad o plantean modificar la experiencia de uso. Lo ultimo ha sido añadir widgets a GMail - aunque ellos insisten en llamarlos "gadgets" - que se pueden activar desde la pestaña "labs" en las opciones del correo (al menos en la versión en inglés que es la que utilizo). Se pueden añadir widgets de otros servicios de Google (el calendar y los documentos), pero también dan la opción de sumar funcionalidades de terceros, por lo que les abren la puerta de Gmail.

Me encanta el modo en que han abordado el tema de ampliar la experiencia del correo electrónico web, no evolucionando hacia imitar clientes complejos en el escritorio sino dando la opción de una configuración personal avanzada. ¿Qué sólo quiero webmail? No hay problema, ¿qué prefiero integrar otras herramientas que para mi perfil de usuario son interesantes? También tengo esa opción. Para mí tener ahí las tareas del Calendar o el widget de RTM me aporta valor. Me parece una aproximación mucho más inteligente que la dejaron entrever hace tiempo, un newsfeed en un Gmail social, algo que para muchos usuarios - entre ellos, un servidor - resultaría una confusión del contexto de navegación: voy a GMail a ser productivo y no a ver qué han hecho mis amigos.

Un último punto en la evolución del webmail de Google. Están preparando la integración de envío y recepción de SMS en el chat de GMail (Gos), de forma que completan una nueva forma de comunicación: asíncrona sin interrupción (correo), síncrona (chat / mensajería instantánea) y asíncrona con interrupción (SMS). Parece que por fin vamos a empezar a ver por qué Google compró Grandcentral depués de más de un año de la adquisición.

Los usuarios de cuentas de correo GMail podrán utilizar en servicios que acepten OpenID, anuncia oficialmente Google. Con esto podemos dar por superada la etapa inicial de este sistema de identificación distribuido y comenzar con la fase de maduración y llegada al gran público. Y, por mucho que nos pese a algunos, esto pasa indefectiblemente por ocultar la complejidad del mismo a los usuarios y que estos sólo vean que utilizan su cuenta de correo habitual para identificarse en cualquier web.

¿Qué será lo siguiente? Como señalan en R/W, desde Google apuntan al uso de Oauth para hacer algo más que identificar. Oauth define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña. De esta forma no sólo nos identificamos si no que nos podemos traer todo lo que tengamos en Google: contactos, favoritos, etc...

Con este paso de cuentas de correo GMail como OpenId, Google se convierte en proveedor de este sistema y parece descartar la posibilidad de convertir GMail en un nuevo Passport. ¿Por qué estamos asistiendo a esta catarsis de anuncios de los grandes de internet sobre OpenId? Mi impresión es que, al margen de la simpatía que pueda causar el estándar en algunos, hay miedo a cierto lobo feroz que está a punto de ser liberado. Su nombre es Facebook Connect.

Actualización: interesantes los comentarios de Sacha, ya que como señala, esto realmente no es OpenId estándar. En cuanto pueda analizar más a fondo la propuesta de Google, volveré a publicar.

Relacionados: Windows Live Id como proveedor de OpenID, Yahoo implementa OpenId como proveedor.

Está en juego el configurarse en identificador del usuario en la web y de contenedor de su red de contactos para cualquier otro servicio. Los grandes contendientes son OpenId - que apuesta por ser abierto y distribuido - pero también Google / Gmail y Facebook con Connect. Ya hablamos de él, pero ha sido esta semana cuando se ha dado el pistoletazo de salida en la conferencia "F8 developer". ¿Qué es lo que realmente ofrece? Facebook Connect es un sistema de identificación con la cuenta de esta red social en sitios de terceros, que lo podrán integrar con un poco de código. Desde ellos se podrá acceder a todo lo que tengamos en Facebookl: información del perfil, foto, nombre, contactos, fotos, eventos, grupos.... todo.

Con el entierro del Passport de Microsoft, la abundancia de nuevos servicios y redes sociales ha traído de nuevo el problema de las múltiples cuentas de usuario. Han habido varios planteamientos, los que seguís este blog conocéis de sobre mi preferencia por OpenId y como lo estamos empujando desde Weblogssl, siendo Google y Facebook quienes más seriamente se configuran como alternativas. La estrategia de la empresa del buscador está siendo más sutil, ofreciendo Gmail como identificador para las aplicaciones de App Engine, a través de Google Friend Connect o con acuerdos como el que tienen con Zoho.

La estrategia de Facebook es más agresiva, Facebook Connect es sin duda la alternativa más potente a OpenId y la tecnología que más cerca está de revivir el "caso Passport". De hecho, los acuerdos a los que han llegado impresionan: Twitter, Digg (por cierto, toma petardazo a Google), Movable Type (para los comentarios en los blogs), CitySearch, CNet, Hulu, CBS, Disney, Xobni, Seesmic y así hasta 24 (News.com). Toda la presentación de la plataforma en Venture Beat. La apuesta es fuerte y desde luego pueden dar un golpe de mano al erigirse como identificador en un montón de las webs de más éxito del mercado anglosajón...

Habíamos hablado por aquí del estándar OAuth. De forma resumida podemos decir que OAuth define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña. Hasta ahora, aún siendo el estándar de iure perfecto para los mashups, no era el estándar de facto puesto que cada compañía estaba apostando por una solución propia (Google AuthSub, Yahoo BBAuth, Windows Live DelAuth, AOL OpenAuth y la de la API de Facebook). La noticia de que Google soportará OAuth en sus APIs cambia las cosas.

¿Para que nos sirve esto a los usuarios? Digamos que OAuth viene a arreglar el problema de que otros servicios nos pidan el usuario y contraseña del correo. Algo que por muy habitual que sea, en realidad es una locura ofrecerles, y para lo que este estándar ofrece una alternativa segura: terceros pueden permitirnos identificarnos en las cuentas de Google y traernos datos de sus servicios (GMail, Calendar, youtube...) sin saber en ningún momento nuestra contraseña. En este sentido, aquí si que hablamos de verdadera portabilidad de datos de los usuarios que tienen el control de a qué datos permiten el acceso y desde donde. Claro que esto podía hacerse ya con los estándares propios de cada servicio que hemos indicado arriba, pero el tener uno como OAuth ayuda a que una vez programada una solución desde nuestro servicio cliente, se puede utilizar para cualquier proveedor. Siguiendo con el ejemplo, si Yahoo adoptase OAuth, los terceros que ya se integran con las cuentas de Google podrían hacerlo con Yahoo sin trabajo adicional.

Ojo porque también google empuja así hacia el uso de sus cuentas desde servicios de terceros, como en el ejemplo de Zoho y como empuja desde Google App Engine. En todo caso, en la adopción de estándares abiertos, Google sigue sacando nota.

También lo comenta Webmaster Libre.

Mi experiencia actual de usuario de GMail y Google Groups se puede calificar como insoportable por culpa del spam. En WeblogsSL hacemos un uso intensivo del servicio de listas de Google y la mayoría también tenemos GMail para gestionar todas las cuentas de correo: desde hace un par de meses nuestra productividad está cayendo en picado. Al principio pensé que sería algo temporal, el mejor escriba tiene un borrón, pero la degeneración en la capacidad para detectar y filtrar el spam es evidente en el caso de GMail y mayúscula en el de Google Groups.

El spam en Google Groups llega hasta extremos tragicómicos: mientras que mensajes perfectamente inocentes, con apenas una url en la firma del emisor que además es miembro de la lista, son frenados para ser revisados, cientos (sí, lees bien, cientos) de mensajes con un patrón fácilmente identificable (decenas de enlaces a otras listas spam del propio Google Groups, que tiene guasa) son enviados. El interfaz para señalar como spam en Google Groups es también infame: hay que ir de uno en uno y añadir una explicación: horas perdidas en eso a cambio de que el sistema no sólo no mejora sino que empeora.

El caso de Gmail no es tan llamativo en cantidad, pero si en grado de perjuicio: el número de falsos positivos (correos legítimos que van a la carpeta de spam) ha crecido bastante, al igual que el spam que llega a la bandeja de entrada. Si cuando apareció, era sinónimo de limpieza y efectividad, ahora mismo no tiene nada que envidiar a los peores tiempos de Hotmail (que por cierto, ahora está bastante mejor desde que es Windows Live Mail).

A los usuarios sólo nos queda quejarnos y buscar una alternativa en alguien que maneje mejor el spam que Gmail y Google Groups. ¿Soporte? Nada, como se paga con atención (a la publicidad) y no con dinero, Google puede olvidarse de ambos servicios, llegando al abandono en el caso de los Google Groups en español.

Y Google quiere entrar en el mercado del software para empresa. Qué risa.