Підказки, підтвердження та попередження JavaScript вважаються "старомодними" [закрито]


21

Останнім часом я розробляв веб-систему управління спортзалом. Їх попереднє додаток було розроблено в Visual Basic. У новому додатку всі сценарії сценаріїв використовуються jQuery, сервер працює на PHP & MySQL ... ти знаєш, типовий стек на базі el-cheapo linux.

У будь-якому разі, мені було цікаво, чому діалогове вікно швидкого підтвердження, підтвердження та попередження JavaScript настільки не використовується в даний час. Існує багато плагінів jQuery для модальних вікон та попереджувальних повідомлень, які намагаються імітувати те, що мова вже пропонує, і кожен браузер змушений належним чином підтримувати.

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


7
"El cheapo?" Дійсно? Хіба це не трохи пристрасне?
asthasr

1
Я збентежений; спочатку ви говорите, що додаток було розроблено в Visual Basic, потім ви кажете, що сервер працює на PHP. так?
поштовх

@jhocking: схоже, він каже, що стара система була настільним додатком, написаним на VB, а нова (та, яку він пише) написана зі стеком LAMP.
Йорданія

Здається, що їх попереднє додаток було написано в vb, він наразі робить передній веб-кінець для цього.
GrandmasterB

Відповіді:


56

1. UX: скриньки повідомлень в основному злі

Поле сповіщень погано у всіх випадках з точки зору UX. У настільних додатках. У веб-додатках як сповіщення або вбудовані повідомлення JavaScript. Скрізь.

Ви можете прочитати About Face 3 від Алана Купера, якщо хочете дізнатися, чому; це дуже добре пояснює, як це перериває робочий процес і дратує користувача, і як майже кожне поле попередження, яке існує в поточному програмному забезпеченні, глибоко помиляється . На сторінці 542 "Діалогове вікно, яке крикнуло" Вовк! ", Пояснює, що поля попередження відкидаються регулярно, тому їх модель повністю порушена. На сторінці 543 книги перераховано три основні принципи дизайну:

  • Робіть, не питайте.
  • Зробіть всі дії оборотними.
  • Забезпечуйте безпроблемний зворотний зв'язок, щоб допомогти користувачам уникати помилок.

Потім автори розповідають нам, як замінити вікна оповіщення правильним дизайнерським підходом.

Повідомлення підказок дещо відрізняються. І все-таки вони порушують користувацький досвід вашого додатка. Якщо ви хочете, щоб користувач щось вводив, спробуйте скористатися текстовим полем або текстовою ділянкою, прикрасивши її JavaScript за потреби. Не лінуйтеся, надайте багатий інтерфейс в епоху додатків із підтримкою RIA та AJAX ; у всіх випадках, якщо JavaScript відключений, ваше запит не відображатиметься.

На веб-сторінках як вікна сповіщень, так і запити в основному дратують. Деякі приклади:

  1. Деякі форуми дозволяють вам створювати списки, нескінченно підказуючи елементи списку. Це означає, що під час створення списку ви не можете використовувати саму сторінку, включаючи copy-paste. У вас також є одне крихітне поле. Що з довгим текстом? Що про жирний шрифт та курсив?

  2. "Якщо ви продовжите, фотографія буде остаточно видалена з вашого профілю. Ви впевнені?" . Звичайно, я впевнений! Я б інакше натиснув "Видалити фотографію зі свого профілю"? Чому ваш веб-додаток припускає, що я такий дурний? Насправді програми Google як GMail демонструють правильний підхід. Ви можете видалити, видалити, знищити все, що завгодно, і коли ви це зробите, додаток відображає невелике посилання "Скасувати".

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

  4. "Клацнути правою кнопкою миші на цьому веб-сайті для захисту фотографій, захищених авторським правом" . Ну, насправді я правою кнопкою миші змінив мову перевірки орфографії, перш ніж надсилати коментар. Звичайно, я надішлю його, не перевіряючи написання.

Висновок: з точки зору досвіду користувачів, більшість часу програми невірно використовують вікна повідомлень.

Але зачекайте! Багато веб-сайтів низької якості замінюють дратівливі скриньки попередження дратівливими повідомленнями JQuery напівпрозорим фоном, який охоплює всю сторінку. Тож недоліки залишаються.

Що ж, є й інші причини не використовувати скриньки повідомлень у веб-додатках:

2. Дизайн: сигнальні скриньки мають власний дизайн

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

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

Вони також набагато більш масштабні. Ви можете додати жирний шрифт та курсив, ви можете вибрати власні кнопки (про що: "Ми вибачаємось, але введений вами пароль недійсний. [Скинути мій пароль] [Спробуйте інший] [Скасувати]"?) ².

3. JavaScript: потік додатків зупиняється

Під час відображення вікна оповіщення JavaScript припиняє виконувати, поки користувач не натисне. На веб-сайті це може бути нормально. З веб-додатком це часто стає проблемою.

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

Пам’ятаєте шалених веб-сайтів, на яких показано нескінченну кількість скриньки повідомлень ? Єдиний спосіб, щоб користувачі, які не мали достатнього технічного досвіду, змогли продовжувати працювати, були насправді перезавантажити комп'ютер. Це приводить нас до проблеми: вікна оповіщення виходять за межі веб-сайту чи веб-програми. Ви не маєте права забороняти користувачеві отримувати доступ до інших вкладок браузера³.

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

На знімку екрана відображається вікно попередження з прапорцем "Заборонити цій сторінці створювати додаткові діалоги"

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

Факт залишається тим самим, більшість користувачів буде дратувати поля сповіщень, тому вони все ще не дуже зручні для користувачів і можуть серйозно заблокувати користувача, не маючи достатньо технічного досвіду. Вбудовані повідомлення JavaScript можуть блокувати сторінку, але не сам браузер. Оскільки модель веб-додатків є свого роду пісочницею, де ви не можете, наприклад, отримати доступ до клавіатури користувача або перезавантажити комп’ютер, читати файли з жорсткого диска або переходити на весь екран або використовувати два монітори, вікна оповіщення з ефектом блокування сильно порушують це модель пісочниці .

І останнє, але не менш важливе, що робити, якщо користувач перейшов на іншу вкладку, коли ваша програма вирішила показати поле сповіщення? Що робити, якщо користувач робив щось важливе і не хоче зараз спілкуватися з вашим додатком?


¹ Про Face 3, Основи дизайну взаємодій , Алан Купер, Роберт Рейманн та Девід Кронін, ISBN 978-0-470-08411-3; Глава 25: Помилки, сповіщення та підтвердження.

² Це лише приклад. Будь ласка, не робіть цього у своїх веб-додатках, оскільки це дійсно поганий вибір дизайну.

³ Якщо ви хочете порівняти зі світом настільних додатків, вбудоване повідомлення JavaScript схоже на поле повідомлень настільної програми. З іншого боку, вікно попередження у веб-переглядачі - це як вікно, яке з'являється з нізвідки, встановлене як верхнє, на непрозорому тлі на весь екран, що блокує вам доступ до будь-якої іншої програми для настільних ПК. Будь-яка програма, яка вирішить зробити це один раз на моєму комп’ютері, буде видалена негайно та назавжди.


1
Питання не мало нічого спільного з нескінченними або спам-появами, то чому ви тут це згадуєте? І я не вважаю, що це обов'язково погано, що JS спливаючі вікна є непростими. При правильному використанні (для сповіщення користувача про щось ОСОБЛИВО) вони змушують користувача звертатися до них, перш ніж робити що-небудь інше, що іноді потрібно.
Грем

Це не відповідає на запитання.
CaffGeek

1
"Відображаючи вікно попередження, JavaScript припиняє виконувати, поки користувач не натисне" - це справедливо для а confirm()та prompt(); з alert(), поведінка залежить від браузера (виконання може продовжуватися навіть тоді, коли відображається alar () - обґрунтування "все одно існує лише один вихід").
Пісквор

1
@ Грехем: ти правий для нескінченних спливаючих вікон; Я був поза темою з цього приводу. Я намагався переформулювати це краще. Щодо нагадування про щось важливе, див. Четвертий пункт моєї відповіді: так, ви можете зупинити все до того, як користувач підтвердить дію, але це не дозволяє вам блокувати кожну вкладку браузера, оскільки інші вкладки не належать до вашого веб-додатку.
Арсеній Муренко

1
@BornToCode: альтернативи немає. Як тільки ви показуєте фотографії на екрані користувача, немає можливості захистити їх від копіювання. Щодо вашого другого питання, ви повинні бути більш конкретними. Спробуйте ux.se .
Арсеній Муренко

3

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


2

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

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


1

Тому що браузери не дуже добре поводяться з ними . Як ви, можливо, зауважили, що вони зазвичай є модальними діалогами, і не лише перешкоджають переміщенню та зміні розміру веб-переглядачів, але також запобігають доступу до інших вкладок, що дуже дратує.

Для таких діалогів, як підтвердження та зміни, я все ще думаю, що браузер повинен виконувати поведінку, а для останнього браузера Firefox ви бачите, що вони виправили проблему, про яку я згадував вище. Вони використовуються у попередженнях сторінок, які відносяться до поточної сторінки.

Тому я пропоную вам переосмислити поведінку сповіщень, щоб усі веб-переглядачі могли опрацювати (принаймні сповіщення) більш елегантно.

Кілька узагальнених причин:

  • Це стандартний API, і розробники можуть зрозуміти, що ви намагаєтеся зробити.
  • Це більш зручно для користувачів і виглядає краще.
  • Підтримка платформи, мобільні сайти, можливо, потребуватимуть нативного API.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.