Обсуждение

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

Я думаю, что в ACM можно выиграть от визуализации набора возможных следующих шагов. Например, есть баг-трекер. В документации к нему есть граф состояний. С полным списком возможных переходов. Состояний штук 10. И не из любого в любой можно перейти. Как ни странно, регулярно находятся сотрудники, путающиеся в них. По-моему, было бы неплохо иметь графическое представление того, в какое состояние может быть переведен баг их состояния "Open" (т.е. что-то вроде "налево пойдешь — коня потеряешь и т.д.). Но это, конечно, возможно только тогда, когда есть граф, отражающий все наборы состояний, а также возможные варианты переходов между ними.

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

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

Недостаток малой визуализации (IMHO) состоит в отображении излишней информации для принятия решения. Если нужно узнать, в какие состояния можно перейти из одного конкретного, то сначала происходит выбор этого одного (при этом не важны никакие связи, а значит список вариантов - лучшее решение), а потом отображается список состояний, возможных для перехода. И в этом случае список лучше, поскольку точно отвечает на наш запрос (мы ведь про связи не спрашивали). Самый ходовой пример: autocompletion в различных IDE. Если же у нас малая визуализация в виде, например, графа с десятью вершинами, то на первом этапе человек излишне нагружается необходимостью отфильтровать связи, а после определения начальной вершины сам вынужден составлять у себя в сознании список допустимых для перехода состояний.

По поводу моего примера. 10 — общее число состояний. Граф доступен в документации по системе. При этом из каждой вершины можно перейти максимум в 4, а в основном в 2-3. Именно вот эти 2-3-4 мне и представляется удобным визуализировать непосредственно в среде ACMS.

Какую дополнительную информацию Вы предполагаете отображать в "малой визуализации" этих 4 вершин по сравнению с обычным списком? И зачем?

Например так: В моем случае разные вершины относятся к разным подразделениям. Т.е., например, есть состояния, в которых баг должен быть назначен на тестировщика, а есть другие — в которых на разработчика. Я бы предпочел развести эти 2-3-4 вершины по соответствующим "функциям", выделив "функции", например, цветом фона. При этом было бы неплохо иметь подсказку, всплывающую при наведении курсора на статус, с разъяснением смысла перехода в данное состояние в 1-2 предложениях.

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

Не понимаю, почему вопросы UX должны обсуждаться отдельно от вопросов визуализации (что такое визуализация если не UX?). В любом случае, считаю целесообразным свернуть дискуссию здесь, у ailev'а.

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

Не исключаю, что не "в тему", потому как не знаю здесь ли ее начало: Речь идет о "визуализации" вообще или о конкретной графической нотации? "Выпадающее" - это уже прием визуализации. Или я не прав? Список может содержать не только слова, но и/или пиктограммки. Это как бы тоже визуализация. Что здесь "в малом", а что "в большом"? Пиктограммки могут быть путем преодоления языковых проблем для больших систем...

Вообще-то, представление информации и в "текстовом виде", и "графическом" - есть примерами "визуализации", приемы разные... ИМХО

"В моем случае разные вершины относятся к разным подразделениям." ИМХО: Мы имеем систему у которой несколько стейкхолдеров, потребности которых надо удовлетворить. Как их удовлетворить эффективно - это вопрос КОНКРЕТНОГО контекста: В одном случае можно немного напрячь стейкхолдеров, в другом "создателей системы"...

Безусловно. Однако же приведенные ailev'ом цитаты говорят о том (упрощенно), что визуалиция плоха. Мне интересна критика того, почему именно плоха. И любая ли. Приведенный мной пример — не более чем пример. Его, на мой взгляд, осмысленно обсуждать только в том случае, если таковое обсуждение приводит к формулированию каких-либо общих утверждений о пользе/вреде визуализации в контексте ACM.

"цитаты говорят о том (упрощенно), что визуалиция плоха" - важен контекст - важно понимание о чем речь, потому как одно из определений "визуализации" может звучать, как представление (артефакт) информации в форме, которая может быть воспринята человеком по зрительному каналу. я так понимаю, что пытаются дискутировать о "графика" vs "текста", но это только мое предположение... Почему-то вспомнилась "Брильянтовая рука" с ее: "МЭ" "ЖО" ;)

Кстати, еще одна хорошая цитата из того же обсуждения: "You can't visualize something that is unknown. One can visualize what has happened but not what will happen if you do not know what it is." (Max Pucher)