2010-02-18 5 views
6

¿Hay algunas normas que considere tan obvias que se suponga que están en alguna especificación?¿Qué es siempre 'Estándar'? Si la especificación no lo dice, ¿debería suponerse?

Por ejemplo, si se golpea el escape siempre se debe cancelar un formulario? ¿Debería hacer doble clic en un separador de encabezado de columna para cambiar el tamaño de la columna?

Cuando un cliente dice "esto es obvio y 'comportamiento estándar' por lo tanto, es un error no tenerlo" - ¿están algunas veces en lo cierto? Si es así, ¿hay algunos recursos que pueden ayudar a mediar?

Recuerdo que un profesor nos pidió que escribiéramos todos los detalles relacionados con tareas simples y lo ridículo que podía ser. No quiero que nuestras especificaciones sean ridículas, pero me canso de escuchar esto y estoy pensando que nuestras especificaciones no son lo suficientemente específicas.

+2

Incluso las cosas obvias deberían tener al menos una mención rápida en los requisitos como "Generalmente, la IU debe seguir las pautas de UI definidas en http://somebigcompany.com/defaultUIguidelines/" –

Respuesta

3

Por cuestiones de interfaz de usuario, es posible que desee consultar una guía de interfaz de usuario existente, como Apple's o Microsoft's . Hay bastantes más, pero esos dos son jugadores lo suficientemente grandes como para que sus pautas reflejen probablemente lo que los usuarios esperan en mayor grado que la mayoría de los demás.

Editar: el cierre de un diálogo con la tecla Escape está cubierto en Microsoft guideline (vaya a "interacción"):

Al pulsar la tecla Esc cierra siempre un cuadro de diálogo activo. Esto es cierto para los cuadros de diálogo con Cancelar o Cerrar, e incluso si se ha cambiado el nombre de Cancelar a Cerrar porque los resultados ya no se pueden deshacer.

No me veía muy duro, pero no vi nada sobre las columnas de cambio de tamaño automático, y es lo suficientemente inusual que me sorprendería si estuviera allí.

Como tal, si yo estuviera a cargo de esto, yo diría que es una decisión dividida (por así decirlo). Es razonable que el cliente espere que la clave de escape descarte un diálogo (sin especificarlo explícitamente), y no hacerlo debería considerarse un error.

Auto-cambiar el tamaño de la columna en respuesta a doble clic en el borde de la cabecera de la columna no es razonable esperar sin especificar, por lo que la implementación debe considerarse una característica adicional.

Advertencias:

  1. Si está desarrollando para algo que tiene sus propias directrices de interfaz de usuario (por ejemplo, el Mac o iPhone) esas son las reglas a seguir. La participación de mercado de Microsoft hace que la suya sea una opción obvia para un objetivo que no tiene su propia guía de interfaz de usuario.
  2. Esto es claramente una cuestión de relaciones con los clientes. Es evidente que no desea perder a su mejor cliente por algo que podría implementar con bastante facilidad. Si la función de cambiar el tamaño de las columnas hace una gran diferencia para ellos, y ellos son un buen cliente de lo contrario, puede tener sentido que lo haga por ellos - pero que sepan que les está haciendo un favor a causa de lo mucho que los valora . Sólo tienes que tener cuidado con el equilibrio del calentamiento difusa "porque eres especial" parte con la leve sentimiento de culpa y vuelta de "por lo que le estamos haciendo un favor y ahora que nos debe ..." (OMI, por lo general mejor no decir la "y ahora que nos debe" parte en voz alta, pero yo no conozca a su cliente).
+0

Gracias - eso es bueno, pero lectura muy larga. No vi ninguna mención de los dos ejemplos en mi publicación en Microsoft. ¿Eso significaría para usted que el cliente debería haber sido específico? es decir: ¿escapar para cancelar y hacer doble clic en el encabezado de la columna para autoescribir serían características adicionales en lugar de correcciones de errores? – aSkywalker

1

Cree una especificación de placa de caldera que incluya/referencia en todos sus proyectos del mismo diseño general. Esta especificación debería crecer y cambiar a medida que aprenda más sobre las demandas de sus clientes/clientes. Esta especificación también debe hacer referencia a las pautas de UI apropiadas proporcionadas por Apple o Microsoft. Incluso si está en una plataforma, le recomiendo leer las otras especificaciones para conocer mejor las formas de hacer las cosas o identificar posibles contratiempos. También hay varios buenos libros sobre el diseño de la interfaz de usuario de los que es posible que desee pedir prestado.

3

es una práctica estándar para especificar los estándares de interfaz de usuario, no los asuma

por ejemplo, hacer doble clic en el encabezado de la columna en una cuadrícula para cambiar su tamaño es no un comportamiento estándar de Windows GUI. Sin embargo, hacer doble clic en el separador de columna para cambiar el tamaño de la columna.

vale la pena el esfuerzo para especificar los comportamientos estándar de la GUI para que no haya confusión; si puede hacer referencia a un estándar existente que está bien, pero asegúrese de que el cliente lo firme

"No puedo leer su mente, y tal y tal no es un comportamiento estándar/predeterminado" es la lógica réplica ... pero no muy cortés. ;-)

2

Mi cita favorita de la universidad "Lo bueno de los estándares es que hay muchos para elegir".

Supongo que está haciendo esta pregunta porque desafortunadamente se ha visto envuelto en una disputa "pero no ha pedido eso". Eso puede ponerte en un punto difícil. En general, quiere que la empresa le proporcione su estándar o, como han mencionado otros, puede acordar mutuamente un estándar de terceros. Si está ejecutando una empresa que produce muchos tipos del mismo tipo de aplicación, debe pasar el tiempo una vez para generar su "estándar".

Si está sentado en el momento de la firma y alguien se niega a pagar debido a las características "estándar", entonces necesita tener algunos ejemplos de lugares donde esto no es estándar. En su ejemplo, por ejemplo, cerrar formulario en la clave de escape es solo estándar en Windows (no en la web) y luego solo para Microsoft. Acabo de abrir tres aplicaciones en mi computadora donde ESC no hizo nada en absoluto en un formulario.

Casi nada es estándar. En cualquier persona determinada, el "estándar" de la mente va a significar algo ligeramente diferente y, si no se especifica en alguna definición mensurable, dará lugar a argumentos en el futuro.

+0

Agregando a eso: no puedo pensar en ninguna forma que se cierre al tocar ESC así que definitivamente no es estándar (es decir, el explorador de Windows permanece abierto, el calc permanece abierto, el bloc de notas permanece abierto, Internet Explorer 8 permanece abierto ... eso es cada aplicación de Microsoft incluso remotamente podría reaccionar a ESC con el cierre). – dbemerlin

+0

ESC se usa a veces para cerrar Diálogos, que es probablemente lo que quiso decir ... otro ejemplo más de definición de "estándar". Por ejemplo, el diálogo "Guardar como ..." en prácticamente todos los productos de Microsoft inicia Cancelar en ESC. –

1

Nada es estándar a menos que esté escrito y especificado en algún lugar relacionado con su proyecto (o vinculado a partir de la especificación). Si no está escrito, no es estándar, por lo que el cliente debe definirlo.

En otra nota:
Si la biblioteca de la interfaz de usuario lo hace de una manera y que requeriría de codificación para hacerlo de otra manera (ejemplo estúpida: ¿Quiere que los usuarios hacen clic botones con el botón derecho del ratón), entonces usted debe parar y volver a pensar acerca lo que los usuarios pueden esperar

Cuestiones relacionadas