Os quiero recomendar una aplicación muy útil.

Cuando la descubrí se me alegró el día. Es un programita que gestiona carpetas en un ftp de 2 Gb en la versión gratuita, 50 Gb por $9.99 al mes y 100 Gb por 19.99€. Lo que más me gustó es la facilidad de uso, y la interface muy intuitiva y agradable.

Ya cuando activas el instalador (versión de Mac), se intuye el gran nivel de profesionalidad. En unos pocos pasos, en el proceso de instalación, te enseña cómo utilizar la herramienta con imágenes visuales muy bien realizadas, el conjunto de los elementos gráficos y la colocación de cada elementos, me trasmite que trabajaron mucho en el campo de usabilidad y los resultados son evidentes.

A nivel de desarrollo, está muy bien hecho. Yo trabajo directamente con los archivos compartidos, en pocos segundos se actualizan en la carpeta del equipo donde trabajo, la carpeta en la web y la carpeta del equipo de casa. Desde entonces he dejado de utilizar Flash drive para mover archivos.

Otra de las ventajas que tiene es que ofrece la posibilidad de carpetas públicas y carpetas privadas. Cuando copio un archivo en una carpeta pública me deja generar una ruta (URL). ¿Cuál es la ventaja de todo eso? Pues, si necesito enviar un archivo a una imprenta, por ejemplo, le envío una mail con la ruta y ya está.

Para mi fue una gran sorpresa encontrarlo: ya puedo olvidarme de las interfaces poco amables de los FTP comunes, “upload” , “download” y trabajar cómodamente desde mac arrastrando archivos en carpetas.

Aquí tenéis la web www.dropbox.com

namron Curiosidades Herramientas útiles

Quiero resumir en algunos puntos el proceso creativo y las pruebas de usabilidad que hay detrás de la creación de una nueva aplicación.
En realidad deberían ser más puntos, pero muchos se repiten, es un trabajo muy meticuloso que necesita muchas pruebas, a nivel de desarrollo y también de diseño.

Punto 1

Analizar la información que tenemos (briefing), en caso de no tenerla disponible, debemos recopilar toda la información necesaria, para tener perfectamente definidos los objetivos y la misión.

Punto 2

Investigar aplicaciones existentes y estudiar ideas que están funcionanando en la competencia.

Punto 3

Dibujar los primeros bocetos e ideas en lápiz y papel.

Punto 4

Una vez realizadas estas pruebas por tí mismo, llegando a la conclusión de que sí puede funcionar correctamente por tu experiencia personal y profesional, empezamos a pasar los bocetos a pantalla, con un programa de diseño. En mi caso utilizo el “Fireworks”.
Los bocetos generados en pantalla, van sin diseño, a modo de “WireFrame” . Simplemente son rectángulos colorados que me sirven para plasmar la idea y realizar una maqueta provisional sobre la que realizar pruebas.

Punto 5

Imprimimos y recortamos los “WireFrame” (como si fueran las páginas reales de trabajo), recortamos ventanas pop-up, pestañadores etc… todo lo que necesitemos, para simular una navegación dentro de una aplicación.

Puntos 6

Debemos encontrar un “observador”, en mi caso el responsable de desarrollo “Sgomez”.
Realizamos pruebas de usuarios, con gente de perfil diferente, tomando nota de todos los comportamientos, y damos las gracias a los participantes por ofrecernos su valioso tiempo. En nuestro caso utilizamos personal interno de la empresa, pero en el caso de que fuesen personas externas, deberíamos pagar la hora etc…

En esta fase descubriremos muchas cosas:
Por ejemplo, en esta ocasión nos sorprendimos mucho al ver que, al ver una rejilla vacía, los usuarios no hacían absolutamente nada. Sin embargo, nosotros estábamos convencidos, por costumbre, que sin dudar pincharían encima de una linea para acceder a ella, o al menos hacer algo y nos parecía lo más normal del mundo. Esto supuso una buena lección, que nos enseñó a ser más humildes y pensar que no siempre nuestras convicciones son ciertas.

Punto 7

Analizar los datos, encontrar soluciones eficientes, realizar nuevos Wireframe, imprimirlos.

• Para solucionar el problema mencionado antes, hemos puesto un botón “entrar” al final de cada línea de la rejilla y un check-list al principio de la linea para seleccionar. Funcionalmente a nivel de programación no sirve, en nuestro caso, pero fue muy útil para guiar visualmente a nuestro usario y que pinche en la rejilla.
• Otra mejora que realizamos está relacionada con los niveles de jerarquía. Nos dimos cuenta de que la pestaña “listado” no era necesaria y que los botones en la mismo nivel que la pestaña “listado” creaban confusión. Daba la impresión de que eliminaría toda la caja de contenido. Elaboramos una nueva propuesta en la que destacamos más los niveles de cada bloque de contenido. En cuanto a los botones, los colocamos justo encima de la rejilla, para hacer entender que actúan encima de ella y no de todo el bloque.

Punto 8

Otra prueba de usabilidad, recopilación de datos y volver al diseño a realizar cambios.

Punto 9

Ya tenemos una estructura más solida y usable, podemos empezar a diseñar, de verdad, cada uno de los elementos y componerlos.

Punto 10

Diseño y desarrollo, esta parte es donde se crea en real todo el diseño, realizando pruebas y solucionando fallos que se pueden encontrar por el camino.
Con mucha paciencia y muchas pruebas sobre la marcha, se sigue trabajando en equipo hasta alcanzar una maqueta que sea ya operativa.

Punto 11

Nueva fase de test de usabilidad, esta vez con diseño real y aplicaciones reales.
En esta prueba descubrimos problemas con los iconos (los botones de la aplicación).

• El primer problema era a nivel cromático: el contraste entre desactivado y activado era demasiado ligero y provocaba incertidumbre para algun usuario.
• Otro problema estaba en la estética del icono, que no era tan clara como a nosotros nos parecía, , en particular el icono papelera.
• Además de descubrimos algunos fallos de programación.

Punto 12

Analizamos los nuevos datos y buscamos la solución más correcta a cada problema.
Se cuidan los detalles, y se prueba todo lo que se puede para que no haya fallos de ningún tipo, ni a nivel de diseño ni tampoco a nivel de código.

• En esta fase solucionamos los fallos, mejorando el efecto de activado y desactivado con colores (azul como activado y gris desactivado), y los iconos se dibujaron con más detalles y más intuitivos.

Punto 13

Presentación del producto internamente.
Fue todo un éxito, y surgieron algunas ideas de mejoras para la aplicación.

Punto 14

Aplicamos las mejoras propuestas en la presentacion interna y aquí tenéis el resultado de la aplicación.

La moraleja es que para realizar un buen desarrollo y un buen diseño, debemos realizar muchas pruebas con diferentes usuarios, durante todo el procedimiento de creación y hasta al desarrollo, pensando en las personas reales que trabajarán con el producto final, y no desarrollar un producto hecho a medida para nosotros, que sólo sabremos utilizar nosotros.

Punto 15

Quiero que os fijéis en los elementos clave para hacer accesible nuestra aplicación a todos los usuarios, dejándole moverse con tranquilidad en nuestro entorno gráfico sin perderse.
Todo lo que añadimos o modificamos, surge de preguntas y dudas lógicas que nos hacemos de manera automática en nuestra mente. Por lo que lo que debemos hacer es tratar de solucionar todas estas preguntas de la manera más simple y eficaz.

Os dejo un listado para aclarar mejor las ideas, cada elemento responde a una pregunta logíca.

• Identificador Sitio: ¿Que aplicaciones estamos ejecutando?
• Identificador Usuario: ¿Quien soy, que rol tengo aquí?
• Nombre apartado: ¿Donde estoy, que estoy viendo?
• Nombre rejilla: ¿Como se llama lo que veo?
• Navegación local: ¿Que puedo hacer, como tengo que actuar?

Quiero dar las gracias a todo el magnifico entorno de trabajo, a todas las personas que participaron en este proyecto directa e indirectamente.
No menciono los nombres de todos para evitar que se me escape alguno, prefiero mencionar solo a quien luchó codo con codo conmigo en todo este proceso, Sgomez (Santiago Gómez Seoane) responsable de desarrollo en Velneo V7.

namron Usabilidad Desarrollo

Vinculación Link

Los vínculos constituyen una parte importante del hipertexto y podemos dividirlos en 3 tipos principales:

De navegación.

Aquellos vínculos que te permiten moverte por las páginas de una web, botones de menú principal, vínculos de páginas secundarias etc…

De contenido de la pagina.

Aquellos vínculos que te llevan a más contenido de la página, suelen ser texto subrayado o img (más info).

Listas de referencia externa.

Son listas que Ayudan el usuario a encontrar lo que quiere si la página no es la adecuada.

Reglas básica de como debería ser un vínculo.

Páginas enlazadas cortas.

Las páginas enlazadas desde un vínculo no deberían ser muy largas, porque como en una revista impresa, estas páginas son un sitio donde descansar la vista mientras examinas un artículo.

Ejemplo:
página enlazada corta

No usar “Haga clic aquí”.

Evitar enlazar un vínculo con el texto “Haga clic aquí” utilizado como hipertexto.
La razón es que sólo los usuarios que usan los ratones harán clic, mientras que los discapacitados que tengan dispositivos especiales no harán clic.
Otra razón que las palabras “Haga clic aquí” no aportan mucha información, como tal no hay que aplicarlas como elemento de diseño.

Ejemplo:
Incorrecto > Para saber más sobre Namron, haga clic aquí
Correcto > Tenemos más información sobre Namron

Un link de hipertexto no debe contener más de 4 palabras

Dato que debería tener sólo 4 palabras*, se aconseja añadir texto sin ancla que explique el vínculo.

Ejemplo:
Incorrecto >Tenemos más información sobre Namron
Correcto > Tenemos más información sobre Namron

*Este punto es muy debatido en usabilidad, esa es la versión de Jacob Nielsen, pero sobre la “longitud” de un vínculo y el “número de palabras” hay diversas opiniones. Desde mi punto de vista, lo que dice Nielsen tiene sentido, pero hay que añadir siempre, un poco de sentido común dependiendo del caso específico.

Diferenciar los vínculos iguales.

Si los vínculos con ancla se parecen, hay que diferenciarlos con textos descriptivos.
De esa forma el usuario, antes de acceder, ya sabrá previamente lo que va a encontrar.

Ejemplo:
Para ir a la página principal > …podemos verlo en la página de inicio de Jakob Nielsen
Para ir a la biografía > Jakob Nielsen es una de las personas más respetadas en el ámbito mundial sobre usabilidad

La costumbre del Title.

Una buena costumbre a la hora de maquetar código html para crear un vínculo, es describir correctamente el comando “title” para denominar nuestro vínculo.

Ejemplo:
<a href=”http://namron.es/2009/11/22/usabilidad-como-crear-un-enlace” title=”Como crear un enlace”>Este artículo</a>
Con este código si pasamos el cursor encima del vínculo, transcurrido un segundo, nos aparecerá “Como crear un enlace” indicando dónde enlaza, podéis probarlo: Este artículo

Colorear los vínculos

Azul aquellos vínculos que el usuario nunca ha visto
Morado o rojo los vínculos que un usuario ha visto antes.

Ejemplo:
Vínculo nunca visto > Vínculo
Vínculo ya visto > Vínculo

* Jacob Nielsen aconseja no utilizar colores no estándar, pero está claro que desde que Nielsen dijo eso, los tiempo evolucionaron y las web cada vez son más variadas. Así aconsejo más que utilizar estos colores, intentar mantener una coherencia: si en vuestra web en la “pagina de inicio” los enlaces son de color naranja (cuando no están visitados) y de color verde (cuando están visitados), mantener esta gramática en todas la páginas de vuestra web, para facilitar el aprendizaje a los usuarios.

Utilizar la misma URL

Es un fallo bastante común, hago una web de contenido y hago una vez un vínculo a una pagina con una URL, después hago otro vínculo que enlaza a la misma página con URL diferente. Por ese pequeño fallo, el enlace nos aparecerá como (no visitado, color azul por ejemplo) cuando seguramente ya lo hemos visitado anteriormente.

Ejemplo:
<a href=”http://www.namron.es/”> o <a href=”http://namron.es/”> enlaza a la misma página, pero por el simple echo de estar escrito de formas diferentes, los lee como dos vínculos distintos.
Prueba 1
Prueba 2

Vínculos externos

• Si hacemos un vínculo externo asegurarnos que la calidad de la página valga la pena para salir de nuestra web.
• Asegurarnos de no vincular páginas temporales.
• No utilizar en código html target=”blank”, se ha estudiado que hacer que al pinchar en un vínculo se abra otra ventana o pestaña, resulta incómodo a la hora de volver atrás, porque es más simple volver atrás si lo carga en la misma ventana.

Vínculos internos (o entrantes)

Es cuando otro sitio enlaza al tuyo, esa es una de las mejores formas para generar tráfico en tu web.
Una de las formas para provocar que tu web sea enlazada es no creando páginas temporales para que se puedan enlazar.
Reallizar contenidos de calidad, para que las personas te utilicen como referencia.
Otra forma es especializarse en un tema, así mucha gente hará referencia a tus páginas

Vínculos publicitarios

Caso especial de vinculo entrantes.
Se aconseja crear un vínculo con páginas que sigan el mensaje del anuncio en vez de crear vínculos directos con su página de inicio.
Los estudios de publicidad web han descubierto que entre el 20% y el 30% de los usuarios web que hacen clic en un banner y comprueban que están conectados con una página corporativa de inicio, hacen clic en el botón Atrás.

P.D.
Es una buena norma, utilizar las cosas que funcionan a la hora de generar vínculos, más es un estándar mejor es…

Se vemos que en muchas web ponen para acceder a más informaciones de esa forma “más info” o “saber más”, ¿por qué tenemos que re-inventar la rueda y llamarlo “descubre más”? utilizar lo que ya la gente conoce es una gran ventaja.

namron Usabilidad

En primer lugar, quiero aclarar que el título está hecho para provocar un poco. Yo, personalmente, no tengo nada en contra de las betas, suelo utilizarlas y trabajar con ellas. Lo único que quiero decir con este artículo es que debemos valorar bien los riesgos que tienen a la hora de implementarlas en los clientes.

Unos de mis últimos descubrimientos en la Usabilidad es, el consejo de no utilizar las beta.

Se aconseja esperar un mínimo de un año tras la salida de la versión oficial de un producto.

El porqué es muy simple y lógico:

• 1º Hay que pensar que la tecnología beta es muy inestable, puede aportar más problemas que beneficios.
• 2º La tecnología beta, normalmente no es accesible para los usuarios finales hasta que deja de ser beta, por tanto después de la salida oficial. Aún así pasará un mínimo de un año hasta que muchos usuarios la conozcan y la tengan disponible.
• 3º Esperar un año después de que salió la versión oficial es una buena estrategia, porque después de la salida oficial se siguen encontrando errores y trabajando en mejoras.
• 4º Esperar un tiempo desde la versión oficial es también una buena forma para aprovechar y formarse en la nueva tecnología y no implementar algo que no sabemos utilizar bien.

Para entenderlo mejor: hay que pensar que cada semana sólo un 2% aprox. de los usuarios se actualiza a lo último. Así que, de acuerdo con las estadísticas se tardará un mínimo de un año para que más del 80% de los usuarios tengan la nueva tecnología instalada. Éste es el gran motivo por el cual tomarse con calma la salida de una nueva versión.

Está claro que todo eso no vale en caso de que seas el promotor de la nueva tecnología. En ese caso, tendrás que utilizarla desde la fase beta, pero teniendo particular cuidado en facilitar la accesibilidad a personas que no tienen los mismos avances.

namron Usabilidad Beta

La tecnología debería ser tan sencilla como la caja que la contiene.

Creemos que la tecnología puede ser muy avanzada y sencilla al mismo tiempo.

Debe ser fácil de utilizar y diseñada para todos. La sencillez debe ser su objetivo principal.

Para Philips lo es. Tiene sentido.

Reflexiones:
Esta publicidad me encanta. En pocas palabras explica la importancia de lo usable para una empresa importante como Philips.

namron Usabilidad Philips