Подсказки, подтверждения и предупреждения JavaScript считаются «старомодными» [закрыто]

В последнее время я занимаюсь разработкой веб-системы управления тренажерным залом. Их предыдущее приложение было разработано в Visual Basic. Для нового приложения все сценарии внешнего интерфейса используют jQuery, сервер работает под управлением PHP и MySQL ... вы знаете, типичный стек на основе el-cheapo linux.

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

Использование решений, созданных вручную или на основе плагинов, хорошо для сложных форм и особых потребностей, но если вам просто нужно запросить одно значение или подтвердить удаление записи, зачем вам добавлять такие издержки в ваше веб-приложение? Кроме того, iOS и Android предлагают красиво адаптированные диалоги сообщений, когда вы используете подсказки, подтверждения и оповещения.

1. UX: окна сообщений в основном злые

Оповещения плохие во всех случаях с точки зрения UX. В настольных приложениях. В веб-приложениях в виде предупреждений или встроенных сообщений JavaScript. Где угодно.

Вы можете прочитать About Face 3 от Alan Cooper¹, ​​если хотите знать почему; он очень хорошо объясняет, как это прерывает рабочий процесс и раздражает пользователя, и как почти каждый блок предупреждений, существующий в текущем программном обеспечении, глубоко неверен . На странице 542 «Диалог, который закричал« Волк! »» Объясняется, что блоки оповещений регулярно закрываются, поэтому их модель полностью нарушена. На странице 543 книги перечислены три основных принципа дизайна:

• Делай, не спрашивай.
• Сделайте все действия обратимыми.
• Обеспечьте немодальную обратную связь, чтобы помочь пользователям избежать ошибок.

Затем авторы рассказывают нам, как заменить блоки оповещений правильным подходом к проектированию.

Быстрые сообщения немного отличаются. И все же они нарушают пользовательский опыт вашего приложения. Если вы хотите, чтобы пользователь что-то ввел, рассмотрите возможность использования текстового поля или текстовой области, при необходимости, украшая это с помощью JavaScript. Не ленитесь, предоставьте богатый интерфейс в эпоху приложений с поддержкой RIA и AJAX ; во всех случаях, если JavaScript отключен, ваша подсказка не будет отображаться.

На веб-страницах как окна предупреждений, так и приглашения в основном раздражают. Несколько примеров:

1. Некоторые форумы позволяют создавать списки, бесконечно запрашивая элементы списка. Это означает, что при создании списка вы не можете использовать саму страницу, включая копирование-вставку. У вас также есть одно крошечное поле. Как насчет длинного текста? Как насчет жирного и курсива?

2. «Если вы продолжите, фотография будет окончательно удалена из вашего профиля. Вы уверены?» , Конечно я уверен! Могу ли я нажать «Удалить фотографию из моего профиля» в противном случае? Почему ваше веб-приложение полагает, что я такой глупый? Собственно, приложения Google как GMail показывают правильный подход. Вы можете удалять, удалять, уничтожать все, что захотите, и при этом приложение отображает небольшую ссылку «Отменить».

3. "Вы хотите принять наш самый большой опрос?" , Ну, вообще-то, я был там, чтобы посетить твой сайт, но так как ты беспокоишь меня своими раздражающими сообщениями, я бы предпочел пойти куда-нибудь еще.

4. «Правый клик отключен на этом сайте для защиты защищенных авторским правом фотографий» . Ну, на самом деле я щелкнул правой кнопкой мыши, чтобы изменить язык проверки орфографии перед отправкой моего комментария. Конечно, я отправлю это без проверки правописания.

Вывод: с точки зрения пользовательского опыта, приложения в большинстве случаев неправильно используют окна сообщений.

Но ждать! Многие некачественные веб-сайты заменяют раздражающие окна предупреждений раздражающими сообщениями JQuery с полупрозрачным фоном, который покрывает всю страницу. Так что недостатки остаются.

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

2. Дизайн: окна оповещений имеют свой дизайн

Вы не можете создать окно оповещения вообще. Вы не можете изменить его цвет, размер, шрифт. Это делает его еще более раздражающим для пользователя: вы работали с веб-приложением, и ваш рабочий процесс прерывается сообщением, которое, кажется, приходит из ниоткуда и даже не соответствует визуальному аспекту приложения. Не считая того, что язык кнопок также соответствует языку ОС / браузера, а не веб-приложения.

Для дизайнеров сообщения JavaScript намного мощнее, чем окна предупреждений.

Они также намного более обширны. Вы можете добавить жирный и курсив, вы можете выбрать свои собственные кнопки (как насчет: «Мы приносим свои извинения, но введенный вами пароль недействителен. [Сбросить мой пароль] [Попробуйте другой] [Отменить]»?) ².

3. JavaScript: поток приложений останавливается

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

4. Песочница: не заставляйте пользователя перезагружать свой компьютер

Помните дрянные сайты, которые показывают бесконечное количество окон сообщений ? Единственный способ, позволяющий пользователям, не имеющим достаточных технических знаний, продолжать работу, - это перезагрузить компьютер. Это приводит нас к проблеме: окна предупреждений выходят за рамки веб-сайта или веб-приложения. Вы не авторизованы, чтобы запретить пользователю доступ к другим вкладкам браузера³.

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

Хотя подход Firefox совершенно верен, подход Chrome можно подвергнуть критике (поскольку он по-прежнему блокирует все вкладки) и вызывает проблему: что, если пользователь был сильно раздражен несколькими окнами сообщений, выпущенными вашим приложением, и проверил дело, а затем вы пытался показать что-то действительно важное? Правильно, пользователь никогда его не увидит.

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

И последнее, но не менее важное: что если пользователь был на другой вкладке, когда ваше приложение решило показать окно предупреждения? Что если пользователь делал что-то важное и не хочет сейчас взаимодействовать с вашим приложением?

^{¹ О лице 3, Основы проектирования взаимодействий , Алан Купер, Роберт Рейманн и Дэвид Кронин, ISBN 978-0-470-08411-3; Глава 25. Ошибки, оповещения и подтверждения.}

^{² Это всего лишь пример. Пожалуйста, не делайте этого в своих веб-приложениях, так как это действительно плохой выбор дизайна.}

^{³ Если вы хотите сравнить с миром настольных приложений, встроенное сообщение JavaScript похоже на окно сообщения настольного приложения. Окно предупреждения в браузере, с другой стороны, похоже на окно, появляющееся из ниоткуда, установленное как самое верхнее, на полноэкранном непрозрачном фоне, которое блокирует вам доступ к любому другому настольному приложению. Любое приложение, которое решит сделать это один раз на моем компьютере, будет удалено немедленно и навсегда.}

Итог: диалоговые окна по умолчанию для подтверждения, подтверждения и предупреждения соответствуют стилю вашего браузера, а не стилю вашего сайта. Большинство пользователей пользовательского интерфейса хотят, чтобы все диалоговые окна совпадали с пользовательским интерфейсом их сайта. Они используют модальные окна для представления сообщений и сбора данных, используя те же шрифты и цвета, что и пользовательский интерфейс сайта, а не серые и синие цвета по умолчанию MSIE или FF.

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

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

Потому что браузеры не очень хорошо с ними справляются . Как вы, возможно, заметили, они обычно являются модальными диалоговыми окнами и не только запрещают пользователям перемещать и изменять размеры своих браузеров, но также предотвращают доступ к другим вкладкам, что очень раздражает.

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

Поэтому я предлагаю вам переопределить поведение оповещений, чтобы все браузеры могли обрабатывать (по крайней мере, оповещения) более элегантно.

Несколько обобщенных причин:

• Это стандартный API, и разработчики могут понять, что вы пытаетесь сделать.
• Это более удобный и выглядит лучше.
• Поддержка платформы, мобильным сайтам может потребоваться собственный API.