DRAKON.SU

Зашел в песочницу. Ссылка неверная

Владимир Даниэлович, спасибо...

-

Хотелось бы иметь "аэровид" -- для навигации по схеме. Он же сгодится для косвенных внешних ссылок...

Сегодня такой инструмент есть в очень примитивном виде: Поиск икон ...

Подробней - смотрите в "песочнице".

> Подробней - смотрите в "песочнице".

В твоей "песочнице" написана какая то байда. Ты сам можешь написать что такое "аэровид"?

— "Вид с самолёта".

Лет двадцать назад этот термин я подсмотрел в CAD-программе. В правом-нижнем углу была миниатюрная копия чертежа. Если на ней "нарисовать" мышкой прямоугольник (он всегда получался геометрически-подобный текущим размерам окна CAD-программы), то его содержимое (всё, что внутри рамки) автоматически появлялось на экране. Чтобы всё влезло, масштаб чертежа сам подгонялся под эти условиия.

-

Пазл-схема позволяет преобразовать силуэт в "примитив". Она делает это автоматически; строго по определённым правилам...

В мелком масштабе она не теряет чёткости; и заставляет абстрагироваться от формы и размеров иконок. Главное внимание -- на форму самой схемы; на её "абстрактный образ".



Думаю, что эта штука тоже сгодится для управления позиционированием и масштабом экрана. Но и не только для этого....

--

Подробней опять отвечу в "песочнице". Но вряд ли сегодня.
Там нет лимитов для правок.

Вообще рациональное зерно в ваших размышлениях есть. Я могу высказать свои мысли по этому поводу, а ещё лучше нашу дискуссию вынести в отдельную тему "навигация в дракон-схемах".
Давайте для начала немного покритикую пазл-схемы, назову по-своему причины, по которым ваша идея с самого начала была непонятна.
Начнём с того, что блоки в пазл-схемах вы обозначаете латинскими буквами. Что случится, если в схеме будет около 100 икон? Наверняка появятся уникальные способы нумерации - ещё буквы, ещё цифры, ещё символы - и это проблема потому, что навигация накладывает на пользователя большую ответственность на запоминание условных обозначений. Если же эти последовательности символов отмечать на самих иконах, оригинальных графоэлементах, то это затруднит их читабельность, поставит под угрозу эргономичность всей схемы.
Второй вопрос - это принципы, по которым возле букв ставятся плюсы (+). По своему опыту конструирования дракон-схем могу сказать, что это непростая задача - найти начало и конец фрагмента схемы, в которой многократно выполнялась пересадка лианы. Могу поделиться своими черновиками о пересадке лианы, когда я создавал свой редактор схем на бакалавриате. В нём есть картинки из книги Владимира Паронджанова "Учись писать, читать и понимать алгоритмы...". И даже на этих иллюстрациях есть фрагменты, в которых нельзя однозначно сказать, где границы развилки заканчиваются.
Теперь давайте вернёмся от реализации к задаче. Задача - представить дракон-схему в компактном виде так, чтобы по ней пользователь перемещался быстро и без значительных усердий.
Моё предложение такое. Трудность чтения схем вызвана их текстовым наполнением. Во-первых, пользователь вынужден переключать восприятие образов с графического на текстовый. Во-вторых, пользователь вынужден осмысливать фрагмент и ориентироваться относительно него, что гипотетически не всегда получится в больших схемах. В-третьих, текст внутри икон увеличивает их размер по ширине и высоте, из-за чего даже пролистывание одной иконы ощущается тяжеловесным. Я считаю, что для удобства навигации именно по таким нагруженным и объёмным дракон-схемам, нужно окно навигации не с пазл-схемой, а с абстрактной дракон-схемой. Можно даже сказать, с минимализированной дракон-схемой. В этой схеме важны только некоторые типы икон из известной классификации. Подробнее я постараюсь выразить в следующем письме на этот форум

Степан Борисович, возможна ли обратная совместимость режимов редактора?

В режиме дракон-конструктора все иконки лианы получаются одинаковой ширины. А хотелось бы на финишной обработке открыть дракон-схему в "произвольном" режиме. Она – как набор линий и многоугольников – теоретически вполне пригодна для изменений при помощи штатных инструментов. Без "исчисления икон".



А пока, чтобы уменьшить ширину зеленоватой иконки выбора – пришлось звать на помощь сторонний редактор...

Я бы предложил такую технологию. Например, возьмём большой процесс заключения поставки техники, который я примерно 3 года назад рассматривал в аквапарке "Лазурный" г. Белгород. Использующиеся иконы можно представить в виде "минимализированной" дракон-схемы. Она состоит из четырёх элементов - действие (квадрат), вопрос (ромб), начало и конец обособленных смыслосодержащих фрагментов алгоритма (треугольники вершиной вверх и вниз).


Чтобы переместиться в рабочей области, необходимо выделить произвольную прямоугольную область на "минимализированной дракон-схеме". Перемещение происходит относительно центра этой области по отношению ко все схеме. То есть обычная математическая операция по переносу точки из одного пространства в другое.
Удобство навигации может обеспечить цвет. Существует рекомендация, что для читаемости схемы, иконы можны раскрашивать. "Минимализированная дракон-схема" может тоже перенять принцип заливки фигур. Вот такая идея.

Полезно иметь в виду

Правило Сергея Ефанова



Сергей Дмитриевич Ефанов работает именно так.
viewtopic.php?f=172&t=6853

Сейчас речь о новой технологии: аэровиде. С его помощью вообще никуда ничего прокручивать не обязательно: просто перетаскивай красную рамку по "аэровиду" -- и увидишь в окне редактора то, что в неё схематично поместилось.

Можно перетаскивать границы красной рамки: таким способом меняем масштаб схемы.

А можно штатными средствами почти вслепую перемещаться по схеме или менять её масштаб. Приэтом на втором мониторе увидим как рамка "сама" ползает по аэровиду, и меняет свои размеры!

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

Если дробить силуэтные ветки помельче, то привязка к нижнему краю перестанет быть заметна.

Технология аэровид отчасти похожа на экранную лупу с курсором. Как вы считаете?

> В правом-нижнем углу была миниатюрная копия чертежа. .... Чтобы всё влезло, масштаб чертежа сам подгонялся под эти условия.

По умному это называется миникарта. Для программирования она избыточна, но для бизнес процессов почему бы и нет.

Из Википедии

За центрирование икон по низу веток прошу прощения. Я использую DrakonHub, такое центрирование заложено в правилах, я не нашёл как его исправить. Сам тоже не удовлетворён такой ситуацией.
Чем дольше мы обсуждаем навигацию в крупных дракон-схемах, тем сильнее я сомневаюсь в её необходимости.
Допустим, чертёжник или инструментальная среда придерживаются правила Сергея Ефанова. Чертёжник создаёт ветку примитва, если видит, что появляется вертикальный скролл. Инструментальная среда не позволяет добавлять атомы, которые потенциально создадут вертикальный скролл.
Тогда:
1) навигация по примитиву вообще элементарна для пользователя
2) навигация по силуэту складывается из нескольких этапов. Сначала найти ветку, в которой может быть искомая икона. Потом постараться найти икону в ветке. Сначала человек задействует просмотр слева направо, а потом - и слева направа, и сверху вниз.

Чем будет мини-карта в таком случае? Такой же большой горизонтальной областью, которая воспоминаний не освежит, если веток достаточно много. Поэтому я заключил бы, что и миниатюрные дракон-схемы, и пазл-схемы, и "аэровиды" будущим редакторам схем не нужны. А вот на соблюдение правила Сергея Ефанова лучше взять ориентир. Оно кажется простым в формулировке и сложным в соблюдении, но раскрывается по мере практики. Например, схему оформления поставки вычислительной техники аквапарка "Лазурный" можно дальше развивать. Для наглядности я покажу три варианта схемы:
1) исходный (сделан сотрудниками аквапарка, опыт работы с дракон-схемами небольшой)
2) мой вариант без правила Сергея Ефанова (сделан с учётом трёхлетнего опыта конструирования)
3) мой вариант с правилом Сергея Ефанова (сделан с учётом уже шестилетнего опыта конструирования)

Если картинки плохо видно, можете скачать по ссылке https://disk.yandex.ru/d/yk0xuPzMlVVQ0g
Навигацию по третьему варианту можно упростить, опять же, с помощью изобразительных средств (заливок, шрифтов) или с помощью отдельного интерактивного списка (или ГРАФ-схемы, если привлекать вселенную Дракона до конца). В этом списке могут быть перечислены названия веток и при щелчке происходить переход на ту самую ветку, как гиперссылка.

«Миникарта схемы»?

— Плохо звучит. Мне "аэровид" больше по душе.

Ну, это если привычными способами.

А через аэровид будет в разы легче и быстрее... Вы пока этого не увидели.
— Кликнул по иконке аэровида -- и видишь:

1. Красная рамка метнулась своим левым-верхним углом к этой иконке.
2. На схеме соответствующая иконка автоматически выделяется, будто вы на ней кликнули (или нашли через Поиск).

Эти события произойдут в долю секунды. Практически мгновенно.

-

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

Ну, здрасте!

В программном смысле, аэровид — это вторая дракон-схема, выполненная по той же базе данных. Да, специфичная... Особеннно, динамичный красный [Свободный прямоугольник] — рамка аэровида. Но ничего сверхсложного.

Зачем переводить бумагу, чернила, время? Ведь любое изменение, внесённое в схему, делает всю эту бумажную работу напрасной...

▒ Аэровид практически во всех случаях снимет потребность распечатывать схему. Выбираем для него отдельный монитор, побольше. А на втором мониторе — сама дракон-схема. Такой подход снимает все ограничения на размеры дракон-схем.

Только программу-помощницу подобрать для быстрого переключения мышки — с одного монитора на другой. UltraMon, например (для Windows).

Единичка, вы совсем не поняли моё предложение. И вы очень настырны в своей идее, не приводя иных доказательств кроме удобности, что является фактором субъективным.

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


Миникарта - не единственный способ представления силуэтов целиком. Программы Степана Митькина поддерживают масштабирование, схему можно отдалять и приближать, в том числе и отдалять настолько, чтобы смотреть целиком. Так как из текущих редакторов дракон-схем нет ни одного, который имеет миникарту, ваше утверждение не подкреплено практическими примерами. Ваш способ гипотетический, и даже концепция вольных набросков пользователя на салфетке более реализована на практике, чем аэровид.
Давайте уточним, что такое красная рамка в миникарте. Это экран вашего устройства. Рамку можно увеличивать и уменьшать для масштаба в тех же пропорциях. Теперь обсудим применение рамки в дракон-схемах, составленных по правилу Сергея Ефанова, то есть не выходящих за нижнюю границу экрана, не образующих вертикальную полосу прокрутки. Какой в таком случае будет миникарта и будет экранная лупа? Примерно такими, как я нарисую сейчас ниже:
Перемещение по миникарте окажется идентичным перемещению через полосу прокрутки. Этот факт уже ставит под сомнение необходимость миникарты.
Сложность навигации возрастает, если схема становится очень широкой. Может даже не столько в силу веток, сколько в силу развилок и переключателей. Какой будет миникарта?
1. Если миникарта имеет динамически расширяемый по горизонтали размер, то рано или поздно возникнет ситуация, когда она будет загораживать саму схему или другие важные элементы.
2. Если миникарта имеет фиксированную ширину, то рано или поздно возникнет ситуация, когда масштабирование и ипользование самой миникарты для удобного перемещения станет сложной операцией ввиду растущего масштаба. Тогда пользователь будет либо тыкать наугад, либо выверять как в аптеке эту рамку на разных уровнях масштабирования, чтобы достичь желаемой области.
Я предлагаю не просто избавиться от миникарты и оставить полосу прокрутки, а добавить функциональность навигации в иконы "адрес" - при щелчке на икону адрес происходит переход в область дракон-схемы. Эта область содержит икону "имя ветки", на которую ссылается "адрес" (собственно говоря, саму ветку). По принципу построения дракон схем, предлагаю подбирать область так, чтобы искомая ветвь располагалась по левому краю холста:

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


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


Сомневаюсь, что миникарты должны храниться в базе данных. Они ведь являются переработкой существующих схем. Сверхсложностей в миникартах нет, вопрос в необходимости. Я отвергаю эту идею не потому, что она сложная, а потому, что она ненужная. Я сначала её принял, потом отверг. И всё аргументировал в этом письме. На мой взгляд, использовать миникарты с учётом других идей и возможности браузеров масштабировать экран - это переливать из пустого в порожнее.

С вашей стороны, Единичка, хотел бы попросить ответить на несколько вопросов:
1. Является ли миникарта уменьшенным представлением дракон-схемы или минимализированной дракон-схемой, как это показывал я ранее? Или на миникарте будет пазл-схема?
2. Какова технология составления пазл-схемы?
3. Каким образом пазл-схема отмечает развилки, циклы, переключатели и преобразует силуэты в примитивы?
4. Каков принцип именования элементов пазл-схем? Какие символы в них используются, что обозначает + перед и после имени блока пазл-схемы?
5. Пусть чертёжнику понадобилось изменить иконы "адрес" и "имя ветки". Как он их найдёт на миникарте и как он их найдёт на пазл-схеме?

Алексей, вы не ошиблись? Дайте ссылку на DrakonHub