Monit JavaScript, potwierdzenie i ostrzeżenie uważane za „staromodne” [zamknięte]

Ostatnio opracowuję internetowy system zarządzania siłownią. Ich poprzednia aplikacja została opracowana w języku Visual Basic. W nowej aplikacji wszystkie skrypty front-end korzystają z jQuery, na serwerze działają PHP i MySQL ... no wiesz, typowy stos oparty na el-Tanieo na Linuksie.

W każdym razie zastanawiałem się, dlaczego okna dialogowe monitowania, potwierdzania i alertów JavaScript są obecnie tak niewykorzystane. Istnieje wiele wtyczek jQuery do modalnych okien i komunikatów ostrzegawczych, które próbują naśladować coś, co już oferuje język, a każda przeglądarka jest zmuszona do prawidłowej obsługi.

Korzystanie z rozwiązań wykonanych ręcznie lub opartych na wtyczkach jest odpowiednie w przypadku złożonych formularzy i specjalnych potrzeb, ale jeśli musisz tylko poprosić o jedną wartość lub potwierdzić usunięcie rekordu, dlaczego miałbyś dodawać taki narzut do swojej aplikacji internetowej? Ponadto systemy iOS i Android oferują ładnie dostosowane okna dialogowe wiadomości, gdy używasz monitu, potwierdzenia i alertu.

1. UX: skrzynki wiadomości są w większości złe

Pola powiadomień są złe we wszystkich przypadkach z punktu widzenia UX. W aplikacjach komputerowych. W aplikacjach internetowych jako alerty lub wbudowane komunikaty JavaScript. Wszędzie.

Możesz przeczytać About Face 3 autorstwa Alana Coopera¹, jeśli chcesz wiedzieć, dlaczego; bardzo dobrze wyjaśnia, w jaki sposób zakłóca to przepływ pracy i denerwuje użytkownika, i jak prawie każde okno alarmowe, które istnieje w obecnym oprogramowaniu, jest głęboko błędne . Na stronie 542 „Okno dialogowe, w którym zawołał„ Wilk! ””, Wyjaśnia, że ​​skrzynki alarmowe są rutynowo usuwane, więc ich model jest całkowicie zepsuty. Na stronie 543 książki wymieniono trzy główne zasady projektowania:

• Nie pytaj.
• Spraw, aby wszystkie działania były odwracalne.
• Przekaż niemodalne informacje zwrotne, aby pomóc użytkownikom uniknąć błędów.

Następnie autorzy mówią nam, jak zastąpić pola powiadomień odpowiednim podejściem projektowym.

Monitowane wiadomości są nieco inne. Mimo to pogarszają wrażenia użytkownika z Twojej aplikacji. Jeśli chcesz, aby użytkownik coś wpisał, zastanów się nad użyciem pola tekstowego lub obszaru tekstowego, w razie potrzeby udekoruj go JavaScript. Nie bądź leniwy, zapewnij bogaty interfejs w erze aplikacji obsługujących RIA i AJAX ; we wszystkich przypadkach, jeśli JavaScript jest wyłączony, monit nie zostanie wyświetlony.

Na stronach internetowych zarówno ostrzeżenia, jak i monity są w większości denerwujące. Kilka przykładów:

1. Niektóre fora pozwalają tworzyć listy, nieskończenie pytając o elementy listy. Oznacza to, że podczas tworzenia listy nie można korzystać z samej strony, w tym z funkcji kopiuj-wklej. Masz również jedno małe pole. Co z długim tekstem? A co z pogrubieniem i kursywą?

2. „Jeśli będziesz kontynuować, zdjęcie zostanie definitywnie usunięte z Twojego profilu. Jesteś pewien?” . Oczywiście, że jestem pewien! Czy w innym przypadku kliknę „Usuń zdjęcie z mojego profilu”? Dlaczego twoja aplikacja internetowa jest tak głupia? W rzeczywistości aplikacje Google, takie jak Gmail, pokazują prawidłowe podejście. Możesz usuwać, usuwać i niszczyć, co chcesz, a gdy to zrobisz, aplikacja wyświetli mały link „Cofnij”.

3. „Czy chcesz wziąć udział w naszej największej ankiecie?” . Cóż, właściwie byłem tam, aby odwiedzić twoją stronę, ale ponieważ przeszkadzasz mi irytującymi wiadomościami, wolałbym iść gdzie indziej.

4. „Kliknięcie prawym przyciskiem myszy jest wyłączone na tej stronie w celu ochrony zdjęć chronionych prawem autorskim” . Właściwie kliknąłem prawym przyciskiem myszy, aby zmienić język sprawdzania pisowni przed wysłaniem komentarza. Jasne, wyślę to bez sprawdzania pisowni.

Wniosek: z punktu widzenia doświadczenia użytkownika aplikacje błędnie korzystają z okien komunikatów.

Ale poczekaj! Wiele witryn o niskiej jakości zastępuje irytujące skrzynki alarmowe irytującymi wiadomościami JQuery półprzezroczystym tłem, które pokrywa całą stronę. Wady pozostają.

Są też inne powody, dla których nie należy używać skrzynek wiadomości w aplikacjach internetowych:

2. Projekt: skrzynki alarmowe mają swój własny projekt

W ogóle nie można zaprojektować pola alertu. Nie możesz zmienić jego koloru, rozmiaru, czcionki. To sprawia, że ​​jest to jeszcze bardziej denerwujące dla użytkownika: pracujesz z aplikacją internetową, a Twój przepływ pracy jest przerywany przez komunikat, który wydaje się pochodzić znikąd i nawet nie pasuje do wizualnego aspektu aplikacji. Nie licząc, że język przycisków odpowiada również językowi systemu operacyjnego / przeglądarki, a nie aplikacji internetowej.

Dla projektantów komunikaty JavaScript są znacznie potężniejsze niż pola ostrzeżeń.

Są również znacznie obszerniejsze. Możesz dodać pogrubienie i kursywę, możesz wybrać własne przyciski (a co z: „Przepraszamy, ale hasło jest nieprawidłowe. [Zresetuj moje hasło] [Spróbuj ponownie] [Anuluj]”?) ².

3. JavaScript: przepływ aplikacji zostaje zatrzymany

Gdy wyświetla się okno ostrzeżenia, JavaScript przestaje działać, dopóki użytkownik nie kliknie. Na stronie internetowej może być w porządku. W przypadku aplikacji internetowej często staje się to problemem.

4. Sandbox: nie zmuszaj użytkownika do ponownego uruchomienia komputera

Pamiętasz kiepskie strony internetowe, które pokazują nieskończoną liczbę skrzynek wiadomości ? Jedynym sposobem dla użytkowników bez wystarczającego zaplecza technicznego, aby móc kontynuować pracę, było zrestartowanie komputera. To prowadzi nas do problemu: pola powiadomień są poza zakresem witryny lub aplikacji internetowej. Nie masz uprawnień, aby uniemożliwić użytkownikowi dostęp do innych kart przeglądarki³.

Ten sam problem zmusił przeglądarki do rozwiązania go na różne sposoby. Na przykład Firefox zezwala na dostęp do innych kart podczas wyświetlania ostrzeżenia na karcie. Z drugiej strony Chrome pozwala sprawdzić, czy nie chcesz już otrzymywać żadnych alertów ze strony, ale nadal blokuje dostęp do innych kart.

Podczas gdy Firefox jest całkowicie poprawny, Chrome można skrytykować (ponieważ nadal blokuje każdą kartę) i powoduje problem: co, jeśli użytkownik był poważnie zirytowany przez kilka okien komunikatów wysłanych przez Twoją aplikację i sprawdził skrzynkę, a następnie próbowałeś pokazać coś naprawdę ważnego? Racja, użytkownik nigdy go nie zobaczy.

Fakt pozostaje ten sam, większość użytkowników będzie zirytowana oknami ostrzegawczymi, więc nadal nie są zbyt przyjaźni dla użytkowników i mogą poważnie zablokować użytkownika bez wystarczającego zaplecza technicznego. Wbudowane wiadomości JavaScript mogą blokować stronę, ale nie samą przeglądarkę. Ponieważ model aplikacji internetowej jest rodzajem piaskownicy, w której nie można na przykład uzyskać dostępu do klawiatury użytkownika lub zrestartować komputera, odczytać plików z dysku twardego lub przejść do trybu pełnoekranowego lub użyć dwóch monitorów, pola ostrzeżeń z efektem blokowania poważnie się psują model piaskownicy .

Wreszcie, co jeśli użytkownik był na innej karcie, gdy aplikacja zdecydowała się wyświetlić pole alertu? Co jeśli użytkownik zrobił coś ważnego i nie chce teraz wchodzić w interakcje z Twoją aplikacją?

^{¹ Informacje o Face 3, The Essentials of Interaction Design , Alan Cooper, Robert Reimann i David Cronin, ISBN 978-0-470-08411-3; Rozdział 25: Błędy, alerty i potwierdzenia.}

^{² To tylko przykład. Nie rób tego w aplikacjach internetowych, ponieważ to naprawdę zły wybór projektu.}

^{³ Jeśli chcesz porównać ze światem aplikacji komputerowych, wbudowany komunikat JavaScript jest jak okno komunikatu aplikacji komputerowej. Z drugiej strony pole ostrzeżenia w przeglądarce przypomina okno pojawiające się znikąd, ustawione jako najwyższe, na nieprzezroczystym tle pełnoekranowym, które blokuje dostęp do dowolnej innej aplikacji komputerowej. Każda aplikacja, która zdecyduje się to zrobić raz na moim komputerze, zostanie natychmiast usunięta i na zawsze.}

Konkluzja: Domyślne okna dialogowe monitów, potwierdzeń i alertów odpowiadają stylowi przeglądarki, a nie stylowi witryny. Większość osób korzystających z interfejsu użytkownika chce, aby wszystkie okna dialogowe były przesyłane z interfejsem użytkownika ich witryny. Używają okien modalnych do prezentowania wiadomości i zbierania danych przy użyciu tych samych czcionek i kolorów, co interfejs użytkownika witryny, a nie domyślnej szarości i błękitu w MSIE lub FF.

Dodajesz koszty ogólne tylko wtedy, gdy nie potrzebujesz fantazyjnych okien dialogowych w innym miejscu, co prawdopodobnie robisz. W tym momencie nie ma większego znaczenia, czy funkcjonalność jest zawarta jako część przeglądarki, czy jako część używanego frameworka, a także możesz zachować spójność wszystkich wyskakujących okienek.

Chociaż możesz wiele zrobić z javascript i bez frameworków, pamiętam, jak to było rozwijać się w javascript przed udostępnieniem frameworków i nie chciałbym do niego wracać.

Ponieważ przeglądarki nie radzą sobie z nimi zbyt dobrze . Jak pewnie zauważyłeś, są to zazwyczaj modalne okna dialogowe, które nie tylko uniemożliwiają użytkownikom przenoszenie i zmianę rozmiaru przeglądarki, ale także uniemożliwiają dostęp do innych kart, co jest bardzo denerwujące.

W przypadku okien dialogowych, takich jak potwierdzanie i modyfikacja, nadal uważam, że przeglądarka powinna wymuszać zachowanie, aw najnowszej przeglądarce Firefox widać, że rozwiązały problem, o którym wspomniałem powyżej. Używają one w alertach stron o zasięgu do bieżącej strony.

Dlatego sugeruję, aby zastąpić zachowanie alertów, aby wszystkie przeglądarki mogły obsługiwać (przynajmniej alarmy) bardziej elegancko.

Kilka podsumowanych powodów:

• Jest to standardowy interfejs API, a programiści mogą dowiedzieć się, co próbujesz zrobić.
• Jest bardziej przyjazny dla użytkownika i wygląda lepiej.
• Obsługa platformy, witryny mobilne mogą wymagać natywnego interfejsu API.