Como você especifica a interação da interface do usuário com o mapeamento de dados (do servidor para o cliente)?
Para um determinado modelo de dados e lógica de negócios (que processa/extrai esses dados), como você especifica uma interface do usuário para exibir/interagir com esses dados de uma maneira que um desenvolvedor possa criá-los.
m exemplo trivial: seria que nome próprio, sobrenome e sexo são armazenados em um banco de dados junto com - signUpDate. A lógica de negócios expõe uma propriedade fullName (composta por nome do arquivo + "" + sobrenome).
O requisito da interface do usuário é que a interface do usuário exiba um rótulo fullName e um ícone de homem/mulher, dependendo do valor em sex. Quando você passa o mouse sobre o rótulo, ele deve mostrar o valor signUpDate.
Como você especificaria isso de tal forma que
- o cliente pode entender o que está sendo exibido, o usuário irá interagir com a interface do usuário (por exemplo, o mouseover)?
- o desenvolvedor pode entender de onde vêm os dados e que eles mudam dinamicamente, dependendo dos dados?
Atualmente, estamos usando uma combinação de Balsamiq, diagramas de ER, diagramas de sequência, diagramas de modelo de dados e palavras para descrever layouts complexos/mapeamento de dados/interações.
Edit: Especificamente em termos de sites baseados em RIA, e não em html (pense em Silverlight/Flash/GWT)
Axure é bastante impressionante para isso - você pode criar seus wireframes e criar elementos interativos que criam cliques interativos em HTML. Custa embora.
A maneira melhor para especificar a interação é com um protótipo interativo . Como um protótipo é o mais próximo possível do real, ele remove quase todas as camadas de abstração entre o design e o aplicativo final, facilitando a comunicação de como as coisas vão funcionar. Isso aumentará significativamente a compreensão do cliente. Ele também permitirá que você teste as coisas das quais não tem certeza (já que está perguntando sobre como especificar coisas para que o usuário interaja com a passagem do mouse).
Para mostrar os estados dos desenvolvedores e como esses estados mudam, seu modelo de protótipo deve oferecer suporte a esses estados e permitir que a pessoa que está visualizando o protótipo ative diferentes estados do aplicativo. Você pode fazer isso usando dados simulados (e devem ser dados simulados reais, não lorem ipsum filler ) e, possivelmente, modelos simples que permitam a modalidade.
O formato do protótipo não precisa ser o mesmo que o produto final. Ele só precisa representar as interações da mesma maneira que o produto final. Portanto, você pode usar HTML, por exemplo, para criar seu protótipo, mesmo que seu aplicativo final seja um cliente de desktop ou um aplicativo Silverlight.
Todas as opções acima são suportadas pelo produto que estamos desenvolvendo e eu o recomendo para a situação que você está descrevendo.