Здравствуйте, Ikemefula, Вы писали:

I>Минимальный набор хоткеев и мышиных жестов не запомнил, ниасилил, забил.

Вотименно.

I>Для начала надо научиться думать. А как научишься думать, нужно просто показать ,как правильно записывать свои мысли. А в программухе все наоборот — сначала записывать, а думать всё время некогда. Вот потому Синклер называет программистов скайпа мутантами — код научились писать, а научиться думать не было времени — боролись с синтаксисом.

Это утверждение нуждается в доказательстве.

Здравствуйте, Ikemefula, Вы писали:

I>>>Думаешь, это 2003 студия, которой у меня нет, заставляет софтины требовать именно эти фремворки ?
НС>>Какая софтина у тебя именно требует 1.0?
I>Без понятия

Почему ты тогда решил что фреймворк вообще кому то нужен?

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Минимальный набор хоткеев и мышиных жестов не запомнил, ниасилил, забил.

НС>Вотименно.

Берешь простое действие мышо — нажатие кнопки перетаскивание отжатие.
Если ты работаешь с текстом, то обычно это селекшн.
А если нет текста, от это драг.
Вопрос — как сделать и драг и селекшн если есть текст ? Нужен модификатор.

Далее, есть возможность тащить всю конструкцию, а есть только заголовок. Опаньки, еще один модификатор.

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

А без текста все просто, как в десктопе вындоуса — взял да потащил.


I>>Для начала надо научиться думать. А как научишься думать, нужно просто показать ,как правильно записывать свои мысли. А в программухе все наоборот — сначала записывать, а думать всё время некогда. Вот потому Синклер называет программистов скайпа мутантами — код научились писать, а научиться думать не было времени — боролись с синтаксисом.

НС>Это утверждение нуждается в доказательстве.

Открой сайп и смотри эти доказательства.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>>>Думаешь, это 2003 студия, которой у меня нет, заставляет софтины требовать именно эти фремворки ?
НС>>>Какая софтина у тебя именно требует 1.0?
I>>Без понятия

НС>Почему ты тогда решил что фреймворк вообще кому то нужен?

Думаешь фремворк сам себя поставил ? Интересная мысль.

Здравствуйте, Ikemefula, Вы писали:

I>Берешь простое действие мышо — нажатие кнопки перетаскивание отжатие.
I>Если ты работаешь с текстом, то обычно это селекшн.
I>А если нет текста, от это драг.
I>Вопрос — как сделать и драг и селекшн если есть текст ?

Режимы переключать — кому надо, будет мышой или пальцем возить, кому не надо — будет иметь возможность использовать нормальный редактор.

I>Далее, есть возможность тащить всю конструкцию, а есть только заголовок. Опаньки, еще один модификатор.
I>И вот после небольшого количества кейсов сложность простых мышиных операций требует целый талмуд документации.

Вотименно.

I>А без текста все просто, как в десктопе вындоуса — взял да потащил.

Просто там только языком.

НС>>Это утверждение нуждается в доказательстве.
I>Открой сайп и смотри эти доказательства.

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

Здравствуйте, Ikemefula, Вы писали:

НС>>Почему ты тогда решил что фреймворк вообще кому то нужен?
I>Думаешь фремворк сам себя поставил ? Интересная мысль.

Его мог поставить какой нибудь древний софт, который ты давно уже снес.

Здравствуйте, Ikemefula, Вы писали:

I>А если нет текста, от это драг.
I>Вопрос — как сделать и драг и селекшн если есть текст ? Нужен модификатор.
Хорошим тоном считается "мышь по невыделенному тексту — выделение", "мышь по выделенному — перетаскивание", вот только реализовано оно далеко не везде (например, в Опере есть с незапамятных времён). Модификаторы нужны только для действий, смысл которых нельзя восстановить из контекста.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Почему ты тогда решил что фреймворк вообще кому то нужен?
I>>Думаешь фремворк сам себя поставил ? Интересная мысль.

НС>Его мог поставить какой нибудь древний софт, который ты давно уже снес.

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

Здравствуйте, Sinix, Вы писали:

I>>А если нет текста, от это драг.
I>>Вопрос — как сделать и драг и селекшн если есть текст ? Нужен модификатор.
S>Хорошим тоном считается "мышь по невыделенному тексту — выделение", "мышь по выделенному — перетаскивание", вот только реализовано оно далеко не везде (например, в Опере есть с незапамятных времён). Модификаторы нужны только для действий, смысл которых нельзя восстановить из контекста.

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

Итого, как редактор отличит перетаскивание кусочка текста от перемещения стейтмента ?

в одном случае перетаскивание это работа с языком — выделяем и тащим a = getValue(x); и дейтсвие должно быть следующим — на новом месте привязаться к новой переменной а или создать такую переменную
В другом случае это работа с текстом программы — выделяем и тащим ту же строку, но помогать не надо

Итого — покажи как это возможно без модификаторов. Как только закончишь — я могу назвать еще пару сотен кейсов, где нужно будет сделать тоже самое.

Здравствуйте, Ikemefula, Вы писали:

S>>Хорошим тоном считается "мышь по невыделенному тексту — выделение", "мышь по выделенному — перетаскивание", вот только реализовано оно далеко не везде (например, в Опере есть с незапамятных времён). Модификаторы нужны только для действий, смысл которых нельзя восстановить из контекста.
I>В обсуждаемом редакторе все действия такие, что смысл нельзя восстановить из контекста.

С чего бы это? Особенно если учесть что основная фишка IDE от Лаптева и ко (мы ведь про неё сейчас?) — в хранении распарсенного AST вместо "голого" текста.
Вопрос два: почему такой подход должен мешать произвольным правкам? В рослине используется именно что унифицированное AST, и почему-то ничего от этого не ломается

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

I>в одном случае перетаскивание это работа с языком — выделяем и тащим a = getValue(x); и дейтсвие должно быть следующим — на новом месте привязаться к новой переменной а или создать такую переменную
I>В другом случае это работа с текстом программы — выделяем и тащим ту же строку, но помогать не надо

Это "программерское" решение. Любой спец по UI-дизайну с ходу скажет, что правильное* решение:
1. По перетаскиванию нужно просто показать smart-tag с доступными вариантами действия.
2. По умолчанию применить последний выбранный вариант (возможно, подбирать разные действия для разных ошибок в готовом AST), при выборе другого действия в смарттеге — поменять на выбранное.
3. Позволять переопределять поведение нажатием модификаторов при перетаскивании.
4. Поведение не должно отличаться от способа перемещения текста: копипаста, мышь или сенсорный ввод** — неважно.

* правильное для среднестатистической целевой аудитории. Для подростков или хардкорных линуксоидов ключевые сценарии будут различаться.
** сенсорный ввод, как ни странно нужен и в "профессиональных" программах, не забываем про людей со всякими disabilites. Тем более что добавление в семёрке и выше стоит копейки.

Здравствуйте, Sinix, Вы писали:

S>>>Хорошим тоном считается "мышь по невыделенному тексту — выделение", "мышь по выделенному — перетаскивание", вот только реализовано оно далеко не везде (например, в Опере есть с незапамятных времён). Модификаторы нужны только для действий, смысл которых нельзя восстановить из контекста.
I>>В обсуждаемом редакторе все действия такие, что смысл нельзя восстановить из контекста.

S>С чего бы это? Особенно если учесть что основная фишка IDE от Лаптева и ко (мы ведь про неё сейчас?) — в хранении распарсенного AST вместо "голого" текста.

Я привел пример.

S>Вопрос два: почему такой подход должен мешать произвольным правкам? В рослине используется именно что унифицированное AST, и почему-то ничего от этого не ломается

Потому что действий мышом всего три штуки — mouse move, mouse down, mouse up. Отсюда понятно, что очень сложно комбинировать и таким образом, что бы полушать широкий спектр возможностей.

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

I>>Итого, как редактор отличит перетаскивание кусочка текста от перемещения стейтмента ?
S>Элементарно. Можно просто парсить текст повторно, после перетаскивания, можно заморочиться с сопоставлением диапазона выделения и выбранных узлов AST.

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

I>>в одном случае перетаскивание это работа с языком — выделяем и тащим a = getValue(x); и дейтсвие должно быть следующим — на новом месте привязаться к новой переменной а или создать такую переменную
I>>В другом случае это работа с текстом программы — выделяем и тащим ту же строку, но помогать не надо

S>1. По перетаскиванию нужно просто показать smart-tag с доступными вариантами действия.

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

S>2. По умолчанию применить последний выбранный вариант (возможно, подбирать разные действия для разных ошибок в готовом AST), при выборе другого действия в смарттеге — поменять на выбранное.

то есть, тебе не хватает даже тегов и ты хочешь ввести режим редактирования, опаньки !

S>3. Позволять переопределять поведение нажатием модификаторов при перетаскивании.

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

S>4. Поведение не должно отличаться от способа перемещения текста: копипаста, мышь или сенсорный ввод** — неважно.

поведение чего ?

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

Здравствуйте, Ikemefula, Вы писали:

S>>С чего бы это? Особенно если учесть что основная фишка IDE от Лаптева и ко (мы ведь про неё сейчас?) — в хранении распарсенного AST вместо "голого" текста.
I>Я привел пример.
Я на него ответил выше — необходимо учитывать контекст (есть/нет выделения).

S>>Вопрос два: почему такой подход должен мешать произвольным правкам? В рослине используется именно что унифицированное AST, и почему-то ничего от этого не ломается
I>Потому что действий мышом всего три штуки — mouse move, mouse down, mouse up. Отсюда понятно, что очень сложно комбинировать и таким образом, что бы полушать широкий спектр возможностей.
Снова та же ошибка. Нельзя забывать про контекст.

I>>>Итого, как редактор отличит перетаскивание кусочка текста от перемещения стейтмента ?
S>>Элементарно. Можно просто парсить текст повторно, после перетаскивания, можно заморочиться с сопоставлением диапазона выделения и выбранных узлов AST.
I>для простоты условимся, что все координаты всех элементов и операций во всех случаях идентичные. Понятно, что это означает ?
Нет. Серьёзно, чем это принципиально отличается от любого другого действия?

S>>1. По перетаскиванию нужно просто показать smart-tag с доступными вариантами действия.
I>первый твой вариант был "модификаторы не нужны", а сейчас оказывается, что не только не хватает модификаторов, но надо еще намеренния пользователя спрашивать.
I>то есть, тебе не хватает даже тегов и ты хочешь ввести режим редактирования, опаньки !
I>нужны модификаторы уже при кликах, а не только при перетаскивании.

Серьёзно, такое впечатление, что ты не имеешь представления, как делаются подобные штуки и теоретизируешь на пустом месте
Ок, давай на пальцах:

1. По умолчанию после перетаскивания выполняем самое популярное действие. Для простоты и чтобы не уходить в сторону — последнее выбранное.
2. Для частных случаев показываем тег с возможностью выбрать другие (реже используемые) варианты. Это _не_ режим редактирования, для работы тега достаточно откатить предыдущую и накатить выбранную команду. Если разработчики связались с перетаскиванием и рефакторингом без рабочего undo-redo, значит они полные ССЗБ и тему можно закрыть уже на этом пункте.
3. Для совсем частных случаев, когда алгоритм не справляется с определением правильного действия по умолчанию, добавляем возможность подсказать нужное действие, зажав модификатор при перетаскивании. П.3 не отменяет предыдущих, так что я не вижу с чего "нужны модификаторы уже при кликах, а не только при перетаскивании".

Получаем классический opt-in, обжёванный и перепробованный от и до. Другие варианты заметно хуже, т.к. приводят или к разрушающему поведению, или к потере контекста.

I>поведение чего ?
Раньше на рсдн-е не теряли контекста в рамках одного поста
Речь по-прежнему о сценарии драг-дропа, начиная с выделения и заканчивая рефакторингом после перетаскивания.

I>В сумме ты уже описал примерно половину причин, из за которых я забил на мега-редакторы. Осталось еще немного — привести минимальный набор режимов, модификаторов и хоткеев.
Скорее, ты ими не пользовался, или ограничился режимом "неподготовленного пользователя". VS, офис, опера, notepad++ — в любом инструменте для работы с текстом на подобные грабли уже наступали, и, если в команде был специалист по проектированию UI, давно разрешили.

Здравствуйте, Sinix, Вы писали:

S>>>С чего бы это? Особенно если учесть что основная фишка IDE от Лаптева и ко (мы ведь про неё сейчас?) — в хранении распарсенного AST вместо "голого" текста.
I>>Я привел пример.
S>Я на него ответил выше — необходимо учитывать контекст (есть/нет выделения).

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

I>>Потому что действий мышом всего три штуки — mouse move, mouse down, mouse up. Отсюда понятно, что очень сложно комбинировать и таким образом, что бы полушать широкий спектр возможностей.
S>Снова та же ошибка. Нельзя забывать про контекст.

Отличаются только намерения пользователя, контексты идентичные.

I>>для простоты условимся, что все координаты всех элементов и операций во всех случаях идентичные. Понятно, что это означает ?
S>Нет. Серьёзно, чем это принципиально отличается от любого другого действия?

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

I>>то есть, тебе не хватает даже тегов и ты хочешь ввести режим редактирования, опаньки !
I>>нужны модификаторы уже при кликах, а не только при перетаскивании.

S>Серьёзно, такое впечатление, что ты не имеешь представления, как делаются подобные штуки и теоретизируешь на пустом месте

Ога, ты хочешь сказать, что знаешь больше и лучше, но почему то не можешь понять, что разница только в намерениях пользователя.

S>Ок, давай на пальцах:

S>1. По умолчанию после перетаскивания выполняем самое популярное действие. Для простоты и чтобы не уходить в сторону — последнее выбранное.

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

S>2. Для частных случаев показываем тег с возможностью выбрать другие (реже используемые) варианты. Это _не_ режим редактирования,

То есть, уже есть усложнение, ибо если отказаться от текста, то это не нужно.

S>3. Для совсем частных случаев, когда алгоритм не справляется с определением правильного действия по умолчанию, добавляем возможность подсказать нужное действие, зажав модификатор при перетаскивании. П.3 не отменяет предыдущих, так что я не вижу с чего "нужны модификаторы уже при кликах, а не только при перетаскивании".

Опаньки — снова усложнение. Модификатор обычно нужен для выделения и вещей навроде. А тебе надо будет подсказывать с помощью модификатора, что же ты хочешь — перетащить текс или перетащить стейтмент.
Если перетаскиваем тест, то все просто. А если стейтмент, то он по окончании должен встроиться в код самостоятельно, по аналогии с автоматическим рефакторингом. Рефакторинг например не спрашивает у тебя, как преобразовывать локальные переменные в каждом из 100 случаев который он нашел.
А текстом это не нужно.

S>Получаем классический opt-in, обжёванный и перепробованный от и до. Другие варианты заметно хуже, т.к. приводят или к разрушающему поведению, или к потере контекста.

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

Итого — если отказаться от текста, то можно спокойно делать примерно так
1. клик — селектим стейтмент, предыдущую селекцию теряем
2. драг — перетаскиваем активный стейтмент
3. модификатор ctrl при драге — копирует стейтмент
4. модификатор ctrl при клике — добавляем стейтмент в селекшн

вопрос 1 — как ты в своем варианте будешь угадывать намерения пользователя, с какой целью он кликнул ?
вопрос 2 — как ты собираешься выяснять, как юзер хочет интерпретировать селектнуты текст — как стейтмент или как текст
вопрос 3 — как юзер должен селектить стейтмент , если он на трёх страницах(цыкл на три страницы) и его надо скопировать в другую функцию ?

В моем случае все просто

1 — не надо угадывать намерения, прилага не подразумевает работу с текстом
2 — всегда только стейтмент
3 — ровно один клик в любую область стейтмента, независимо от размера

I>>поведение чего ?
S>Раньше на рсдн-е не теряли контекста в рамках одного поста
S>Речь по-прежнему о сценарии драг-дропа, начиная с выделения и заканчивая рефакторингом после перетаскивания.

Не понял, тащим стейтмент и тащим текст == разное поведение. Как оно будет сохраняться ?

I>>В сумме ты уже описал примерно половину причин, из за которых я забил на мега-редакторы. Осталось еще немного — привести минимальный набор режимов, модификаторов и хоткеев.
S>Скорее, ты ими не пользовался, или ограничился режимом "неподготовленного пользователя". VS, офис, опера, notepad++ — в любом инструменте для работы с текстом на подобные грабли уже наступали, и, если в команде был специалист по проектированию UI, давно разрешили.

ни в одном из этих редакторов нет режима подобного приложению Лаптева. А я говорю именно про такое приложение, где можно работать и текстом, и со стейтментами.

Здравствуйте, Ikemefula, Вы писали:

S>>Я на него ответил выше — необходимо учитывать контекст (есть/нет выделения).
I>Значит в одном из случаев получаем очевидный фейл, т.к. в обоих случаях исходное состояния идентично, кроме намерений пользователя.

С чего бы это? Т.е. по твоему, 99% клиентов, нажимая на выделенный текст собираются его перевыделтить, а не перетащить?
UI-дизайн вообще-то работает не с "я так вижу", а с набором сценариев, которые в обязательном порядке проверяются на выборке по целевой группе пользователей. Поэтому типовая аргументация обычно не "очевидный фейл, гы-гы", а "варианте А пользователи пробуют выделение дважды, затем возвращаются к копипасте" vs "в варианте B пользователи использовали выделение и затем показывали его соседям, которые ещё использовали копипаст".

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

S>>2. Для частных случаев показываем тег с возможностью выбрать другие (реже используемые) варианты. Это _не_ режим редактирования,
I>То есть, уже есть усложнение, ибо если отказаться от текста, то это не нужно.
С чего бы это? Если мы перетащили цикл в пустой файл, то у нас уже 3 выбора — оставить как есть, обернуть в метод + новый класс, обернуть в метод + partial-class (класс определяется по исходному расположению текста).

И не важно, перетащили мы текст или узел AST, для пользователя нет никакой принципиальной разницы, что под капотом. Или для тебя UI 2013 студии до и после установки рослина — принципиально разные вещи?


S>>3. Для совсем частных случаев, когда алгоритм не справляется с определением правильного действия по умолчанию, добавляем возможность подсказать нужное действие, зажав модификатор при перетаскивании. П.3 не отменяет предыдущих, так что я не вижу с чего "нужны модификаторы уже при кликах, а не только при перетаскивании".

I>Опаньки — снова усложнение. Модификатор обычно нужен для выделения и вещей навроде. А тебе надо будет подсказывать с помощью модификатора, что же ты хочешь — перетащить текс или перетащить стейтмент.
Машу ж вать! Это opt-in, т.е. расширение поведения для опытных пользователей. Оно покрывает те 5-8% сценариев, когда пользователь хочет взять дело на ручной контроль.
Вас же модификаторы при работе с инструментами в фотошопе не смущают?

Ну блин, серьёзно, вам что человеко-машинное взаимодействие/UI design в вузе не читали? Это ж совсем-совсем азы.


I>Если перетаскиваем тест, то все просто. А если стейтмент, то он по окончании должен встроиться в код самостоятельно, по аналогии с автоматическим рефакторингом. Рефакторинг например не спрашивает у тебя, как преобразовывать локальные переменные в каждом из 100 случаев который он нашел.
Фига с два. Пользователю пофиг, что он перетаскивает. Ему важен результат. Если пользователь перетаскивает текст и хочет чтобы он отрефакторился по завершению — UI должен это поддерживать. Если пользователь хочет собрать AST из нескольких кусочков (по отдельности невалидных) — UI не должен ему мешать. Если UI ведёт себя иначе — значит, или эти задачи не входят в ключевые сценарии, или UI писал программист, а не дизайнер.

I>Поэтому тебе придется поназаводить дополнительных модификаторов, поназаводить режимов редактировать, увеличить примерно вдвое количество элементов меню и тд и тд и тд.
Ну блин. Я тебе _уже_ расписал всю реализацию от и до, но ты продолжаешь фантазировать на тему "формочек", "элементов меню" и "дополнительных модификаторов". Фу-фу-фу.


I>Итого — если отказаться от текста, то можно спокойно делать примерно так
I>1. клик — селектим стейтмент, предыдущую селекцию теряем
I>2. драг — перетаскиваем активный стейтмент
I>3. модификатор ctrl при драге — копирует стейтмент
I>4. модификатор ctrl при клике — добавляем стейтмент в селекшн

1 — неверно, не позволяет выделить несколько стейтментов простым движением мыши, без помощи клавиатуры.
3,4 — неверно. Перетаскивание должно позволять выбирать действия _после_ перетаскивания, иначе для исправления ошибки нужно сделать отмену и повторить перетаскивание заново, классическая потеря контекста. Выделение не должно требовать участия и мыши и клавиатуры.

Посмотри на работу с shapes в ворде/visio. Она там тоже не идеал, но они хоть додумались добавить прямоугольник для выделения, а не выкликивать стейтменты по отдельности.



I>вопрос 1 — как ты в своем варианте будешь угадывать намерения пользователя, с какой целью он кликнул ?
В UI guidelines для клика отводятся ровно два значения — выбор текущего элемента (если допускается его правка) или выполнение какого-либо действия. Но настоящие дизайнеры guidelines не читают конечно

I>вопрос 2 — как ты собираешься выяснять, как юзер хочет интерпретировать селектнуты текст — как стейтмент или как текст
Для пользователя не должно быть разницы. Поменяет мнение в процессе перетаскивания — выберет нужный вариант в смарт-теге.

I>вопрос 3 — как юзер должен селектить стейтмент , если он на трёх страницах(цыкл на три страницы) и его надо скопировать в другую функцию ?
Как и в любом нормальном редакторе — щелчком мыши по левому полю, повторные щелчки расширяют выделение. Только не надо говорить что и этого не знал.


I>1 — не надо угадывать намерения, прилага не подразумевает работу с текстом
Один фиг надо предлагать действия при перетаскивании в "неправильный" контекст. Например, что делать, если после перетаскивания у нас получился невалидный AST/конфликт имён?

I>2 — всегда только стейтмент
I>3 — ровно один клик в любую область стейтмента, независимо от размера
Как перетащить несколько строчек выше-ниже? Достаточно частый сценарий, соответствующее расширение в VS 2010 — одно из самых популярных.
Что, если нужно перетащить подвыражения внутри стейтмента?

Как всегда, если не начинать с сценариев использования — получается вот такая вот фигня, которую ещё обкладывать и обкладывать костылями.

S>>Речь по-прежнему о сценарии драг-дропа, начиная с выделения и заканчивая рефакторингом после перетаскивания.
I>Не понял, тащим стейтмент и тащим текст == разное поведение. Как оно будет сохраняться ?
С чего бы? Объясни, почему поведение должно отличаться?

S>>Скорее, ты ими не пользовался, или ограничился режимом "неподготовленного пользователя". VS, офис, опера, notepad++ — в любом инструменте для работы с текстом на подобные грабли уже наступали, и, если в команде был специалист по проектированию UI, давно разрешили.
I> ни в одном из этих редакторов нет режима подобного приложению Лаптева. А я говорю именно про такое приложение, где можно работать и текстом, и со стейтментами.
Встречный facepalm

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

Здравствуйте, Sinix, Вы писали:

I>>Значит в одном из случаев получаем очевидный фейл, т.к. в обоих случаях исходное состояния идентично, кроме намерений пользователя.

S>С чего бы это? Т.е. по твоему, 99% клиентов, нажимая на выделенный текст собираются его перевыделтить, а не перетащить?

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

S>UI-дизайн вообще-то работает не с "я так вижу", а с набором сценариев, которые в обязательном порядке проверяются на выборке по целевой группе пользователей.

Это телега впереди лошади. Сначала пользователи, а сценарии появляются после того, как аналитик закончит свою работу.

>Поэтому типовая аргументация обычно не "очевидный фейл, гы-гы", а "варианте А пользователи пробуют выделение дважды, затем возвращаются к копипасте" vs "в варианте B пользователи использовали выделение и затем показывали его соседям, которые ещё использовали копипаст".

Драг-дропом пользуются на раз в графических средствах, безо всяких подсказок. А вообще драг-дроп считается очень неудобной и неочевидной техникой.
Итого — придется решать эту проблему. У тебя пока что нет этого решения.

S>Ошибки на конкретном пользователе неважны, если текущее поведение устраивает остальных 99999 пользователей.

А как проверить это "если" ?

>Тем более что для него, такого уникального, предусмотрена возможность поменять результат после перетаскивания.

И это плохое решение, потому что необоснованое усложнение.

Внимание, тонкий намёк — открой десктоп и перетащи иконку левой кнопкой мыши, а потом правой кнопкой мыши. Разницу заметил ?

Теперь тоже самое, но выделяй группу синим прямоугольником. Разница есть ?

Пудозреваю, ты считаешь, что левая кнопка работает не правильно, так как не показывает никаких подсказок

Как думаешь, надо ли учитывать, что пользователь знаком как работает мышиный ввод в ОС которую он каждый день видит ?


S>>>2. Для частных случаев показываем тег с возможностью выбрать другие (реже используемые) варианты. Это _не_ режим редактирования,
I>>То есть, уже есть усложнение, ибо если отказаться от текста, то это не нужно.
S>С чего бы это? Если мы перетащили цикл в пустой файл, то у нас уже 3 выбора — оставить как есть, обернуть в метод + новый класс, обернуть в метод + partial-class (класс определяется по исходному расположению текста).

В пустом файле незачем оставлять, как такст, ибо очевидно, что графический тул даёт валидное АСТ, а не хрен знает что. Поскольку тул предназначен для студентов, то partial-class не нужен, не того уровня задача. Остаётся один вариант.

В варианте с текст+картинка будет минимум два варианта.

S>И не важно, перетащили мы текст или узел AST, для пользователя нет никакой принципиальной разницы, что под капотом.

Есть разница — если я тащу АСТ, то ожидаю, что тул сам встроит его в новый скоп. А если текст, то очевидно, что мне такое не надо.

И вот здесь надо усложнять UI. То есть, UI будет сложнее только из за того, что текст одновременно и картинка.


I>>Опаньки — снова усложнение. Модификатор обычно нужен для выделения и вещей навроде. А тебе надо будет подсказывать с помощью модификатора, что же ты хочешь — перетащить текс или перетащить стейтмент.
S>Машу ж вать! Это opt-in, т.е. расширение поведения для опытных пользователей.

А нам надо не для опытных, а для студентов, которые программировать не умеют и текст редактируют с большим трудом.
Твои opt-in не востребованы целевой аудиторией

>Оно покрывает те 5-8% сценариев, когда пользователь хочет взять дело на ручной контроль.

Ручной контроль это редактирование текста, а не программирование драг-дропом.

S>Вас же модификаторы при работе с инструментами в фотошопе не смущают?

А что, в фотошотпе тоже два редактора в одном — картинка и текст ?

S>Ну блин, серьёзно, вам что человеко-машинное взаимодействие/UI design в вузе не читали?

Наоборот. Основная идея — хороший UI всегда безусловный, то есть, такой который не задаёт вопросов.

>Это ж совсем-совсем азы.

А еще я большую часть времени работал на проекте где тул навроде CAD, при чем реализовывал в частности мышиный ввод, драг-дроп и тд.
Но я боюсь с твоей точки зрения там плохой UI — я не спрашивал пользователя "что делать в конце перетаскивания", как и положено в таких тулах.

I>>Если перетаскиваем тест, то все просто. А если стейтмент, то он по окончании должен встроиться в код самостоятельно, по аналогии с автоматическим рефакторингом. Рефакторинг например не спрашивает у тебя, как преобразовывать локальные переменные в каждом из 100 случаев который он нашел.

S>Фига с два. Пользователю пофиг, что он перетаскивает. Ему важен результат.

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

Тащим текст — это просто текст и в итоге АСТ может и не получится построить. Тащим картинку — АСТ будет и ,мало того, будет валидным, а конфликты обработает сам пользователь.

> Если пользователь перетаскивает текст и хочет чтобы он отрефакторился по завершению — UI должен это поддерживать.

А вот это хотение ты предлагаешь реализовать десятком модификаторов, режимов и тагов.

>Если пользователь хочет собрать AST из нескольких кусочков (по отдельности невалидных) — UI не должен ему мешать. Если UI ведёт себя иначе — значит, или эти задачи не входят в ключевые сценарии, или UI писал программист, а не дизайнер.

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

То есть эта хрень не фичи, а издержки.

I>>Поэтому тебе придется поназаводить дополнительных модификаторов, поназаводить режимов редактировать, увеличить примерно вдвое количество элементов меню и тд и тд и тд.
S>Ну блин. Я тебе _уже_ расписал всю реализацию от и до, но ты продолжаешь фантазировать на тему "формочек", "элементов меню" и "дополнительных модификаторов".

Ну так это у тебя нужны модификаторы. У тебя есть теги. А у меня ничего этого нет — мне не нужен ни тег, ни модификатор, что бы спросить у пользователя, с чем он хочет работать — с текстом или с картинкой.

I>>Итого — если отказаться от текста, то можно спокойно делать примерно так
I>>1. клик — селектим стейтмент, предыдущую селекцию теряем
I>>2. драг — перетаскиваем активный стейтмент
I>>3. модификатор ctrl при драге — копирует стейтмент
I>>4. модификатор ctrl при клике — добавляем стейтмент в селекшн

S>1 — неверно, не позволяет выделить несколько стейтментов простым движением мыши, без помощи клавиатуры.

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

S>3,4 — неверно. Перетаскивание должно позволять выбирать действия _после_ перетаскивания, иначе для исправления ошибки нужно сделать отмену и повторить перетаскивание заново, классическая потеря контекста.

OMG ! Почему ты всё жадешь пнуть пользователя каким нибудь вопросом ?

Простые случаи работают безусловно — и это признак хорошего UI.

>Выделение не должно требовать участия и мыши и клавиатуры.

Правильно, у меня именно так и есть — мыша включается только для изменения режима выделения по аналогии с десктопом.

S>Посмотри на работу с shapes в ворде/visio. Она там тоже не идеал, но они хоть додумались добавить прямоугольник для выделения, а не выкликивать стейтменты по отдельности.

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

I>>вопрос 1 — как ты в своем варианте будешь угадывать намерения пользователя, с какой целью он кликнул ?
S>В UI guidelines для клика отводятся ровно два значения — выбор текущего элемента (если допускается его правка) или выполнение какого-либо действия. Но настоящие дизайнеры guidelines не читают конечно

У меня кликом именно выбор. А у тебя просто перемещение курсора типа w|hile () {}
Кто из нас не читает ?

I>>вопрос 2 — как ты собираешься выяснять, как юзер хочет интерпретировать селектнуты текст — как стейтмент или как текст
S>Для пользователя не должно быть разницы. Поменяет мнение в процессе перетаскивания — выберет нужный вариант в смарт-теге.

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

Теги можно показать, но только если пользователь сам этого захочет — например, как сделано в десктоп винды — перетаскивание правой кнопкой.

I>>вопрос 3 — как юзер должен селектить стейтмент , если он на трёх страницах(цыкл на три страницы) и его надо скопировать в другую функцию ?
S>Как и в любом нормальном редакторе — щелчком мыши по левому полю, повторные щелчки расширяют выделение. Только не надо говорить что и этого не знал.

А мне нужен только один клик Ужос, сложно и непонятно !

I>>1 — не надо угадывать намерения, прилага не подразумевает работу с текстом
S>Один фиг надо предлагать действия при перетаскивании в "неправильный" контекст.

Крайне редко. А у тебя все простые действия требуют выбора. У меня они безусловные.

>Например, что делать, если после перетаскивания у нас получился невалидный AST/конфликт имён?

А что делает решарпер ?

I>>2 — всегда только стейтмент
I>>3 — ровно один клик в любую область стейтмента, независимо от размера
S>Как перетащить несколько строчек выше-ниже?

У меня нет строчек, у меня стейтменты. Открой эксплорер и проверь как это будет делаться.

>Достаточно частый сценарий, соответствующее расширение в VS 2010 — одно из самых популярных.
S>Что, если нужно перетащить подвыражения внутри стейтмента?

Смотря что ты хочешь. Если a = a.getValue(x) то ховер в помощь.
А если while(true) {... break} if(x) {} то такое не даём.

S>Как всегда, если не начинать с сценариев использования — получается вот такая вот фигня, которую ещё обкладывать и обкладывать костылями.

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

S>>>Речь по-прежнему о сценарии драг-дропа, начиная с выделения и заканчивая рефакторингом после перетаскивания.
I>>Не понял, тащим стейтмент и тащим текст == разное поведение. Как оно будет сохраняться ?
S>С чего бы? Объясни, почему поведение должно отличаться?

И ежу понятно — если юзер привык к UI, то незачем задавать ему дополнительные вопросы.
Для таких пользователей UI должен работать безусловно иначе они будут работать медленно или тулом пользоваться не будут.

S>Посмотри на смарт-теги в офисе/физио/экселе, на работу с shapes там же

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

>(не идеал, но хоть что-то), на контекстные действия решарпера. Это всё один и тот же сценарий: выводим нужные действие из контекста, позволяем пользователю их изменить.

Это совсем другое решение. Если действие можно выполнить безусловно — то так и надо делать.
Теги, модификаторы не упрощают UI. Они дают подсказку там, где именно ты усложнил этот UI.

Если тебе нужны теги для простого контрола, то чтото не так в консерватории.

Здравствуйте, Ikemefula, Вы писали:

Чтобы не потерялось: всё давно придумано за нас. Посмотри на TouchDevelop — 1-в-1 задумка Лаптева, только адаптированная под сенорные экраны (поэтому драг-дропа там нет и не будет). Зато контекстных действий (aka smart tags) — выше крыши. Несмотря на целевую аудиторию, заведомо не умеющую программировать.

I>По моему твой подход не даёт разделить два случая про которые ты написал и требует явно усложнить UI за счет модификаторов, тегов и прочего мусора.
Так для пользователей и не должно быть разделения. Иначе, стоит появится ещё одному варианту и весь UI идёт на переплавку.
В 100500й раз: модификаторы и теги — это средство не усложнения, а упрощения, т.к. они позволяют
1. Упростить самый популярный сценарий до одного действия — для него тег и не нужен
2. Добавить альтернативное действие без потери контекста и изменения UI. Вместо залезания в настройки просто открываем тег и выбираем нужное — что может быть проще?

I>Драг-дропом пользуются на раз в графических средствах, безо всяких подсказок. А вообще драг-дроп считается очень неудобной и неочевидной техникой.
I>Итого — придется решать эту проблему. У тебя пока что нет этого решения.
Я его озвучил выше. Главная проблема драг-дропа — высокая стоимость ошибки, помноженная на лёгкость ошибиться. Высокая стоимость решается смарт-тегами, ошибки убираются за счёт политики "выделенное — перетаскиваем", даже если промахнулись, можно просто перетащить в нужное место.

S>>Ошибки на конкретном пользователе неважны, если текущее поведение устраивает остальных 99999 пользователей.
I>А как проверить это "если" ?
Например, выпуском бета-версии с включенной статистикой использования. Или опытом реализации в похожих продуктах.


>>Тем более что для него, такого уникального, предусмотрена возможность поменять результат после перетаскивания.
I>И это плохое решение, потому что необоснованое усложнение.
I>Внимание, тонкий намёк — открой десктоп и перетащи иконку левой кнопкой мыши, а потом правой кнопкой мыши. Разницу заметил ?
Для десктопа и для IDE ключевые сценарии отличаются. Для десктопа действия будут всегда одни и те же, в 99.9% случаев выбор известен заранее. Для IDE, в отличие от десктопа:
* набор действий будет меняться в зависимости от того, куда мы перетащили текст
* действие по умолчанию (например, рефакторинг) может быть неочевидным или незаметным для пользователя.
Теги решают обе задачи — и дают выбрать нужное (при необходимости), и подсказывают пользователю, что он только что натворил.

I>Как думаешь, надо ли учитывать, что пользователь знаком как работает мышиный ввод в ОС которую он каждый день видит ?
Надо. Пользователь знаком с смарт-тегами по офису/другим IDE. А вот твой "ctrl для выделения нескольких блоков текста" ему будет вообще непонятен

I>В пустом файле незачем оставлять, как такст, ибо очевидно, что графический тул даёт валидное АСТ, а не хрен знает что. Поскольку тул предназначен для студентов, то partial-class не нужен, не того уровня задача. Остаётся один вариант.
Вторая главная ошибка UI-дизайнера — нарушение общепринятых метафор. Если код выглядит как текст и правится как текст, то и перетаскивать его надо так же как текст. Если AST неправильный — надо выделять "неполноценный" AST визуально и позволять его подправить, а не запрещать ради абстрактной чистоты кода.

I>Есть разница — если я тащу АСТ, то ожидаю, что тул сам встроит его в новый скоп. А если текст, то очевидно, что мне такое не надо.
I>А нам надо не для опытных, а для студентов, которые программировать не умеют и текст редактируют с большим трудом.
I>Твои opt-in не востребованы целевой аудиторией

1. Неочевидно. Например, решарпер по перемещению текста оставляет его как есть, но позволяет произвести move refactoring. Тег виден пользователям (для неопытных достаточно им помигать).
2. Opt-in как раз и разработаны для доработки UI под профессионалов, не ломая его для новичков. Посмотри на панели фотошопа. Для совсем новичнов — это обычные кнопки, как в пайнте. Затем человек обнаруживает, что нажатие кнопки позволяет переключиться между схожими инструментами. И,наконец, тултип подсказывает клавиатурные сокращения для экспертов. Причём обучение (самообучение) происходит прямо по ходу работы, без отдельных туториалов.

I>А еще я большую часть времени работал на проекте где тул навроде CAD, при чем реализовывал в частности мышиный ввод, драг-дроп и тд.
I>Но я боюсь с твоей точки зрения там плохой UI — я не спрашивал пользователя "что делать в конце перетаскивания", как и положено в таких тулах.
Не факт. Если действия однотипны и не зависят от контекста — нафиг там смарт-тег?


Остальное поскипал, т.к. начинаем повторяться.

I>Посмотрю, если ты назовешь софтину, где есть оба режима редактирования про которые мы говорим — одно и то же редактируется как картинка и как текст. Ни в офисе, ни в визио, ни в экселе такого нет.
DSL-инструменты —
http://strategoxt.org/ , http://blogs.msdn.com/b/dkaufman/archive/2009/03/02/oslo-dsl-for-biztalk.aspx (увы, проект так и не взлетел)

Word/Visio — работа с фигурами с текстом.
Excel — работа с ячейками и с текстом.

Везде пытаются объединить, а не разделить два разных режима редактирования.

Здравствуйте, Sinix, Вы писали:

S>Чтобы не потерялось: всё давно придумано за нас. Посмотри на TouchDevelop — 1-в-1 задумка Лаптева, только адаптированная под сенорные экраны (поэтому драг-дропа там нет и не будет). Зато контекстных действий (aka smart tags) — выше крыши. Несмотря на целевую аудиторию, заведомо не умеющую программировать.

Во первых, мы про тач не говорили пока что.

Во вторых, у микрософта за последние 10 лет появилась только одна хорошая идея в UI — риббон. Всё остальное это компромисный отстой или откровенный шлак.

В третьих — ты начитался про UI, но понять не можешь, что работа с графичекими вещами и текстом это совершенно разные подходы. Каждый из них можно сделать максимально удобным, но если впихнуть одно в другое, то внезапно, ты вынужден будет рисовать графику "как текст". Отсюда и редактирование будет каким то усредненным — ни то ни другое + обложиться тегами и модификаторами.

Еще раз — именно ты хочешь совместить несовместимое — графику и текст, сделав работу одинакову неудобной в каждом из случаев.

S>В 100500й раз: модификаторы и теги — это средство не усложнения, а упрощения, т.к. они позволяют

S>1. Упростить самый популярный сценарий до одного действия — для него тег и не нужен

Ну да, и по этому ты предлагаешь на перетаскивание показывать теги ?

S>2. Добавить альтернативное действие без потери контекста и изменения UI. Вместо залезания в настройки просто открываем тег и выбираем нужное — что может быть проще?

Для обсуждаемой фичи не нужны ни настройки, ни теги.

I>>Драг-дропом пользуются на раз в графических средствах, безо всяких подсказок. А вообще драг-дроп считается очень неудобной и неочевидной техникой.
I>>Итого — придется решать эту проблему. У тебя пока что нет этого решения.
S>Я его озвучил выше. Главная проблема драг-дропа — высокая стоимость ошибки, помноженная на лёгкость ошибиться.

Правильно и именно по этому надо разделять редактор на две части — отдельно текст, отдельно АСТ. То есть, это именно тот случай, где нужно вводить режим редактирования. В этом случае получим два привычных и удобных редактора — текстовы и рисовалка.
А если скрещивать носорога с табуреткой, получится набор модификаторов, тулбаров, тегов, меню и прочих приседаний.

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

Не решается. В твоем случае что бы перетащить, надо сначала выделить фрагмент текста. А мне ничего не надо — взял и тащи сходу любой стейтмент.

I>>И это плохое решение, потому что необоснованое усложнение.
I>>Внимание, тонкий намёк — открой десктоп и перетащи иконку левой кнопкой мыши, а потом правой кнопкой мыши. Разницу заметил ?
S>Для десктопа и для IDE ключевые сценарии отличаются. Для десктопа действия будут всегда одни и те же, в 99.9% случаев выбор известен заранее. Для IDE, в отличие от десктопа:
S>* набор действий будет меняться в зависимости от того, куда мы перетащили текст

Нет, не будет.

S>* действие по умолчанию (например, рефакторинг) может быть неочевидным или незаметным для пользователя.

А это совершенно неважно.

S>Теги решают обе задачи — и дают выбрать нужное (при необходимости), и подсказывают пользователю, что он только что натворил.

Да, решают проблему которую сами же и вводят.

I>>Как думаешь, надо ли учитывать, что пользователь знаком как работает мышиный ввод в ОС которую он каждый день видит ?
S>Надо. Пользователь знаком с смарт-тегами по офису/другим IDE.

Интересно, и откуда это студент, не умеющий программирований, получит опыт в другой IDE или в офисе ?

>А вот твой "ctrl для выделения нескольких блоков текста" ему будет вообще непонятен

Практика показывает обратное

I>>В пустом файле незачем оставлять, как такст, ибо очевидно, что графический тул даёт валидное АСТ, а не хрен знает что. Поскольку тул предназначен для студентов, то partial-class не нужен, не того уровня задача. Остаётся один вариант.
S>Вторая главная ошибка UI-дизайнера — нарушение общепринятых метафор. Если код выглядит как текст и правится как текст, то и перетаскивать его надо так же как текст. Если AST неправильный — надо выделять "неполноценный" AST визуально и позволять его подправить, а не запрещать ради абстрактной чистоты кода.

Правильно. Этот диссонанс ты сам же и ввёл, когда решил в одном флакое редактировать и текст программы и аст. В графической рисовалке нет необходимости придерживаться строгого соответствия. Более того можно менять представление как угодно, например в той части где про ветвление и тд и тд.

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

Дальше я скипнул.

Здравствуйте, Ikemefula, Вы писали:

I>Собтсвенно разговор продолжать смысла нет

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

Здравствуйте, Sinix, Вы писали:

I>>Собтсвенно разговор продолжать смысла нет

S>Вот с этим я полностью согласен, только причина другая. Походу ты в принципе не читаешь то, что тебе пишут

Ты скрещиваешь две принципиально разные метафоры, а я чего то не понимаю или не читаю ? Ну и дела.

Здравствуйте, Sinix, Вы писали:

S>Чтобы не потерялось: всё давно придумано за нас. Посмотри на TouchDevelop — 1-в-1 задумка Лаптева, только адаптированная под сенорные экраны

Вот в том то и дело, что это не его задумка, потому что, в отличие от Лаптева, ответ на вопрос "зачем" можно легко дать, не устраивая многодневных попыток обосрать собеседника. Более того — открываем главную страницу и получаем наиподробнейший ответ крупным шрифтом как раз на этот вопрос.
А то что у Лаптева, это глупая идея, вызванная типичным для бСССР низким уровнем знаний в области компиляторостроения, а поверх нее попытка натянуть презерватива на ежика мутными статьями и несуществующими проблемами. А когда задаешь вопросы — идет предложение сходить в личную почту. А на вопрос — можно ли переписку опубликовать получаем просто молчание.
Но самое смешное в другом:

TouchDevelop sits in between those two worlds: the code is represented in text and the editor is semi-structured which mostly takes care of the syntax for the beginner.

Вот это пример дизайна, который делали люди, понимающие в вопросе. Сравни теперь с лаптевским.
Спасибо, кстати — я все никак не мог вспомнить название проекта чтобы Лаптеву продемонстрировать как надо.