it-swarm-pt.com

Como definir interações e animações de maneira extensível?


A questão toda, resumida para responsabilidade:

  • Como seria melhor para um designer definir interfaces de usuário realmente complexas?
  • Seria uma boa abordagem mapear como o processo criativo mental funciona em ferramentas?

Um dia eu quero criar um designer de interface do usuário melhor para aplicativos de desktop do que o que existe atualmente (é um projeto de longo prazo) e já estou tentando reunir idéias sobre se é possível ou não ter uma estrutura verdadeiramente extensível.

O principal problema que vejo é que você precisa interagir entre abstrações de alto nível, como interações entre componentes, e recursos de baixo nível, como aplicar desfoque em uma superfície semitransparente. Isso requer bons modelos do que uma interface de usuário é composta.

Uma "animação" pode ser qualquer coisa, desde a aplicação de efeitos a uma imagem (como um borrão, ruído ou etc.) até a tradução de objetos em 3D, até o clarão de uma luz percorrer um caminho ao preenchê-lo, a qualquer coisa que se possa imaginar .

Interações também são complexas. Talvez você não queira que uma animação aconteça se outra estiver em andamento, ou se alguns dados não estiverem presentes etc., ou talvez apenas desencadeie alguma ação em algum evento.

Definir tudo isso a partir do código, qualquer que seja o código, não é o ideal. Quero opiniões sobre como isso poderia ser "ideal", ou apenas melhor, visualmente, da perspectiva de um designer.

Em outras palavras, como seria o ambiente de design da interface do usuário/UX dos seus sonhos ?

(observação: esses problemas também se aplicam ao design de sites ou dispositivos móveis; portanto, se você tiver opiniões nesses campos, também será bem-vindo).

Atualizar:

Vou expor alguns pensamentos que tenho sobre como isso pode ser feito.

Primeiro e acima de tudo, um dos objetivos é fazer uma separação completa entre o trabalho do designer e o trabalho do programador.

É minha convicção que a interface do usuário e o UX devem ser considerados antes de escrever qualquer lógica de aplicativo - às vezes, ao ver uma GUI, é possível ver melhor quais recursos estão faltando e quais são desnecessários.
Portanto, o designer deve poder criar interações complexas na interface do usuário, mesmo que essa interface não execute nenhum código. Isso também facilita a depuração da interface do usuário.

Portanto, um aplicativo exporia uma API à interface do usuário, composta por:

  • "Ações" (com ou sem parâmetros)
  • "Propriedades"
  • "Solicitações" (ou seja, funções com parâmetros. As funções sem parâmetros se parecerão com propriedades)

O designer também terá ferramentas que fornecem fontes de dados sem sentido em um formato personalizado, para que ele possa conectar-se a "propriedades falsas" na configuração de depuração, como um Lorem Ipsum.

As propriedades expostas ao designer não podem ter nenhum objeto - elas podem ser um número de tipos de dados genéricos simples, como "Texto" (string), Inteiro, "Decimal" ou até "Imagem" (por simples, eu quero dizer = simples para o designer, mais sobre como lidar com problemas de desempenho posteriormente), matrizes de algum tipo simples ou "dados compostos", semelhante à noção de Tuplas , para agrupe vários tipos de dados ou matrizes.
Isso significa que o designer pode simplesmente solicitar os dados de que precisa ou gerar facilmente alguns dados falsos para fins de depuração.

Agora, e o desempenho?

Bem, todos sabemos que gerar a mesma imagem repetidamente seria caro, mas o designer não deve pensar muito sobre isso. Em vez disso, a solicitação repetitiva para o mesmo elemento seria armazenada em cache por um intermediário entre o código do aplicativo (feito pelo programador) e a interface do usuário, na API.

Ainda estou pensando nos detalhes da implementação disso, mas isso significa que um programador pode dizer à API que chama a mesma função com os mesmos parâmetros repetidamente, gerando o mesmo resultado e a API armazenará em cache os resultados dessa função de maneira inteligente.
De qualquer forma, isso pode ser implementado, será transparente para o designer, pois esse é o objetivo.

Sobre alguns conceitos que estou pensando para a composição da interface do usuário:

(termos bastante auto-explicativos)

Superfícies: Componentes básicos da interface do usuário que possuem propriedades e uma forma e estão vinculados a um material. Representado internamente em formato vetorial.
Material: Elemento compartilhado na interface do usuário que pode definir em um só lugar o estilo de vários elementos (como preenchimentos de gradiente ou textura, bordas sombras projetadas etc.).
Componentes: Partes da interface do usuário com lógica própria, que poderiam fazer coisas mais avançadas do que superfícies, como gerar efeitos de partículas , vinculando-se a outros componentes de maneira interativa e gerando subcomponentes próprios. Isso tornará certos efeitos como um círculo de círculos "carregando" animado ( como este ) mais simples de fazer. Eles conterão uma linguagem de script, talvez um mecanismo Javascript.
Efeitos/transições: Destina-se a ser acionado por outras partes da interface do usuário ou alterações de estado. Coisas como ButtonFoo.Glow ou PanelBar.MoveToLeft nomeado e projetado pelo designer e agrupado em um sistema semelhante ao namespace.
Estados: Representam o estado atual da interface do usuário e podem ser usados ​​por gatilhos.
Disparadores: Estes disparam certos efeitos ou transições.
Condições: São verificações que podem ser anexadas aos gatilhos.

O designer também poderá expor os dados ao programador, por um sistema que se parece com as propriedades consumidas do lado do designer.

7
Camilo Martin

Eu acho que o usuário pode estar focado em uma coisa ao mesmo tempo: pode haver alguma visão na hierarquia de visualizações (1); caso contrário, quando temos muitas visualizações de interação ao mesmo tempo, essas visualizações devem ser (serão boas) independentes (2). ) Portanto, no (1) caso, o aplicativo pode controlar a visualização atual do estado, e no (2) caso, o aplicativo não precisa sincronizar o estado das visualizações independentes.

Por exemplo, o desenvolvedor deve implementar uma máquina de estado finito orientada a eventos para processar todas as visualizações dependentes ou deve usar gatilhos da interface do usuário para reproduzir animações.

1
igor