TheTarPit

Targeting Small Screens

Truizm: urządzenia przenośne to przyszłość jutro komputerów osobistych. PDA czy inne MDA stają się z dnia na dzień lepsze, szybsze, mocniejsze i ... po prostu ciekawsze. Trzymając w kieszeni hybrydę mini komputera (już nie „elektronicznego notatnika” jak kiedyś, bo w tym siedzi i oprogramowanie biurowe w komplecie i prawie-komplet do internetu i teoretycznie wszystko co zechcę), telefonu i czegoś w rodzaju aparatu czuję, że to jest Dobry Kierunek. Zatem najwyższy czas zastanowić się jak powinniśmy pisać programy na coś takiego i dlaczego aktualnie piszemy źle.

ograniczenia?

Zagadnienia związane z ilością dostępnej pamięci czy szybkością procesora są dosyć oczywiste i rozwiązywalne w sposób „klasyczny”, niemal szkolny. Zresztą parametry wydajnościowe urządzeń klasy PDA stale rosną i będą rosły nadal. Skończy się to tak samo jak w przypadku PC-tów — mało kogo obchodzi dziś wydajność maszyny, ponieważ jest ona niemal zawsze wystarczająca. A jak nie jest dziś, to będzie jutro.

Natomiast zupełnie inaczej wygląda sytuacja interfejsu użytkownika. Ekran standardowego urządzenia PDA ma rozmiar 240x320 pikseli i nie będzie większy. A może być nawet mniejszy. Oczywiście naciski są w obie strony — większy ekran to większe możliwości, ale z drugiej strony większe gabaryty sprzętu. Osobiście wydaje mi się, że wspomniane 240x320 pasuje idealnie do przeciętnej wielkości dłoni ludzkiej, a równocześnie utrzymuje klasyczne proporcje ekranu komputerowego. Zatem jest to rozmiar optymalny i pewnie „wieczny”.

podglądając najlepszych(?)

Wykorzystanie powierzchni 75 kpx w sposób wydajny jest generalnie trudne. Wydajność rozwiązania (jakkolwiek by to pojęcie definiować) zależy mocno od programu i wymaganej od niego funkcjonalności. Nawet zupełnie dziwny i niestandardowy interfejs przeglądarki ThunderHawk (rys.1.) można w pewnych okolicznościach uznać za optymalny. Wymaga on co prawda ułożenia urządzenia w poziomie, ale takie, jak rozumiem, są założenia — ekran 320x240 zamiast 240x320.

Jednak pomijając sytuacje ekstremalne jak powyżej, w każdej aplikacji występują pewne elementy stałe i przynajmniej w nich wydaje się sensowne wzorowanie się na rozwiązaniach systemowych. Aplikacje preinstalowane w danym systemie siłą rzeczy stanowią powinny stanowić jasny standard naśladowany przez inne programy. Dla przykładu obejrzyjmy jak wyglądają standardowe elementy dialogu z użytkownikiem w systemie Pocket PC 2003. Trochę to ryzykowny wybór, przyznaję, ale zarówno producent, dostępna platforma .NET (Compact Framework) jak i oferta sprzętu (czytaj: to, co mogę czasem znaleźć na moim biurku) prowokuje do zainteresowania się właśnie tą działką. Przynajmniej na początek.

pierwsze rozczarowania

Poniższy obrazek (rys.2) przedstawia banalną niby-aplikację pokazującą dwa kolejne komunikaty i niestety stanowi pierwsze rozczarowanie. Klawisz OK, tak elegancko wkomponowany w belkę tytułową okna, oszczędza miejsce na ekranie tylko i wyłącznie w sytuacji kiedy jest jedynym przyciskiem na danym okienku. Dodanie drugiej opcji (np. Cancel) powoduje natychmiastowe zrezygnowanie z tej oszczędności i wstawienie ordynarnie wielkich przycisków pod tekstem. Wyczuleni na sprawy accessibility zauważą pewnie fakt, że takie duże przyciski znacznie łatwiej nacisnąć grubym paluchem, bez używania „patyczka”. W takim razie dlaczego OK w belce tytułowej może być małe..? W każdej komunikacji z użytkownikiem niekonsekwencja to grzech numer jeden.

Użytkownicy świadomi i stosunkowo zamożni, których w ogóle stać na takie zabawki, często przy wyborze urządzenia stosują zasadę „zero tolerancji”. Gdyby twórcy oprogramowania stosowali podobną, to w zasadzie mógłby to być koniec dyskusji na temat „standardowych elementów” dialogu z użytkownikiem w PPC. Jednak wrodzone skłonności sado-masochistyczne powodują, że porozglądam się jeszcze trochę... ;-)

Przedstawiony obok przykład ekranu zmiany nazwy pliku w programie Album (rys.3) zdradza, że jego projektantem targały podobne jak powyżej rozterki. Przycisk Cancel jest tutaj duży i umieszczony w dole całego ekranu, analogicznie jak w programach desktopowych. I to IMHO dobrze — tam właśnie bym takiego przycisku oczekiwał. Jednak z jakichś dziwnych i zapewne przez nikogo nie zrozumiałych względów przycisk OK pozostał w belce tytułowej okna! Osobiście dostaję na tym ekranie lekkiego oczopląsu...

Z drugiej jednak strony może ten ekran nie jest jeszcze taki zły; może się czepiam i należy się cieszyć, że przycisk Cancel w ogóle tam jest. Jak widać na następnym ekranie (rys.4), jakiś znacznie bardziej wybitny specjalista od UI, projektujący ekran Rename/Move w Pocket Wordzie uznał taki przycisk w ogóle za zbyteczny! Jeśli zaczniesz zmieniać nazwę pliku to ... „pisz pan przepadło” — musisz zaakceptować zmiany, nie możesz się rozmyślić i pozostawić nazwy dotychczasowej. Drobna niedogodność. Ale za to ilość zaoszczędzonego wolnego miejsca jest na tym ekranie imponująca — udało się ją efektywnie wykorzystać wstawiając w dole ekranu ... puste miejsce.

Równolegle z powyższymi kwiatkami istnieje dialog Open w programie File Explorer (rys.5). Miłe zaskoczenie — niby program z tego samego systemowego kompletu, a jednak zawiera „normalne” przyciski OK i Cancel, umieszczone w naturalnym dla użytkownika miejscu, nie gigantyczne i nie mikroskopijne. Czyli wygląda na to, że jednak można, chociaż podejrzewam, że to raczej przypadek a nie element świadomego projektu GUI...

Powyższy szybki przegląd prowokuje dwa wnioski: po pierwsze aplikacje systemowe na PPC 2003 nie trzymają standardów w podstawowych, banalnych wręcz miejscach i jako takie nie są dobrym wzorcem dla nowych aplikacji. A po drugie nie bardzo wiadomo jakie właściwie rozwiązania powinno się stosować — choćby tak banalna sprawa jak wygląd, rozmiar i umiejscowienie przycisków na oknach dialogowych mogą być rozwiązane na wiele sposobów i żaden nie wydaje się jednoznacznie optymalny. Słowem — szykujemy sobie dokładnie taki sam bałagan jaki mamy na PC-tach... :-/

Komentarze