Pull to refresh

Comments 11

Плюс 100 этой публикации. Я как пользователь и одновременно программист всегда бываю вдвойне в ступоре от подобных сообщений. Первый ступор от того, что как пользователь я понятия не имею, как такую проблему решить. Пятиминутный квест оформления заказа превращается в многодневный квест бодания с техподдержкой. Второй ступор от того, что как программист я знаю: не так уж и трудно в месте возникновения ошибки собрать побольше сведений о ней и донести до пользователя, как ему жить с этой ошибкой дальше. Это предельно важно! Только программист знает, что именно в недрах его программы стряслось, и какими обходными путями можно попробовать эту ошибку обойти.

Ну и диагностику неплохо бы собирать, чтобы, если уж пользователь обратился в техподдержку, то его не посылали бы на попробовать сделать то же самое в другом браузере, а смогли сходу выдать внятный ответ.

Просто не так давно натыкался на такую ошибку при оформлении заказа в одном крупном магазине. И заказ-то был уже не первый, и магазин-то солидный — так нет же: «попробуйте повторить позже». Была бы хоть какая альтернатива — сразу молча ушёл бы, и магазин потерял клиента с ежегодными платежами в 10к рублей. Но идти некуда, я потыкался в других браузерах и отправился в техподдержку. Где меня предсказуемо послали обратно в те же самые другие браузеры. И только после того, как я сдерживая мат, вежливо объяснил, что всё это я уже сделал до обращения, и вопросил: а не начать ли программистам уделять больше внимания проблемам пользователей, через несколько дней получил ответ, что ошибка возникала из-за выбранного мной пункта выдачи. Тогда я спокойно выбрал другой пункт выдачи, находящийся от первого в трёхстах метрах, и совершенно без проблем завершил оформление заказа.

Вопрос: вот зачем так трепать нервы покупателям?

Ответ очевиден — проблема с пунктом выдачи неординарная и такого сценария у приложения нет. Соответственно, обаботкой этой ошибки занимается какой-то обработчик внутренних ошибок, а внутренние ошибки никто пользователю показывать не собирается и правильно делает.
Первичный ответ технической поддержки тоже абсолюно верный, так как в 80% проблема решается правильной последовательностью действий или сменой окружения на максимально протестированное.
Не совсем понимаю, что вас не устроило в данной ситуации.

Еще проблема решается парочкой кодеров, брошенных на чтение логов и быстрый фикс ошибки
Меня не устроило то, что кто-то посторонний потратил моё личное время и усилия, хотя я его об этом не просил и не позволял.

Да, я тоже иногда пишу обработчики ошибок, которые выдают пользователю «неизвестная внутренняя ошибка». Но только в том случае, когда пользователю действительно нечего рассказать (ошибка в базе по нештатной причине, например), и только для того, чтобы не показывать ему голую страницу 500. Никакие данные, введённые пользователем, при этом не теряются.

Согласен, что в случае ошибки с пунктом доставки, возможно, никак нельзя было установить причину. Но что-то мне подсказывает, что на самом деле можно. Просто нет такой привычки у программистов. Ну это как в былые времена не было практики подсвечивать поля ввода с ошибкой, а описания ошибок просто вываливались вверху страницы одной кучей после сабмита. И хорошо, если можно было понять, что не так с полем, а то часто получал просто «поле заполнено неправильно». Да ещё пароль с подтверждением очищались, и их перед каждой попыткой сабмита надо было набивать снова и снова.

Верю, что когда-нибудь забота о пользователе шагнёт ещё дальше, и в продуктах повсеместно(!) будут не только подсвечиваться неправильно заполненные поля, но и вообще на каждом шагу будут даваться подсказки, что можно предпринять даже в нештатной ситуации.
А я вот заполнял визовую анкету и на 8 странице кнопка Submit была задизейблена. Что за черт, подумал я и проверил все поля, благо статусы сохранялись. Не тут-то было! Блюститель чистоты анкет все так зашифровал, что я только через два дня разобрался с помощью тревел-менеджера, что в разделе про опыт работы у меня даты работы N пересекались с датами работы N+1.

Вы призываете к лаконичности и сокращению лишнего, но при этом публикация с трудом дочитывается до конца.


Oops! Something went wrong. ©

Недавно в интернет магазине выбирал товар, настраивал фильтры значит под нужды свои (к слову результат поиска не перестраивается автоматически). И вот проверил я фильтр на одном параметре, все ок, дальше накидываю и думаю что в конце применю все фильтры, а нннет, какой то из фильтров не работает(а их было штук 9) и весь поиск просто не работает. Ни ошибки, ни результатов, ничего, как будто и не делал ничего.

В общем не пользуюсь теперь этим интернет магазином, а могли бы что-то да написать)
Отличная статья для тех, кто хочет выпускать классный, качественный продукт. Только вот жаль, что таких желающих крайне мало…
В статье приведены конкретные примеры продуктов конкретных компаний. Уверен, если мы посмотрим на них через пару-тройку месяцев, то увидим, что ничего не изменилось. Увы.
А меня почемуто всегда заставляли скрывать вообще любую информацию об ошибке от пользователя. Даже когда это был исключительно внутренний проект исключительно для сотрудников. Чтото типо «не выносить сор из избы». Потом разумеется ко мне приходили тикеты «у нас чтото сломалось».
Температурный датчик — кровать?
А мне нравится как сделаны ошибки на ютубе:
Картинка
image

Да, здесь не пишет конкретно что сломалось. (Не выносят сор из избы)
Зато есть зашифрованая диагностическая информация, позволяющая поддержке сразу вникнуть в суть.
Sign up to leave a comment.