DRAKON.SU

Тогда вид нужен другой. Не к одной "иконе", а к блоку в общем случае.
В результате вырождается в развилку

Я считаю, что Вы лидер. Вам и карты в руки.
Я не обладаю полнотой знаний.

Я знаю реальное время, как оно используется в ракетной технике.
В вашем случае мой опыт недостаточен.

Ардуино — новая для меня область. Точно так же у меня нет знаний о промышленных контроллерах. Очень хорошо, что в обсуждении участвует такой опытный специалист, как Алексей Донской.

Общие обсуждения полезны, но гораздо лучше перейти от слов к картинкам и скриншотам. Когда появятся реальные картинки и скриншоты, будет больше отзывов. И больше критики со стороны сообщества. Будет больше оснований для принятия решений. Будет больше толковых предложений.
Мой голос не может быть решающим в вашем проекте.

Выношу на суд специалистов мои вычисления "столбиком", основанные на едином способе использования данных с указанием их типа и механизма выражений. Для сравнения вытащил из книги картинку "Рамочное логическое выражение" (цитату приводить не стану )

Всеобщим домашним обсуждением, включая жену вариант вложения икон друг в друга - забракован, требуются идеи ..
-"Папа! Это какой-то бочонок с крышкой, а не выражение!"

Присоединяюсь к мнению сына: это бочонок с крышкой, а не выражение.
В книге Учись надо смотреть рис.128 и 129.

Почему вы их забраковали?

Не забраковал вовсе. Просто хочу формализовать применение данных в алгоритмах ДРАКОН для превращения алгоритма в рабочую программу.

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

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

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

Связывать иконы данных лианами как иконы-действия и искать для них свой "шампур-метод" - тоже уже пробовал и убедился в аналогичном результате. Сейчас данные из ФЛОКС, как понимаю записываются текстом, в т.ч. и на полках в формате имен ФЛОКС. Вот, хочется уйти от текста в этой части, хотя бы в какой-то степени или повысить визуальную информативность идентификатора. Сам по себе текстовый "идентификатор" - не визуален, в том смысле что "не говорит ни о чем": ни о типе/классе данных, ни о времени его жизни ни о видимости.

Пока остается: введение икон-данных, их типизация боковинами и указание класса ("классификация") изображениями. Да, вроде как нашелся полезный вид отрисовки параметров в вызовах (икона "Вставка"). Даже 2шт.

Пожалуйста, никаких сишных и вообще программерских операций (!!, != и т.п.).
Это визуальный инструмент, и надо отображать привычные математические символы (впрочем, полного единообразия нет и там ).

Ну и да, вложенные конструкции - бяка. Визуальный мусор. Агрегацию и прочее такое лучше показывать отступами, чем рамками.
В конце концов, блин, почему всем так сдались рамки?! Используйте просто цвет (тон), в том числе, возможно, с градиентом в точки фокуса - но только не чёткие рамки! Они отвлекают и резко усложняют процесс восприятия.

Владимир, будет время, гляньте для общего развития, что Эрик пишет.
Это так, между прочим

http://blog.interfacevision.com/design/ ... snapshots/

Спасибо, обязательно поизучаю детальней. При беглом осмотре показалось, что это некая сборка примеров на разных визуальных языках .. ну и по сути "всё тоже самое": цветные квадратики, стыки, линии куда попало и охваты одних объектов другими. Бегло ничего не заметил выходящего из уже известного ряда.
Так стыкующиеся квадратики разными способами, я впервые увидел в Ардублоке и теперь уже знаю, что пришли они туда из "scratch mit.edu", впрочем как и охват блоков операциями выражений и уже претендует на некий "стандарт де факто". Разница только в дизайне. Ну .. вот тут я - не дизайнер ни разу.
Видимо стоит оставить "как есть" ардублоковский подход в данным в виде "стыкующихся типизированных и раскрашенных икон" и изменять только управляющие языковые конструкции под ДРАКОН - раздельное рисование с соединительными лианами и ограничивающими правилами.

По поводу картинки viewtopic.php?p=99281#p99281

1. Внизу два фото моторов сделаны хорошо и крупно. Они вписаны в размер иконы ДРАКОНа.

2. Вверху два фото датчиков сделаны плохо и мелко. Вокруг них одна или даже две ненужные рамки.

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

Владимир, как вы считаете?

Можно, но там исходные картинки плохие, это мало что даст для конкретно этих картинок. Надо искать лучше или сфотографировать датчики. Убрать рамки - тоже надо, и вообще отказаться от такого вложенного оформления, оставив только стыковку. Или вернуться на дизайн scratch - закрашивать вложения разными цветами и сделать их прямоугольными с выделенными стыковочными узлами. Но боюсь что такое смешение стилей ДРАКОН и scratch окажется жуткой эклектикой.
Буду пробовать.

Отрисовать блок второго датчика силов уже не хватило .. пошел спать. Тут согласно цветовой раскраске типов данных из Ардублока. Поскольку он оказался сильно похож на Scratch mit.edu, то оставил эту цветовую палитру. Для сравнения оставил блок таймера и моторов "как было".

Вверху фото датчика сделано плохо и мелко. Вокруг него две ненужные рамки.

Я говорю только про фото (а не про текст). Желательно убрать ненужные рамки вокруг фото. Это позволит увеличить размер фото. И сделать хорошо — точно так же как внизу фото моторов.

Владимир, куда вы пропали?
Общественность обеспокоена.

Какие поживает ваш замечательный проект?
Какие новости?
Как успехи?

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

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

Неудовлетворенность своей работой и самокритичность — хорошее (позитивное) качество личности. Однако оно не должно быть чрезмерным и выходить за разумные рамки (зашкаливать). Тем более оно не должно мешать работе.

В дополнение к Эрику вот еще одна визуальная коллекция
https://www.revolvy.com/main/index.php? ... type=topic

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

Подниму тему..

Совсем недавно, неделю назад, разрабатывая очередную тележку по линии, с ПИД-регулятором, натолкнулись на слабое визуальное представление относительно сложных вычислений в скретчах Ардублока... результат сильно похож на те "бочноки" по сложности воспритяия, что рисовал в той теме.

Это в общем-то простое выражение, но уже и оно не влезает полноценно в широкий экран.

Ну вот, понемногу вернулся к вопросу.

Разобрал таки ардублок на незнакомой мне Java и понял что "править" там практически нечего. Все рисовалки и переводилки (транслятор) зашиты глубоко в хардкод, а то что позволяется "настраивать" в части кодогенерации также требует расширения классами на JAVA. Увы, переделать это поделку под стиль ДРАКОН - это примерно тоже самое что написать всю использованную в нем рисовалку (openblocks mit edu) заново.

В идеях оформления использования данных в ДРАКОН, пока ничего нового нет, но то что есть мне УЖЕ кажется вполне приемлемым, особенно после такой активной работы с Ардублоком и стилем оформления от mit edu .. точно также на хотя бы сколько-то сложных местах полностью теряется вся наглядность отображения и полезность "красот" в виде цветов, вдавленного или выдавленного оформления границ блоков.

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

Ну, кстати, похвастаюсь: мы заняли третье место в общероссийском финале фестиваля Робофест-2017 в категории Hello Robot, Arduino направлении "шорт-трек, младшая группа 9-11 лет" и первое место в квалификациях с временем прохождения трассы 8.72сек, при ближайшем втором месте в 10.66сек. Детальное описание всех наших приключений есть тут: http://arduino.ru/forum/proekty/lego-ki ... 560?page=3 , начиная с поста №154 - собственно соревновательные приключения и с поста №124 - гонка по переделке робота из-за запрета использования деталей от Лего по изменению в регламенте соревнования.

Выражаю огромную благодарность Паронджанову Владимиру Даниэловичу за его книги по ДРАКОН. Без них дитенка вряд ли бы смог разобраться в моих подсказках и наваять такую навороченную программу самостоятельно.

В этой теме обсуждался вопрос: как отобразить данные на языке ДРАКОН применительно к проекту "Язык ДРАКОН и Ардуино".

Увы, в данной теме решения не было найдено.

К счастью, Андрей Дышлевый успешно решил данную проблему с помощью программы "ИС Дракон" Геннадия Тышова.
Более того, он наглядно показал решение на видео в YouTube
см. тему viewtopic.php?f=233&t=6833