Iván Mendoza

Por si eres un poco despistado(a) y aún no lo sabías, Facebook lanzo su rediseño y con él vinieron muchos cambios, entre ellos el nuevo tamaño para las aplicaciones (especificanmente en el área de canvas page).

La nueva medida de las aplicaciones de Facebook es de 760px, anteriormente 648px, que es un aumento de 112px, te dejo con la imagen en donde se puede apreciar mejor la diferencia (click para agrandar):

Nueva medida para aplicaciones de Facebook

Avisado estas del cambio, espero lo pongas en practica porque pocas aplicaciones han hecho el cambio y Facebook se siente muy grande

Alfonso Luna, Director de Marketing de Google para la región de América Latina, presento la 2da conferencia del Google Developer Day: La nube, la conectividad y el cliente. O como se tituló en el programa, Un vistazo a la estrategia de nuevos productos.

Alfonso Luna inició su charla hablando acerca de como la información debe de ser accesible, los clientes (navegadores) poderosos y disponibles en todo lugar (cualquier plataforma). Requisitos bastante obvios, y que sin ir muy lejos, son los que promueve el W3C, pero que Google toma en cuenta para el desarrollo de nuevos productos y la promoción de nuevas tecnologías.

Dos de los tres requisitos anteriores dependen en gran parte del navegador, o cliente como lo llamó Luna, porque a traves de este acceden los usuarios al Internet por lo tanto es importante que se desarrolle lo mejor que se pueda. Sin embargo, no se trata solo de agregar características sino de trabajar bajo un estándar, por llamarle de alguna forma, para facilitar el desarrollo de Internet.

Como ejemplo, dentro de sus diapositivas mostró una gráfica con la diferencia entre clientes como Adobe Air y los navegadores estándar (Firefox e Internet Explorer por ejemplo) que sin duda no deja de impresionar.

Explicado lo anterior puedo mostrar los productos que Google promovió en el Developer Day y en que se enfoca cada uno de ellos

• Google App Engine, parte de “La nube”, ofrece un entorno para el desarrollo de aplicaciones gratis (aplican restricciones) facilitando el acceso a aplicaciones escalables sin la complejidad de encargarse de la administración. Un comentario interesante de Luna fue que si los desarrolladores nos apegabamos a los lineamientos de la API de App Engine entonces no deberíamos de preocuparnos por escalar nuestra, Google lo haría por nosotros. Ver más información en Google Code.
• Google Gears es una “extensión” para el navegador (cliente) que permite acceder a aplicaciones web aún cuando estemos desconectados (offline) brindando al navegador, y a los desarrolladores web, una característica para competir contra “aplicaciones de escritorio”. Una característica antes inimaginable y que ahora permite a aplicaciones como Google Docs o Zoho competir contra Microsoft Word, Excel e incluso Power Point.Hasta el momento pienso que Gears es una de las herramientas que Google ha logrado llevar muy cerca de los estándares (y están orgullosos de ello) porque, como menciono Luna, la “nueva” especificación de HTML5 incorpora muchas de las características que Gears ya ofrece actualmente. Ver más información de Gears.

  

• Android. La pregunta es ¿Por qué Android?, y luego de escuchar las palabras de Alfonso Luna gran parte de la duda se resolvió. Google apuesta por un sistema operativo libre, una plataforma que permita a los fabricantes, operadoras telefónicas y a los desarrolladores crear nuevas aplicaciones bajo “un mismo lenguaje” (hasta cierto punto un estándar) para eliminar el problema actual de los móviles: la brecha de desarrollo entre navegadores y plataformas.Actualmente existen varias plataformas tan diferentes unas de otras que es prácticamente imposible estandarizar una forma de desarrollo, hay que limitarse a una cantidad de ellas y desarrollar específicamente para cada una, incluso con herramientas como Java (multiplataforma) sigue siendo una tarea enorme por la gran diferencia entre los dispositivos móviles.

  Como ejemplo se puede mencionar la diferencia entre Blackberry, Windows Mobile, iPhone y Symbian, en donde cada uno trabaja como mejor le conviene sin importar nada mas.

  La propuesta de Google es una plataforma común para todos, que pueda ser modificada por todos pero que permanezca como una. ¿Solucionará el problema? No lo sabremos hasta que sea lanzado el primer dispositivo que incorpore Android, pero hasta el momento es la mejor opción para los desarrolladores.

  Ver más información de Android en Google Code.

• Google Earth. De los productos de Google pienso que este es de los que no concuerda con el listado anterior, creo que es por el hecho de ser contenido más que una herramienta, aunque bien es cierto que se puede trabajar sobre ella su principal característica es la información que ofrece.De momento los esfuerzo de Google se centran es migrar Google Earth al navegador (por la misma razón de unificar clientes) para poder ofrecer toda la experiencia en un mismo lugar y con ofrecer a los desarrolladores trabajar bajo las mismas herramientas con las que actualmente lo hacen, javascript por mencionar un ejemplo.

  Más información de Google Earth.

• Open Social. Por último, y no menos interesante, esta Open Social, el producto de Google para el desarrollo de aplicaciones. Justo como sucede con Android, Google propone un nuevo estándar abierto para desarrollar aplicaciones, pero en este caso enfocado a redes sociales y que actualmente ya es soportado por varias redes sociales, según Google, con un alcance total de 270 millones de usuarios, 20 mil desarrolladores y 50 millones de aplicaciones instaladas. Todo un éxito si tomamos en cuenta el tiempo que tiene de haber sido lanzada.La tendencia actual de la web son las redes, porque la web es social, y el nuevo enfoque es compartir e interactuar con otras personas a traves del mundo entero sin importar la plataforma (incluyamos aquí sitios web). Las herramientas para participar en esta “conversación” ya existen siendo funcionales y bonitas, pero también son diferentes y en la mayoría de los casos incompatibles unas de otras, por eso Google apuesta de nuevo por crear un estándar que permita a los desarrolladores trabajar una vez y distribuir muchas veces.

  Google dice que OpenSocial es a las aplicaciones, lo que OpenId es a las identificaciones y OAuth a las autorizaciones.

  A mi parecer la idea, de nuevo, es bastante interesante y útil para los desarrolladores, que aunque actualmente no sea el estándar definitivo si establece los parámetros para uno que si lo sea más adelante.

  Ver más información de OpenSocial en Google Code.

y luego de la exposición de productos, que por supuesto fue mucho más extensa que las palabras en este artículo, Alfonso Luna dio por terminada su charla que a mi gusto fue una buena introducción para entender que enfoque tiene cada uno de los productos y que podría esperar yo, como desarrollador, de ellos.

Si mi memoria no me ha fallado, eso es todo respecto a la conferencia acerca de los productos de Google, seguiré en el próximo tema con las conferencias especificas de OpenSocial a las que asistí.

Solo como recordatorio/nota, anteriormente publique acerca de la charla Google y el mercado méxicano de John Farrell, Director General de Google México.

Desde el 7 de mayo (antes había algo pero no tan concreto) Facebook publicó un artículo acerca de los cambios en el perfil de los usuarios, en su momento me entere por Techcrunch y me dedique a recopilar información sobre el tema, además de hacer un resumen para saber que esperar y no olvidarlo luego.

Hoy leyendo Denken Über recordé el tema y decidí publicar el resumen que tengo guardado por allí, básicamente un documento copy+paste de la información disponible en el wiki.

Por el hecho de ser desarrollador de apps. pienso que me enfoque mucho en los aspectos técnicos, así que te recomiendo leerlo solo si eres desarrollador o conoces Facebook como la palma de tu mano:

Publisher

(desconozco como lo traducirán al español)

• La idea es reemplazar El muro (wall) y ser una herramienta para publicar contenido creado por el usuario (igual que un blog), compartir enlaces, subir fotos y vídeos. Pienso que más que parecer un blog en realidad es un tumblelog (como los de Tumblr).
• A diferencia de un tumblelog, Facebook ofrece la ventaja de las aplicaciones que permiten al usuario publicar contenido “prefabricado”, como resultados de un test (equivalente a un meme) o la letra de una canción.
• La interfaz del Publisher esta disponible para el usuario tanto en su propio perfil como en el de sus amigos, las diferencias se dan en las opciones de publicación, por ejemplo: en mi perfil público lo que quiero mientras que en la de mis amigos tengo limites. Imagino que función a de forma similar a un blog, en el sentido de que en mi blog puedo publicar lo que quiera mientras que en el blog de mis amigos solo puedo comentar, de igual forma existirán dos “interfaces” distintas para cada caso.
• Especificaciones para el diseño y programación del Publisher
  • 500 pixeles de ancho y 40 de padding
  • No deberá sobrepasar 700 pixeles de alto.
  • Permitirá la utilización de FBML, Flash (con autoplay) y FBJS
  • Puede incluir sección de comentarios debajo de la publicación
  • FBJS permitirá activar y desactivar el botón de publicación hasta que la persona termine de publicar.
• Más información en el wiki: New Design Publisher

Feed Wall

• Un cambio que me atrae mucho es la integración del mini-feed junto a El Muro en una nueva sección llamada Feed wall (vaya creatividad :P), que desde mi punto de vista no es más que un “lector de feeds” en donde estamos suscritos a la actividad y comentarios de nuestros amigos, lo mismo que el newsfeed pero con nuestra actividad y comentarios incluidos.
• Anteriormente existía un formato par publicar en el feed que permitía el uso de texto e imágenes (además del icono), en el nuevo perfil existirán tres formatos. El pequeño one line (una línea), el short(corto o mediano) y el full size (el completo). El one line como su nombre lo dice permite publicar con texto de la forma más simple, el short permite la utilización de imágenes e incluso swf (flash) mientras que el full size nos da la libertad de publicar “lo que sea” siempre y cuando no sobrepase los 700 px de alto. Este último permite algunas etiquetas de FBML.
• Facebook requiere que registremos un “paquete de plantillas” y nos proporcionará un ID que deberemos utilizar cada vez que vez que publiquemos una historia en el feed. Las plantillas se deben de registrar con el tamaño (los tres anteriores que mencione) para poder publicar un tema de ese tipo.
• Respecto a los permisos para publicar, Facebook permite que las aplicaciones publiquen automáticamente temas de una linea (one line) sin permiso del usuario, temas cortos (short) con permiso del usuario y temas completos (full size) cuando son generados por el usuario a través del Publisher.
• Especificaciones para el diseño y programación para publicar en el Feed Wall
  • Historias one line se publican con un ancho de 500 px y siempre necesitan plantilla. Sino estoy mal, casi la misma que se utiliza actualmente. Se permite el uso de un poco de HTML y FBML, por ejemplo etiquetas como a, fb:name, fb:pronoun fb:if-multiple-actors.
  • Historias cortas (short) se publican utilizando las plantillas proporcionadas por Facebook ( alrededor de 5-10 segun indican). Permiten el uso de HTML y FBML con etiquetas como fb:userlink, fb:name, fb:pronoun, fb:if-multiple-actors, a, b y i.
  • Historias completas (full size) al igual que las anteriores utiliza plantillas, aunque si estoy en lo correcto no serán administradas por Facebook, estas permitirán el uso de FBML de igual forma que lo permite El muro actualmente. Se mostrarán en un área de 500 px de ancho y no deberán superar los 700 px de alto.

  Más infomación en el wiki: New design feed wall

Narrow Boxes

• Narrow boxes son el equivalente (por no decir que son lo mismo) a las cajas de perfil actuales, estas tienen un ancho de 200px (las actuales usan 380px aprox.) y estan limitadas a 250px de alto.
• Las narrow boxes se crean, de forma similar a las actuales, usando profile.setFBML en la API.
• Se publican en el perfil del usuario cuando este utiliza el botón “Add to profile” que se muestra utilizando la etiqueta fb:add-section-button de FBML. Si no se crea una nueva “caja” para el perfil principal entonces esta aparece en la pestaña de boxes que es el área para colocar las cajas de las aplicaciones que usemos.
• Más información en el wiki: New design Narrow boxes

Puntos a tener en cuenta al actualizar las aplicaciones

1. Nuevo contenido integrado: El feed con El Muro, el perfil con pestañas, cajas de perfil junto al feed y nueva sección de información de las aplicaciones.
2. Modificaciones en la plataforma: Incluyen cambios en la API (nuevas formas de llamar), nuevas etiquetas FBML, y algunas etiquetas y métodos serán eliminados.
3. Session Key: Modificaciones en el manejo de sesión de los usuarios, que de alguna forma puede afectar las llamadas y actualizaciones “masivas” que hagamos desde nuestra aplicación. Como mencionan en el mismo wiki, algunas funciones que requerían iniciar sesiones infinitas ahora necesitan sesiones normales, mientras que otras, como la actualización de la caja de perfil no requieren inicio de sesión.

Para finalizar el tema y entender mejor los cambios, incluyo un resumen acerca del por qué de los cambios.

¿Por qué rediseñaron?

Objetivos

• Crear perfiles simples y más relevantes para los usuarios y sus amigos.
• Ayudar a los usuarios a controlar sus perfiles.
• Apoyar la comunicación entre amigos a través de los canales ya establecidos.

Mejoras

• Nuevas formas de comunicación de usuario a usuario
• Mejor integración del perfil.
• Mejoras en flujo de instalación e inicio de sesión.

Más información:

Si no han quedado satisfechos con el tema y quiere saciar su curiosidad les recomiendo visitar los siguientes enlaces:

• Anuncio oficial: Preparing for the New Facebook Profile Design
• Screenshot: Weekly Update 5.6.08: Check out the new “Boxes” tab
  
• “Resumen de todo” en insidefacebook
• y la noticia en Techcrunch

Saludos,
Iván

—-
Escrito mientras escuchaba No Quarter de Led Zeppelin