Dostosowywanie interfejsu użytkownika, czyli customizacja

Podejrzewałem to i wygląda na to, że częściowo moje podejrzenie znalazło odzwierciedlenie w badaniach:

http://www.useit.com/alertbox/customization.html

Możliwość dostosowania interfejsu aplikacji, czy strony internetowej, nie jest bezwzględnym „plusem”.

Dla wielu użytkowników, customizacja stanie się

a) pracochłonnym dodatkiem, wymagającym nauki – np. ilu użytkowników zmieniło sobie w Wordzie skróty klawiaturowe? Np. uciążliwe Shift-F4 (Znajdź następne – FindNext) na bardziej naturalne F3? Nota bene: dla ilu użytkowników, nie będących informatykami/pasjonatami, F3 to naturalny sposób wyszukiwania kolejnego wystąpienia?

b) utrudniającym pracę zbędnym „wrzodem” – w starym Wordzie (2003) mój znajomy odrobinę starszej daty, regularnie przemieszczał sobie główny pasek narzędziowy za pomocą przypadkowego przeciągnięcia, gdzieś na środek ekranu, po czym zirytowany jego obecnością i zasłanianiem tekstu, zamykał go malutkim iksikiem w prawym górnym rogu. Po następnym otwarciu Word’a był wściekły, że nie może znaleźć „dyskietki” do nagrywania plików. Niezliczoną liczbę razy przywracałem mu ten pasek. To była możliwość customizacji, całkowicie zbędna i niewygodna, naprawiona poprzez wstęgę, która pojawiła się w Office 2007

Dla Twoich developerów stanie się za to przekleństwem, bo gdy każdy użytkownik korzysta z innego interfejsu. Odpowiada to temu, gdyby obsługiwać trzeba i poprawiać ogromną liczbę wersji aplikacji.

Bez badań, nieco intuicyjnie podejrzewam, że jako atrakcyjną użytkownicy postrzegają możliwość dostosowania prostych rzeczy, w łatwy sposób – np. ustawienie melodii sygnału w telefonie, zmiana tapety na ekranie komputera. To są proste customizacje, o szybko widocznym, trwałym i „spektakularnym” rezultacie.
Tymczasem już np. skróty klawiszowe – to często wyższa szkoła jazdy. Żeby ich zmiana miała sens, trzeba jeszcze umieć bardzo łatwo zachować/wyeksportować cały układ, żeby móc do niego wrócić na wypadek awarii/reinstalacji/zmiany wersji oprogramowania. Inaczej będzie to frustrujące, kiedy cała pracowicie wprowadzona customizacja zniknie.

Istnieją też możliwości dostosowania, które mają być „sprytne” li tylko dla twórców. Przykład: bankowość internetowa jednego ze znanych banków. Domyślnie na wszystkich listach (np. w liście operacji w historii rachunku) wyświetlane jest 10 pozycji, ze stronicowaniem rekordów. W ustawieniach można jednak zmienić liczbę 10 na znacznie bardziej użyteczne 50-200 wierszy na jednej „stronie” – ciekawe ile osób o tym wie, a ile używa w mozole domyślnego 10, przeklikując się mozolnie na kolejne strony historii rachunku? Dlaczego nie dać wszystkim domyślnie 100? Bo to (prawdopodobnie) bardziej obciążyłoby serwery i jeżeli w ogólnej masie 90% używa ustawienia domyślnego, to można trochę („sprytnie”) oszczędzić. To jest opcja customizacji, która ma być mniej użyteczna w imię oszczędności.

Ciekawym przyczynkiem do argumentacji jest zmiana zauważalna pomiędzy Word’em 2003, a 2007. Wprowadzenie wstęgi znacząco odsunęło customizację od użytkowników. Być może można nawet ją wprowadzić, ale kto by się czymś takim zajmował? Szczerze powiedziawszy w Wordzie 2003, miałem bardzo znacząco pozmieniany pasek narzędziowy. W 2007 i 2010 – nawet nie próbowałem ruszać wstęgi, bo raz, że jest wygodna, dwa – szkoda mi czasu.

Dlaczego tak jest?
Myślę, że przyczynami są:

1) „prawo zachowania energii” ;-) – z reguły inwestycja w naukę customizacji wiąże się z niepewnym efektem („a co jak tam są błędy i mi się zresetuje wszystko”, „jak przeinstaluję, to stracę ustawienia”), a do tego wymaga głębszego zrozumienia co się robi, na które często nie mamy czasu w natłoku bieżących obowiązków. Do tego rezultat niekoniecznie będzie poprawiał naszą efektywność – czasami to „sztuka dla sztuki”

2) oczekiwania wobec narzędzia – oprogramowanie ma służyć do wykonywania konkretnych czynności, a nie do zapewniania funkcji. Jakkolwiek działy marketingu producentów oprogramowania lubią porównywać się na liczbę funkcji i parametry, to w praktyce użytkownicy potrzebują oprogramowania do „robienia swojej roboty”. Wyobraźmy sobie młotek z możliwością customizacji koloru trzonka i położenia elementów. To byłoby narzędzie koszmar…

3) mnożenie możliwości wyboru nas unieszczęśliwia – a customizacja to wybór i to często w setkach wariantów. Więcej o tym: http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html

Tyle argumentacji. A jaka konkluzja?

A) Projektuj dobre rozwiązania domyślnie dostępne w aplikacji. Nic nie zastąpi aplikacji stworzonej do realizacji czynności, prowadzącej użytkownika za rękę wtedy kiedy trzeba, zamiast do udostępniania pojedynczych funkcji, z których użytkownik musi sobie swoje zadania składać

B) Udostępnij customizację prostą w obsłudze i dającą znaczące, zauważalne i trwałe rezultaty

C) Zadbaj o to, aby customizacja nie miała szansy utrudnić pracy – niech nic nie znika bezpowrotnie, nie zmniejsza się poniżej zauważalnego i obsługiwalnego rozmiaru, nie ucieka za ekran, a jeżeli już musi to robić – niech będzie łatwo przywrócić stan oryginalny

D) Nie ufaj temu co użytkownicy mówią – badaj to co robią, żeby lepiej poznać ścieżki pracy z Twoją aplikacją

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *