# Listas de comprobación

## Cosas que puede hacer por si mismo

### Antes de comenzar

Escriba el tipo de personas que espera que usen su aplicación. Luego escriba algunos «escenarios» para cada tipo de usuario; una pequeña historia que describa las tareas habituales para las que esos usuarios usarán su aplicación. Estas tareas deben seguir estas líneas:

> Alfredo necesita encontrar un correo electrónico, que recibió la semana pasada, acerca de widgets

rather than

> Alfredo pulsa en el botón Buscar y escribe `widgets` en el diálogo.

De esta forma, puede usar los mismos escenarios para comprobar y comprar diferentes diseños de interfaces y describir cualquier funcionalidad que falte.

Include these user descriptions and scenarios with the documentation you commit to CVS. This way, other contributors will get to understand your users too, can help to develop the application with that knowledge, and can provide more scenarios of their own.

### Acceso y foco del teclado

Cuando empiece a implementar la interfaz, esconda su ratón y asegúrese de que sigue pudiendo hacer todo usando solamente el teclado. Implemente la funcionalidad del teclado al mismo tiempo que implementa la del ratón: no lo deje para el final.

Usando solo comandos de teclado, mueva el foco por todas las barras de menú y de herramientas en la aplicación. Confirme también que:

- Los menús de contexto sensitivo muestran correctamente (Mayús F10).

- Los consejos o sugerencias se pueden mostrar arriba y abajo para todos los controles que los tienen (Ctrl F1, Esc).

- Todas las funciones listadas en la barra de herramientas se pueden realizar usando el teclado.

- Puede operar completamente todo control en el área del cliente de la aplicación y diálogos.

- El texto y los objetos en el área del cliente se pueden seleccionar.

- Cualquier mejora de teclado o combinación de tecla funciona como se ha diseñado.

- Compruebe que al moverse entre objetivos el indicador del foco visual es fácil de identificar en todo momento.

### Temas, colores y contraste

Pruebe varios temas de GNOME para asegurarse de que su aplicación respeta todos los ajustes disponibles.

Test your application with black and white, high contrast themes and confirm that all information is still conveyed correctly. If you don't have a suitable high contrast GNOME theme available to test, print off some screenshots in black and white (not grayscale) and make sure all the important information is still visible— this will approximate what a high contrast theme user will see.

### Animación

Asegúrese de que ha implementado una opción para apagar cualquier animación en su aplicación (por razones de accesibilidad), y de que funciona tal y como está diseñada. Apague la animación. Confirme que toda la información se muestra correctamente.

## Lo que puede hacer con otras personas

### Obtener comentarios rápidamente

It's always tempting, but don't start coding your interface straight away. Sketch out some ideas on paper first, or in Glade or HTML if you prefer. (But don't be tempted add any functionality at this point if you do it this way!)

Show these prototypes to other people— the GNOME mailing lists and IRC are ideal for finding likely candidates. Ask them to use these prototype interfaces to run through some of the scenarios you came up with earlier. You'll probably get questions like "how would I do X", "which menu is Y on"... these questions will help you think about the interface from the user's viewpoint. You'll probably also get a few suggestions about how to do things differently— these ideas may or may not turn out to better than yours, but any idea from a potential user is worth considering!

You should also consider seeking opinions from the GNOME Usability team. They have designed many user interfaces before and may be able to spot potential problems at this early stage, before you take your design too far to change easily.

Once you've decided on the basic interface design and have started coding parts of it, find somebody to try it out again— it doesn't have to be the same person. You'll probably find some more problems that were hard to see on your static paper prototype. By finding these now, it's usually not too late to fix them without too much trouble.

### Internacionalización y localización

If you intend your application to be translated into different languages, show draft designs of your application to the GNOME Translation Team. They'll help you find potential translation problems, such as not leaving enough space for translated labels, shortcut keys that cause problems on a different keyboard layout, or using new terms in your app that are hard to translate.

If possible, try out your application with users from the locales you are targeting. This will help you determine whether users understand how to use the application, if they perceive the graphics and colors the way you intended, and if there are words or images in the application that may cause offence to users of that locale.