TP

1. IInntteerrffaacceess ddee UUssuuaarriioo
((ccoonnsseejjooss ddee ddiisseeññoo))
Asignatura: MMeettooddoollooggííaa ddee ssiisstteemmaass 11
Curso: 4B
Alumno:
LLuunnaa JJeessúúss
Martes 18 de Noviembre de 2014

2. VENTANAS
● Deben soportar la resolución minima efectiva de 800 x 600 pixeles.
Para las interfaces de usuarios criticas que deben trabajar en modo
seguro la resolución minima efectiva debe ser de 640 x 480 pixeles.
asegurarse de tener en cuenta el espacio utilizado por la barra de
herramientas que se reserva 48 pixeles verticales, para las ventanas
que incluyen la barra de herramientas.
● Si la ventana es hija de otra ventana, en un principio mostrarla
"centrada" en la parte superior de la ventana propietaria. Nunca debajo.
Para la visualización posterior, considere mostrarla en su última
ubicación (relativa a la ventana propietaria), haciéndolo de esta manera
es la forma mas conveniente.
● Si una ventana es contextual, siempre que aparezca cerca del objeto
desde el cual fue invocada. Sin embargo debe estar colocada de
manera estratégica (preferiblemente abajo, hacia la derecha), de modo
que el objeto no quede cubierto por la ventana.

3. Palabras
● Es recomendable usar términos ordinarios con los cuales el usuario este familiarizado,
“entablar una conversación con el usuario”, cuando sea posible. Centrarse en las
necesidades y objetivos del usuario, pensar que es lo que el usuario necesita hacer y no
centrarse en la tecnología. Esto es extremadamente eficaz si se está explicando un
concepto técnico o una acción compleja. Imagínese estar en el mismo lugar con el
usuario mirando y guiándolo para llevar a cabo la tarea a realizar.
● Elimine las palabras redundantes. Buscar las palabras redundantes en los títulos de las
ventanas, las instrucciones principales, instrucciones suplementarias, áreas de
contenido, enlaces de comandos y botones de confirmación. En general, dejar el texto
principal completo en
las instrucciones y los controles interactivos y eliminarlo de cualquiera de los otros lugares.
Sugerencia: Mostrar texto incompleto o truncado en una ventana o una página con espacio
sin utilizar indica una mala administración del espacio o un tamaño de ventana por
defecto incorrecto y que es demasiado pequeño. Esforzarse por lograr diseños y
ventanas con tamaños predeterminados que eliminen o reduzcan la cantidad de texto
truncado.
● No utilice el texto de color azul cuando no se trate de un enlace, ya que los usuarios
pueden suponer que se trata de un enlace y esto podría causar confusión. En vez de esto
Utilice negrita o un tono de gris.
● Utilizar negrita con moderación, solo para llamar la atención de los usuarios cuando se
presenta texto que requiera ser leído por el usuario.

4. Barras de progreso
● Utilice barras de progreso solo para determinadas operaciones que requieren una
cantidad limitada de tiempo, incluso si esa
cantidad de tiempo no se puede determinar con precisión. Aún no sabiendo la cantidad
de tiempo que requiere cierta operación las barras de progreso muestran que el
programa se esta ejecutando y no dan la sensación de que el programa se colgó,
pero estas no deben proporcionar ninguna otra información.
● Proporcionar una estimación del tiempo restante para la finalización de un proceso es
conveniente, si puede hacerlo con precisión mucho mejor, las estimaciones del
tiempo restante precisas son muy útiles, pero si estas estimaciones son erróneas el
impacto en el usuario seria altamente negativo de manera que lo frustraría y el
software perdería credibilidad. Puede que tenga que realizar algún tipo de
procesamiento antes de poder dar estimaciones precisas. Si es así, no muestre las
estimaciones potencialmente inexactas durante este período inicial.
● No reinicie el progreso. Una barra de progreso pierde su valor si se reinicia (tal vez
porque un paso en la operación no esta completo), ya que los usuarios no tienen
forma de saber si la operación se completará.
En cambio, todos y cada uno de los pasos de la operación deben representar un
porcentaje de la barra de progreso y tener la barra de progreso completa
a la finalización de la misma.

5. Antelación
● Los desarrolladores deben esforzarse en realizar aplicaciones que "lean la mente del usuario“,
que se anticipen a sus necesidades de manera contextual. que la aplicación sea una ayuda y
no un estorbo a la hora de que el usuario deba realizar sus tareas. Muestra al usuario toda la
información y herramientas necesarias para cada etapa en su trabajo. No hay que esperar a
que el usuario busque algo hay que dárselo antes de que incluso el mismo sepa que lo va a
necesitar.
● Bríndale al usuario confort , que se sienta cómodo usando el sistema que sienta que el maneja al
sistema y no el sistema a el, "que el sea el que manda" y las cosas se hagan como el quiere
dándole cierta libertad. De esta manera aprenderá mas rápido a usar el sistema y así el
sistema ganara reputación entre los usuarios.
● Pese a que un sistema pueda parecer, sin fronteras o restricciones el usuario no se siente libre
(Yallum, 1980); es como un niño pequeño que llora cuando se le mantiene muy atado o se le
deja en un edificio grande y vacío. Los adultos también se sienten más cómodos en un entorno
ni muy restrictivo ni demasiado grande, un entorno explorable pero no peligroso.
● Mantén informado al usuario del estado y las acciones que va tomando el sistema.
● No existe autonomía en ausencia de control; y el control no se puede tener sin información
suficiente. Comunicar el estado es fundamental para que el usuario responda apropiadamente
con la información disponible.
● Ejemplo: los trabajadores sin información del estado del sistema, tienden a mantenerse bajo
presión durante cortos periodos de tiempo hasta que el trabajo se termina. Un estrés y fatiga
innecesarios por lo que cuando venga la siguiente carga de trabajo, puede que los trabajadores
no estén en las mejores condiciones físicas y mentales.

6. Información de estado visible y actualizada
● De un vistazo los usuarios deberían ser capaces de hacerse una idea aproximada del
estado del sistema. La información de estado puede ser bastante sutil: el icono de la
bandeja de entrada puede mostrarse vacía, medio llena o hasta los topes, por ejemplo.
Sin embargo, no es conveniente abusar. Macintosh utilizó durante años un icono de la
papelera que parecía que iba a explotar en cualquier momento, aunque sólo tuviese un
documento. Los usuarios adquirieron la costumbre de vaciar la papelera apenas
contuviese un documento, convirtieron un proceso de un paso en uno de dos (primero
llevamos el documento a la papelera, luego lo vaciamos). Esto tuvo el efecto negativo
de reducir una de las funciones básicas de la papelera: la posibilidad de deshacer la
acción.
● Otro ejemplo posible de información de estado sería el de un una caja de búsquedas que
cambiase de color para indicar si la búsqueda está todavía en marcha o si ya ha
terminado, con demasiados resultados, con muy pocos o justos con lo necesario.
Valores por defecto
● Los valores por defecto deberían ser poder descartados con facilidad y rapidez. Los
campos de texto con valores por defecto deben aparecer seleccionados, para que el
usuario sólo tenga que teclear y no seleccionar todo, borrar y escribir.
● Los valores por defecto deben tener sentido. Deben ser un ejemplo del valor que el
usuario debe ingresar
● No uses la palabra "por defecto" en una aplicación o servicio. Utiliza "estándar", "Usar
valores habituales", "Restablecer valores iniciales" o términos más específicos que
describan lo que sucederá.

7. BBiibblliiooggrraaffííaa::
● Msdn Microsoft, http://msdn.microsoft.com
/es-ar/library/windows/desktop/aa511258.
aspx
[consulta: 18/11/2014 ]
● Galinus, http://galinus.com/es/articulos
/principios-diseno-de-interaccion.html
[consulta: 18/11/2014 ]