Atividade:
| ||||||||||||
Finalidade
|
|
| Passos
Para cada protótipo da encenação de caso de uso a ser criado na iteração atual, siga estes passos:
Esses passos estão apresentados aqui em uma ordem lógica, mas é provável que você precise alterná-los e executá-los em paralelo. Inicialmente, você leva mais tempo criando o protótipo. Depois, quando já o conhece melhor, leva menos tempo para implementá-lo e obter feedback sobre ele. |
|
| Artefatos Informados: | Artefatos Resultantes: |
| Papel: Designer de Interface de Usuário | |
| Detalhamentos do Fluxo de Trabalho: |
Estes são diversos aspectos envolvidos no design do protótipo da interface do usuário:
Esses aspectos serão apresentados a seguir. No entanto, um projeto não precisa considerar todos esses aspectos no protótipo. Freqüentemente, alguns aspectos podem ficar por conta dos implementadores e, portanto, não os inclua no protótipo. Nesse caso, recomenda-se deixar de lado os últimos aspectos listados e concentrar-se nos primeiros.
Ao projetar o protótipo, você deve:
Cada agregação de classe de fronteira oferece uma sugestão para a janela principal da interface do usuário. Entretanto, lembre-se de que uma das metas durante a criação do modelo de objetos é identificar as hierarquias de agregação mais superficiais. A finalidade é, essencialmente, minimizar o número de janelas principais e, portanto, os caminhos de navegação entre elas. Além de representarem uma carga de interação desnecessária, os caminhos de navegação muito longos entre as janelas aumentam a probabilidade de o usuário "se perder" no sistema. Idealmente, todas as janelas devem ser abertas a partir de uma janela principal, o que resulta em uma navegação máxima entre duas janelas. Tente evitar a navegação entre mais de três janelas.
A janela principal deve ser aquela que é aberta quando o usuário inicia o aplicativo. Normalmente, ela permanece aberta durante a execução do aplicativo e é onde o usuário passa uma considerável parte de seu "tempo". Como ela está sempre aberta e constitui o primeiro contato do usuário com o sistema, ela é o veículo principal para impor o modelo mental que o usuário tem do sistema.
A sugestão mais óbvia para a janela principal é definida pela classe de fronteira superior na hierarquia de agregação. Por exemplo, a classe Documento em um editor de documentos. Para obter detalhes, consulte Diretrizes: Classe de Fronteira. Se houver várias hierarquias de agregação, escolha a que é mais importante para o usuário, ou seja, onde ele passa a maior parte de seu tempo.
Quando a janela principal for identificada, considere as outras classes agregadas que fazem parte das hierarquias de agregação e decida se elas devem ser as janelas principais. A recomendação padrão é que elas devem ser janelas compostas, e não janelas principais propriamente, se possível. Mais uma vez, o objetivo é minimizar o número de janelas principais e, dessa forma, diminuir também os caminhos de navegação entre elas. Além do mais, uma janela composta é, com freqüência, justificada pelo fato de que seus componentes precisam aparecer juntos e manter uma relação espacial com os componentes de outros compostos. Lembre-se de que o acesso é difícil se forem usadas janelas (principais).
A agregação Parágrafo em um editor de documentos é projetada como uma janela composta e não como uma janela principal própria. Isso ocorre parcialmente porque os componentes de um Parágrafo, ou seja, os Caracteres, devem aparecer juntos e em relação espacial com os Caracteres de outros Parágrafos.
Como uma alternativa de design, imagine a usabilidade de um editor de documentos em que o usuário tenha que navegar para uma janela (principal) separada, toda vez que o conteúdo de determinado parágrafo tiver que ser visualizado.
Entretanto, freqüentemente, as agregações não podem ser todas projetadas como janelas compostas devido às limitações de área da tela. Se não houver espaço para projetar todas as agregações como compostas, tente ao menos projetar as seguintes agregações como compostas:
Lembre-se de que, nesse passo, a informação sobre o volume médio de objetos é importante, pois indica quantos objetos precisam ser exibidos de uma vez. Excesso de objetos pode sugerir que eles não podem ser projetados como objetos compostos. Em vez disso, podem ter uma representação compacta na janela principal em que residem e definir suas próprias janelas principais.
A visualização das janelas principais e de sua janela principal em particular causarão um impacto significativo sobre a usabilidade do sistema. O design dessa visualização envolve a determinação de quais partes (atributos) dos objetos contidos devem ser visualizados. As descrições do fluxo de eventos e da encenação ajudam a priorizar os atributos a serem exibidos. Se o usuário precisa ver diversos atributos diferentes dos objetos, você pode implementar várias visualizações de uma janela principal, cada qual com um conjunto distinto de atributos. O design dessa visualização também significa que você tem que verificar como as partes (atributos) dos objetos contidos devem ser visualizadas, por meio de todas as dimensões visuais. Para obter detalhes, consulte a seção "Dimensões Visuais" em Diretrizes: Interface do Usuário (Geral).
Se uma janela principal contiver objetos de várias classes, será importante identificar os "denominadores comuns" para essas classes, como, por exemplo, os tipos de atributo contidos em todas as classes ou na maioria delas. Com a visualização de denominadores comuns em alguma dimensão, o usuário pode relacionar objetos de diversas classes entre si e verificar a existência de padrões. Dessa forma, a "largura de banda" da interface do usuário aumenta bastante.
Suponha que você tenha um sistema de atendimento ao cliente, no qual deseja mostrar aspectos como:
Reivindicações e questões levantadas pelos clientes ao longo do tempo.
Produtos que o cliente adquiriu até hoje.
Valor total de todas faturas do cliente até o momento.
Aqui, o denominador comum é "tempo". Sendo assim, a exibição de reivindicações/questões, aquisições e faturas lado a lado no mesmo eixo temporal horizontal permitirá ao usuário verificar os padrões de relacionamento entre esses itens (se houver algum).
As responsabilidades das classes de fronteira especificam as operações necessárias às respectivas janelas. Comumente, as operações das janelas principais e os objetos que elas contêm são oferecidos como itens em uma barra de menus e como alternativa e complemento em menus de atalho e barras de ferramentas. Se uma janela principal contém objetos de várias classes e se elas executam várias operações, você poderá atribuir um menu a cada classe ou um menu a cada grupo de operações coesas.
Em um editor de documentos, há um menu Editar, que agrupa operações coesas como Recortar, Copiar e outras.
Algumas operações podem precisar de uma interação complexa com o usuário e, por isso, justificar uma segunda janela para suas próprias atividades.
Em um editor de documentos, há uma operação Imprimir em um Documento que, devido à complexidade da interação, justifica uma janela de diálogo separada.
As janelas de propriedades precisam ser projetadas para todas as classes de fronteira e, dessa forma, disponibilizar todos os seus atributos para o usuário. Lembre-se de que alguns objetos só podem ser parcialmente visualizados quando estão em uma janela principal (consulte a seção "Projetar a Visualização das Janelas Principais" acima). Suas janelas de propriedades, por outro lado, visualizarão todos os respectivos atributos. Nesse passo, os valores médios dos atributos são informações importantes, pois ajudam a escolher a visualização ideal de um atributo específico.
Algumas responsabilidades simples das classes de fronteira, como a definição do valor de determinado atributo, são freqüentemente fornecidas como operações pela janela de propriedades. Uma operação desse tipo não é disponibilizada na janela principal na qual reside o objeto ou pode funcionar como alternativa ou complemento de uma operação semelhante na janela principal.
Se fizer parte de uma associação (inclusive os objetos associados), a classe de fronteira será visualizada na janela de propriedades.
Se uma classe de fronteira definir a visualização de um grande número de objetos na interface do usuário, o design das operações que envolvem esses objetos será delicado. Estas são diversas variantes dessas operações:
Consulte Diretrizes: Interface do Usuário (Geral) para obter mais detalhes.
Acrescente o comportamento dinâmico necessário à interface do usuário. A maioria das dinâmicas são oferecidas pela plataforma-alvo, como o paradigma selecionar-operar, e abertas com um clique duplo, menus pop-up do botão direito do mouse e outros. Apesar disso, algumas decisões devem ser tomadas:
Avaliar também outras características comuns que melhoram a usabilidade, inclusive:
Consulte Diretrizes: Interface do Usuário (Geral) para obter mais detalhes.
Esses são basicamente os três tipos de implementação de um protótipo da interface do usuário:
Na maioria dos projetos, você deve usar todos os três tipos de implementação na ordem listada acima. Essa ordem permite a incorporação de mudanças iniciais, pois o tempo de implementação de cada um difere bastante (desenhos são bem mais rápidos de serem criados e modificados do que executáveis). Entretanto, os desenhos não refletem corretamente a área de tela limitada, eles podem conter mais detalhes do que o espaço da tela.
Por fim, a melhor maneira de especificar a interface do usuário é através da combinação de bitmaps e executáveis. Isso deve ser feito assim que você precisar expor o protótipo a outras pessoas além dos designers da interface do usuário. Um bitmap pode especificar a aparência exata das janelas principais, enquanto os executáveis podem mostrar a aparência aproximada das janelas principais e do suporte às suas operações, assim como a aparência e o comportamento das janelas secundárias. Naturalmente, será melhor se, com um esforço razoável, você puder implementar a aparência exata das janelas principais no executável do que combinar o executável e um bitmap. Se não tiver recursos suficientes para produzir um executável, você poderá usar bitmaps como a implementação final do protótipo. Nesse caso, pode ser útil complementá-los com encenações de casos de uso que descrevam sua dinâmica. Caso contrário, é provável que os implementadores da interface do usuário usem a dinâmica incorreta.
Concentre-se não em obter uma boa estrutura e modularização do código-fonte para o protótipo do executável, mas sim na criação de um protótipo temporário que visualize os aspectos importantes da interface do usuário e ofereça algumas de suas operações mais significativas. De mais a mais, um protótipo está sujeito a várias mudanças quando é projetado e exposto a outras pessoas. Essas mudanças são geralmente efetuadas como patches de baixo custo. Como conseqüência, o valor do código-fonte do protótipo é limitado, além de não poder "evoluir" quando a interface real do usuário é implementada.
Em geral, é aconselhável manter a implementação de um protótipo executável mais barata do que a implementação de uma interface real do usuário. Estas são algumas diferenças entre o protótipo e a verdadeira interface do usuário:
Consulte Conceitos: Teste de Usabilidade.
|
Rational Unified Process
|
