Le escribo esta carta abierta, primero para felicitarle por las maravillosas creaciones de los Doodles conmemorativos del 40 aniversario de Sesame Street (en estas latitudes Barrio Sesamo) y en segundo lugar para remitirles un sentimiento que he visto a lo largo de estos días entre muchísimas personas:

Queremos camisetas (o lo que sea) con esos Doodles :))

barrio sesamo en el logo de Google

Entendemos que puede no ser una labor fácil, que puede haber problemas por ambas partes en cuanto a temas de marketing o derechos que a nuestras humildes mentes se nos pueden escapar.

Proponemos algunas ideas:

• Venta directa
• Regalarlas (al fin y al cabo iremos haciendo publicidad de ambas empresas)
• Venderlas y donar el dinero a una buena causa (se acerca la Navidad y son fechas muy dadas a ello)
• Usar los Doodle en alta definición y ya nos haremos nosotros las camisetas :)

Desde aquí, muchas gracias por atendernos :)

PD: les dejo mis favoritos (incluído el de más arriba) por si quieren mandarme alguna camiseta, mi talla es la L jejeje

elmo de barrio sesamo en el logo de google

el monstruo de las galletas en el logo de google

oscar the grouch en el logo de google

epi y blas en el logo de google

Pero retrocedamos, ¿a qué viene esta prueba? De todos es conocido que hasta hace bien poco podíamos determinar si Google seguía o no un enlace a través del famoso NOFOLLOW. No sólo Google no seguía el enlace si no que distribuía nuestro PageRank entre el resto de enlaces.

Desde hace más bien poco, Google no sigue esos enlaces pero los contabiliza para distribuir el PageRank. Con lo cual, no es lo mismo distribuir un PageRank entre 20 enlaces, que entre 40. Obvio. Las páginas interiores reciben menos PageRank a igual número de enlaces independientemente de los NOFOLLOW que tengamos.

Algo muy común suele ser poner el mismo enlace en el titular de una noticia, la imagen que la acompaña, la entradilla e incluso un enlace tipo “leer noticia completa”. Cuatro enlaces a un mismo punto. Demasiados. Sería mejor si sólo fuera uno ¿no? Menos enlaces, más PageRank.

Solución: Poner un único enlace en el HTML y generar los otros 3 mediante Javascript no intrusivo. Sustituyendo unas inocentes etiquetas <SPAN> por etiquetas de enlaces <A>.

Ventajas:

• Los usuarios sin javascript, siguen viendo el enlace original.
• Los usuarios con javascript ven todos los enlaces.
• Google sólo ve un enlace (eso muestra el GoogleBot, habrá que esperar a más información), así repartimos mejor el PR.
• El SEO contento, los de UX contentos, los de accesibilidad contentos… ¡TODOS CONTENTOS! :)

Cómo:

• En el código HTML indicar mediante un class “enlaceReal” los enlaces reales y otro “enlace” para los SPAN.
• Desde JS (jquery, mootools, prototype,dojo) buscar los SPAN con clase “enlace” y sustituirlos por enlaces, donde el HREF y el TITLE los recogeremos de los enlaces con clase “enlaceReal”.

Lo más sencillo es que veáis el post anterior con javascript y sin javascript, para que veáis que hay un enlace que no se genera. El código JS que he usado es muy básico, pero no necesitaría mucha mayor complejidad en una página real para funcionar adecuadamente.

Además de incorporar jquery, he usado esta línea:

$(document).ready(function() {$(’span.enlace’).replaceWith(”<a href=’” + $(’a.enlacereal’).attr(”href”) + “‘ title=’” + $(’a.enlacereal’).attr(”title”) + “‘>” + $(’span.enlace’).html() + “</a>”);});

Aviso: si copiáis y pegáis no os va a funcionar… tendréis que ajustarla dependiendo de vuestro proyecto y el número de enlaces usados.

Y esto es todo…

Actualización 4/11/2009: Google ha indexado la página enlazada desde el término ksafsf pero no la enlazada desde el término popotyutyu generado por javascript.

Este post es de prueba, en realidad no voy a contar nada (de momento), para ir probando alguna cosa que voy comentando con Dani Pinillos (aka seovision)

La prueba tiene que ver con este enlace a una página no indexada ksafsf y con este otro enlace a otra pagina popotyutyu.

El video es un repaso desde las distintas tecnologías y los problemas generados por las soluciones actuales hasta la conceptualización de un sistema operativo que aprovecha la idea propuesta por el propio Clayton Miller.

10/GUI from C. Miller on Vimeo.

Vía Microsiervos | Reinventando la interacción con los ordenadores

Si a eso le añadimos que se está creando escuchando en todo momento a la comunidad de usuarios, añadiendo y quitando funcionalidades según la demanda, y explicando por qué se quitan algunas anunciadas previamente (temas de rendimiento o bateria), al final vemos que la expectación creada es enorme.

Lo que tenemos antes nosotros es un terminal de gama media/alta completamente abierta (Root y Open Source), es decir el teléfono permitirá su manipulación sin ningún tipo de límites y siempre se venderá libre.

¿Qué más podemos pedir? ¡Qué salga ya! :D

Las especificaciones finales están publicadas en el blog oficial, y en Xataka podéis disfrutar de la galería de fotos y un video del funcionamiento.

Acaba de salir la primera versión de Napkee, la herramienta que transformará nuestros prototipos hechos con Balsamiq Mockups en auténticos wireframes navegables.

Podemos probarlo de manera gratuita o adquirir una licencia por 79$/usuario, aunque al igual que sucede con la herramienta de Peldi, si tenemos un blog o lo necesitamos para formación, nos permiten escribirles para que nos den una licencia gratuita.

Este número está especialmente dedicado al Taller Mexicano de Interacción Humano Computadora que se celebró en octubre de 2008.

portada revista faz número 3

Podéis descargarla directamente de su web

He intentado que las pautas sigan un orden lógico que lleve desde la concepción de la idea hasta el desarrollo, aunque reconozco que son generalizaciones que por si mismas no conforman una “guía paso por paso para crear mi propia web móvil”. Como ya he dicho se trata más de una ordenación de lo que he ido viendo y leyendo en el último par de años.

1. Adaptación web o desarrollo específico

Antes de desarrollar una versión web móvil, debemos pensar si lo que queremos es una adaptación de la web “corriente” o vamos a hacer un desarrollo específico.

En algunos casos, nos bastará (siempre desde servidor) con ocultar partes de la web “corriente” y usar una CSS distinta que adapte el contenido a dispositivos móviles. Para ello detectaremos desde servidor que el agente de usuario que accede corresponde a un dispositivo móvil y le serviremos la versión móvil. Incluso podemos agrupar los dispositivos por segmentos (básicos, medios, avanzados) y servir distintas CSS para distintos dispositivos y así ofrecer una mejor experiencia a cada usuario.

En otros quizás nos compense realizar un desarrollo específico para móvil, con su propia URL y un código específico. Ya sea porque la adaptación de la web “normal” sea costosa, o porque la página sobre la cual tenemos que crear la versión móvil tenga un código que no permita su rápida adaptación.

Es cierto que lo ideal es tender a la web única, pero con algunas tarifas de datos creo que resulta molesto e irritante para el usuario servirle páginas cuyo peso y tiempo de descarga supere el umbral de su paciencia y su bolsillo. Además debemos tener en cuenta que la mayoría de navegadores móviles no tienen caché, así que en realidad el usuario se descarga todo el contenido cada vez que accede.

2. Pensar en el escenario de uso

Es importante valorar qué información queremos mostrar en la versión móvil y qué va a necesitar el usuario en cada uno de los escenarios posibles de uso.

No es lo mismo consultar una página web desde un ordenador, sentado en casa que cuando hemos parado el coche en el arcén o estamos perdidos en un sitio que no conocemos y llegamos tarde a esa reunión tan importante. La mayoría suelen ser escenarios en los que la usabilidad juega un papel fundamental porque el usuario reclama una información con urgencia o se encuentra en una situación complicada. Aunque también hay otros escenarios en los que las prisas no son el principal problema, pero el entorno dificulta la navegación. Consultar las noticias en el metro (ruido, poco espacio para el usuario, al menos una mano ocupada), o en la calle donde la visualización de ciertos elementos puede verse perjudicada por la luz.

En el caso de aplicaciones o servicios web, también es importante remarcar que la mayoría de usuarios de versión móvil son usuarios registrados de nuestra aplicación, así que ofrecerles su página de inicio con lo más destacado es algo que cobra mucha importancia. Los principales ejemplos pueden ser las versiones móviles de Facebook o Tuenti, claramente enfocadas a usuarios registrados.

3. Los dispositivos táctiles: nuestras manos quitan visión.

A la hora de prototipar una versión móvil, tenemos que tener en cuenta algo muy importante en los dispositivos táctiles, y es que en la mayoría de los casos nuestras manos dificultan la visión de parte del contenido cada vez que el usuario interactúa. En un monitor tradicional, el usuario ve toda la página, hace scroll con facilidad y cuando ve un link en el que pinchar mueve el ratón, mientras que en un móvil el usuario no ve todo el contenido, hacer scroll puede ser más complicado y en ese gesto la propia mano del usuario tapa el contenido con lo que hay que tener en cuenta dónde se colocan ciertos elementos ya que puede que el usuario no llegue a verlos nunca. ¿Alguien recuerda por qué el Doctor Hibbert no veía nunca el lápiz clavado en el cerebro de Homer? Pues eso.

Es importante hacer prototipos en papel y que nosotros mismos los probemos y veamos los posibles problemas. ¿Por qué en papel? Porque la interacción táctil es más fácil de representar mediante papel que sobre un documento digital.

4. No depender de eventos que requieran exclusivamente un método de entrada

Los dispositivos móviles pueden ser controlados tanto gestualmente como por teclado, y en el caso de dispositivos como la Palm Pre, Blackberry Storm, Nokia N97 o HTC Dream que cuentan con pantalla táctil y teclados qwerty además de “pads” pueden ser manejados por ambos métodos.

Así pues usar manejadores de eventos exclusivos (como “onclick” que sólo funcionaría con ratón) para un tipo de dispositivo de entrada excluiría automáticamente al resto de usuarios.

Traduciendo con un ejemplo: Cogemos una carpeta local y a través de Opera Unite la compartimos con el mundo a través de una dirección de Internet.

Esta es su visión de Unite explicada en un video:

Antes de lanzarme a alabar o criticar el producto, lo he probado con uno de los servicios que trae preinstalado, más concretamente con File Sharing que es el que nos permite compartir ficheros. Y funciona realmente bien, he podido compartir un documento de mi escritorio con una persona que está fuera de mi oficina sin ningún problema.

Opera Unite trae varios servicios preinstalados (para compartir ficheros, nuestra librería musical, crear un chat,…), pero permite a los desarrolladores crear más, esto le da al producto una enorme flexibilidad y un gran potencial.

No sé si Opera ha reinventado la web, pero está claro que este nuevo servicio va a traer cola seguro.

Hi from Multitouch Barcelona on Vimeo.

Vía: no me puedo creer