¿Cómo se especifica la interacción de la interfaz de usuario con la asignación de datos (del lado del servidor al lado del cliente)?
Para un modelo de datos determinado y una lógica de negocios (que procesa/extrae esos datos), ¿cómo se especifica una interfaz de usuario para mostrar/interactuar con esos datos de manera que un desarrollador pueda crearlos?.
n ejemplo trivial: sería que a nombre, apellido y sexo se almacenan en una base de datos junto con - signUpDate. La lógica de negocios expone una propiedad fullName (compuesta de nombre + "" + apellido).
El requisito de la interfaz de usuario es que la interfaz de usuario debe mostrar una etiqueta de nombre completo y un icono de hombre/mujer según el valor en sexo. Cuando pasa el mouse sobre la etiqueta, debe mostrar el valor signUpDate.
¿Cómo especificarías esto de modo que
- el cliente puede entender lo que se muestra, el usuario interactuará con la interfaz de usuario (por ejemplo, el mouseover)?
- ¿El desarrollador puede entender de dónde provienen los datos y que cambian dinámicamente dependiendo de los datos?
Actualmente estamos utilizando una combinación de Balsamiq, diagramas ER, diagramas de secuencia, diagramas de modelos de datos y palabras para describir diseños complejos/mapeo de datos/interacciones.
Editar: Específicamente en términos de sitios web basados en RIA en lugar de html (piense en Silverlight/Flash/GWT)
Axure es bastante impresionante para esto: puede diseñar sus estructuras alámbricas y hacer elementos interactivos que creen clics HTML interactivos. Costos sin embargo.
La forma ¡la mejor para especificar la interacción es con un prototipo interactivo . Dado que un prototipo es lo más parecido posible a lo real, elimina casi todas las capas de abstracción entre el diseño y la aplicación final, lo que facilita la comunicación de cómo van a funcionar las cosas. Esto aumentará significativamente la comprensión del cliente. También le permitirá probar cosas de las que no está seguro (ya que está preguntando cómo especificar cosas para que el usuario interactúe con el mouseover).
Para mostrar los estados de los desarrolladores y cómo cambian esos estados, su modelo de prototipo debe admitir esos estados y permitir que la persona que ve el prototipo active diferentes estados de la aplicación. Puede hacerlo utilizando datos simulados (y deben ser datos simulados reales, no lorem ipsum filler ) y posiblemente plantillas simples que permitan la modalidad.
El formato del prototipo no necesita ser el mismo que el producto final. Solo necesita representar las interacciones de la misma manera que lo hará el producto final. Por lo tanto, puede usar HTML, por ejemplo, para crear su prototipo, incluso si su aplicación final será un cliente de escritorio o una aplicación Silverlight.
Todo lo anterior está respaldado por producto que estamos desarrollando y lo recomiendo para la situación que está describiendo.