20.12.2004
Bez przewijania?
Podczas ostatniego spotkania z klientem, dla którego tworzę niewielką aplikację (interfejs webowy), zostałem poproszony o zaprojektowanie poszczególnych stron w taki sposób, aby zminimalizować konieczność przewijania. Argumentem za tym ma być wygoda.
Praca z systemem będzie polegała głównie na wypełnianiu formularzy i drukowaniu pewnych zestawień. Klient uważa, że konieczność przewijania dłuższych stron w celu np. zobaczenia i kliknięcia przycisku “Wyślij” lub wypełnienia dalszych pól formularza:
- spowoduje frustrację i niezadowolenie użytkowników (będzie to męczące)
- zmniejszy efektywność użytkowników (trudności manualne u osób rzadko korzystających z komputera)
Odruchowo uznałem to za jak najbardziej uzasadnione żądanie. Dopiero kilka godzin później zdałem sobie sprawę, że to przecież arbitralna decyzja projektowa, która niekoniecznie ma wielki sens i którą lepiej zweryfikować.
(Użytkownikami systemu będzie kilka osób mało doświadczonych w pracy z komputerami - Internetem w szczególności - oraz kilka osób o całkiem przyzwoitym poziomie umiejętności komputerowych. Ta pierwsza grupa jako niedoświadczona może mieć kłopoty przy intensywnym stosowaniu przewijania, przy czym mam na myśli nie tylko z trudności zauważeniem, ale też problemy czysto manualne.)
Typowe aplikacje okienkowe służące do wprowadzania danych, np. systemy finansowo-księgowe, istotnie dość rzadko wymagają przewijania (co częściowo wynika być może z tradycji lub po prostu trudności z konstrukcją takich przewijanych zbiorów komponentów). Za naturalne uznałem jednak, że skoro aplikacja oparta zostaje o możliwości współczesnych przeglądarek i HTML-a, to razem z całym dobrodziejstwem inwentarza… zamiast zakładek dostajemy dowolnie długie, ale przewijane strony.
Moje pytanie brzmi następująco: jakie są Wasze doświadczenia i spostrzeżenia w kontekście przewijania, jeśli chodzi o używanie stron internetowych przez osoby mało z nimi obeznane?
Z moich skromnych doświadczeń wynika, że przewijanie istotnie nie jest oczywiste i w momencie, gdy na ekranie nie widać właściwe przycisku lub odnośnika, użytkownik często gubi się i ostatnią rzeczą, na którą zwróci uwagę, będzie mało wyróżniający się pasek przy prawej krawędzi ekranu. Dotyczy to nawet biegłych informatyków!
Swego czasu Jakob Nielsen poświęcał temu tematowi całe rubryki Alertboksa, zauważając, że w początkach Sieci internauci w ogóle nie byli skłonni do przewijania stron, wraz z jej rozwojem powoli się do niego przyzwyczajając. Martwi mnie to, bo muszę założyć, że duża część przyszłych użytkowników projektowanego interfejsu należy raczej do grupy osób, o których Nielsen pisał dawno temu…
Ja tam jak zwykle proszę, żeby nie traktować mojej wypowiedzi jako reprezentacyjnej, bo byłaby to straszna pomyłka ;), ale…
Najbardziej przerażająca prawda, która mi się ostatnio objawiła: nie każdy ma rolkę w myszce, a część z tych, którzy rolkę mają, nie korzystają z niej. I tak, dotyczy to nawet biegłych programistów. Znam jednego, który ma rolkę, ale jej nie używa, “bo mu się zepsuła” i radzi sobie bez, bo nie czasu wymienić. Twardziel.
A dlaczego wspominam o rolce? Bo przewijanie www za pomocą rolki jest dużo wygodniejsze (szybsze, bardziej ergonomiczne, bardziej naturalne, bardziej, bardziej…) niż latanie wskaźnikiem myszy po całym ekranie. Przewijanie zawartości okna za pomocą belki i ruchów myszką przy czytaniu tekstu to straszna pomyłka - przewijanie belką ma tylko sens, gdy tekst przeglądamy, a nie czytamy od-deski-do-deski. btw, nadal wydaje mi się, że kluczem do wygodnego interfejsu (btw, słowo “wygodny” jest dużo sensowniejsze od obcojęzycznego “ergonomiczny”) jest minimalizacja czynności (w tym zakresu ruchów myszką), które prowadzą do celu. Tak, tak: uważam nawet, że wygodę GUI można mierzyć właśnie poprzez badanie długości pociągnięć myszką i liczby kliknięć. I wydaje mi się, że taka właśnie analiza jest dużo bardziej bezpośredni sposób mierzy usability niż statyczna analiza wyglądu interfejsu.
Gdy jeszcze byłem młody i piękny to swego czasu programowałem dużo w Delphi. I miałem taką książkę (”Delphi 3″?), w której jeden rozdział poświęcony był tworzeniu aplikacji zgodnych ze specyfikacją “Designed for Microsoft Windows” (albo jakoś tak) - wymienione tam były takie typowe, dobrze ukute zalecenia odnośnie liczby kontrolek (nie za dużo) i ich rozmieszczenia (przejrzyście i zgodnie z resztą Windows) w okienku dialogowym.
W komentarzu do któregoś z Twoich poprzednich wpisów napisałem, że ciekawy jestem wytycznych odnośnie projektowania nie tyle serwisów www, co interfejsów typowo biznesowych aplikacji webowych. Z różnych względów (dłuższa dyskusja) uważam, także jako developer, że coraz więcej aplikacji kiedyś pisanych jako stand-alone będzie tworzonych jako aplikacje webowe. Głównie dlatego, że centralne składowanie aplikacji ma ogromne zalety (przede wszystkim: łatwy update i bezpieczeństwo), poza tym pojawiły się narzędzia, które pozwalają tanio i dobrze tworzyć aplikacje oparte na interfejsie webowym (myślę głównie o ASP.NET 1.1).
Ciekawią mnie nawet nie tyle same wytyczne odnośnie projektowania GUI aplikacji webowych, co różnice w sposobie konstruowaniu interfejsów aplikacji okienkowych i webowych. Funkcjonalność implementowana w aplikacjach webowych, jak już pisałem, będzie coraz bardziej zbliżać się do tego, co oferują okienkowe aplikacje stand-alone. Ciekawi mnie próba zbudowania takich zasad projektowania GUI, które pozwoliłyby stworzyć ładny interfejs dla aplikacji webowej o funkcjonalności Worda, Corela, czy innego kolosa o GUI bardziej skomplikowanym niż kokpit myśliwca F-22. Nie są mi znane sensowne próby stworzenia takich wytycznych, a samowolka kwitnie, ponieważ często choćby formularze rejestracyjne w formie www są tak długie, że odechciewa się ich wypełniać.
Przechodzi mi jednak przez myśl stwierdzenie, że doświadczenia zdobytego przez lata konstruowania aplikacji okienkowych nie można lekceważyć. Jakby nie było zarówno strona www, jak i okno aplikacji wyświetlane są nadal na tym samym ekranie, nie ma więc powodów dla tworzenia różnych standardów projektowania GUI. Naprawdę więc nie tworzenia, a wymuszenia - znacznie sensowniejszy jest standard wypracowany doświadczeniami od standardu narzucającego doświadczenia. Jestem więc jak najbardziej za tym, żeby aplikacje www upodabniać do aplikacji okienkowych, tworzyć kilkuetapowe wizardy, toolbary z ikonkami, itp. Wątpliwość, jaka wydaje mi się istotna, to dostępna wielkość okna i zastąpienie okien dialogowych popupami w aplikacjach www. Bo popupow przecież nikt za bardzo nie lubi. Ale z drugiej strony to nawet dobrze. Naprawdę! Nie wydaje mi się, żeby stosowane standardy projektowania GUI aplikacji okienkowych były optymalnie efektywne. Przede wszystkim nadmiar dostępnych opcji na jednym ekranie oraz “ułatwienie” w postaci możliwości wykonania danej akcji w różny sposób (wybór z menu, ikonka, kliknięcie po skosie, kliknięcie od tyłu z podskokiem…) powoduje, że robi się syf. Obecna prostota GUI aplikacji www jest więc niezłym punktem wyjścia do pójścią nieco inną drogą - przede wszystkim w kierunku uproszczenia GUI i nacisku na przejrzystość. A moment na to jest niezwykle odpowiedni, bo narzędzia wizualne, choćby Visual Studio dla ASP.NET, już pozwalają tworzyć interfejsy www przez zwykłe drag-and-drop kontrolek. Do tej pory GUI aplikacji www było proste, z natury leniwym programistom nie chciało się tworzyć rozbudowanych ekranów. Teraz każdy wrzucając kontrolki bezpośrednio na www będzię mógł zrobić burdel, jaki tylko mu do głowy przyjdzie. Czas więc na standard, najwyższy czas!
P.S. A Nielsen imho znał się na projektowaniu GUI jakieś 5-10 lat temu. Teraz niestety od jego alertboxów i poglądów wieje anachronizmem… i to strasznym. Głównie dlatego, że dla współcześnie młodych ludzi korzystanie z interfejsów komputerowych jest naturalne natomiast Nielsen, a nawet my, widzieliśmy, jak bardzo zmieniało się podejście do projektowania GUI, w szczególności: jaką ewolucję przeszły standardy tworzenia stron www od czasów stron opartych na
i .
Komentarz dłuższy od notki, w dodatku nieodpowiadający na Twoje pytanie, więc…
Nie napisałeś, co to za system, ale większość ludzi stale korzystających z danej aplikacji i jej interfejsu przyzwyczaja się i szuka najkrótszych ścieżek: w przypadku aplikacji typu wpisz-i-raportuj opartych na formularzach używanie myszki zastępowane jest użyciem klawisza TAB. btw, czytałem kiedyś co najmniej kilka felietonów i bardziej formalnych tekstów dotyczących prawidłowego ustawiania tab-order w aplikacjach okienkowych.
W przypadku aplikacji do częstego użytku wewnętrznego można imho projektować GUI bardziej skomplikowane, tzn. mniej czytelne, ale szybsze, z wiekszą liczbą opcji dostępną w jednym kroku. Formularz na dwie strony dla pani Krysi z księgowości, która będzie go wypełniać 5 razy na godzinę każdego dnia - czemu nie? Natomiast GUI dla klientów, czyli osób z zewnątrz korzystających sporadycznie z interfejsu powinno być przede wszystkim czytelne i przejrzyste. I nie powinno straszyć rozbudowanymi formularzami - znacznie lepszym rozwiązaniem byłoby zrobienie kilkuetapowego wizarda (w każdym kroku mały, czytelny formularz).
Ciekawym, co sądzisz. Dobranoc.
Już naprawdę się kładę, ale to zdanie mi się bardzo nie podoba:
Za naturalne uznałem jednak, że skoro aplikacja oparta zostaje o możliwości współczesnych przeglądarek i HTML-a, to razem z całym dobrodziejstwem inwentarza? zamiast zakładek dostajemy dowolnie długie, ale przewijane strony.Nie myśl tak, no ja Cię proszę! :)
Oj, Misia - o co konkretnie w tym zdaniu Ci chodzi?
Jak na razie zaprojektowany jest niewielki kawałek systemu, ktory służy do rejestracji zlecenia, i on już składa się z 4 kroków (jak wizard) ;P
Co do TAB-ów i ew. innych skrotów klawiaturowych - smuci mnie, że mnóstwo informatyków nie stosuje wielu przydatnych skrotów klatwiaturowych, więc nie mogę oczekiwać, że skorzystają z nich użytkownicy tego systemu (chyba że wskażę im go palcem, ale nie o to chodzi na tym etapie - tak długo, jak to możliwe, dostosowujemy system do ludzi, dopiero w ostatecznosci na odwrót ;P). Za duże ryzyko…
Po prostu wydaje mi się, że “dowolnie długie, ale przewijane strony” są miłe-w-dotyku tylko, gdy zawierają kolumnę tekstu do czytania. W przypadku stron zawierających nie sam tekst, ale też kontrolki wymagające skupienia wzroku i uwagi, długie, wizualnie skomplikowane (upstrzone elementami formularzy) strony stają się nieprzyjemne. Długie formularze na www bardzo mi się nie podobają, pamiętaj też o tym, że błąd zgłaszany jest zwykle przy Submicie - powiedzmy, że wypełniłem ten formularz składający się z 30 pól, naciskam “Send”, a tu mi jakieś trzy errory wyskakują: tu wpisałem coś nie tak, tam w ogóle nie wpisałem. Masakra, Els, masakra.
Odpowiadając na Twoje pytanie…
Moje doświadczenia są następujące: jeżeli mamy do czynienia z dokumentem zawierającym kontrolki - w szczególności z wszelkiego rodzaju formularzami - to przewijane dokumenty sprawiają poważne kłopoty i są niekomfortowe. Abstrahując od tego, co obserwuję, ja sam łapie się czasami na tym, że zanim przewinę nieco stronę, żeby ujrzeć “Submit” czy inny przycisk na dole strony, przeszukuję wzrokiem to, co jest aktualnie widoczne w poszukiwaniu przycisku (odnośnika), który pozwoliłby mi przejść dalej. Dopiero po chwili zorientowuje się (sic!), że niewielki fragment strony jest schowany.
Jeżeli już bardzo chcemy tworzyć długie formularze (zgadzam się z przedmówcą, że długie strony zawierające ciągły tekst to IMHO mniejsze zło, ale o tym za chwilę) to, moim zdaniem, należy jasno zwrócić uwagę użytkownika, że jest coś jeszcze poniżej. Sposobów jest mnóstwo. Niech to będzie choćby duża, wyraźna strzałka na marginesie z podpisem “See more”, etc.
I jeszcze słowo na temat stron z ciągłym tekstem. Moje obserwacje pokazują, że rzeczywiście lepiej jest, z punktu widzenia laika, rozdzielać tekst i tworzyć “krótkie” strony bez konieczności przewijania ich. Jednak osobiście zdecydowanie preferuję długie strony zawierające cały dokument i drażni mnie konieczność “skakania” po stronach, gdy np. czytam długi artykuł. Oczywiście w tym przypadku dochodzi jeszcze jasne kryterium czasu ładowania takiej strony.
Podsumowując, unikałbym długich stron, jeżeli nie są uzasadnione i rozbicie dokumentu/formularza nie będzie miało żadnych negatywnych konsekwencji.
Po co nam wogóle scrollbar’y?
Heh, żebyśmy się dobrze zrozumieli - uważam, że scrollbary na stronach www zawierających jedynie długi potok tekstu (artykuły, opowiadania, zbiory linków, itp.) są zupełnie OK, jak i same strony - nie ma sensu dzielić artykułu na kilka części, chyba że po to, żeby wstawić na kolejnych stronach bannery z nowymi reklamami;). Ale, tu Nielsen byłby ze mnie dumny, powołuję się w tym momencie na tradycję, a tradycją jest (było?), że długie jednolite teksty wrzucane były na jedną stronę. Nie widzę powodów, żeby to zmieniać. Jedynym ograniczeniem jest rozsądek i szybkość ładowania strony.
Problem długich stron IMHO ma za to ogromne znaczenie w przypadku formularzy i, z powodów opisanych w poprzednich komentarzach, uważam, że należy jak ognia unikać tworzenia strony z długim formularzem zastępując ją kilkuetapowym wizardem. Jedyne odstępstwo, jakie widzę, to aplikacje intranetowe, tzn. do użytku wewnętrznego, częstego, codziennego przez pracowników firmy - im nie jest potrzebne prowadzenie za rączkę, ale efektywne GUI.
Dobranoc!
No właśnie dążymy (narazie ideologicznie, w praktyce jest to dość ciężko osiągnąć przy dzisiejszym GUI API), żebyśmy nie musieli mówić o żadnych odstępstwach. Efektywne GUI to dobrze zaprojektowane GUI,pod względem usability. Niepotrzebny jest podział na profesjonalistów i nieprofesjonalistów. I jedni i drudzy są ludźmi. Interfejs ma być ludzki.
Zaznaczam jeszcze raz, że na etapie, na którym jesteśmy, jest to raczej kierunek myślenia o przyszłości niż wytyczna przy projektowaniu konkretnego interfejsu.
Nie mogę się zgodzić. Podział jest potrzebny, bo nie istnieje jeden standard GUI, który byłby uznany za efektywny (pomijając kwestię znaczenia tego słowa) przez każdą z możliwych grup użytkowników. Jestem bardzo przekonany do tezy, że to potrzeby end-userów powinny wyznaczać standard, a nie odwrotnie. A użytkownicy są różni - dla jednych ważna jest przejrzystość i czytelność, dla drugich maksymalna ilość informacji widoczna na ekranie, dla trzecich szybkość i możliwość dostępu do każdej funkcjonalności systemu za pomocą wykonania jednej akcji. Inne potrzeby ma klient sklepu internetowego korzystający z formularza zamówienia, inne księgowa obsługująca rutynowo swoją aplikację, a jeszcze inne administrator monitorujący obciążenie serwera baz danych. Gdyby wspomniana księgowa miała wpisywać każdą fakturę korzystając z wieloetapowego wizarda, to spokojnie można by oskarżyć projektanta takiego GUI o skrócenie jej życia o kilka ładnych lat. Projektowanie GUI sprowadza się w zasadzie do kompromisu między czytelnością, swobodą wyboru opcji (szybkością) i stopniem szczegółowości prezentowanych treści (czy o czymś zapomniałem?). Balans między tymi kryteriami zależy właśnie od kluczowych potrzeb end-usera.
przewijanie meczy uzytkownika… taka prawda!
nieznosze przewijanych stron…dlatego uzywam rodzielczosci co najmniej 1280×1024
by uniknac przewijania…(dziala tak sobie, gdyz wiele stron ma ustalona na sztywno szerokosc…)
Ja bym użył ECMA do zbudowania zakładek z ładnym fallbackiem na jeden dłuższy formularz z linkami “przejdź do sekcji Lorem Ipsum“.
fallback = graceful degradation?
Tak, fallback ;]. Ogólnie przyjęty termin informatyczny oznaczający “wyjście awaryjne” bez niepokojenia użytkownika ;].