Скажем есть некая веб страница или форма в программе с
неким набором полей ввода.
Встает вопрос об имплементация undo/redo для полей. Имеем
два подхода:
1) IE — вся форма есть один большой документ и стек undo/redo общий на все элементы.
Т.е. изменили поле A а потом B. Затем жмем Ctrl-Z не важно где и откатываем все изменения —
сначала в B потом в A.
2) FF (и любые другие программы Windows ) — каждый элемент имеет свой собственный независимый стек.
Что еще интересно: undo/redo есть только для edit fields в обоих случаях.
Radio и check boxes, selects — лишены такой возможности (так надо?)
Соответсвенно возникает вопрос: куда податься крестьянину — жителю деревни Юзабиловки?
Здравствуйте, c-smile, Вы писали:
CS>Встает вопрос об имплементация undo/redo для полей. Имеем CS>два подхода:
Внутренний голос подсказывает мне, что можно посмотреть на задачу:
— если это что-то типа графического редактора, то андо необходимо делать только по всем изменениям;
— если это что-то типа екселя, то я бы дал пользователю возможность отката либо только в ячейке, либо по всем изменениям.
Тектовой процессор в этом случае я считаю аналогом графического редактора. Форму с кучей полей — аналогом екселя.
О! Родилось: откат производить в зависимости от того, откуда этот откат вызван: редактируем ячейку — откат в ячейке, редактируем рисунок — откат в рисунке, фокус на форме (не элементе) — откат по элементам формы.
Здравствуйте, c-smile, Вы писали:
CS>Скажем есть некая веб страница или форма в программе с CS>неким набором полей ввода.
CS>Встает вопрос об имплементация undo/redo для полей. Имеем CS>два подхода: CS>1) IE — вся форма есть один большой документ и стек undo/redo общий на все элементы. CS> Т.е. изменили поле A а потом B. Затем жмем Ctrl-Z не важно где и откатываем все изменения - CS> сначала в B потом в A.
ИМХО крайне порочный путь... Причина: пользователь работал с формой, пользователь отвлекся, затем вернулся к работе...
Какое поле он менял последним еще можно при помощи фокуса отметить. А вот какое поле он менял перед этим? И соответственно, какое поле пойдет в undo после нажатия Ctrl-Z? Пользователь уже не помнит...
Так что смысл такого механизма стремится к нулю.
CS>2) FF (и любые другие программы Windows ) — каждый элемент имеет свой собственный независимый стек.
CS>Что еще интересно: undo/redo есть только для edit fields в обоих случаях. CS>Radio и check boxes, selects — лишены такой возможности (так надо?)
CS>Соответсвенно возникает вопрос: куда податься крестьянину — жителю деревни Юзабиловки?
Второй способ соответственно более правильный. Но!
Мое мнение такое, что вообще при грамотном проектировании форм механизм undo/redo для форм не требуется. Максимум что может потребоваться это кнопка сброса всех настроек в первоначальное состояние (чтобы не закрывать форму без изменений — "Отмена" и снова не открывать для изменения какой-нибудь одной настройки). Такой механизм, кстати, будет более понятен пользвателям чем undo/redo.
PS. И вообще-то на будущее... Слишком мало данных Вы даете, чтобы дать какой-нибудь более или менее правильный совет. Что за программа? Что за форма? Как много элементов в этой форме? Кто пользователи Вашей программы? Ведь, если опытные пользователи компьютера воспринимают возможность undo/redo как само собой разумеющееся, то начинающим пользователям зачастую не понятна сама концепция этого действия... А уж объяснять, что каждое поле имеет свой собственный стек undo/redo — увольте меня!
Здравствуйте, Бушин Илья, Вы писали:
БИ>ИМХО крайне порочный путь... Причина: пользователь работал с формой, пользователь отвлекся, затем вернулся к работе...
Вообще-то, андо расчитано или на то, что пользователь не отвлекается, т.к. по возвращению к работе не то что про андо не вспомнит, так и вообще не вспомнит, что он делал.
Если андо так важно — используется лог, например как в фотошопе.
БИ>Мое мнение такое, что вообще при грамотном проектировании форм механизм undo/redo для форм не требуется. Максимум что может потребоваться это кнопка сброса всех настроек в первоначальное состояние (чтобы не закрывать форму без изменений — "Отмена" и снова не открывать для изменения какой-нибудь одной настройки). Такой механизм, кстати, будет более понятен пользвателям чем undo/redo.
Более понятен, но не эффективен. Есть формы (и их не мало) которые используются для ввода данных с бумаги: пользователь смотрит на бумагу, читает, на экран, вбивает, на бумагу, читает, на экран, вбивает, и случается, что вбивая строку N, он промахивается и смотрит на бумагу на продолжение строки N+/-1, на экран, вбивает, матерится.
Имхо, надо оставить default behaviour такой, как в браузерах — undo/redo только в пределах input/textarea/htmlarea. Если понадобится хитрая функциональность, требующая undo/redo пол всей форме, то пусть юзер сам ее и имплементирует. Потому что ни один элемент на форме, кроме текстовых, не требует, в принципе, undo/redo.
Здравствуйте, Mamut, Вы писали:
M> Если понадобится хитрая функциональность, требующая undo/redo пол всей форме, то пусть юзер сам ее и имплементирует.
.
M> Потому что ни один элемент на форме, кроме текстовых, не требует, в принципе, undo/redo.
Здравствуйте, Real 3L0, Вы писали:
БИ>>Мое мнение такое, что вообще при грамотном проектировании форм механизм undo/redo для форм не требуется. Максимум что может потребоваться это кнопка сброса всех настроек в первоначальное состояние (чтобы не закрывать форму без изменений — "Отмена" и снова не открывать для изменения какой-нибудь одной настройки). Такой механизм, кстати, будет более понятен пользвателям чем undo/redo.
R3>Более понятен, но не эффективен. Есть формы (и их не мало) которые используются для ввода данных с бумаги: пользователь смотрит на бумагу, читает, на экран, вбивает, на бумагу, читает, на экран, вбивает, и случается, что вбивая строку N, он промахивается и смотрит на бумагу на продолжение строки N+/-1, на экран, вбивает, матерится.
Хм-м-м-м-м-м... Мы сейчас разводим спор на пустом месте. Как я уже писал в предыдущем сообщении, автором дано слишком мало информации о сути вопроса для того, чтобы давать какие-либо конкретные рекомендации.
А по сути Вашего примера могу сказать следующее. Насколько я понял из Вашего описания, эту ошибку можно классифицировать как опечатку вызванную недостаточным вниманием человека выполняемому действию. Соответственно эту проблему (привлечение большего внимания) и надо решать, а не придумывать "костыли" в виде механизма undo/redo.
Здравствуйте, Бушин Илья, Вы писали:
БИ>Здравствуйте, Real 3L0, Вы писали:
БИ>Хм-м-м-м-м-м... Мы сейчас разводим спор на пустом месте. Как я уже писал в предыдущем сообщении, автором дано слишком мало информации о сути вопроса для того, чтобы давать какие-либо конкретные рекомендации.
Автор т.е. я имплементирует вот это http://www.terrainformatica.com/htmlayout/
Будем считать это броузером. Вопрос стал о разработке общего механизма undo/redo
т.е. делать его сквозным как в IE или локальным как в FF.
Здравствуйте, Mamut, Вы писали:
CS>>Давайте ваши умные мысли
M>Имхо, надо оставить default behaviour такой, как в браузерах — undo/redo только в пределах input/textarea/htmlarea. Если понадобится хитрая функциональность, требующая undo/redo пол всей форме, то пусть юзер сам ее и имплементирует. Потому что ни один элемент на форме, кроме текстовых, не требует, в принципе, undo/redo.
Наверное ты прав. Тем более в свете <htmlarea> будет грустно если в процесс откакта будет встревать нечто еще.
Здравствуйте, Mamut, Вы писали:
M>Селективные — типа list?
Да, а также чекбокс, сомбобокс и т.п.
M> Имхо, все равно не надо
Ну вот лично мне такая функциональность не помешала бы: а то apply есть, а андо нет. Пример: настройка цветов в виндовсе — настроил, apply, настроил, apply, не понравилось (окно настроект открыто), откатил.
M>>Селективные — типа list?
R3>Да, а также чекбокс, сомбобокс и т.п.
M>> Имхо, все равно не надо
R3>Ну вот лично мне такая функциональность не помешала бы: а то apply есть, а андо нет. Пример: настройка цветов в виндовсе — настроил, apply, настроил, apply, не понравилось (окно настроект открыто), откатил.
Ну, это решает кнопочка "reset" или общая "undo last changes"
Здравствуйте, Mamut, Вы писали:
M>Ну а это должно быть на совести создателя программы, имхо. Как фреймворк, HTMLLayout должен позволять такое сделать, но не навязывать. ИМХО.
Ну, навязать то, чего не видно — трудно. А вот знать, что это есть — приятно.
M>Хм. Интересная идея — получить snapshot текущего состояния системы.
Если ты о виндовых формах, то в чем проблема? Это элементарно делается, наверно, ещё с 3.11ых. Можно даже отдельным приложением.
А если о фэбформах/страницах, то тут я не силен.
Здравствуйте, Real 3L0, Вы писали:
БИ>> Соответственно эту проблему (привлечение большего внимания) и надо решать R3>Интересно, как по твоему решить эту аппаратную проблему программным методом?
Честно сказать?
Не знаю... Если бы знал уже все давно пользовались бы. Держать при себе не стал бы...
Но думать-то над этой проблемой мне никто не мешает...
Кстати сказать, не знаю как эту проблему решить кардинально... Но! Придумано куча, на мой взгляд, более правильных способов уменьшения значимости таких проблем.
Пример: Индуктивный пользовательский интерфейс
БИ>>, а не придумывать "костыли" в виде механизма undo/redo. R3>Это не костыль, а механизм исправления ошибок.
Ну если принять за допущение, что человеческие ошибки существуют, то да...
Но я более согласен с мнением автора книги "Дизайн пользовательского интерфейса", о том что ошибок пользователя не существует как таковых. Есть ошибки проектирования систем. И вот когда фантазии проектировщиков не хватает (или просто лень что-либо другое придумывать, или от незнания) появляются на свет такие костыли.
В некоторых задачах без такого механизма действительно не обойдешься. Например, текстовый или графический редактор. Но в формах, где и так все разложено по полям и совершенно ясно какую информацию пользователь может ввести, а какую не может, городить такой достаточно сложный для понимания и использования механизм. На мой взгляд — нонсенс!
M>>Ну а это должно быть на совести создателя программы, имхо. Как фреймворк, HTMLLayout должен позволять такое сделать, но не навязывать. ИМХО.
R3>Ну, навязать то, чего не видно — трудно. А вот знать, что это есть — приятно.
M>>Хм. Интересная идея — получить snapshot текущего состояния системы.
R3>Если ты о виндовых формах, то в чем проблема? Это элементарно делается, наверно, ещё с 3.11ых. Можно даже отдельным приложением.
Ээээ....
R3>А если о фэбформах/страницах, то тут я не силен.
Ну, тут, теоретически, надо DOM созранить, я так полагаю.
Здравствуйте, Mamut, Вы писали:
M>>>Селективные — типа list?
M>Ну, это решает кнопочка "reset" или общая "undo last changes"
Reset он есть (в смысле будет) — его никто не отменял.
Вопрос был немного о другом.
Кстати еще один — гранулярность.
Для <input type="text"> IE считает одним действом все что произошло между focus-in и focus-out.
FF — бъет на более мелкие гранулы.
Да что Вы привязались к этой счет-фактуре? Я, между прочим, тоже в основном работаю на ниве автоматизации бухгалтерской/управленческой деятельности. И смею Вас уверить, что счет-фактура не самый сложный документ... И многие бухгалтеры нормально воспринимают перемены в организации интерфейса. А то что есть часть (довольно небольшая часть) кричаших, это при любом внедрении новых технологий есть недовольные. Я бы назвал это нежеланием перемен вообще.
CS>Кстати еще один — гранулярность. CS>Для <input type="text"> IE считает одним действом все что произошло между focus-in и focus-out. CS>FF — бъет на более мелкие гранулы.
CS>Как правильно?
Не знаю, как правильно , но удобней с более мелкими гранулами. то есть знаешь, что ткнешь туда и можешь при помощи Ctrl+z вернуться в то место, которое сам захочешь. Кстати, Опера тоже дробит на гранулы
Здравствуйте, Mamut, Вы писали:
R3>>Если ты о виндовых формах, то в чем проблема? Это элементарно делается, наверно, ещё с 3.11ых. Можно даже отдельным приложением.
M>Ээээ....
Находим окно, находим элементы окна, записываем их состояние ...
Или я плохо знаю WinAPI?
R3>>>Если ты о виндовых формах, то в чем проблема? Это элементарно делается, наверно, ещё с 3.11ых. Можно даже отдельным приложением.
M>>Ээээ....
R3>Находим окно, находим элементы окна, записываем их состояние ... R3>Или я плохо знаю WinAPI?
Тьфу блин, EnumChildWindows, GetWindowText и так далее А я-то думал, что-то такое, навороченное
M>>Имхо, надо оставить default behaviour такой, как в браузерах — undo/redo только в пределах input/textarea/htmlarea. Если понадобится хитрая функциональность, требующая undo/redo пол всей форме, то пусть юзер сам ее и имплементирует. Потому что ни один элемент на форме, кроме текстовых, не требует, в принципе, undo/redo.
CS>Наверное ты прав. Тем более в свете <htmlarea> будет грустно если в процесс откакта будет встревать нечто еще.
) текущего состояния системы. В целом, undo по состоянию прочих объектов уже ведь сейчас можно легко имплементировать, как я понимаю, достаточно сохранить DOM документа. Ну или ту часть, которая изменяется. То есть — оставить на совесть разработчика. А вот undo в тексте — это да
