Home > javascript, интернет, перевод > Функция отмены последнего действия (Undo) – это просто(Вторая часть): Срочные события

Функция отмены последнего действия (Undo) – это просто(Вторая часть): Срочные события

undo.jpgЭто вторая часть серии “Функция отмены – это просто”. Если вы их пропустили, то прочитайте первую часть [ перевод ].

В предыдущий раз рассматривали метод очереди событий, как полностью клиентскую реализацию лёгкой многоуровневой функции отмены. Я упоминал о паре обмолвок: это не работает в многопользовательской среде и не работает в время-зависимых событиях, как отправка email. Я пропустил существенную оговорку, на которой обратил внимание один с моих читателей, Alexander Botero-Lowry: два таба, в которых открыта одна и та же страница, не синхронизируются. Я написал, как это решить с помощью cookies [ перевод ].

На этот раз, давайте взглянем на решение Отмены для срочных действий. В методе очереди событий, мы могли бы подождать, пока событие “onunload” синхронизирует действия пользователя на стороне клиента с серверной стороной. Для срочных действий, таких как отправка email, у нас нет такой роскоши. Хуже всего, что email – это не push-технология. Отправивши раз email по диким трубам Internet, оно уже не может быть не отправленным.* Для несчастных, которые нажали “отправить” и лишь потом осознали, что переслали томное любовное письмо своему боссу, остаётся надеяться на перебои с электроэнергией и спам-фильтры. Учитывая, как часто спам проходит последние мои фильтры, перспективы не столь хороши.

Электронные письма нужно отправлять вскоре после того, как пользователь нажал на “Отправить” и операцию отправки нельзя отменить. Что мы можем сделать?

Для решения данной проблемы мы должны обратится к интерфейсу на основе времени. Как правило, интерфейсы на основе времени не в состоянии быть действительно годным к употреблению, потому что расчёт времени, в действительности, неправильный. Для некоторых людей оно слишком быстро, для других – медленно. Даже ваше собственное восприятие изменений времени основанно на вашей умственной нагрузке. Когда вы о о чём-то сильно думаете, вы не замечаете течение времени: что было слишком медленно прежде, теперь будет слишком быстрым. Старая поговорка: “Время летит, когда вы веселитесь” действительна для пользовательского интерфейса. Хорошим примером недостатка интерфейса на основе времени можно увидеть в наборе текста в мобильных телефонах, но эта тема подождёт до следующей заметки.

Когда посылается письмо, как правило в период “‘о, НЕТ! секунду“— доли секунды после нажатия “отправить” — вы понимаете, что отправили письмо на неправильный адрес. Желание не посылать электронную почту, которую послали час назад, происходит, но с намного меньшей частотой. Таким образом, решение на основе времени, когда пользователь может не послать письмо, имеет смысл только на коротком промежутке времени: back-end может просто отложить посылку письма на 30-60 секунд и, если пользователь захочет отменить отправку на протяжении нормального периода времени, back-end уберёт с очереди email и письмо не отправится.

Теперь, я не особенно счастлив с поддержкой интерфейса на основе времени, но я зажат ограничениями. С одной стороны, отправка электронной почты в реальном мире, действие, которое невозможно отменить. С другой стороны, письма надо отправлять живчиком. Функция отмены для срочных событий не является канонической проблемой и единственное решение, которое я вижу – это компромисс (если кто-то знает другое решение, я весь во внимании!). В целом, многие ситуации, в которой мы, как проектировщики, попадали с непроходимыми препятствиями. Лучшее, что мы можем сделать – разрабатывать системы, которые заботятся о наиболее вероятно использованных случаях, и позволяет пользователям изящно вернуться из наиболее распространенных ошибок. Undo на основе времени не решит всех недостатков отмены отправки письма ( это не будет помогать с ночными электронными письмами, Вы обнаружите, что послали следующим утром), но он будет ловить большинство ошибочно отправленных писем (ошибки типа “‘о, нет!’ секунду!” и вариант “Я-нажал-на-кнопку-случайно”). И это поймает намного больше ошибочных писем, чем банальное оповещение. Оказалось, что Paul Buchheit, создатель Gmail, тоже так думает. Как жаль, что это не было реализовано— это низковисячие фрукты, которые могли бы дать Gmail больший перевес в его превосходстве.

Не так то и много там этого метода. Для реализации его в стиле Ajax, вам просто понадобится mutex и таймер. Когда время истекает (или при переходе со страницы), письмо будет отправлено. Более продвинутый способ предполагает установление флага на сервере наряду с серверным обратным отсчётом. В сложной частью всего этого дело заключается в том, чтобы указать время, оставшееся таким образом, чтобы не запугать пользователей. Например, обратный отсчёт времени вызывает внутреннее чувство паники:

Не хорошее чувство, неправда-ли? Взамен, медленное затухание работает лучше:

Обратный отсчет, который не начинает считать в обратном порядке до последних 10 секунд, мог бы также работать. Это прекрасная задача – разработать механизмы красивого отображения лимита времени для отмены. Поделитесь своими мыслями в разделе комментариев. Бонусы за предложения любого вида!

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

*
Есть определенные решения – хотя и не очень – для этой проблемы. Для примера, письмо может состоять только с одного вложенного рисунка в виде текста. Если картинка хранится на вашем сервере, тогда для отмены отправки email, вы просто удаляете или меняете рисунок. Это эффективно не отправит контент письма (если уже не отправило). Так что кто-то будет знать только то, что вы отправили сообщение (с темой), но не содержание.

Перевод: Undo Made Easy with Ajax (Part 2): Time-Sensitive Actions

  1. No comments yet.
  1. No trackbacks yet.