Comments 28
Сразу же вспоминаются случаи из реальной практики. Прсдставьте, что 3 их 100 заказов будут заканчиваться сканадалами с утрверждениями что сайт выдал информацию о том, что заказ принят и директор сразу же будет начинать искать крайних кого нужно наказать за сложившуюся ситуацию. А если в корпоративной цепочке заказов таких элементов несколько скажем у менеджера есть своя форма, которую также можно не проверять на правильность заполнения а у бухгалтера своя (они ведь тоже хотят быстрых форм), то вероятность «ошибочных заказов» резко возрастет в геометрической прогрессии с 3% до 10% а то и больше. Жизнь компании очень быстро превратится в один нескончаемый ад в попытках выяснить кто в этом всем виноват. В итоге сэкономили по секунде на пяти формах, а потеряли сотни человекочасов на попытки выявить ошибки.
Ну в тексте же как раз говорится, что если для лайка достаточно простого отката кнопки в начальное состояние, то вот для более сложной формы уже может требоваться явное сообщение об ошибке, так что с ощущением «заказ принят» не должны оставаться даже 3%.
И что в тех случаях, где точность информации особенно критична (заказы, связанные с деньгами, как раз могут относиться к таким), лучше вообще без «оптимистичного».
И что в тех случаях, где точность информации особенно критична (заказы, связанные с деньгами, как раз могут относиться к таким), лучше вообще без «оптимистичного».
Если учесть посетителей которые увидели сообщение о принятом заказе и сразу же закрыли браузер подход с позднем учедомлением об ошибке сокртит количество недопонимания посетителей. Но если по хорошему такой способ оправдан только на формах внутри цепочки действий. К примеру если вы заполнили форму заявки и в этот момент вас сразу же перекидывает на форму с просьбой написать отзыв все будет отлично работать. Времени пока человек ознакомится со следующей формой скрипту хватит времнеи получить ответ на запрос предыдущей и маловероятно что человек закроет просьбу не прочитав. В нашем располяжении есть несколько секунд минимум чтобы его предупредить в случае ошибки в заказе.
Хочу уточнить – не «несколько секунд», а МАКСИМУМ 2 (две). Если Ваша форма заказа на сервере обрабатывается в течение более долгого времени, то смотрите соответствующий пункт в Практических правилах (в конце статьи). Более того, если Вы не обрабатываете потенциальные ошибки на клиенте до отправки формы на сервер, то опять таки, оптимистический интерфейс внедрять пока рано. Обо всем этом есть в тексте статьи :)
Вообще-то когда вы настраиваете оплату картами, например, через какой-то банк (Альфа, РБК и т.д.), то у них есть требования к странице оплаты. И документы это страниц на 150, там есть требования по безопасности и дизайну.
Спасибо за комментарий. Совершенно верно – внедрение оптимистичных интерфейсов, в отличие от многих доступных на данный момент техник, требует подключения логики и адекватных размышлений. Это не та техника, которую можно «размазать» по сайту и все улучшится.
По поводу форм заказа, прочтите, пожалуйста, мой последний комментарий к оригинальной статье и все встанет на свои места, я надеюсь. Если нет, то просто-напросто это значит что техника Вам не подходит. И это абсолютно нормально. Вы пишите что это случай из реальной практики, а потом переходите в гипотетическое рассуждение, как мне показалось, но в любом случае, неправильное применение техники и ее контроля еще не означает что техника не работает. Просто она вам не подходит.
По поводу форм заказа, прочтите, пожалуйста, мой последний комментарий к оригинальной статье и все встанет на свои места, я надеюсь. Если нет, то просто-напросто это значит что техника Вам не подходит. И это абсолютно нормально. Вы пишите что это случай из реальной практики, а потом переходите в гипотетическое рассуждение, как мне показалось, но в любом случае, неправильное применение техники и ее контроля еще не означает что техника не работает. Просто она вам не подходит.
Была история, когда при ошибке в форме не выводилось ни одного уведомления, и компания теряла «неправильные» заказы, в которых пустой было поле «комментарий к заказу»…
Статья была бы лучше без иллюстраций, мое настроение ухудшилось :(
«Самым неприятным случаем было бы, если бы он закрыл её даже до того, как запрос отправился на сервер. Но если только пользователь не чрезвычайно ловкий или обладает способностью замедлять время, это вряд ли возможно.»
На мой взгляд, это вполне возможно. У каждого браузера есть ограничение на количество одновременных соединений к одному серверу/домену/прокси (например, обсуждается здесь http://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser). Если лимит одновременных соединений исчерпан (а это вполне может произойти, оптимистичный интерфейс это поощряет), то последующие запросы ожидают, пока не появится вакансия на соединение. Браузеры могут по-разному обрабатывать такую ситуацию, но вероятность закрыть вкладку до того, как запрос отправится на сервер, с учетом ограничений браузера гораздо больше 0.
На мой взгляд, это вполне возможно. У каждого браузера есть ограничение на количество одновременных соединений к одному серверу/домену/прокси (например, обсуждается здесь http://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser). Если лимит одновременных соединений исчерпан (а это вполне может произойти, оптимистичный интерфейс это поощряет), то последующие запросы ожидают, пока не появится вакансия на соединение. Браузеры могут по-разному обрабатывать такую ситуацию, но вероятность закрыть вкладку до того, как запрос отправится на сервер, с учетом ограничений браузера гораздо больше 0.
Вот это интересное замечание. Спасибо. Это действительно возможный сценарий. Но, есть два момента:
1. Количество соединений к одному домену в контексте современного веба выглядит гораздо оптимистичнее – http://www.browserscope.org/?category=network&v=top
2. Если во время работы страницы (не загрузки страницы, когда подгружаются ассеты, а именно уже в процессе) Вам недостаточно 6 одновременных соединений к одному и тому же домену, то проблема кроется не в оптимистическом интерфейсе, а в архитектуре проекта.
Боле того, когда Вы внедряете интерфейс и проводите тестирование, Вы должны проводить его в тех же условиях что и пользователь. В таком случае Вы «отловите» ситуацию с исчерпанием лимита по соединениям на достаточно раннем этапе. Но, я вполне уверен что такая ситуация не случится в проектах написанных не «на коленке».
1. Количество соединений к одному домену в контексте современного веба выглядит гораздо оптимистичнее – http://www.browserscope.org/?category=network&v=top
2. Если во время работы страницы (не загрузки страницы, когда подгружаются ассеты, а именно уже в процессе) Вам недостаточно 6 одновременных соединений к одному и тому же домену, то проблема кроется не в оптимистическом интерфейсе, а в архитектуре проекта.
Боле того, когда Вы внедряете интерфейс и проводите тестирование, Вы должны проводить его в тех же условиях что и пользователь. В таком случае Вы «отловите» ситуацию с исчерпанием лимита по соединениям на достаточно раннем этапе. Но, я вполне уверен что такая ситуация не случится в проектах написанных не «на коленке».
Дело не в каком-то конкретном проекте. Даже в «хорошо написанном проекте» при определенных условиях можно достичь того же эффекта: пользователь работает в нескольких вкладках, «пинг» данных с сервера, высокие сетевые задержки. Дело в самом физическом существовании возможности получить статус об успехе операции, закрыть вкладку/браузер, и при этом даже не отправить запрос на сервер.
Поправьте меня, если такой возможности вообще нет в природе.
Поправьте меня, если такой возможности вообще нет в природе.
Теоретически такая возможность существует. Но тут мы говорим даже не про 1-3%, а скорее про 0.01-0.03% если не меньше. Для того что бы забить все каналы на один хост в браузере так чтобы на еще один запрос «не хватило места» нужно постараться.
Например – загрузить что-то, что нагружет все доступные каналы (минимум 6) и пока эти запросы «держат» сервер, активировать оптимистичный элемент (или отправить запрос каким-то другим способом) и закрыть вкладку до того как освободится хоть один канал (если не успеть, то наш запрос от оптимистичного элемента займет его место). Так что по сути Вы правы – такая возможность существует. Но если мы не рассматриваем момент загрузки страницы и не говорим про проекты написанные ногой, то это маловероятно.
Плюс есть еще одно «но». Все это уже смахивает на преднамеренное желание поломать интерфейс. А это уже совсем не имеет отношения к оптимистичным запросам.
Например – загрузить что-то, что нагружет все доступные каналы (минимум 6) и пока эти запросы «держат» сервер, активировать оптимистичный элемент (или отправить запрос каким-то другим способом) и закрыть вкладку до того как освободится хоть один канал (если не успеть, то наш запрос от оптимистичного элемента займет его место). Так что по сути Вы правы – такая возможность существует. Но если мы не рассматриваем момент загрузки страницы и не говорим про проекты написанные ногой, то это маловероятно.
Плюс есть еще одно «но». Все это уже смахивает на преднамеренное желание поломать интерфейс. А это уже совсем не имеет отношения к оптимистичным запросам.
Для тех же заказов — я при шопинге на Авито имею 10-15 открытых одновременно вкладок — поиск+выбранные + я нажал в одной вкладке добавить в корзину (и сразу закрыть), ушел в другую и сразу нажал на связанные товары (и получил кучу запросов на подгрузку изображений этих товаров). А потом выйду собственно в корзину и не увижу там добавленного и закрытого элемента.
Еще такая ситуация весьма вероятна, если у пользователя плохой интернет (например, мобильный).
понравилась статья Progress Bars vs. Spinners: When to Use Which, рассказывающая, что использовать при различных ответах сервера
Спасибо за ссылку. В прошлом году я тоже писал похожее в контексте «Tolerance Management» – Show Me Your Progress если интересно посмотреть откуда вообще идет идея индикаторов прогресса и психологическое обоснование разных типов
Статья порадовала!
Кстати, а есть ли какая-то информация о том, насколько реализация оптимистичного UI повышает стоимость проекта?
Кстати, а есть ли какая-то информация о том, насколько реализация оптимистичного UI повышает стоимость проекта?
Спасибо за комментарий. Хороший вопрос.
На самом деле, все зависит от того где и как реализуется оптимистичный интерфейс. По своей сути, сам по себе он не сильно влияет на стоимость. Но вот грамотная обработка ошибок может повлиять как в большую, так и в меньшую сторону.
НО, грамотная обработка ошибок нужна вне зависимости от того какие идеи вкладываются в интерфейс изначально. Поэтому по сути, на стоимости грамотно построенного проекта оптимистический интерфейс скорее всего не отразится. Тут нужно еще учитывать что оптимистичный интерфейс может быть интегрирован как к одному единственному элементу на сайте, так и ко всем видам взаимодействий – тут только голову включать и работать.
На самом деле, все зависит от того где и как реализуется оптимистичный интерфейс. По своей сути, сам по себе он не сильно влияет на стоимость. Но вот грамотная обработка ошибок может повлиять как в большую, так и в меньшую сторону.
НО, грамотная обработка ошибок нужна вне зависимости от того какие идеи вкладываются в интерфейс изначально. Поэтому по сути, на стоимости грамотно построенного проекта оптимистический интерфейс скорее всего не отразится. Тут нужно еще учитывать что оптимистичный интерфейс может быть интегрирован как к одному единственному элементу на сайте, так и ко всем видам взаимодействий – тут только голову включать и работать.
Во-первых, обоснование необходимости перезагружать отдельные части страницы слабое, ибо в процессе выполнения может развалиться/измениться масса всего. Во-вторых, можно нажать на кнопку, закрыть страницу и никогда не узнать о проблеме, которая возникла в процессе выполнения, в том числе, что запрос вообще не был отправлен. В этом случае проще идти по пессимистичному сценарию, это принципиально решит все потенциальные проблемы (в том числе и человекозависимые), а больше кнопок пользователь всё равно не успеет понажимать.
Не хочу показаться резким, но налито много воды.
Логическая цепочка не стройная. То что описывает автор — тривиальный случай, большинство элементов активных страниц ведут себя именно так. Величайшая глупость держать открытой базу данных во время сессии — проще пнуть данные одним пакетом.
Чуть посложнее — видео, звук. Если вы не проинформирует меня о процессе — плохо. Если после появления галочки я не увижу фильма — обозлюсь.
Раздутое обсуждение элементарных вещей. То что мы видим сейчас — индикаторы загрузки — это результат естественной эволюции интерфейса.
Логическая цепочка не стройная. То что описывает автор — тривиальный случай, большинство элементов активных страниц ведут себя именно так. Величайшая глупость держать открытой базу данных во время сессии — проще пнуть данные одним пакетом.
Чуть посложнее — видео, звук. Если вы не проинформирует меня о процессе — плохо. Если после появления галочки я не увижу фильма — обозлюсь.
Раздутое обсуждение элементарных вещей. То что мы видим сейчас — индикаторы загрузки — это результат естественной эволюции интерфейса.
Оптимистический интерфейс требует оптимистического интернет-канала. Лично мне не нравится сама концепция: лгать, и выдумывать оправдания, если ложь не сработала. Но поговорим о более общем случае.
Пусть пользователь мобильного интернета сидит на канале с умеренно-уверенным приёмом, лайкает фотки и слушает музыку. Или скачивает игру (одновременно, он же не любит ждать). Он читает ленту, открывает интересные ссылки в новой вкладке, лайкает хорошие, закрывает. Каковы его шансы потерять лайки? (Здесь мог быть поиск по статистике, но с планшета немного некомфортно искать)
Реалистичный интерфейс имеет преимущество: он отражает реальное положение дел. Ответ на лайк идёт десять секунд? Читаем что-то ещё, возвращаемся, проверяем изменение счётчика / другой индикации. На дата-центр упал метеорит? «Извините, что-то пошло не так, наши инженеры уже работают над этим».
Одно дело — стабильный и быстрый интернет в каждый уголок мира. Другое — негативный опыт, который запоминается сильнее. Все любят завернуть, как они любят 100% своих пользователей; но сколько процентов незначительных запросов они готовы проигнорировать? Что сочтут незначительным завтра в свете новых трендов?
Пусть пользователь мобильного интернета сидит на канале с умеренно-уверенным приёмом, лайкает фотки и слушает музыку. Или скачивает игру (одновременно, он же не любит ждать). Он читает ленту, открывает интересные ссылки в новой вкладке, лайкает хорошие, закрывает. Каковы его шансы потерять лайки? (Здесь мог быть поиск по статистике, но с планшета немного некомфортно искать)
Реалистичный интерфейс имеет преимущество: он отражает реальное положение дел. Ответ на лайк идёт десять секунд? Читаем что-то ещё, возвращаемся, проверяем изменение счётчика / другой индикации. На дата-центр упал метеорит? «Извините, что-то пошло не так, наши инженеры уже работают над этим».
Одно дело — стабильный и быстрый интернет в каждый уголок мира. Другое — негативный опыт, который запоминается сильнее. Все любят завернуть, как они любят 100% своих пользователей; но сколько процентов незначительных запросов они готовы проигнорировать? Что сочтут незначительным завтра в свете новых трендов?
Спасибо за комментарий. Да, хоть и еще один на ту же тему что и 25 предыдущих, но все равно спасибо. Значит тема заинтересовала раз потратили время.
Очень жаль что Вы рассматриваете эту концепцию в свете «лгать, и выдумывать оправдания, если ложь не сработала». Это достаточно недальновидно. Если Вы не видите применение техники, это не значит что она не работает. Вы же уже являетесь пользователем этой техники на Facebook, и/или Twitter, и/или еще многих сервисах. То что Вы не знаете о том что являетесь пользователем этой техники не замечая ее говорит только о том, что Вас все устраивает :)
А теперь по существу – если ответ на лайк идет 10 секунда Вы НЕ ИСПОЛЬЗУЕТЕ оптимистичный интерфейс прежде всего. Если задержка связана с временными проблемами, то это частный случай. Если с сервером «временные» проблемы слишком часто, то надо что-то менять и на это время, возможно отключить оптимистичные операции. Не можете отключить временно? Надо что-то менять. На дата-центр упал метеорит? Не поверите, но это случается не так часто и называется «форс-мажор». Он случается еще реже чем ошибки сервера. Если на дата-центр упал метеорит, вся ваша база пошла кувырком! Вы, скорее всего, даже не сможете отобразить вот это вот «Извините…» :) Но если до этого дойдет, с удовольствием подискутирую с Вами на тему «негативного опыта, который запоминается сильнее». Заметьте я не оспариваю это утверждение (потому что так оно и есть), а просто хочу упомянуть что негативный опыт может быть в любом интерфейсе и в любом контексте.
Но по секрету я вам скажу большую тайну, которая многим не столь очевидна – пользовательский интерфейс не предназначен для закрытия дыр в вашей архитектуре. По крайней мере не в широком смысле этого понятия.
Я сам не сторонник ускорения всего что возможно, а только того что необходимо ускорить. Но когда люди на «молоток» говорят «утюг» только потому что не знакомы с молотком и не понимают как его применять – это может вызывать только улыбку :)
Хорошего всем дня и настроения! :)
Очень жаль что Вы рассматриваете эту концепцию в свете «лгать, и выдумывать оправдания, если ложь не сработала». Это достаточно недальновидно. Если Вы не видите применение техники, это не значит что она не работает. Вы же уже являетесь пользователем этой техники на Facebook, и/или Twitter, и/или еще многих сервисах. То что Вы не знаете о том что являетесь пользователем этой техники не замечая ее говорит только о том, что Вас все устраивает :)
А теперь по существу – если ответ на лайк идет 10 секунда Вы НЕ ИСПОЛЬЗУЕТЕ оптимистичный интерфейс прежде всего. Если задержка связана с временными проблемами, то это частный случай. Если с сервером «временные» проблемы слишком часто, то надо что-то менять и на это время, возможно отключить оптимистичные операции. Не можете отключить временно? Надо что-то менять. На дата-центр упал метеорит? Не поверите, но это случается не так часто и называется «форс-мажор». Он случается еще реже чем ошибки сервера. Если на дата-центр упал метеорит, вся ваша база пошла кувырком! Вы, скорее всего, даже не сможете отобразить вот это вот «Извините…» :) Но если до этого дойдет, с удовольствием подискутирую с Вами на тему «негативного опыта, который запоминается сильнее». Заметьте я не оспариваю это утверждение (потому что так оно и есть), а просто хочу упомянуть что негативный опыт может быть в любом интерфейсе и в любом контексте.
Но по секрету я вам скажу большую тайну, которая многим не столь очевидна – пользовательский интерфейс не предназначен для закрытия дыр в вашей архитектуре. По крайней мере не в широком смысле этого понятия.
Я сам не сторонник ускорения всего что возможно, а только того что необходимо ускорить. Но когда люди на «молоток» говорят «утюг» только потому что не знакомы с молотком и не понимают как его применять – это может вызывать только улыбку :)
Хорошего всем дня и настроения! :)
Действительно, ещё один)
Возможно, я старомоден. Я вижу применение техники; если отклик на действие, требующее обработки на стороне сервера, возникает быстрее, чем щелчок мыши достигает уха, это о чём-то да говорит ) Поэтому я стараюсь проверять совершение действия там, где считаю важным, и ограничиваюсь пассивными методами (пауза перед уходом со страницы) там, где не считаю. Если меня что-то устраивает, это не означает, что я считаю это лучшим из возможных вариантов,)
Я говорю не о задержке на сервере, а о сетевой задержке. Живу в лесу, хотя 3G здесь присутствует, так что лаги при заполнении полосы пропускания мне знакомы, как и нестабильная связь в пути. Про инженеров я, конечно, лирически отступил. Но я считаю естественным шаблон с индикацией сетевого запроса. Пусть кнопка станет зелёной, но покажите, что не со всем ещё покончено.
Я помню непроставленные лайки, нестёртые сообщения, неотмеченные уведомления. Возможно, потому, что выполнение запрошенного действия является нормой, сливается с фоном, а невыполнение является событием, пиком, отклонением на этом фоне. Не мной придумано высказывание: «Хорошее забывается, плохое — помнится». В принципе, при стабильной связи время отклика сервера (реалистичный интерфейс) меня вполне устраивает. Если я вижу ответ, я в нём уверен. Если что-то пошло не так, индикация тоже однозначна. Никакого туннелирования якобы полностью выполненного действия обратно в невыполненное через 2 секунды. Я могу рассматривать оптимистичный подход в приложениях, где исходящие запросы сохраняются в некой локальной очереди до обработки сервером; т. о. «пропавшие» запросы будут переотправлены и обработаны.
Что я пытаюсь выразить? При благоприятных условиях (LAN, нормально написанная серверная часть) интерфейс и так будет отзывчивым. При неблагоприятных — оптимистичный интерфейс вынужден играть в Пиноккио. Свой выбор я озвучил ) Для меня не очевидно преимущество подхода, когда ради долей секунды и показной отзывчивости UI жертвуют удобством пользователей в ситуациях, которые для меня не являются сферическими в вакууме; для меня эти проценты не пренебрежительно малы. Для меня это выглядит как пренебрежение N-ным количеством реальных людей. Решением, что для них важно, а что нет.
Активируя контрол, я ожидаю 100% выполнения заданного действия. Моё внимание ведь обратят, если что-то пойдёт не так?Вы держитесь тут, вам здоровья Хорошего настроения! :)
P. S. Пардон, если многословно; тема действительно задевает )
Возможно, я старомоден. Я вижу применение техники; если отклик на действие, требующее обработки на стороне сервера, возникает быстрее, чем щелчок мыши достигает уха, это о чём-то да говорит ) Поэтому я стараюсь проверять совершение действия там, где считаю важным, и ограничиваюсь пассивными методами (пауза перед уходом со страницы) там, где не считаю. Если меня что-то устраивает, это не означает, что я считаю это лучшим из возможных вариантов,)
Я говорю не о задержке на сервере, а о сетевой задержке. Живу в лесу, хотя 3G здесь присутствует, так что лаги при заполнении полосы пропускания мне знакомы, как и нестабильная связь в пути. Про инженеров я, конечно, лирически отступил. Но я считаю естественным шаблон с индикацией сетевого запроса. Пусть кнопка станет зелёной, но покажите, что не со всем ещё покончено.
Я помню непроставленные лайки, нестёртые сообщения, неотмеченные уведомления. Возможно, потому, что выполнение запрошенного действия является нормой, сливается с фоном, а невыполнение является событием, пиком, отклонением на этом фоне. Не мной придумано высказывание: «Хорошее забывается, плохое — помнится». В принципе, при стабильной связи время отклика сервера (реалистичный интерфейс) меня вполне устраивает. Если я вижу ответ, я в нём уверен. Если что-то пошло не так, индикация тоже однозначна. Никакого туннелирования якобы полностью выполненного действия обратно в невыполненное через 2 секунды. Я могу рассматривать оптимистичный подход в приложениях, где исходящие запросы сохраняются в некой локальной очереди до обработки сервером; т. о. «пропавшие» запросы будут переотправлены и обработаны.
Что я пытаюсь выразить? При благоприятных условиях (LAN, нормально написанная серверная часть) интерфейс и так будет отзывчивым. При неблагоприятных — оптимистичный интерфейс вынужден играть в Пиноккио. Свой выбор я озвучил ) Для меня не очевидно преимущество подхода, когда ради долей секунды и показной отзывчивости UI жертвуют удобством пользователей в ситуациях, которые для меня не являются сферическими в вакууме; для меня эти проценты не пренебрежительно малы. Для меня это выглядит как пренебрежение N-ным количеством реальных людей. Решением, что для них важно, а что нет.
Активируя контрол, я ожидаю 100% выполнения заданного действия. Моё внимание ведь обратят, если что-то пойдёт не так?
Twitter сообщает об этом самым ненавязчивым способом из возможных — просто возвращая кнопку в первоначальное состояние.
P. S. Пардон, если многословно; тема действительно задевает )
Sign up to leave a comment.
Правдивая ложь оптимистичных интерфейсов