Единичка, вы совсем не поняли моё предложение. И вы очень настырны в своей идее, не приводя иных доказательств кроме удобности, что является фактором субъективным.
Единичка писал(а): «Миникарта схемы»?
— Плохо звучит. Мне "аэровид" больше по душе.
Понятие "аэровид" в интернете вообще не найти. Ничего кроме загадочной программы, в который вы работали много лет назад, не использует это слово в том смысле, в котором мы с вами это обсуждаем. "Миникарта" - более распространённое название схематического изображения объекта/местности. Игнорировать факт популярности слова "миникарта" и желать называть это "аэровидом" - проявление вашей настырности, ничем не подкреплённое. Но это ладно, "роза пахнет розой, хоть розой назови её, хоть нет".
Единичка писал(а): А через аэровид будет в разы легче и быстрее... Вы пока этого не увидели. — Кликнул по иконке аэровида -- и видишь: - Красная рамка метнулась своим левым-верхним углом к этой иконке.
- На схеме соответствующая иконка автоматически выделяется, будто вы на ней кликнули (или нашли через Поиск).
Эти события произойдут в долю секунды. Практически мгновенно. - И не забываем, что аэровид -- это единственный способ внятного отображения больших силуэтов целиком. На небольших мониторах. Видеть схему целиком -- это важно для понимания.
Миникарта - не единственный способ представления силуэтов целиком. Программы Степана Митькина поддерживают масштабирование, схему можно отдалять и приближать, в том числе и отдалять настолько, чтобы смотреть целиком. Так как из текущих редакторов дракон-схем нет ни одного, который имеет миникарту, ваше утверждение не подкреплено практическими примерами. Ваш способ гипотетический, и даже концепция вольных набросков пользователя на салфетке более реализована на практике, чем аэровид.
Давайте уточним, что такое красная рамка в миникарте. Это экран вашего устройства. Рамку можно увеличивать и уменьшать для масштаба в тех же пропорциях. Теперь обсудим применение рамки в дракон-схемах, составленных по правилу Сергея Ефанова, то есть не выходящих за нижнюю границу экрана, не образующих вертикальную полосу прокрутки. Какой в таком случае будет миникарта и будет экранная лупа? Примерно такими, как я нарисую сейчас ниже: Вложение:
Минимализированный дракон-схема Миникарта.jpg [ 76.16 КБ | Просмотров: 2317 ]
Перемещение по миникарте окажется идентичным перемещению через полосу прокрутки. Этот факт уже ставит под сомнение необходимость миникарты.
Сложность навигации возрастает, если схема становится очень широкой. Может даже не столько в силу веток, сколько в силу развилок и переключателей. Какой будет миникарта?
1. Если миникарта имеет динамически расширяемый по горизонтали размер, то рано или поздно возникнет ситуация, когда она будет загораживать саму схему или другие важные элементы.
2. Если миникарта имеет фиксированную ширину, то рано или поздно возникнет ситуация, когда масштабирование и ипользование самой миникарты для удобного перемещения станет сложной операцией ввиду растущего масштаба. Тогда пользователь будет либо тыкать наугад, либо выверять как в аптеке эту рамку на разных уровнях масштабирования, чтобы достичь желаемой области.
Я предлагаю не просто избавиться от миникарты и оставить полосу прокрутки, а добавить функциональность навигации в иконы "адрес" - при щелчке на икону адрес происходит переход в область дракон-схемы. Эта область содержит икону "имя ветки", на которую ссылается "адрес" (собственно говоря, саму ветку). По принципу построения дракон схем, предлагаю подбирать область так, чтобы искомая ветвь располагалась по левому краю холста:Вложение:
сцена1.png [ 129.11 КБ | Просмотров: 2317 ]
Вложение:
сцена2.png [ 139.74 КБ | Просмотров: 2317 ]
В результате комбинации этих двух подходов пользователь может перемещаться по дракон-схеме и на уровне интуиции, памяти, скорости восприятия, перемещая горизонтальную полосу прокрутки вдоль схемы, и на уровне понимания процесса, алгоритма, выбирая ту последовательность ветвей, которая приведёт его к цели.
Единичка писал(а): Пазл-схемы -- это единственный способ целиком отобразить силуэт на экране мобильника.
Эти схемы могут работать как "графические вычислители": мгновенно находить и показывать все циклы. Например, для бизнес-схем циклы нежелательны, т.к. люди не любят, когда их кто-нибудь заставляет "ходить по кругу"; особенно, на публике. В силуэтах межветочные циклы видны плохо. Пазл-схемы это исправят.
На мобильных устройствах я ещё слабее представляю навигацию через миникарту. Навигацию по миникарте в смартфонах будет включать много нажатий, что не является признаком хорошего интерфейса. Классический свайп и масштабирование по оригинальной схеме выполняются проще хотя бы по количеству движений и скорости достижения результата.
Как пазл-схемы могут работать как графические вычислители, не понимаю. Вы до сих пор не предоставили технологию составления пазл-схем из дракон-схем. Я думаю, что как только появится чётко эта технология в виде текстового файла, я смогу найти вам пару примеров, где ваше преобразование окажется затруднительным.
Я не понимаю формулировки, что межветочные циклы плохо видно. Они вполне чёткого качества и как раз-таки создают иллюзию отсутствия цикла. Каждая ветвь, не содержащая циклов, читается сверху вниз. А веточный цикл заставляет пользователя неявно, посредством петли силуэта, выйти на обособленный участок, другую "нецикличную" колею - другую ветвь, или начать заново текущую инструкцию, а не проходить заново по хоженой ранее ветке, как это делается в обычном цикле из развилки. Именно икона "имя ветки" представляет дальнейшую последовательность действий как что-то предусмотренное, не нарушающее правила, в отличие от стрелки, которая пытается вклиниться в уже существующий шампур. Вложение:
Комментарий к файлу: Без веточного цикла
Написание сообщения на форуме.png [ 506.72 КБ | Просмотров: 2317 ]
Вложение:
Комментарий к файлу: С веточным циклом
Написание сообщения на форуме (1).png [ 763.28 КБ | Просмотров: 2317 ]
Правило Сергея Ефанова в моём педложении способствует увеличению ветвей, что в свою очередь предоставляет пользователю больше элементов для навигации. Создать ещё одну ветку и веточный цикл - несложно. В ветку можно занести группу развилок из сложного условия, варианты из переключателя (правда потребуется иерархия, классификация вариантов). Но сделать так можно, и я рад, что постепенно знакомясь с новыми правилами, идеями, ты сам стремишься к универсальности своей мысли, чтобы её поняло большинство людей. Особенно это важно в рабочих процессах.
Единичка писал(а): В программном смысле, аэровид — это вторая дракон-схема, выполненная по той же базе данных. Да, специфичная... Особеннно, динамичный красный [Свободный прямоугольник] — рамка аэровида. Но ничего сверхсложного.
Сомневаюсь, что миникарты должны храниться в базе данных. Они ведь являются переработкой существующих схем. Сверхсложностей в миникартах нет, вопрос в необходимости. Я отвергаю эту идею не потому, что она сложная, а потому, что она ненужная. Я сначала её принял, потом отверг. И всё аргументировал в этом письме. На мой взгляд, использовать миникарты с учётом других идей и возможности браузеров масштабировать экран - это переливать из пустого в порожнее.
С вашей стороны, Единичка, хотел бы попросить ответить на несколько вопросов:
1. Является ли миникарта уменьшенным представлением дракон-схемы или минимализированной дракон-схемой, как это показывал я ранее? Или на миникарте будет пазл-схема?
2. Какова технология составления пазл-схемы?
3. Каким образом пазл-схема отмечает развилки, циклы, переключатели и преобразует силуэты в примитивы?
4. Каков принцип именования элементов пазл-схем? Какие символы в них используются, что обозначает + перед и после имени блока пазл-схемы?
5. Пусть чертёжнику понадобилось изменить иконы "адрес" и "имя ветки". Как он их найдёт на миникарте и как он их найдёт на пазл-схеме?
|
Зачем переводить бумагу, чернила, время? Ведь любое изменение, внесённое в схему, делает всю эту бумажную работу напрасной...