Ограничения множественной отмены

Реакцией на минусы одиночной отмены было создание многоуровне' вой реализации той же самой модифицирующей отмены. Программа сохраняет каждое действие пользователя. При многократном обраще' нии к функции отмены действия отменяются в порядке, обратном по' рядку их выполнения. В предыдущем сценарии с шестью абзацами текста, имея подобную функцию, пользователь может восстановить удаленное слово при первом вызове отмены и шесть удаленных абза' цев при втором. Необходимость повторного удаления одного слова яв' ляется небольшой платой за возможность восстановить шесть ценных абзацев. Интерфейсный налог в виде необходимости заново удалить одно слово практически незаметен и не принимается во внимание, как не принимается во внимание стоимость вызова машины скорой помо' щи: кто будет подсчитывать такие мелочи, когда речь идет о человече'

ской жизни? Однако факт остается фактом: механизм отмены постро' ен на ошибочной модели, и при иных обстоятельствах отмена в стро' гом порядке «последним вошел, первым вышел» может привести к то' му, что лечение принесет столько же страданий, сколько сама болезнь.

Вернемся к нашему пользователю, удалившему шесть абзацев. Пред' положим, что затем он открыл другой документ и выполнил в нем гло' бальный поиск с заменой. Чтобы вернуть на место недостающие шесть абзацев, пользователь должен будет вначале отменить довольно слож' ную операцию глобального поиска с заменой. На этот раз «вмешав' шаяся» операция не столь незначительна, как удаление одного слова. Она потребовала сил и времени, и ее отмена, очевидно, является не' приятной дополнительной нагрузкой. Было бы очень удобно, если бы пользователь мог выбирать, какую операцию из очереди следует отме' нить. Это позволило бы оставить нетронутыми промежуточные без' ошибочные операции.

Проблемы модели множественной отмены

Проблемы, свойственные множественной отмене, кроются не в ее пове' дении, а в ее модели представления. Большинство механизмов отмены спроектированы в жестокой функциональной манере. Они помнят, ка' кие действия пользователь выполнял шаг за шагом, и разбивают их на отдельные функции. В лучших традициях модели представления, осно' ванной на модели реализации, системы отмены пытаются отразить ло' гику кода и заложенные в продукт структуры данных вместо того, что' бы следовать целям пользователей. Каждый щелчок по кнопке Отмена обращает действие размером ровно в одну функцию. Отмена, реализо' ванная по этому принципу, является подходящей ментальной моделью для устранения большинства простых проблем, связанных с ошибками пользователя при вводе. Пользователи замечают ошибки сразу и сразу же их исправляют – как правило, не позже, чем через два'три дейст' вия. Но когда проблема становится более сложной, модель модифици' рующей множественной отмены перестает хорошо масштабироваться.

Недостатки стека

Когда пользователь оказывается в логическом тупике (а не просто оши' бается при вводе данных), он нередко делает несколько шагов в неиз' вестность, прежде чем осознает, что заблудился и ему необходима ко' манда спасателей. К этому моменту он, возможно, уже выполнил це' лый ряд тесно связанных функций, из которых лишь часть требует от' мены. Он, скорее всего, захочет отменить действия выборочно, не обязательно в строго обратном порядке. Что, если пользователь введет какой'то текст, отредактирует его, в затем решит отменить ввод части текста, но не действия по редактированию? Такую операцию нелегко объяснить и реализовать. Нил Рубенкинг (Neil Rubenking) привел вот такой фатальный пример: предположим, пользователь выполнил в тек' сте глобальную замену слова «шницель» на слово «котлета», а затем

глобально же заменил «кот» на «собака». Если попросить программу отменить первое действие без отмены второго, сможет ли она коррект' но обработать вхождения слова «собакалета»?1

В этой запутанной ситуации упрощенное представление функции отме' ны в виде одного линейного стека не столь уместно, как в более триви' альных случаях. Возможно, пользователь захочет изучить список своих действий и выбрать те, которые подлежат отмене (не обязательно иду' щие подряд), оставив остальные нетронутыми. Такой подход потребует реализации поясняющей отмены с более ясным представлением дейст' вий пользователя, нежели принято при реализации множественной от' мены или отмены вслепую. Кроме того, в таком представлении должны быть в достаточной степени развиты средства выбора элементов. Еще бо' лее трудной задачей является представление операции в списке таким образом, чтобы пользователь ясно понимал, что именно он отменяет.

Повтор

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

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

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