Планируется использовать в программе-симуляторе работы машина Тьюринга:
Как по-другому сделать редактирование символа пустой ячейки? Насколько хороши для этого используемые сейчас кнопки обмена с текущим символом алфавита ("<>")?
Здравствуйте, Loonie, Вы писали:
L>Планируется использовать в программе-симуляторе работы машина Тьюринга:
[]
Бррр, как страшно все . Зачем такой список слева, да еще и с кодами? В этом есть какой-то особый сакральный смысл?
Не проще ли просто один edit со строкой, включающей используемые символы, например "absdef2345"? И второй edit для символа пустой ячейки. Такое решение, имхо, будет гораздо более юзабельным, чем чудовище, приведенное на рисунке.
F>Бррр, как страшно все . Зачем такой список слева, да еще и с кодами? В этом есть какой-то особый сакральный смысл?
F>Не проще ли просто один edit со строкой, включающей используемые символы, например "absdef2345"? И второй edit для символа пустой ячейки. Такое решение, имхо, будет гораздо более юзабельным, чем чудовище, приведенное на рисунке.
В указанном мной варианте нет необходимости делать контроль ввода. Да и Edit'ы смотреться будут топорно, имхо.
Здравствуйте, Loonie, Вы писали:
L>Планируется использовать в программе-симуляторе работы машина Тьюринга:
L>Как по-другому сделать редактирование символа пустой ячейки? Насколько хороши для этого используемые сейчас кнопки обмена с текущим символом алфавита ("<>")?
На троечку окно. Не понятно назначение списка "Доступные символы". Я бы сделал так — поле ввода (или выпадающий список) куда пользователь вводит символ. Если символ разрешен, то все нормально. Если нет, кнопка "Добавить" (которая находится справа от поля ввода) блокируется. Внизу (в строке состояния окна) выводится причина, по которой нельзя добавить символ. Я с ходу вижу две причины: "Недопустимый символ алфавита" и "Символ уже используется". Во втором случае можно попробовать делать на него фокус в таблице уже добавленных.
Насчет символа пустых ячеек — проанализировать, как часто он будет использован. Что-то мне подсказывает, что очень часто. Тогда добавляем его по умолчанию. Иначе можно на него забить пробел? Или сделать специальную кнопку "Добавить пустой символ" (первый вариант мне нравится больше). Или ввести метасимвол "ES".
PS Когда я делаю диалоговые окна, кнопки "Принять изменения" и "Отменить" располагаю по ширине всего окна, то есть каждая в половину формы. И делаю чуть выше стандартных (33 пикселя вместо 25? в D7). Насчет высоты — это конечно дело личного вкуса, а вот насчет ширины — пользователю так банально легче попасть мышкой по кнопке.
F>То есть вы свои проблемы перекладываете на юзера? Ну-ну.
F>Да ну? Во всех прогах они смотрятся нормально, а в вашей — топорно. Лол
Имею ввиду, что придется выводить много сообщений в случае некорректного ввода. Да и символы алфавита обычно разделяют чем-либо (запятыми например) при записи постановки задачи. Потому Ваш вариант считаю не слишком подходящим (хотя по скорости ввода параметров он и лучше).
LV>На троечку окно. Не понятно назначение списка "Доступные символы". Я бы сделал так — поле ввода (или выпадающий список) куда пользователь вводит символ. Если символ разрешен, то все нормально. Если нет, кнопка "Добавить" (которая находится справа от поля ввода) блокируется. Внизу (в строке состояния окна) выводится причина, по которой нельзя добавить символ. Я с ходу вижу две причины: "Недопустимый символ алфавита" и "Символ уже используется". Во втором случае можно попробовать делать на него фокус в таблице уже добавленных. LV>Насчет символа пустых ячеек — проанализировать, как часто он будет использован. Что-то мне подсказывает, что очень часто. Тогда добавляем его по умолчанию. Иначе можно на него забить пробел? Или сделать специальную кнопку "Добавить пустой символ" (первый вариант мне нравится больше). Или ввести метасимвол "ES". LV>PS Когда я делаю диалоговые окна, кнопки "Принять изменения" и "Отменить" располагаю по ширине всего окна, то есть каждая в половину формы. И делаю чуть выше стандартных (33 пикселя вместо 25? в D7). Насчет высоты — это конечно дело личного вкуса, а вот насчет ширины — пользователю так банально легче попасть мышкой по кнопке.
Через выпадающий список работа с окном будет происходить медленее: нельзя будет добавить несколько символов сразу. Строка состояния в диалоговых окнах, как правило, не используется.
Символ пустой ячейки необходимо сделать редактируемым (по ТЗ).
Не думаю, что хороший это вариант — растягивать кнопки на все окно. Нигде не встречал раньше.
Здравствуйте, Loonie, Вы писали:
L>Имею ввиду, что придется выводить много сообщений в случае некорректного ввода.
Вот интересно, вы пост разместили, чтобы убедить всех в том, что вы правы, или чтобы воспринять критику? Еще раз: то, что есть — ужастно страшное убожество. Неюзабельное совершенно.
Зачем "выводить много сообщений в случае некорректного ввода"? Ведь достаточно один раз при нажатии кнопки "ОК" проверить введенную строку и _вежливо_ попросить поправить неправильно введенное, аргументировав причину, например:
Извините, но введенный вами набор символов содержит следующие недопустимые значения: х, y, z.
Нажмите ОК для того, чтобы программа автоматически удалила недопустимые значения перед их сохранением. Для возврата к редактированию нажмите "Отмена".
[ ОК ] [ Отмена ]
L>Да и символы алфавита обычно разделяют чем-либо (запятыми например) при записи постановки задачи.
Зачем их разделять, если edit можно предварить label-ом с надписью "Набор символов"? Ключевое слово улавливаете? Набор. Что автоматически превращает эту строку именно в набор символов. Юзеру так понятней, чем полчаса мудохаться с предложенным диалогом, выбирая символы. Меня уже скриншот напрягает, что уж там говорить о юзабилити?
L>Потому Ваш вариант считаю не слишком подходящим (хотя по скорости ввода параметров он и лучше).
См. выше. Нет, дело, конечно, ваше — оставляйте все, как есть, раз вы считаете, что так лучше. Но сперва спросите окружающих, сколько диалогов подобного вида они видели? И сколько диалогов вида, описанного мной? Думаю, результат будет сильно не в вашу пользу. Потому что юзабилити среди прочего включает в себя такие понятия, как узнаваемость, предсказуемость и привычность Что в вашем случае наличия шести кнопок, разбросанных по диалогу там-сям, двух list-view разных размеров, трех label-ов (причем один и них используется в ключе, отличном от первых двух), и усложнения сущностей введением никому не нужных кодов символов — превращается в тихий ужас. Я уж не говорю о никаком layout контролов.
Бррр, опять пупырышные мурашки выскочили
З.Ы. Пользуясь случаем, хочу передать привет c-smile — он меня в свое время очень хорошо макнул в мое г. в плане интерфейса. До сих пор вспоминаю с благодарностью.
Здравствуйте, Loonie, Вы писали:
L>Планируется использовать в программе-симуляторе работы машина Тьюринга: L>img L>Как по-другому сделать редактирование символа пустой ячейки? Насколько хороши для этого используемые сейчас кнопки обмена с текущим символом алфавита ("<>")?
Плохой интерфейс.
Сделайте табличку (как в charmap) — в белой клеточке символ и ниже его код меленько подписать. Пусть пользователь тыкает на символы — выбранные отмечаются цветом, зелёненьким. Раз тыкнул — выбрал. Другой раз тыкнул — снял выбор. Последний тыкнутый символ пусть обводится хорошей (толстой и заметной, а не соплёй в мелкую точечку) рамкой фокуса, чтобы его можно было выбрать кнопкой "символ пустой ячейки". Плюс двойным щелчком. Плюс выводить с.п.я. в контроле с рамочкой и ловить туда drag'n'drop-нутый символ. Его ещё тоже подсвечивать на поле символов, по-другому как-нибудь. Фоном другого цвета, наверное, голубым.
Не забыть про клавиатуру, чтобы можно было вводить символы прямо с клавиатуры, нажимая соответствующие клавиши.
Прочитав всю ветку по этому сообщению возникло желание овтетить=)
Везде идёт обсуждение реализации интерфейса, но НИКТО НИГДЕ не сказал и не поинтересовался ЗАДАЧАМИ пользователя. Что он хочет решать с помощью этой формы, какие перед ним стаят задачи, цели, чего он хочет достигнуть используя эту форму, в каком контексте он использует эту форму? Без ответа на эти вопросы бесполезно обсуждать насколько хорош или плох интерфейс. =) Всё-равно, что обсуждать фильм, просто послушав аудиодорожку=) Проектирование интерфейса исходит именно из ответов на эти вопрсы и очень полезно перед началом создания формы задать их себе=)
Здравствуйте, eXod, Вы писали:
X>Везде идёт обсуждение реализации интерфейса, но НИКТО НИГДЕ не сказал и не поинтересовался ЗАДАЧАМИ пользователя. Что он хочет решать с помощью этой формы, какие перед ним стаят задачи, цели, чего он хочет достигнуть используя эту форму, в каком контексте он использует эту форму?
Контекст был указан: >> Планируется использовать в программе-симуляторе работы машина Тьюринга
Включив режим телепатии, можно догадаться, для чего всё это нужно.
Предполагаю, что программа для МТ будет вводиться с помощью модальных диалогов "Добавить состояние", "добавить правило", где диалог редактирования правила содержит комбо-боксы используемых символов.
Гораздо прикольнее было бы сделать текстовый редактор — а ещё лучше табличку.
Поскольку каждое правило — это кортеж (исходное состояние, исходный символ, новый символ, смена позиции, новое состояние), то таблица прямо-таки напрашивается.
А алфавит и множество состояний — уже получать постфактум (и показывать либо сразу же, либо по запросу).
Ещё можно прикрутить подсветку: когда фокус ввода на текущем правиле — то подсвечивать правила, в которых упомянуты те же символы и состояния.
А ещё — прикрутить сортировку по каждой из колонок (чтобы группировать правила, относящиеся к одинаковым входам, выходам или действиям).
И валидацию: подсвечивать правила с проблемами
— неоднозначности (одинаковые входы, разные выходы)
— дубликаты
— заведомо недостижимые правила (в т.ч. анализируя текущее содержимое ленты)
И профилирование:
— сколько раз выполнилось каждое правило в данном сеансе
L>Планируется использовать в программе-симуляторе работы машина Тьюринга:
Прошу всех участников оценить готовый проект: Машина Тьюринга. От обсуждаемого окна отказался в пользу автоматического составления алфавита на основе таблицы алгоритма + задания символа пустой ячейки отдельно. Последний необходим для указания символа, которым заполнена условно бесконечная лента МТ.
А вот я, если бы делал подобную штуковину, придумал бы DSL для описания MT. И написал бы консольное приложение, которое читало бы файл с описанием МТ, а выдавала текстовый файл с описанием конфигурации МТ на каждом шаге, вплоть до допускающего. Для пущей наглядности можно было бы открыть окно, где весь процесс показывался бы в действии, так сказать. Ну, можете считать меня маньяком, но я поступил бы именно так (если бы сам себе писал ТЗ). Мне проще открыть SciTE и быстренько набить программу МТ, чем долго-долго издеваться над мышью.
Здравствуйте, Loonie, Вы писали:
L>Прошу всех участников оценить готовый проект: Машина Тьюринга. От обсуждаемого окна отказался в пользу автоматического составления алфавита на основе таблицы алгоритма + задания символа пустой ячейки отдельно. Последний необходим для указания символа, которым заполнена условно бесконечная лента МТ.
Неудобно это как-то. Очень наглядно, и это плюс, но забивать программу умучаешься.
Например, при добавлении символов и состояний нужно каждый раз указывать в отельном окне "выше" или "ниже", что отвлекает, заставляет судорожно водить мышью. Я бы сделал команды "добавить символ" и "добавить состояние" которые добавляют символ/состояние после текущего — пусть при необходимости пользователь сам перетащит строку/столбец куда нужно. На тулбаре можно поместить кнопки "добавить строку/столбец", которые добавляют элементы в конец. А при добавлении символа не стоит вводить его. Вместо этого лучше сделать возможность переименовать символ (для состояний, я так понимаю, это не актуально). При создании МТ следует выводить диалог, где задаётся количество строк/столбцов, при этом столбцам даются некоторые имена по-умолчанию. Для переименования симолов можно сделать в контекстном меню подменю "переименовать", где каждый пункт содержит доступный символ; или прямо в заголовок внедрить ComboBox.
Очень удивило, что после последнего шага МТ тут же переключатеся в начальную конфигурацию, что неудобно. Не проще ли фиксировать её в допускающей конфигурации, при этом добавить кнопку "Reset". Смотреть какие-то отчёты, чтобы узнать, чем завершился процесс, мне, честно говоря, неудобно. К слову, отчёты лучше помещать в dockable window.
Кстати, может я невнимательный, но когда я закустил МТ в пошаговом режиме, мне пришлось с полминуты рнпу чесать, чтобы понять, что делать дальше.
Здравствуйте, konsoletyper, Вы писали:
K>Например, при добавлении символов и состояний нужно каждый раз указывать в отельном окне "выше" или "ниже", что отвлекает, заставляет судорожно водить мышью. Я бы сделал команды "добавить символ" и "добавить состояние" которые добавляют символ/состояние после текущего —
Резонные замечания, но из них выход вижу только в запоминании последнего выбора (слева/справа, ниже/выше). При определенных навыках владения программой (т.е. при ознакомлении с горячими главишами и использовании Enter) ввод программы должен происходить достаточно быстро.
K>Очень удивило, что после последнего шага МТ тут же переключатеся в начальную конфигурацию, что неудобно. Не проще ли фиксировать её в допускающей конфигурации, при этом добавить кнопку "Reset". Смотреть какие-то отчёты, чтобы узнать, чем завершился процесс, мне, честно говоря, неудобно. К слову, отчёты лучше помещать в dockable window.
Здесь проблема: что отображать в таблице, так как произошел переход в состояние с индексом 0? Как замутить dockable на Delphi — не знаю (может поскажет кто, а, чтобы с сохранением позиции и состояния в форме/за ее пределами?).
K>Кстати, может я невнимательный, но когда я закустил МТ в пошаговом режиме, мне пришлось с полминуты рнпу чесать, чтобы понять, что делать дальше.
Хотелось бы выслушать Ваши предложения по улучшению.
K>PS: На чём писали-то?
Здравствуйте, konsoletyper, Вы писали:
K>А вот я, если бы делал подобную штуковину, придумал бы DSL для описания MT. И написал бы консольное приложение, которое читало бы файл с описанием МТ, а выдавала текстовый файл с описанием конфигурации МТ на каждом шаге, вплоть до допускающего. Для пущей наглядности можно было бы открыть окно, где весь процесс показывался бы в действии, так сказать. Ну, можете считать меня маньяком, но я поступил бы именно так (если бы сам себе писал ТЗ). Мне проще открыть SciTE и быстренько набить программу МТ, чем долго-долго издеваться над мышью.
Параметры определял преподаватель ВУЗа, потом ведь еще дело вкуса: GUI или косольный интерфейс мутить. Есть открытый проект с консольным исполнителем: UTM (http://sourceforge.net/projects/turing-machine/), — но его недостаток — медленный интерфейс в случаях длинной ленты, так как в лог на каждом шаге выводятся все символы. Насилие над мышью необязательно в случае овладения комбинациями горячих клавиш.
Loonie wrote: > Ну, можете считать меня маньяком, но я поступил бы именно так (если бы > сам себе писал ТЗ). Мне проще открыть SciTE и быстренько набить > программу МТ, чем долго-долго издеваться над мышью. > > Параметры определял преподаватель ВУЗа, потом ведь еще дело вкуса: GUI > или косольный интерфейс мутить. Есть открытый проект с консольным
Редактирование мышкой заменить на ввод в красивом текстовом окошке с
возможностью сохранения не позволил ни в какую, или и не просили? > исполнителем: UTM (http://sourceforge.net/projects/turing-machine/), — > но его недостаток — медленный интерфейс в случаях длинной ленты, так как > в лог на каждом шаге выводятся все символы. Насилие над мышью > необязательно в случае овладения комбинациями горячих клавиш.
Здравствуйте, raskin, Вы писали:
R>Редактирование мышкой заменить на ввод в красивом текстовом окошке с R>возможностью сохранения не позволил ни в какую, или и не просили?
Так понял, предлагаете дополнить ввод в таблицу возможностью ввода правил перехода прямо в текстовом виде?
Loonie wrote: > R>Редактирование мышкой заменить на ввод в красивом текстовом окошке с > R>возможностью сохранения не позволил ни в какую, или и не просили? > > Так понял, предлагаете дополнить ввод в таблицу возможностью ввода > правил перехода прямо в текстовом виде?
Когда я такое писал, я долго обсуждал с учителем формат задания правил
(сначала всё написав с использованием неудачных, по его мнению, языка
правил и структуры программы), и система просто загружала файл правил и
запоминала правила в своём внутреннем формате, после чего старательно
рисовала в консоли, как ездит лента, как меняются состояния и считала
шаги. Ленту можно было загрузить из файла и править руками (ну и
сохранить), программы писались отдельно в редакторе. Если бы я писал с
нуля в Ваших условиях, я бы попытался настоять на текстовом внешнем
задании программы в каком-то приличном читаемом виде и вводе её в memo с
возможностью сохранить. Если кому-то предстоит пользоваться данной
программой, наверное, стоит всё же хоть как-то дать вводить в виде
текста. (Да, и числовые состояния доведут кого угодно при попытке
написать простой поиск подстроки в двоичной строке)
Здравствуйте, Loonie, Вы писали:
K>>Например, при добавлении символов и состояний нужно каждый раз указывать в отельном окне "выше" или "ниже", что отвлекает, заставляет судорожно водить мышью. Я бы сделал команды "добавить символ" и "добавить состояние" которые добавляют символ/состояние после текущего —
L>Резонные замечания, но из них выход вижу только в запоминании последнего выбора (слева/справа, ниже/выше).
Нет, это не поможет, а только запутает. Мотивация пользователя — сначала ввести программу МТ, а потом всё это офромить покрасивее. Как следствие, он вначале понасоздаёт состояний/символов, а затем наведёт марафет. Для тех пользователей, которые хотят всё сразу это так же будет удобнее, т.к. после создания состояния они смогут тут же перетащить его, куда нужно, не двигая курсор в центр экрана.
L>При определенных навыках владения программой (т.е. при ознакомлении с горячими главишами и использовании Enter) ввод программы должен происходить достаточно быстро.
Для любителей горячих клавиш не проще ли было бы просто поступить, как описано ниже
? Причём, здесь подошёл бы vim в режиме visual (вот уж от себя не ожидал одобрения vim), чтобы было проще вставлять строки/столбцы. А так, если есть GUI, то надо чтобы он был удобным и с мыши.
K>>Очень удивило, что после последнего шага МТ тут же переключатеся в начальную конфигурацию, что неудобно. Не проще ли фиксировать её в допускающей конфигурации, при этом добавить кнопку "Reset". Смотреть какие-то отчёты, чтобы узнать, чем завершился процесс, мне, честно говоря, неудобно. К слову, отчёты лучше помещать в dockable window.
L>Здесь проблема: что отображать в таблице, так как произошел переход в состояние с индексом 0?
В смысле какую ячейку? Тогда просто снимать выделение, если это возможно. На худой конец, можно просто оставить выделенной ячейку. Или просто останавливать МТ на предпоследнем такте.
L>Как замутить dockable на Delphi — не знаю (может поскажет кто, а, чтобы с сохранением позиции и состояния в форме/за ее пределами?).
Использовать .NET? Причём, не реализацию всё того же Delphi, а C# или, что ещё лучше — смотреть в сторону Nemerle или F#.
K>>Кстати, может я невнимательный, но когда я закустил МТ в пошаговом режиме, мне пришлось с полминуты рнпу чесать, чтобы понять, что делать дальше.
L>Хотелось бы выслушать Ваши предложения по улучшению.
Без понятия . Но то что улучшать нужно — это факт.
. Зачем такой список слева, да еще и с кодами? В этом есть какой-то особый сакральный смысл?
Что в вашем случае наличия шести кнопок, разбросанных по диалогу там-сям, двух list-view разных размеров, трех label-ов (причем один и них используется в ключе, отличном от первых двух), и усложнения сущностей введением никому не нужных кодов символов — превращается в тихий ужас. Я уж не говорю о никаком layout контролов. 
Перекуём баги на фичи!
. Но то что улучшать нужно — это факт.