O que torna uma interface de interface do usuário eficaz para exibir o versão de dados hierárquicos estruturados

StackOverflow https://stackoverflow.com/questions/2550633

  •  23-09-2019
  •  | 
  •  

Pergunta

O sistema de controle de versão tradicional está exibindo informações de versão agrupando projetos-> pastas-> arquivos com visualização de árvore à esquerda e visualização de detalhes à direita, então você clicará em cada item para analisar o histórico de revisões para esse histórico de configuração.

Supondo que eu tenha todas as informações de versão histórica disponíveis para um projeto da perspectiva do modelo orientada a objetos (por exemplo, classes -> métodos -> parâmetros e etc), qual você acha que será a maneira mais eficaz de apresentar essas informações na interface do usuário para que Você pode navegar facilmente e acessar a visualização instantânea do projeto e também as informações históricas de versão? Coloque -se na posição de que você está usando uma ferramenta como essa todos os dias em seu trabalho, como está usando atualmente SVN, SS, Perforce ou qualquer sistema VCS, o que contribuirá para a usabilidade, produtividade e eficácia da ferramenta.

Pessoalmente, acho que a maneira clássica para pastas e arquivos de exibição como acima são muito restritivos e menos eficazes para exibir modelos lógicos aninhados profundos. Supondo que este seja um projeto Greenfield e não restrito por tecnologia específica, como você acha que devo abordar isso melhor?

Estou procurando idéia e entrada aqui para adicionar valores ao meu projeto de pesquisa. Sinta -se à vontade para fazer sugestões que você acha valioso. Mais uma vez obrigado por quem compartilha seus pensamentos.

EDITADO: Para fornecer mais informações, um item de configuração média, pegue um método será aninhado em cerca de 6 níveis (Projeto-> Assembly-> Module-> Namespace-> Type-> Método e mais níveis para navegar para itens filhos dentro dele) e Este é consistentemente o caso, não como na estrutura do arquivo de pastas, onde você ocasionalmente, em algum projeto, possui uma estrutura aninhada profunda. Quando você tem muitos níveis, o painel de árvores se torna inutilizável para navegar. IMHO, painel de árvores também menos eficaz nesse cenário para apresentar a estrutura geral do sistema.

Foi útil?

Solução

Em vez de tentar selecionar 1 Esquema de apresentação para ajustar n níveis de informações em uma GUI, por que não deixar o usuário escolher o nível certo de detalhes que ele/ela deseja ou precisa?

Perspectivas

Eclipse é um exemplo (não o único) que permite que o usuário definir perspectivas.

Dentro da bancada de trabalho, o recurso de perspectiva é usado para controlar a visibilidade dos itens no modelo e na interface do usuário.
Ele controla o que você vê no modelo (qual projeto, pasta ou arquivos) e o que você vê na interface do usuário (quais ações ou visualizações).
Esses controles possibilitam a navegação e modificar o espaço de trabalho de uma maneira adequada à tarefa do usuário.

Perspectivas pode ser facilmente adaptado para qualquer tipo de exibição de informações hierárquicas.

Perspective

Filtragem de informações por tarefa

Outra maneira eficaz de exibir informações complexas é propor um mecanismo de filtragem eficaz, com base na tarefa atual.
Cada vez que o usuário muda para uma nova tarefa, as várias árvores de informações exibem apenas as informações relevantes.

Ver Mylyn por exemplo:

Mylyn faz das tarefas uma parte de primeira classe do IDE, integra a edição rica e offline das ferramentas ALM e monitora sua atividade de programação para criar um "contexto de tarefa" que focalize seu espaço de trabalho e vincula automaticamente todos os artefatos relevantes à tarefa à mão.
Isso coloca as informações de que você precisa na ponta dos dedos e melhora a produtividade, reduzindo a sobrecarga de informações, facilitando a multitarefa e facilitando o compartilhamento de especialização.

Novamente, isso pode ser aplicado a qualquer tipo de informação.

http://www.tasktop.com/sites/default/files/images/part1-overview.jpg

Outras dicas

Que tal uma variação em um enredo de haste e folha?

http://en.wikipedia.org/wiki/stemplot

Este é um conceito das estatísticas, mas você pode aumentar a estrutura tradicional da árvore, adicionando uma lista de versões à direita de cada arquivo na árvore. Com alinhamento adequado, acho que essa pode ser uma solução visualmente expressiva e utilizável. Algo assim:

* Root Directory
    * Sub Directory A
        * File A.A     | 1 2 3
        * File A.B     | 1 2
    * File A           | 1 2 3 4 5 6 7 8 9
    * File B           | 1 2 3 4 5

O gráfico de caule e folhas fornece uma indicação visual de quantas vezes um arquivo foi revisado junto com o acesso rápido à visualização (edição etc.) e versões.

É provável que isso seja apenas uma visão dos dados. Você ainda ficaria sobrecarregado pela estrutura aninhada, mas se precisar viver com isso, talvez isso ajudasse.

Se você está aninhando 6 níveis, provavelmente está misturando artificialmente várias preocupações. Veja abaixo o modelo 5D. Parece que você deve estar usando o método de classe namespace como o modelo básico de navegação. Você está pelo menos misturando estrutura de código com sua organização em disco (arquivos e pastas) e o mapeamento para variantes. SmallTalk Ides como Pharo Forneça um conjunto de navegadores de código, facilitando a navegação ao longo de algumas dimensões e forneça um kit de construção de navegador Glamour Para fazer o seu próprio para outras dimensões de navegação.

Você vai querer dar uma olhada no trabalho realizado por Richard Wettel. Algo semelhante a Codecity. Usando o OpenGL para criar uma exibição 3 e 4D (tempo) do histórico de desenvolvimento de um projeto. Faz parte da pesquisa em reengenharia de software ALCE.

Para sua pesquisa, você pode querer usar o modelo 5 dimensional para isso:

  • versão (querendo mudar)
  • Status (ciclo de vida: criação, teste, implantação, aposentadoria)
  • Visualização (requisito, código, teste, documentação)
  • Hierarquia (módulo, classe, método)
  • Variante (em grande parte semelhante, descrevendo as diferenças, famílias de produtos)

A maioria dos sistemas lida apenas com algumas dessas dimensões. Para lidar com todos os cinco, você deve descrever (corrigir) seu processo de desenvolvimento. Se o fizer, você pode descrever os casos de uso que deseja apoiar em sua interface do usuário. Caso contrário, você precisa de um mecanismo de exibição flexível de 5 dimensões. Isso não será tão fácil de usar.

A referência:

Gerenciando dados de design: as cinco dimensões das estruturas CAD, gerenciamento de configurações e gerenciamento de dados do produto.
Van den Hamer, P. Lepoeter, K.
Philips Res., Eindhoven;

Este artigo aparece em: Anais do IEEE
Data de publicação: janeiro de 1996
Volume: 84, edição: 1
Na página (s): 42-56
ISSN: 0018-9219
Referências citadas: 26
Codeno: Ieepad
Número de adesão ao inspec: 5175049
Identificador de objeto digital: 10.1109/5.476025
Versão atual publicada: 2002-08-06

Hmm, eu começaria com silo, cilindros verticais, para cada ramo: Dev, liberação, terá um ou mais aqui. Você deve colocar visualmente versões que foram cometidas historicamente aquele silo. Entre essas versões, você teria várias outras alterações que eventualmente voltam.

Ao longo de cada loop, existem pontos de comprometimento fora do silo com X número de alterações. Visualize -os logicamente achatados como frutas penduradas, será uma bagunça um pouco confusa do alto nível, mas a textura, a cor, o padrão, o tamanho da fruta daria a você uma noção do que aconteceu. Também pairando sobre a fruta fornecerá os comentários que foram feitos com o compromisso.

Em seguida, clique no caule da fruta e aqui você vire a vista em vários estilos, mas em vez de navegar na hierarquia para a mudança, use a mudança para navegar na hierarquia. Grande espaço à esquerda, com pouco espaço de enigma à direita. Passando sobre as mudanças se aproximará da hierarquia. Clique na alteração e a hierarquia está congelada e, em seguida, você pode clicar na hierarquia e ir para a visualização do silo novamente, mas desta vez com o arquivo/função/qualquer que seja a única coisa mostrada.

--- Edit --- Aqui está um esboço do que eu estava pensando. Minha ideia é baseada no uso do Mercurial como um repositório de controle de origem. Para mim, pelo menos, seria mais interessante ter uma noção dos tipos de mudanças feitas em cada revisão, uma idéia que pode não combinar com o que você estava atirando. Observando os tipos de alterações, o repositório deve ser capaz de caracterizar e quantificar o que foi alterado, algo mais essencial, acho que quais arquivos foram alterados. Os pequenos pontos seriam apenas o código alterado dentro do próprio método ou possivelmente adições de métodos privados a uma classe. Quando você amplia o zoom de uma fruta, ela preenche o espaço e os troncos desaparecem ou desaparecem a uma marca d'água fraca ou algo assim.

Espero que esse esboço bruto transmita minha ideia um pouco melhor.TEXTO DE ALT HTTP://IMG704.IMAGESHACH.US/IMG704/9034/IMG0507H.JPG

Se você deseja encontrar rapidamente onde o código foi modificado, pode usar uma representação gráfica, indo para a representação semelhante a uma árvore (como a apresentada por McLiedtk) apenas ao selecionar um elemento que seja suficientemente baixo (espaço para nome ou tipo).

Para cada elemento, do nível inferior ao superior, calcule um % de modificação:

  • Para um método ou atributo: 100% se criado/modificado/excluído, 0% caso contrário
  • Para uma classe: média de todos os elementos incluídos (método ou atributo) ou 100% se criado/excluído
  • A mesma coisa para elementos superiores (100% se criado/excluído, média dos componentes).

Agora você precisa ter uma representação que seja mostrar a estrutura hierárquica.
Você pode (por exemplo) usar um radial: o projeto está no centro (ou seja, um círculo). A montagem é apresentada como um anel ao redor, com cada um ocupando o mesmo espaço. Um anel de terceiro nível representa os módulos, cada módulo ocupando o mesmo espaço para sua montagem (ou seja, se houver 4 montagem, cada um receberá 90 ° e se um conjunto tiver 3 módulo, cada módulo obtém 1/3 desses 90 °) , e assim por diante. Cada elemento obtém uma cor mapeada de sua% de modificação (0% = verde = sem modificação,> 85% = vermelho = modificação de heavey)

Um exemplo pode ser como http://www.neoformix.com/2006/bb_topicialtialtreemapimages.png ou http://www.datavisualization.ch/wp-content/uploads/2009/04/stacked_wedge_01.png

No lado profissional, você pode ver de maneira quiked onde ocorreu a modificação e em qual nível.
No lado menos, isso fornece modificação desde uma data de referência e um arquivo modificado uma ou duas vezes é o mesmo que um arquivo modificado 10 tempo. Você também pode precisar adicionar dicas de ferramentas para facilitar a navegação, pois 6 níveis podem se tornar rapidamente não -letais (mas você pode exibir apenas os 4 de 5 níveis mais altos ...)

Cumprimentos
Guillaume

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top