El Kindle Fire es el nuevo reto para los diseñadores web

El desarrollo web se pone interesante con la aparición de nuevos dispositivos móviles

Hace unos pocos días salió a la venta el muy anticipado Kindle Fire, el nuevo “lector de libros” de Amazon que además de leer libros es algo así como una tableta.

Y digo “algo así” porque en realidad no es una tableta, competencia del iPad u otras similares, sino es un dispositivo diferente que ocupa un nicho entre el lector antiguo y el iPad, el Xoom, el Galaxy Tab y demás.

Como tal es más limitada. Lo que no es muy limitado es la pantalla, tiene una resolución de 1024 x 600 pixeles, lo que la coloca en la categoría de algunos monitores de 14 o 15″ de antaño. El problema es que su pantalla es de solo 7″, por lo que todo se ve mucho más pequeño.

La resolución de la pantalla del Kindle hace que nuestros sitios web se vean completos, pero la densidad, es decir, el número de puntos por centímetro, es mucho mayor, los pixeles son mucho más pequeño y por tanto todo nuestro sitio se verá más pequeño: tamaño de letra, botones, imágenes, etc.

El experto en usabilidad Jakob Nielsen dejó al Kindle por lo suelos cuando se trata de usar sitios web. De plano recomendó a los desarrolladores a presentar el contenido móvil en un Kindle. El problema es que la pantalla es bastante más grande que un móvil por lo que no estaremos aprovechándola bien.

¡Qué dilema! El Kindle es apenas el primero de una clase nueva de dispositivos: pantallas pequeñas con una gran densidad de pixeles. Además es un dispositivo móvil, así que de todos modos el contexto en que se usará seguramente será muy diferente al de una computadora de escritorio, o incluso un teléfono. Así que estaría mal darle la misma página que le damos a una PC o a un iPhone.

La mejor manera de acercarse al desarrollo de un dispositivo como estos sería usando la característica resolución para un media query en css:

media: screen and (min-resolution: 99dpi);

Esto nos ayudaría a determinar si la pantalla de nuestro visitante es de muy alta densidad y poder así presentarle botones más grandes e imágenes de mejor calidad, y tal vez ocultarle o quitar relevancia a partes que tienen sentido en otro tipo de aparatos pero no en una tableta.

La diferencia entre una pantalla de 10″ y una de 7″ es notoria y presenta nuevos retos para el diseño de sitios web. Foto de Gadgetmac.

Desafortunadamente no tengo un Kindle Fire para probar (se aceptan donaciones 🙂 ) y no sé si aceptará este tipo de media query. Sería lo ideal porque así nos aseguramos que otros dispositivos en el futuro también podrán ver nuestro sitio correctamente.

Si no tendremos que recurrir a métodos un poco más salvajes, como la detección por medio de javascript, lo cual tiene inconvenientes.

Es un reto más para los diseñadores y desarrolladores web. Nos dificulta un poco más el trabajo, pero es parte de lo que lo hace emocionante. Y eso que no mencioné que el usuario puede estar usando el Kindle horizontal o verticalmente.

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!

La vida secreta de las ligas

Por estos días se llevó a cabo la conferencia An Event Apart que reúne a muchos de los mejores desarrolladores y diseñadores del mundo web para compartir sus experiencias, mejores prácticas y opiniones sobre hacia donde va todo esto.

Jeremy Keith ha estado blogueando en vivo varias de las pláticas, y esta que dio Jared Spool me ha parecido de las mejores opiniones que se han expresado en torno al web. Tanto, que voy a hacer algo que casi nunca hago: traducir. Sé que es la percepción de Jeremy de lo que se habló, pero me parece un documento imperdible para cualquiera que se dedique o se quiera dedicar seriamente a la web.

Puedes ver el original en el sitio de Jeremy, así como sus transcripciones de otras charlas.

La charla se llama “La vida secreta de las ligas”. Comienza hablando de una de las científicas más prometedoras de los Estados Unidos: Lisa Simpson. Un día se le cayó un diente, lo puso en un tazón y después, cuando lo examinó bajo el microscopio, descubrió a una civilización dedicada a lo suyo, todos los ciudadanos con sus vidas íntimas.

El web es así.

Justo antes de que el gobierno estuviera por cerrar por falta de fondos, Jared estaba viendo las noticias y la manera en que actualizaban sus ligas. Jared sugiere que la organización de CNN debería ser así:

  1. La noticia más importante.
  2. La segunda noticia más importante.
  3. La tercera noticia más importante.
  4. Una noticia irrelevante pero entretenida.
  5. La nota sobre Charlie Sheen.

    Pero las cosas no funcionan así. Es el contenido de las ligas lo que determina su importancia. La vida secreta de las ligas consiste en llevar los visitantes hacia su contenido.

    Comparen el viejo diseño de CNN con el nuevo. El diseño visual es diferente, pero la esencia subyacente es la misma. Las ligas funcionan de la misma manera.

    Todos los sitios de noticias reportaban sobre el inminente cierre del gobierno, con ligas que decían cosas diferentes pero hacían la misma cosa.

    Jared ha estado trabajando en la web desde 1995. Todo este tiempo se la ha pasado observando la manera en que los usuarios usan los sitios. El patrón que ha visto es que el contenido se comunica con el usuario a través de las ligas. Todo gira alrededor de las ligas. Son la esencia de la comunicación.

    Esto nos lleva hasta una teoría que se manejaba en el Xerox PARC: si hubiera que modelar el comportamiento de los usuarios cuando buscan información sería muy similar al de un zorro siguiendo un rastro. Los usuarion son informívaros.

    Esto lo podemos ver en sitios de educación. El contenido puede ser diferente pero las ligas son las mismas.

    Todos hemos sufrido la batalla del dueño del sitio, que quiere darle prioridad al contenido en que los usuarios no tienen interés.

    El sitio de Walgreens es un ejemplo interesante. Una quinta parte de los visitantes siguen la liga de Fotos, 16% se van a la búsqueda. La tercera liga más importante es la de reordenar prescripciones. La cuarta es la liga de la farmacia. La quinta es la de buscar tiendas físicas. Estas cinco ligas suman el 59% del tráfico total, pero sólo ocupan 3.8% de la página.

    Esto viola la Ley de Fitts:

    La velocidad a la que un usuario puede encontrar su objetivo es proporcional al tamaño del blanco e indirectamente proporcional a la distancia de ese blanco

    Básicamente, mientras más grande y más cerca esté, más fácil de atinarle. El sitio de Walgreens viola esto. Claro, se vería muy feo si la liga para Fotos ocupara la quinta parte de la página, pero el punto es este: hay un montón de cosas que el negocio le enjareta al usuario.

    Otro ejemplo de la Ley de Fitts son esos enormes anuncios que aparecen de repente con unos botones de “Cerrar” muy pequeños.

    Debes llevar a tus usuarios hacia su objetivo deseado. Dales ligas que comuniquen el rastro de lo que buscan de manera comprensible. Haz que la distribución de tu sitio refleje los deseos del usuario.

    Volvamos a un sitio educacional: La Estatal de Ohio. La gente llega a un sitio por una variedad de razones. Mucha gente no va simplemente a ver como luce (excepto nosotros). La gente va a al sitio de la Estatal de Ohio para informarse sobre cursos y horarios. El texto de estas ligas se llaman palabras detonantes: inician una acción del usuario. Cuando se hace correctamente, las palabras detonantes llevan al usuario a su meta deseada.

    Es difícil saber cuando has dejado un buen rastro de información. Pero es fácil saber cuando ese rastro es malo. El comportamiento de los usuarios te lo hará saber: usan el botón para regresar, saltan de página en página y usan la búsqueda.

    Jared ha visto los mismos patrones en cientos de sitios que ha visto como usa la gente. Tomaban todas las series de clics que tuvieron éxito y todas las que fallaron. Durante 15 años ha habido una tasa constante de 58% de fallas. Es muy impactante.

    Uno de los patrones que emergen de las series de clics que fallan es la presencia del botón para regresar. Si un usuario lo aprieta la tasa de fallas para esa serie de clics aumenta al 80%. Si el usuario lo usa dos veces, sube al 98%.

    El botón para regresar es el botón de la muerte.

    El usuario usa el botón para regresar cuando pierden el rastro, igual que un zorro volviendo sobre sus pasos. Pero los zorros tienen éxito porque los conejos son estúpidos y regresan a donde viven y comen. Así que el zorro puede regresar a ese lugar y esperarlo. Los usuarios regresan a la página anterior con la esperanza que haya cambiado de algún modo.

    Pon atención al botón de regresar. El usuario te está diciendo que ha perdido el rastro.

    Otro comportamiento es saltar, de atrás a adelante en una página de “galería” con una lista de ligas a esas páginas. Los saltos tienen una tasa de falla de 89%. Existe el mito que en sitios de catálogos que a los usuarios les gusta saltar para comparar productos, pero no es verdad. Mientras más saltos es menos probable que el usuario encuentre lo que busca y haga la compra.

    Los usuarios rastrean una página buscando las palabras detonantes. Si la encuentran le hacen clic pero si no comenzarán a buscar. Así funciona en 99% de los sitios, Amazon es una excepción. Y eso porque Amazon ha hecho un gran trabajo enseñando a los usuarios que en la página inicial no hay absolutamente nada útil.

    Algunos sitios tratan de imitar a Google y ponen nada más una caja de búsqueda. No hagas eso.

    Un nombre más adecuado para la caja de búsqueda sería ITPL: Inventa Tu Propia Liga. ¿Qué es lo que la gente escribe en esta caja? ¡Palabras detonantes!

    Consejo: Tus bitácoras de búsqueda están completamente llenos de palabras detonantes. ¿Los has revisado últimamente? Los usuarios te están diciendo cuales deberían ser esas palabras detonantes. Si sigues de donde vienen las búsquedas incluso sabrás en que páginas debes poner esas palabras detonantes.

    Lo más importante es entender que la gente no quiere hacer una búsqueda. Hay un mito que dice que a algunas personas les gusta buscar. Es el diseño del sitio lo que los obliga a buscar. La tasa de falla para una búsqueda es 70%.

    Jared imagina un experimento que se llama “experimento de la leche en el Super 7”. Imaginemos que a alguien se le acaba la leche. Los llevamos al Super 7 y les damos dinero para comprar leche. En el 100% de los casos debería haber un compra de leche.

    Eso es lo que Jared hacer con los sitios. Le da a la gente dinero para comprar un producto, los lleva al sitio y les pide que compren un producto. Idealmente la tasa de compra debe ser de 100%. Pero aún el sitio con mejor desempeño -The Gap- obtuvo apenas 66%. El peor nada más 6%.

    La variable más importante que contribuyó a este patrón fue el número de páginas visitadas por compra. En Gap.com se realizaron compras a razón de 11.9 páginas. Los peores sitios tuvieron 51 páginas por compra. ¿Y sabes qué patrones vieron en los peores? Uso del botón para regresar, saltos, y búsqueda.

    Dale a los usuarios lo que quieren. Páginas que nosotros diríamos que están abarrotadas, no lo están para un el usuario si ese es el contenido que quieren. El revoltijo es subjetivo dependiendo de cuanto te interesa el contenido.

    Es difícil mostrar buenos ejemplos del rastro de información porque no estmos buscando algo específico. El buen diseño es invisible. Uno no nota el aire acondicionado cuando está bien ajustado, sólo cuando está muy frío o muy caliente. No notamos el buen diseño.

    Las ligas viven en secreto para verse bien y seguirse viendo como ligas. Hace tiempo existía la creencia que las ligas debían ser azules y subrayadas. Nuestra elección no pudo haber sido peor. ¿Quién lo decidió? No fueron diseñadores. Fueron astrofísicos en el CERN. Sucede que el azul es el color más difícil de percibir. Los hombres comienzan a perder la habilidad para verlo alrededor de los 40 años. Las mujeres a los 55 porque son mejores. Y el subrayado altera la geometría de la palabra, haciendo la lectura más lenta.

    Afortunadamente hemos avanzado y ahora podemos tener “ligas de color”. Pero a veces vamos demasiado lejos, como el LA Times, en el que es muy difícil sabes que es una liga y que no. Los usuarios tienen que mover el ratón de un lado para otro para ver si el navegador les enseña el dedo.

    Usa un vocabulario consistente. Muestra claramente que ligas llevan a una página diferente y cuales producen una acción en la misma página.

    Confundimos a los usuarios con cosas que parecen ligas pero no lo son.

    Las ligas viven secretamente para hacer lo que el usuario espera.

    Crea tus ligas sabiamente. No pongas ligas a artículos relacionados en la mitad del artículo que alguien está leyendo.

    No uses la navegación de carne misteriosa. Los usuarios no mueven el ratón sino hasta que saben que quieren hacer clic en algo, así que no escondas las ligas detrás de un mouseover. Para cuando esas ligas se revelen será demasiado tarde: el usuario ya habrá decidido en lo que va a hacer clic. Los menús volantes son lo peor.

    Algunos de los ejemplos de ligas favoritas de Jeff son “Cosas que nuestros abogados nos obligaron a poner”, “Menos opciones” y “Todo lo demás”.

    En resumen, esto es lo que nuestras ligas quieren hacer en secreto:

    • Llevar al usuario a su objetivo deseado
    • Dejar el rastro correcto
    • Verse bien sin dejar de verse como liga
    • Hacer lo que el usuario espera

Thanks Jeremy for providing such a fabulous summary of the talk.

¡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.

Pelearán a dos de tres caídas: Diseñadores Gráficos contra Expertos en Usabilidad

En la historia del universo hay muchas peleas eternas entre enemigos acérrimos: luz vs oscuridad, bien vs el mal, Coca-Cola vs Pepsi, Amiga vs Atari ST, Mac vs PC, etc. Hoy mismo Cybergus me recordó con un twitt de una más: Diseñadores Gráficos vs Expertos en Usabilidad.

Verán ustedes, en el principio de los tiempos, como por 1997 inició una pelea sobre el objetivo de la incipiente World Wide Web. De un lado estaban aquellos que abogaban por una red gráfica de cosas bonitas, brillantes y llamativas, que atrajeran la atención y causaran deleite y placer en los visitantes. Sus herramientas favoritas eran Flash, los tatuajes y pastas baratas para alucinar.

Por el otro lado estaban aquellos que insistían que los sitios deberían ser rápidos, utilizables, navegables y su objetivo debería ser permitir al visitante llegar y ¡zaz, pum, bam! hacer lo que tuvieran que hacer y seguir con sus actividades diarias sin volver a pensar más en el sitio. Sus herramientas favoritas eran cuadernos de notas, una calculadora y un cuarto para entrevistas.

Representando al lado de la lógica y la usabilidad estaba Jakob Nielsen, gurú de la accesibilidad y autor de varios libros populares sobre el tema. Del lado de la web como objeto de arte y pasiones desatadas estaba una agencia llamada Kioken Design que ya se murió aunque sus miembros más vocales andan todavía regados por ahí, en especial Joshua Davis que por alguna razón se convirtió en parte muy visible de la agencia.

Aunque en un principio parecería que ganaron los del lado de la medición y la usabilidad ante todo, en realidad no es así. En aquellos tiempos, por allá del año 2000, no existía lo que hoy conocemos como banda ancha, por lo que los sitios altamente gráficos eran muy difíciles de cargar. Tampoco habían surgido las tecnologías que grupos como el WCAG y el WaSP nos han dado (Bueno, ambos existían, pero no habían cobrado ninguna fuerza todavía). Encima de eso los navegadores estaban enfrascados a una lucha a muerte por establecerse como los únicos medios de acceso a internet.

Desde entonces hasta ahora han surgido cambios muy importantes: Flash ha incorporado muchas mejoras orientadas a la accesibilidad y usabilidad; los navegadores siguen (o tratan de seguir) los estándares acordados por el grupo WHATWG; los lenguajes en el servidor como php y .net han madurado y se han vuelto sumamente sofisticados; tecnologías como RSS, JSON, Ajax y el surgimiento de lo que se ha dado en llamar Web 2.0 o Web Social ha hecho el intercambio de información más importante que nunca; y el ancho de banda del navegador promedio se ha multiplicado muchísimas veces al mismo tiempo que la web se ha liberado de la computadora de escritorio. Todavía más importante es el hecho que ahora se comprende mucho mejor al medio y hay mucha gente ahora que no pasó por otros tipos de desarrollo de software o de diseño gráfico sino que se ha formado únicamente en web.

Lo que todo esto quiere decir es que ya no es más necesario una separación entre la forma y la función de un sitio web. Usando tecnologías modernas es perfectamente posible tener un sitio que se vea y se sienta bien que al mismo tiempo pueda usarse fácilmente, responda rápido a las demandas del usuario y pueda ser usado por personas con incapacidades físicas e indexado por Google. Construyendo un sitio correctamente es posible servir la información del mismo a un navegador común y corriente, una interfaz en Flash, un iPhone, una aplicación hecha en Silverlight o a un widget en Facebook.

La capa de presentación ha quedado completamente separada de la del contenido, por lo que se puede pensar en satisfacer la funcionalidad y la forma del sitio sin sacrificios. Ahora hay gente especializada en comprender y fusionar ambos conceptos para construir una experiencia usable y accesible para los visitantes.

De hecho la pelea nunca fue tal. Si en ese entonces se hubieran comprendido mejor las limitaciones de la web como medio tanto diseñadores como desarrolladores hubieran sido capaces de crear sitios más utilizables y estéticos. Esa dicotomía hoy es aún más falsa, sobre todo cuando la funcionalidad de la web se ha ensanchado y explorado más a fondo. Lo más irónico es que sigue la misma pelea de siempre. Todavía hay gente discutiendo si se debe dar prioridad a la usabilidad o al diseño cuando es posible y necesario hacer ambas cosas.

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.

Sitios web con calidad

Hacer un sitio web de calidad es más que desarrollar buen código o tener un diseño visualmente atractivo. Muchas cosas influyen en la impresión final que va a dejar el sitio en las personas que lo visiten y lo más importante es definir con anterioridad cual queremos que sea esa impresión.

De Robertobaca.Net

Lo primero es definir que es calidad y si algo me acuerdo más o menos de mis clases en la universidad es que la calidad al final la define el consumidor en la medida en que cierto producto cumple con sus expectativas.

Es decir, lo primero que tienes que pensar es quienes van a ser los visitantes del sitio, que es lo que quieren de él, y entonces elaborar un sitio que les dé lo que quieren de manera fácil, rápida y accesible.

Entonces, un sitio de calidad, aparte de tener la información que los clientes desean, debe ser:

  1. Encontrable: Debe haber por lo menos una buena oportunidad de que aparezca en las búsquedas de términos relacionados.
  2. Accesible: Los requisitos técnicos para visitar el sitio deben ser fáciles de cumplir, pero no se debe excluir a los visitantes que no los cumplan.
  3. Utilizable: El visitante debe poder encontrar fácilmente la información que necesita así como todo lo que puede hacer en el sitio.

No hay una fórmula exacta para lograr todo lo anterior, pero sí hay mejores prácticas para aumentar la calidad de nuestros sitios y evitar caer en trampas que los hagan inservibles a nuestros visitantes.

Una de las mejores reglas a seguir es escribir en código estandarizado, no abusar de tecnologías restrictivas como flash y ajax, cuando se usen hacerlo en plena conciencia de sus limitaciones y buscar una manera de contrarrestarlas.

Escribir claro, sin verborrea, conciso y sobre el tema del sitio ayudará al visitante a hacerse de la información así como a los buscadores a indexarla correctamente.

Una buena navegación ayudada de un diseño visualmente interesante que ayude a clarificar las secciones y elementos importantes también es de gran utilidad para las personas que visitan el sitio por primera vez o incluso para aquellos que ya han estado antes.

Pero lo más importante es tener un objetivo bien definido de quien queremos que sean nuestros visitantes y como vamos a medir el éxito del sitio, ya sea por visitas nuevas, repetidas, por suscriptores, ventas, etc. Pero tiene que ser algo concreto y medible. Esto, junto con un sistema que deje a nuestros visitantes opinar sobre el sitio nos ayudará a corroborar si de verdad tenemos una página de calidad o no.