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:
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ą?
„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”.
„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.
„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.