Pull to refresh

Comments 24

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

Хоткеи копирования/вырезания/вставки более однозначны.

Работа только через хоткеи сразу отсекают людей которые с планшета/смартфона.

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

Можно через меню открыть

У большей части приложений (как минимум на маке) уже реализовано перетаскивание. Как по мне это удобно, особенно когда можно из папки в dock перетащить файл в приложение, что быстрее, чем открывать отдельное окно finder, искать файл, копировать, а потом это же окно закрывать

Для меня неудобно именно тащить, целиться с нажатой кнопкой. Особенно на тачпаде...

Hidden text

Здравствуйте, очень понравилась ваша идея, в будущем можно добавить команды. Как вы считаете, чем ваше приложение будет привлекать больше, чем Miro, почему вы выбрали именно эту нишу, если есть уже монополисты?

Спасибо за поддержку.

> можно добавить команды
Какие команды?

Miro молодцы, красиво сделали. Но можно лучше.
Нишу не выбирал. Ради интереса сделал прототип, знакомым понравилось.
Затянуло, интерес не пропал.

Редактор развивается

А, есть ли какая то предполагаемая дорожная карта?

P.S. Есть программы как FlProg, Hiasm, Алгоритм Билдер где с помощью визуального представления схемы связей между узлами/компонентами и управлению свойствами этих "модулей" может быть сгенерирован исполняемый код.
Возможно ли будет в будущем использовать такой подход и с Вашим инструментарием?

>дорожная карта?
Ближайшая задача - совместная работа

>может быть сгенерирован исполняемый код.
Прям исходный код генерировать не планировал.
Была идея приделать к bpm движку. Пока отложил эту идею.
https://vimeo.com/632994077

По опыту работы с BPMN.io:

  1. При выборе контрола хорошо-бы контекстное меню доступных компонент (у вас их не много)

  2. Хранение и перенос диаграм лучше в открытом формате, например хмл или json.

Пример:

Hidden text

Спасибо за советы.

>Хранение и перенос диаграм лучше в открытом формате, например хмл или json.
json и меньше весить будет чем картинка. Но пока решил оставить только картинку. Кому кроме dgrm.net нужны json-ы его формата?

Ещё было бы здорово сохранять не только в пнг, но и например в svg

Хочу лучше понять конечную цель выгрузки схемы в svg. Что потом с этими svg будете делать, почему png не подходит?

Обычно делают два вида выгрузки - save и export. Save во внутреннем формате для последующей работы и обмена, export для вставки в другие документы. SVG векторный формат и скейлится в современных онлайн-презентациях на пол-стены (могу показать кейсы), PNG когда SVG невозможен.

У меня был кейс, когда диаграмму надо было в ворде держать для последующей распечатки. Но потом выяснилось, что печатать надо в разных форматах (А5, А4, А3 и т.п.). Пересохранил в SVG и вопрос был закрыт.
Когда было в PNG печаталось, мягко говоря, не очень. А так отдал и пусть ресайзят как хотят.

Единственная проблема, не все SVG одинаково полезны. Были с этим заморочки при сохранении из Word в PDF. Не знаю почему, но иногда SVG растеризовался в PNG, со всеми вытекающими. Пришлось перебрать разные варианты настроек экспорта и перегонять из одного приложения диаграмм в другое.

Может человек хочет json сгенерировать по каким-нибудь данным, и визуализировать?
Ну и диффать/мерджить текст обычно попроще — если, например, хочется диаграммы в репозитории хранить.

Интересно, не думал в таком ключе

Drawio сделали внутреннее представление объектов и связей в XML и сдк для манипуляции ими. Это позволяет делать генераторы, анализаторы и всякие конвертеры.

Настройки отображаются рядом с фигурой. Не нужно прыгать взглядом между панелью настроек и фигурой.

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

Думаю боковая панель нужна когда много настроек.

Если нужно изменить свойство сразу у нескольких фигур: Выделить несколько фигур. Кликнуть на любой из выделенных фигур -> настройки открываются рядом с местом клика.

Сейчас в dgrm так и сделал. См рисунок «Операции с группой фигур. 4 кнопки.».

Если нужно изменить свойство сразу у нескольких фигур: Выделить несколько фигур. Кликнуть на любой из выделенных фигур -> настройки открываются рядом с местом клика.

Там не настройки, а управление (удалить, копировать вставить). Если вы добавите настройки (цвет, стиль), то будет новая проблема - сброс выделения при miss-click.

Кстати, а почему для создания элементов у вас боковая панель, а не настройки рядом с фигурой? Почему бы не сделать при клике на connection end-point показ элементов, которые можно создать дальше по цепочке?

Создание "по цепочке"
Создание "по цепочке"



Предложения и наблюдения:
1. Ctrl+Click не добавляет в текущий список выделений
2. Между двумя end-point можно сделать сколько угодно одинаковых соединений. Может проверять на наличие и не создавать?
3. Список объектов очень нужен. Если я случайно создал кучу элементов друг на друге (те же стрелки между двумя точками), то во-первых - это тяжело увидеть, во-вторых - тяжело исправить, а со списком это делается быстрее. Но не обязательно его показывать всегда.

Спасибо! Записал в to-do.

1. Ctrl+Click не добавляет в текущий список выделений

Это первым пунктом

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

Sign up to leave a comment.

Articles