Ce qui rend une interface utilisateur efficace pour afficher des données hiérarchiques versioning structurées

Question

Système de contrôle de version traditionnelle sont affiche des informations de versioning en regroupant Projets-> Folders-> Fichiers avec vue sur des arbres sur la gauche et les détails voir sur la droite, puis vous cliquez sur chaque élément pour examiner l'historique des révisions pour cette histoire de configuration.

En supposant que j'ai toutes les informations versioning historiques disponibles pour un projet du point de vue du modèle orienté objet (par exemple des classes -> Méthodes -> paramètres et etc), que pensez-vous sera la façon la plus efficace de présenter ces informations l'interface utilisateur afin que vous puissiez naviguer facilement et accéder à la vue instantanée du projet ainsi que les informations historiques versioning? Mettez-vous dans la position que vous utilisez un outil comme celui-ci tous les jours dans votre travail comme vous utilisez actuellement SVN, SS, Perforce ou tout autre système VCS, ce qui contribuera à la facilité d'utilisation, la productivité et l'efficacité de l'outil.

Personnellement, je trouve la manière classique pour les dossiers d'affichage et des fichiers comme ci-dessus sont très restrictifs et moins efficaces pour l'affichage des modèles logiques imbriqués profonds. Si l'on suppose que c'est un projet entièrement nouveau et non limité par une technologie spécifique, comment voulez-vous que je devrais meilleure approche cela?

Je cherche idée et entrée ici pour ajouter des valeurs à mon projet de recherche. Ne hésitez pas à faire des suggestions que vous pensez est précieux. Merci encore pour tous ceux qui partage leurs pensées.

ÉDITÉ: Pour donner plus d'informations, un élément de configuration moyenne, prenez une méthode sera imbriquée dans environ 6 niveaux (Projet-> Assemblage> module-> Espace de nommage> type-> méthode, et plus de niveaux pour naviguer vers les éléments enfants en son sein), ce qui est toujours le cas, pas comme dans la structure dossier-fichier dans lequel vous de temps en temps dans certains projets a structure imbriquée profonde. Lorsque vous avez que beaucoup de niveaux, volet de l'arborescence devient inutilisable pour naviguer. À mon humble avis, volet Arbre également moins efficace dans ce scénario pour présenter la structure générale du système.

Answer 1

Plutôt que d'essayer de sélectionner un système de présentation pour le montage n niveaux de informations dans une interface graphique, pourquoi ne pas laisser l'utilisateur choisir le bon niveau de détails qu'il / elle veut ou a besoin?

Perspectives

Eclipse est un exemple (pas le seul) permettant à l'utilisateur de définir des perspectives .

  

Dans le plan de travail de la fonction Perspective permet de contrôler la visibilité des éléments dans le modèle et l'interface utilisateur.
  Il contrôle ce que vous voyez dans le modèle (quel projet, dossier ou fichiers) et ce que vous voyez dans l'interface utilisateur (actions ou vues).
  Ces contrôles permettent de naviguer et modifier l'espace de travail d'une manière qui convient à la tâche de l'utilisateur.

Perspectives peut facilement être adapté à tout type d'affichage de l'information hiérarchique.

Filtrage des informations par tâche

Une autre façon efficace d'afficher des informations complexes est de proposer un mécanisme de filtrage efficace, en fonction de la tâche en cours.
Chaque fois que le changement d'utilisateur à une nouvelle tâche, les différents arbres d'information afficher uniquement les informations pertinentes.

Voir Mylyn par exemple:

  

Mylyn fait des tâches une première partie de la classe de l'IDE, intègre l'édition riche et hors ligne pour les outils de gestion actif-passif, et surveille votre activité de programmation pour créer un « contexte de la tâche » qui se concentre votre espace de travail et relie automatiquement tous les objets pertinents à la tâche à -hand.
  Cela met les informations dont vous avez besoin à portée de main et améliore la productivité en réduisant la surcharge d'information, ce qui facilite multi-tâches et de faciliter le partage des savoir-faire.

Encore une fois, qui peut être appliqué à tout type d'informations.

Answer 2

Comment une variation sur une parcelle de tige et feuille?

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

Ceci est un concept de statistiques, mais vous pouvez augmenter la structure arborescente traditionnelle ajoutant une liste des versions à droite de chaque fichier dans l'arborescence. Avec un alignement correct, je pense que cela pourrait être une solution visuellement expressive et utilisable. Quelque chose comme ceci:

* 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

L'intrigue de la tige et la feuille donne une indication visuelle de combien de fois un fichier a été révisé avec un accès rapide à l'affichage (édition, etc.) et les versions.

Il est probable que ce serait juste un point de vue sur les données. Vous seriez encore encombrés par la structure imbriquée, mais si vous devez vivre avec ça, peut-être que cela aiderait.

Answer 3

Si vous imbriquez 6 niveaux, vous êtes probablement mélanger artificiellement plusieurs préoccupations. Voir ci-dessous pour le modèle 5D. Il semble que vous devriez utiliser méthode namespace-classe comme modèle de navigation de base. Vous êtes au moins mixez structure de code avec son organisation sur le disque (fichiers et dossiers) et la mise en correspondance des variantes. IDEs comme Smalltalk Pharo fournissent un ensemble de navigateurs de code rendant la navigation facile le long de quelques dimensions, et de fournir un kit de construction de navigateur pour faire Glamour vos propres pour d'autres dimensions de la navigation.

Vous voulez jeter un oeil sur le travail accompli par Richard Wettel. Quelque chose de semblable à Codecity . En utilisant OpenGL pour créer un affichage 3 et 4D (temps) de l'histoire du développement d'un projet. Il fait partie de la recherche dans le logiciel MOOSE .

Pour votre recherche, vous voudrez peut-être utiliser le modèle 5 dimensions pour cela:

• Version (vouloir changer)
• Etat (cycle de vie: création, tests, déploiement, retraite)
• vue (exigence, code, test, documentation)
• hiérarchie (module, classe, méthode)
• variante (en grande partie similaire, décrivant les différences, les familles de produits)

La plupart des systèmes ne gèrent que quelques-uns de ces dimensions. Pour gérer tous les cinq, vous devez décrire (fixe) votre processus de développement. Si vous le faites, vous pouvez décrire les cas d'utilisation que vous souhaitez soutenir dans votre interface utilisateur. Sinon, vous avez besoin d'un moteur d'affichage flexible 5 dimensions. Ce ne sera pas aussi facile à utiliser.

La référence:

données de conception de gestion:. Les cinq dimensions des cadres de CAO, gestion de la configuration et la gestion des données de produits van den Hamer, P. Lepoeter, K.
Philips Res, Eindhoven.

Ce document apparaît dans: Proceedings of the IEEE Date de publication: janvier 1996
Volume: 84, Numéro: 1
Page (s): 42-56
ISSN: 0018-9219
Références citées: 26
CODEN: IEEPAD
INSPEC Numéro d'accession: 5175049
Digital Object Identifier: 10,1109 / 5,476025
Version actuelle Publié: 2002-08-06

Answer 4

Hmm, je commencerais avec silo, cylindres verticaux, pour chaque branche: dev, version, aura un ou plusieurs ici. Vous devriez visuellement les versions de place qui ont été historiquement engagés que silo en elle. Entre ces versions vous auriez un certain nombre d'autres changements qui finissent par revenir en boucle.

Le long de chaque boucle il y engager des points à l'extérieur du silo avec x nombre de modifications. Visualisent les logiquement aplaties comme des fruits suspendus vers le bas, ce sera un peu de désordre embrouillé du haut niveau, mais la texture, la couleur, le motif, la taille du fruit serait vous donner une idée de ce qui est arrivé. planant aussi sur les fruits fournira tout commentaires ont été faits avec le commit.

Cliquez ensuite sur la tige du fruit et ici vous retournez la vue autour en plusieurs styles, mais plutôt que de naviguer dans la hiérarchie au changement, utilisez le changement pour naviguer dans la hiérarchie. Grand espace à gauche avec peu d'espace de hiearchy à droite. Planant au-dessus des changements seront zip autour de la hiérarchie. Cliquez sur le changement et la hiérarchie est gelé et vous pouvez cliquer sur la hiérarchie et vous allez à la vue du silo à nouveau, mais cette fois avec le fichier / fonction / whatever étant montré la seule chose.

--- EDIT --- Voici une esquisse de genre de ce que je pensais. Mon idée est basée sur l'utilisation Mercurial en tant que référentiel de contrôle de code source. Pour moi, au moins, il serait plus intéressant d'avoir une idée des sortes de modifications apportées à chaque révision, une idée qui ne peut pas engrener avec ce que vous visiez. En regardant le genre de changements que le dépôt doit être en mesure de caractériser et de quantifier ce qui a changé, quelque chose de plus essentiel, je pense que ce que les fichiers ont été modifiés. Les petits points serait juste code modifié dans la méthode elle-même ou éventuellement des ajouts de méthodes privées à une classe. Lorsque vous effectuez un zoom sur un fruit, il remplira l'espace et les troncs vont disparaître ou disparaître à un filigrane sombre ou une telle.

Hope ce sketch brut transmet mon idée un peu mieux. texte alt http://img704.imageshack.us/img704/9034/img0507h.jpg

Answer 5

Si vous voulez être en mesure de trouver rapidement où le code a été modifié, vous pouvez utiliser une représentation graphique, va à la représentation arborescente (comme celui présenté par mcliedtk) que lors de la sélection d'un élément qui est suffisantly bas niveau (espace de noms, ou le type).

pour chaque élément, à partir du niveau inférieur à celui du haut, calculer un% de modification:

• pour un procédé ou d'un attribut: 100% si créé / modifié / supprimé, 0% sinon
• pour une classe: moyenne de tous les éléments inclus (méthode ou attribut), ou 100% si créé / supprimé
• même chose pour les éléments supérieurs (100% si créé / supprimé, moyenne des composants autres).

maintenant, vous devez avoir pour obtenir une représentation qui est de montrer la structure hiérarchique.
vous pouvez (par exemple) utiliser un radial: le projet est au centre (soit un cercle). ensemble sont présentés sous forme d'anneau autour de, chacun prenant assebly le même espace. un troisième anneau de niveau représentent les modules, chaque module en prenant le même espace pour son ensemble (par exemple, si ther est 4 ensemble, chacun obtenir 90 °, et si un assemblage présente trois modules, chaque module obtenir un tiers des personnes 90 °) , etc. chaque élément obtenir une couleur mis en correspondance à partir de son% de modification (0% = vert = pas de modification,> 85% = rouge = modification de heavey)

Un exemple pourrait être comme http://www.neoformix.com/2006/BB_TopicRadialTreemapImages. ou http: //www.datavisualization. ch / wp-content / uploads / 2009/04 / stacked_wedge_01.png

Sur le côté pro, vous pouvez voir où quikly modification est survenue, et à quel niveau.
sur le côté négatif, cela donne la modification depuis une date de référence, et un fichier modifié une fois ou même deux fois un fichier modifié 10 fois. Vous pouvez également ajouter des infobulles pour faciliter la navigation, comme 6 niveau peut rapidement devenir unreadalble (mais vous pouvez alors afficher uniquement les 4 5 niveaux plus élevés ...)

Cordialement
Guillaume