Como hacer una buena versión móvil de tu sitio

Todos nosotros conocemos la importancia de tener un sitio móvil estos días, es decir, un sitio que sea accesible desde un listófono, o incluso desde un celular básico que ya casi todos vienen con algún tipo de navegador. Y por supuesto los iPhones, iPads, iPods, iPuds y lo que venga después.

Lo bueno es que gracias a desarrollos como html5, css3, mejores pantallas en los móviles y motores como webkit, construir un sitio que se adapte a las dimensiones de un móvil es más fácil que nunca.

Lo malo es que eso no basta para crear un buen sitio móvil. Para que sea bueno tendrá que ir más allá de adaptar la resolución a la pantalla y cargar una nueva hoja de estilos para que se vea bien en el espacio reducido. Tenemos que pensar sobre que es lo más probable que el usuario quiera hacer y dejárselo lo más fácil y rápido posible.

Mirando a un vaso desechable en vez del sitio web

“¡Al diablo! Está más fácil encontrar la información en el vaso” Foto de Ed Yourdon

Por ejemplo, en un sitio para restaurantes en la versión de escritorio tal vez quieras poner fotos para mostrar el ambiente, los platillos, el estilo del lugar, etc. lo cual está muy bien cuando el usuario está pensando en a donde llevar a la novia a cenar al día siguiente o planeando una comida de negocios tranquilamente en su casa u oficina.

En la calle, con el móvil en la mano y un portafolios en la otra o esperando a que se ponga la luz verde, el usuario probablemente estará en una situación muy distinta: quiere saber que hay de comer, que tan lejos está del restaurante y si es necesario llamar para hacer una reservación. Todo eso con una sola mano, en una pantallita y con prisa. Así que si nos ponemos a enseñarle fotos y escondemos el número de teléfono en el pie de la página lo más probable es que sí se acuerde de nosotros pero no de una buena manera.

Esto no quiere decir que no puedas tener estas cosas en tu sitio móvil, pero será mejor dejarlas en un apartado secundario, a uno o dos clics de distancia, mientras que la primera pantalla se la dejamos a la información que el usuario realmente está buscando y las acciones que queremos que tome (llamar y hacer una reservación, por ejemplo).

El truco está en ponerse en los zapatos del usuario y la mejor manera de hacerlo es agarrar algunos cuantos (de preferencia desconocidos que cumplan el perfil de nuestro mercado meta) y pedirles que nos ayuden a probar un sitio. Y si puede ser en su hábitat natural (la calle, el taxi, el café), mejor. Y si tienen todos dispositivos diferentes, mejor.

Ya que los elegimos les pedimos que lleven a cabo una serie de acciones: hacer una reservación, encontrar el menú del día, hacer una orden, pedir más información, es decir, las acciones que a nosotros nos interesa más que nuestros usuarios lleven a cabo.

Mientras las hacen les pediremos que nos digan lo que piensan, que están haciendo y por que lo están haciendo sin darles nosotros ninguna ayuda.

Este es un tipo muy básico de prueba pero nos ayudará muchísimo a darnos cuenta como se comporta nuestro sitio web móvil y donde necesitamos corregir o hacer más fácil su uso. Literalmente hacer estas pruebas representan un mundo de diferencia.

¿Tienes alguna otra sugerencia o pregunta sobre sitios web móviles? ¡Déja un comentario!

¡Video para todos!

Una de las características más cacareadas de html5 es el tag <video> que nos permitiría incrustar video en nuestra página sin tener que depender de plug-ins o hacer malabarismos complicados.

Sin embargo, del dicho al hecho hay mucho trecho y muchos navegadores todavía no soportan ese tag. Lo que es peor, los que lo hacen lo soportan de manera diferente. Ya no digamos la pelea entre los codecs Theora vs H.264 sino en la manera de presentar los controles o alguno que otro error que nos puede afectar al momento de crear nuestra página.

En el sitio de Camendesign han decidido escribir un pedazo de html que nos permitiría usar el tag de html5 pero al mismo tiempo proveer una alternativa para los navegadores que no lo soportan, primero usando QuickTime y finalmente Flash para presentar nuestro video en cualquier dispositivo.

Video for Everybody is simply a chunk of HTML code that embeds a video into a website using the HTML5 <video&ht; element, falling back to QuickTime and Flash automatically, without the use of JavaScript or browser-sniffing. It therefore works in RSS readers (no JavaScript), on the iPhone / iPad (don’t support Flash) and on many, many browsers and platforms. code · Video for Everybody!

El resultado es bastante complicado, con lo que me pregunto si realmente estamos listos para usar el tag video o si será mejor esperar a
que la tecnología esté mejor establecida.

Los únicos usuarios que podrían beneficiarse de este método son los que nos visitan a través de iPhone que no muestra videos en Flash, o los de Mac, cuyo desempeño en Flash apesta. Si estos usuarios son parte importante de nuestra audiencia deberemos considerar servirles el contenido de esta manera.

De otro modo se me hace muy difícil justificar el incremento en complejidad en la página contra el limitado beneficio actual.

¿En realidad la pelea es entre HTML y Flash?

Armando Sosa opina sobre la trifulca del iPad y HTML5 vs Flash:

Dentro de un mes, más o menos, tendremos en el mercado la iPad, el nuevo producto de Apple que viene siendo anunciado como “La mejor forma de experimentar la web”. Lo que no dice Apple, es que la web que vas a experimentar no es la web del mundo real.Dupermag: ¿Flash contra HTML5? ¡Webkit vs. Flash!

En general estoy de acuerdo con Armando. HTML5 y Flash son soluciones distintas a problemas distintos, similares pero distintos.

Flash nació a principios del neolítico (1996 más o menos) como respuesta a la incapacidad de la web de ese entonces de mostrar gráficos de vector, animaciones y la interactividad limitada a hacer clic en ligas. Además le daba a los diseñadores un conjunto de herramientas de desarrollo que les permitían crear de manera fácil y más cercana a su experiencia aplicaciones en línea que podían servir a través de internet u otro medio (como CDs, aunque creo que se usaba más Shockwave para eso).

A partir de entonces HTML se ha desarrollado a pasos agigantados: css, javascript, html 4, xhtml y ahora html 5 han hecho posible que se puedan recrear muchas, pero no todas, las capacidades de Flash.

Por su parte Flash tampoco se ha quedado estático y es, hoy por hoy, el principal medio para servir video en internet. Del mismo modo las herramientas de creación de contenidos de Flash siguen sin tener comparación.

Flash no es perfecto: es un sistema propietario (aunque abierto), tiene problemas de accesibilidad y de indexabilidad, aunque se pueden solventar casi en su totalidad si el diseñador sabe como.

Sin embargo el problema más grande de Flash son los diseñadores que no entienden las limitaciones, sus ventajas y desventajas. Durante muchos años se abusó del uso de Flash y ahora suele asociársele con animaciones de introducción y sitios perfectamente inútiles.

Los estandaristas nos podemos regocijar un poco con la guerra de Apple vs Flash por la concientización hacia estándares que esto ha provocado, pero no debemos confundirnos. El enemigo a vencer no es Flash, sino el abuso de querer usar la ultimísima tecnología, lo más nuevo y vistoso sin ponernos a pensar en los objetivos del sitio ni los principios de usabilidad y accesibilidad que los deben acompañar.

Igual que pasó con AJAX, mucha gente está salivando ante HTML5 y CSS3 por la novedad, pero sin preocuparse por crear un sitio utilizable.

UXExchange: Comparte tu experiencia en UX

UX Exchange es un sitio de preguntas y respuestas, del tipo de Yahoo! Respuestas pero con menos preguntas de chicas adolescentes queriendo saber si es posible que estén embaradas.

De hecho es un sitio orientado hacia profesionales en arquitectura de información, usabilidad, accesibilidad y diseño de interacciones. No parece tener mucho tiempo y la comunidad no es muy grande, pero eso no es necesariamente malo ya que las preguntas y respuestas son de muy buena calidad. Podría haber más y espero que en el futuro así sea sin que se pierda la calidad.

¿Necesitamos servicios en español?

Por supuesto.

Recientemente con el caso de birddi, la copia el plagio de Twitter en español, algunas personas se han cuestionado si realmente es necesario un servicio de Twitter que sea exclusivamente en español.

Algunas de estas opiniones han ido en el sentido de que hay que ser ultranacionalista, ignorante o retrógrada para querer un servicio en español. Estas opiniones son realmente de pena ajena y demuestran el poco contacto con la realidad que tienen algunas personas.

En Hispanoamérica habemos unas 300 millones de personas cuyo principal idioma es el español. Muchas de estas personas también hablamos inglés (el idioma más usado en la red) pero la gran mayoría no, o no lo hablan con la suficiente soltura como para usar un servicio en línea, opinar, comprar, suscribirse o explotar en plena capacidad.

Lo conveniente o no que sea que hablemos más de un idioma es harina de otro costal. Aunque sea lo ideal no vas a lograr que todos ellos usen el inglés de manera fluida de la noche a la mañana. La realidad es que la gran mayoría de los hispanoamericanos se sienten mejor hablando su lengua materna y tener que hablar o escribir en inglés o en otro idioma representa una barrera de entrada real para usar un servicio.

Si realmente queremos democratizar y tener una red verdaderamente abierta que una a todo el mundo, necesitamos tener servicios en español, o por lo menos interfaces en español que nos los permitan usar en la lengua materna. Y, obvio, en francés, catalán, vasco, quechua, maya y rarámuri.

Esto no quiere decir que todos los servicios deban estar en todos los idiomas, sino que sí es váido y hasta necesario que surjan proyectos para clonar o reproducir (pero no plagiar, eso es otra cosa) servicios ya existentes con una orientación a un mercado o un idioma específico. Incluso personajes angloparlantes tan importantes como Jimmy Wales están de acuerdo en esto.

No quiere decir que nos aislemos o que ignoremos el mundo más allá de la hispanidad. Al contrario, al proveer acceso a la información existente en la red en idiomas ajenos al español estamos contribuyendo a que esas personas que hasta ahora han tenido la barrera del idioma puedan contribuir a la creación de contenidos y también asomarse a lo que existe más allá.

Y les recuerdo a los críticos que lo que existe más allá no está sólo en inglés. A quien me diga que los contenidos producidos en francés, chino o ruso no importan le puedo decir con toda seguridad que es un idiota. Muchos de estos contenidos no tienen accesos desde otro idioma, y no son menospreciables por eso. Igualmente, el que exista una red en ruso no impide que los rusos usen servicios en inglés.

Aunque birddi es un plagio descarado el esfuerzo y la intención no dejan de ser respetables. En el caso de específico de Twitter tal vez sea mejor crear un cliente o interfaz en español que usara el API de Twitter en vez de crear una red social separada, pero eso no quiere decir que una red en español no sea necesaria.

¿Qué opinas? ¿Español o sólo inglés?

Diseño para daltónicos: cinco herramientas de accesibilidad

If you are designing, or re-designing your web site, it is time well spent running your website through the color accessibility tools below to ensure that your site can be seen correctly by as many people as possible.Making Your Web Colors Visible For All – Five Color Accessibility Tools

Me gusta este tipo de artículos porque yo mismo soy daltónico. Como tal te puedo decir que me caga sobremanera tener que adivinar los colores en mapas, gráficas e interfaces para saber que demonios me están tratando de decir o donde tengo que picar.

Estas herramientas te ayudarán a crear un sitio que, como dice Jennifer Farley, me va a permitir usar tu sitio sin echar pestes. ¿Qué que te importa? Bueno, alrededor del 8% de la población padece algún tipo de ceguera al color, eso puede representar muchísima gente y mientras más gente pueda usar tu sitio, pues mejor ¿no? (A menos que sea un sitio que hable en contra de los daltónicos, en cuyo caso estas herramientas te ayudarán a asegurarte que no podamos leerlo)

Reblog this post [with Zemanta]

5 Herramientas para mejorar la accesibilidad de tu sitio

Improve Accessibility. Here are some tools you may find useful increase accessibility, a constant battle that UX designers have to face5 Web Accessibility Improvement Tools | UX Booth

Smashing se saca otro 10 con esta lista de 5 herramientas para mejorar la accesibilidad de tu sitio a personas con distintas discapacidades. Desde un simulador de daltonismo hasta un analizador de textos y otro de imágenes.

MaestrosdelWeb en contra de la accesibilidad

Realmente no creo que Maestros del Web esté en contra de la accesibilidad, aunque sus acciones atentan contra esta estoy seguro que es porque no se han puesto a considerar. En Maestros del Web se enteraron de una iniciativa en Noruega para impulsar a la gente a dejar de usar IE6 y lo han tomado como novedad para implementarla ellos mismos y sugerir a otros desarrolladores a hacer lo mismo.

Bueno, la iniciativa me parece mala. Para empezar, cosas así llevan años ¿no se han fijado en como se ve el sitio de Stuff and Nonsense en IE6? Lleva así como dos años. ¿Tampoco se acuerdan de cuando 37Signals anunció que dejarían de desarrollar para IE6?

Puse un comentario en la nota de ellos, pero en lo que se acomiden a aprobarlo lo repito aquí:

Pues estoy totalmente en desacuerdo. Bueno, estoy de acuerdo en que IE6 ya ha cumplido y es un navegador anticuado que no puede mantener el paso de la tecnología actual; pero estoy en desacuerdo en que poner trabas a los usuarios de tal navegador sea buena práctica, ni de creación de sitios, ni de accesibilidad ni nada.

Tengamos en cuenta que el principio de la accesibilidad es crear sitios que puedan ser utilizados por cualquier navegador, incluyendo IE6. También tengamos en cuenta que para alcanzar los objetivos de un sitio no es necesario que este se vea exactamente igual en todos los navegadores. Tanto crear una versión “compatible con IE6″ como construir estos artilugio para decirle al usuario que actualice son una pérdida de tiempo y falta de respeto al usuario (¿cómo sabes qué el usuario está en posibilidades de actualizar?)

Un desarrollador inteligente construirá un sitio que se adapte gradualmente a las capacidades del navegador y no presupondrá la capacidad del usuario. El navegador puede estar en un celular, ser de sólo texto, ser antiguo, etc. El desarrollador no puede suponer que todos usan lo más moderno o el mismo dispositivo para consultar el sitio.

En esencia lo que Maestros del Web propone es detectar el navegador del usuario y mostrarle un mensaje molesto para que se actualice. En esencia parece algo inofensivo y hasta benéfico, pero en realidad va en contra de todas las disposiciones de accesiblidad y buen diseño de un sitio. Peor aún, esto le puede dar excusa a los desarrolladores para no implementar técnicas de mejoramiento progresivo, dejando de lado no sólo a IE6, sino a otros navegadores y dispositivos que no pueden interpretar CSS3 o la más reciente implementación de Javascript. ¿No nos quejábamos cuándo veíamos “Este sitio se ve mejor en IE6”?

“Pero, Roberto,” preguntarán, “¿pero no acabas de señalar ejemplos de eso viniendo de Andy Clarke y 37Signals? Ellos son grandes desarrolladores, seguramente lo harán por algo.” Y tienen razón, lo hacen por algo. Por ejemplo, 37signals no puede implementar nueva funcionalidad en sus aplicaciones en IE6, todo lo nuevo necesita IE7 para funcionar; pero eso no quiere decir que IE6 no pueda usar la funcionalidad anterior. Y Andy Clarke mismo deja clara su posición en otro sitio:

When I talk about designs not looking exactly the same in all browsers I am not talking about making bad designs for people using older or abandoned software. I would never accept that. Andy Clarke, Five CSS design browser differences I can live with

Por cierto, chequen el sitio de la liga de la cita anterior. Es buenísimo.

Hay muchas razones y circunstancias por las cuales es posible que un usuario no quiera o no pueda actualizar su navegador, y no es nuestro papel decirle “tienes que usar tal o cual”, sino proveer la mejor experiencia posible dependiendo de la capacidad de cada navegador; es decir, construir una estructura que permita mejorar gradualmente el sitio de acuerdo a lo que el navegador puede hacer.

Para un ejemplo concreto vean la entrada en Boagworld sobre como implementar mejoramiento progresivo. El tema también se ha tratado en A List Apart y varios otros lugares.

Por supuesto que es más difícil planear e implementar una estrategia de mejoramiento progresivo, al igual que es más difícil la planeación de un sitio hecho con capas y no tablas. Pero al igual que las capas, una vez que se entiende y domina el mejoramiento progresivo las ventajas son bastante evidentes.

Compañeros diseñadores y desarrolladores, gente de Maestros del Web, entiendo que el odio hacia IE6 es comprensible y merecido, y la ira contra él justa, sus ofensas múltiples; pero en nuestro afán por deshacernos de él no debemos afectar al usuario ni pasar a afectar a otros usuarios de otros navegadores. Pensemos mejor en mejorar nuestro dominio de las artes webólicas y procurar la mejor experiencia posible para todo usuario. Además, si creen que actualizar navegadores arregla algo, es que no han visto la sorpresa que trae IE8 o no se han puesto bien a verificar las diferencias entre Safari, Opera y Firefox.

Tipografía en HTML

Un buen tipo de letra puede hacer que tu sitio se vea más interesante, dinámico y original, pero no siempre es fácil usar el que más te gusta. De Robertobaca.Net

El asunto de la tipografía en las páginas de internet es uno de los más complicados. Por lo general, para una página web en html sólo puedes usar los tipos de letra que la computadora de tu visitante tenga instaladas y como no sabes que tipos de letras ha instalado cada quien lo más seguro es usar la tipografía incluida en los sistemas operativos.

Son los más seguros porque casi todo mundo los tiene. Si deseas usar otros que no estén en la lista lo puedes hacer, pero el navegador va a revertirse a uno que sí tenga disponible.

No es necesario usar Arial para todo. Los sistemas operativos actuales incluyen muchos tipos interesantes.

Esto no quiere decir que tengas que usar Arial para todo o que todas los sitios tengan que verse iguales. Como puedes ver en la lista de arriba hay muchas opciones que bien usadas pueden darle a tu sitio más vitalidad y originalidad.

Si aún así esos tipos te parecen limitados o has encontrado la tipografía perfecta para tu sitio pero no es una que sea de las comunes una solución es usar flash. Por lo general flash hace al sitio poco flexible, no estándar e ilegible para quienes no lo tienen y además difícil de encontrar para los robots de google o yahoo.

Pero, puedes usar una técnica llamada sIfr que combina javascript y flash para reemplazar dinámicamente el texto de tu página con tipografía flash. Así puedes usar cualquier tipo de letra que tengas en tu propia computadora.

La ventaja de esta técnica es que si el visitante no tiene flash seguirá viendo el texto de siempre, o sea que puede ser usado por cualquiera sin detrimento y los buscadores lo pueden seguir indexando.