Что делает эффективный интерфейс для отображения версий структурированных иерархических данных

Question

Традиционная система управления версиями отображает информацию о версиях, группируя Проекты-> Папки-> Файлы с древовидным представлением слева и подробным представлением справа, затем вы нажимаете на каждый элемент, чтобы посмотреть историю изменений для этой истории конфигурации.

Предполагая, что у меня есть вся историческая информация о версиях, доступная для проекта с точки зрения объектно-ориентированной модели (например, классы -> методы -> параметры и т. Д.), Что, по вашему мнению, будет наиболее эффективным способом представления такой информации в Пользовательский интерфейс, чтобы вы могли легко перемещаться и получать доступ к представлению снимка проекта, а также к исторической информации о версиях? Поставьте себя в положение, в котором вы используете инструмент, подобный этому, каждый день в своей работе, как в настоящее время вы используете SVN, SS, Perforce или любую систему VCS, что будет способствовать удобству использования, производительности и эффективности инструмента.

Лично я считаю, что классический способ отображения папок и файлов, подобный приведенному выше, очень ограничен и менее эффективен для отображения глубоко вложенных логических моделей. Предполагая, что это проект с нуля и не ограничен какой-либо конкретной технологией, как вы думаете, как мне лучше всего подойти к этому?

Я ищу идею и вклад, чтобы добавить ценности в мой исследовательский проект. Не стесняйтесь делать любые предложения, которые вы считаете ценными. Еще раз спасибо за всех, кто разделяет их мысли.

ИЗД. больше уровней, чтобы перейти к дочерним элементам внутри него), и это всегда так, а не как в структуре папок-файлов, где вы иногда в каком-то проекте имеете глубокую вложенную структуру. Когда у вас есть столько уровней, панель дерева становится непригодной для навигации. ИМХО, древовидная панель также менее эффективна в этом сценарии для представления общей структуры системы.

Answer 1

Как насчет вариации на стебле и листовом участке?

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

Это понятие из статистики, но вы можете дополнить традиционную древовидную структуру, добавив список версий справа от каждого файла в дереве. Я думаю, что при правильном выравнивании это может быть визуально выразительным и удобным решением. Как то так:

* 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

График ствола и листа дает визуальное представление о том, сколько раз файл был пересмотрен, а также быстрый доступ к просмотру (редактированию и т. Д.) И версиям.

Вероятно, это будет только один просмотр данных. Вы все еще были бы обременены вложенной структурой, но если вам придется с этим смириться, возможно, это поможет.

Answer 2

Если вы вкладываете 6 уровней, вы, вероятно, искусственно смешиваете несколько задач. Смотрите ниже для 5D модели. Похоже, вы должны использовать namespace-class-method как базовая модель навигации. Вы по крайней мере смешиваете структуру кода с его организацией на диске (файлы и папки) и отображением вариантов. Среды IDE Smalltalk, такие как Pharo , предоставляют набор браузеров кода, упрощающих навигацию по нескольким измерениям, и предоставляют набор конструктора браузера Glamour , позволяющий создавать собственные для других измерений навигации.

Вы захотите взглянуть на работу, проделанную Ричардом Веттелем. Нечто похожее на Codecity . Использование OpenGL для создания 3- и 4-мерного (временного) отображения истории разработки проекта. Это часть исследований в области реинжиниринга программного обеспечения MOOSE .

Для вашего исследования вы можете использовать для этого 5-мерную модель:

• версия (желающая изменить)
• статус (жизненный цикл: создание, тестирование, развертывание, выход на пенсию)
• просмотр (требование, код, тест, документация)
• иерархия (модуль, класс, метод)
• вариант (в значительной степени похожий, описывающий различия, семейства продуктов)

Большинство систем работают только с некоторыми из этих измерений. Чтобы справиться со всеми пятью, вы должны описать (исправить) ваш процесс разработки. Если вы это сделаете, вы можете описать варианты использования, которые вы хотите поддерживать, в вашем пользовательском интерфейсе. Если нет, вам нужен 5-мерный гибкий движок дисплея. Это будет не так просто использовать.

Ссылка:

Управление данными проектирования: пять измерений CAD-структур, управление конфигурацией и управление данными о продукте.
van den Hamer, P. Lepoeter, K.
Philips Res., Эйндховен;

Этот документ появляется в: Слушаниях IEEE
Дата публикации: январь 1996
Объем: 84, Выпуск: 1
На странице (ах): 42-56
ISSN: 0018-9219
Цитируемые ссылки: 26
КОД: IEEPAD
Инспекционный номер INSPEC: 5175049
Идентификатор цифрового объекта: 10.1109 / 5.476025
Текущая версия Опубликовано: 2002-08-06

Answer 3

Вместо того, чтобы пытаться выбрать одну схему представления для подгонки n уровней информации в графическом интерфейсе, почему бы не позволить пользователю выбрать правильный уровень детализации, который он / она хочет или нуждается?

Перспективы

Eclipse - один из примеров (не единственный), позволяющий пользователю определять перспективы .

В рабочей среде функция перспективы используется для управления видимостью элементов в модели и пользовательском интерфейсе.
Он управляет тем, что вы видите в модели (какой проект, папка или файлы) и что вы видите в пользовательском интерфейсе (какие действия или представления).
Эти элементы управления позволяют перемещаться по рабочему пространству и изменять его так, чтобы это соответствовало пользовательской задаче.

Перспективы можно легко адаптировать для любого вида иерархического отображения информации.

Фильтрация информации по заданию

Другим эффективным способом отображения сложной информации является предложение эффективного механизма фильтрации, основанного на текущей задаче.
Каждый раз, когда пользователь переключается на новую задачу, в различных информационных деревьях отображается только соответствующая информация.

См. Милин , например:

Mylyn делает задачи частью первого класса IDE, интегрирует расширенное и автономное редактирование для инструментов ALM и отслеживает ваши действия по программированию, создавая «контекст задачи», который фокусирует ваше рабочее пространство и автоматически связывает все соответствующие артефакты с задачей на -hand.
Это позволяет получить необходимую информацию у вас под рукой и повысить производительность за счет уменьшения информационной перегрузки, упрощения многозадачности и обмена опытом.

Опять же, это может быть применено к любой информации.

Answer 4

Если вы хотите быстро найти место, где был изменен код, вы можете использовать графическое представление, переходя к древовидному представлению (например, представленному mcliedtk) только при выборе достаточного элементанизкий уровень (пространство имен или тип).

для каждого элемента, от нижнего уровня до верхнего, вычислите% модификации:

• для метода или атрибута: 100%, если создано / изменено / удалено, 0% иначе
• для класса: среднее значение всех включенных элементов (метод или атрибут) или 100%, если создано / удалено
• то же самое для элементов более высокого уровня (100%, если создано / удалено, означаеткомпонентов в противном случае).

теперь вам нужно получить представление, показывающее иерархическую структуру.
вы можете (например, использовать) радиальную: проект находится в центре(то есть круг).сборки представлены в виде кольца вокруг, каждая из которых занимает одно и то же пространство.кольцо третьего уровня представляет модули, каждый модуль занимает одинаковое пространство для своей сборки (т. е. если имеется 4 сборки, каждый получает 90 °, а если сборка имеет 3 модуля, каждый модуль получает 1/3 от этих 90 °), и так далее.каждый элемент получает цвет, сопоставленный с его% модификации (0% = зеленый = без модификации,> 85% = красный = тяжелая модификация)

Пример может быть как http://www.neoformix.com/2006/BB_TopicRadialTreemapImages.png или http://www.datavisualization.ch/wp-content/uploads/2009/04/stacked_wedge_01.png

На про-стороне вы можете быстро увидеть, где произошла модификация и на каком уровне.
со стороны минус, это дает модификацию с контрольной даты, а файл, измененный один или два раза, являетсятак же, как файл, измененный 10 раз.Вам также может понадобиться добавить всплывающие подсказки, чтобы упростить навигацию, поскольку 6 уровень может быстро стать нечитаемым (но тогда вы можете отобразить только 4 из 5 более высоких уровней ...)

С уважением
Гийом

Answer 5

Хм, я бы начал с бункера, вертикальных цилиндров, для каждой ветви: у dev, release будет один или несколько здесь. Вы должны визуально поместить версии, которые были исторически зафиксированы, этот бункер в нем. Между этими версиями у вас будет любое количество других изменений, которые в конечном итоге будут возвращаться.

В каждом цикле за пределами силоса есть точки фиксации с х числом изменений. Визуализируйте, что они логически сплющены, как фрукты, свисающие вниз, с высокого уровня это будет немного запутанным беспорядком, но текстура, цвет, рисунок, размер фруктов дадут вам представление о том, что произошло. Кроме того, наведя указатель мыши на фрукт, вы получите все комментарии, которые были сделаны с коммитом.

Затем нажмите на плодоножку, и здесь вы перевернете представление на несколько стилей, но вместо того, чтобы перемещаться по иерархии к изменению, используйте изменение для навигации по иерархии. Большое пространство слева с небольшим пространством справа. Наведение указателя мыши на изменения приведет к появлению иерархии. Щелкните по изменению, и иерархия будет заморожена, а затем вы можете щелкнуть по иерархии, и вы снова перейдете в представление хранилища, но на этот раз с файлом / функцией / независимо от того, что будет показано только.

--- EDIT --- Вот набросок того, о чем я думал. Моя идея основана на использовании Mercurial в качестве репозитория исходного кода. По крайней мере, для меня было бы более интересно получить представление о изменениях, вносимых в каждую ревизию, идея, которая может не совпадать с тем, за что вы стреляли. Глядя на виды изменений, хранилище должно иметь возможность характеризовать и количественно оценивать то, что было изменено, что я считаю более важным, чем то, какие файлы были изменены. Маленькие точки - это просто код, измененный внутри самого метода или, возможно, добавление приватных методов в класс. Когда вы увеличиваете плод, он заполняет пространство, а стволы исчезают или исчезают с тусклым водяным знаком или чем-то подобным.

Надеюсь, этот грубый набросок немного лучше передает мою идею. альтернативный текст http://img704.imageshack.us/img704/9034/img0507h.jpg