Nieomylność znaczy “nie robię niczego konkretnego”

Napisałem kiedyś na Facebooku, że łatwo rozpoznać aplikację, której UI projektował programista. Wystarczy poszukać, czy kwadrans to 0.25 h. Podśmiewałem się z aplikacji, której demo pokazywał mi marketingowiec. Dwa dni później znalazłem identyczny kod mojego autorstwa.

Programiści nie są głupi, programiści nie są antytalentami, kiedy idzie o projektowanie. Programiści poruszają się w świecie, który ma zupełnie inne punkty odniesień i przez to nie potrafią myśleć “jak zwykli ludzie”. Dla programisty wyłączenie czegoś w panelu przez wpisanie tam zera może mieć sens. Zaawansowane wyszukiwanie przy pomocy wyrażeń regularnych to oczywista oczywistość. Używanie unikalnych identyfikatorów z bazy w kolumnie LP. jest słuszne i pomaga się orientować. Jeżeli zapisujemy datę, to powinniśmy też zapisać godzinę, niewiele kosztuje, a użytkownik z pewnością się ucieszy wiedząc, że Cron wystawił mu automatycznie fakturę o 3:37.

Jedyny sposób na uleczenie tej wizji świata to posadzenie programera z designerem, wrzucenie kilku butelek czegoś mocniejszego i przekręcenie klucza od drzwi. Nie będzie to łatwe. Programerzy myślą o designerach jako o “mośkach od szabloników”, designerzy znów widzą w programerach uparte osły z aparycją małpy. Obie strony tego konfliktu są zwykle pełne gówna i potrzebują lunety, żeby spojrzeć poza czubek własnego nosa.

Ktoś będzie musiał być tym starszym i mądrzejszym, przerwać cykl nienawiści. Zakładam, że będą to programiści, bo są zwykle mądrzejsi i przystojniejsi.

Pamiętaj, nie jesteś alfą i omegą. Tylko tak myślisz!

Dla człowieka z Array() każdy problem wygląda jak .each()

Żeby nie być gołosłownym, pokażę wam problem, nad którym teraz siedzę. Oryginalny autor jest młodym programistą, a to był jego pierwszy większy projekt. Miał wystarczająco dużo wiedzy, żeby programować i zbyt mało, żeby podejmować decyzje projektowe. Niestety, projekty są realizowane zgodnie z zasadą “budżet dąży do zera do momentu napotkania frajera, który zrobi wszystko za jedną pensję”.

Rozważmy uprawnienia w systemie informatycznym. Mamy użytkownika, mamy moduły i metody, mamy uprawnienia. Uprawnienia są listą zawierającą nazwę i identyfikator. Przy wywoływaniu metody z modułu sprawdzamy, czy użytkownik ma identyfikator uprawnienia. Programistyczne przedszkole, prawda?

Implementacja jest poprawna z programerskiego punktu widzenia. Teraz dochodzimy do momentu implementowania międzymordzia dla użytkownika.

Spróbujcie wejść w umysł programisty. Macie listę użytkowników na osi Y, macie listę dozwolonych uprawnień na osi X. Uprawnienie może mieć dwa stany: nadany lub nienadany. Jaki element jest idealny do odwzorowania takiego układu? Checkbox.

To, co tu widzicie, jest efektem myślenia o danych po programersku. Jest to ujęcie całkowicie poprawne technicznie i totalnie spierdolone, jeśli weźmiemy pod uwagę, że użytkownicy systemu nie są robotami.

Wiecie, ile czasu zajmuje narysowanie takiej tabelki dla 120 użytkowników w systemie? Ponad stu pracowników razy ilość uprawnień plus narzut jQuery. Jak myślicie, ile koordynacji oko-ręka wymaga wybranie linii z uprawnieniami pracownika? Tabela jest na tyle wielka, że patrząc w ostatnie checkboksy, muszę odwrócić wzrok na listę nazwisk. To nie są ustawienia, to gra zręcznościowa. No i mój osobisty faworyt: żeby dowiedzieć się jakie uprawnienie nadajesz, musisz potrzymać wskaźnik nad pudełeczkiem checkboksa.

Eksperyment myślowy: jako nowy pracownik nadaj uprawnienia trzyma_kredens i czajnik_zabójca Halinie Krzywonos, ale nie Halinie Krzywons.

Oto kilka programerskich-designerskich błędów, które popełniono:

To, że trzymasz dane w jednej tabeli, nie znaczy że te dane należy prezentować razem. Informacje o uprawnieniach są połączone z profilem użytkownika. Powinny być wyświetlane w kontekście, na stronie z edycją profilu użytkownika.

“Jestem człowiekiem, a nie numerem!” i tak samo jest tu. W programerskim umyśle nowo przyjęty do pracy dostaje taką informację na powitanie: możesz otwierać_drzwi, otwierać_okna, pić_kawę i podrywać_sekretarkę. W prawdziwym świecie powitanie wygląda tak: “będziesz pracował jako sprzedawca”. Uprawnienia powinny być ujęte w grupy. Tworzysz grupę X z uprawnieniami X1, X2 i X3. Pracownicy na odpowiednim stanowisku trafiają do odpowiedniej grupy.

Dwa zwycięstwa od ręki: możesz modyfikować uprawnienia dla całej masy ludzi bez potrzeby wybierania zmian dla każdego. Możesz dodawać wariacje: użytkownik może być w grupie X i mieć dodatkowe uprawnienie. Maksymalna elastyczność, minimalna ilość klikania.

Zapamiętaj: celem tworzenia UI nie jest replikacja struktur danych w twoim kodzie. Wiem, że ciężko się pozbyć takiego myślenia. Najlepiej w ogóle o tym nie myśleć. Znajdź przyjaznego designera, najlepiej takiego, który nie przegina w drugą stronę. Wiesz, takiego łączącego zaokrąglone rogi z feng szuje.

Na zakończenie jedna osobista uwaga. Nie wiem czy to ja jestem takim geniuszem, czy wy jesteście takie pały.

Widziałem to setki razy. Użytkownik wybiera opcję w systemie i zostaje pożegnany zimnym “Brak dostępu”, “Dokument niedostępny”, “Naruszenie uprawnień systemu. Ten wyjątek zostanie zgłoszony!”. Potem zaczyna się żonglowanie e-mailami pomiędzy przestraszonym użytkownikiem, jego kierownikiem i mną. Strata czasu.

Żeby ułatwić sobie życie, do komunikatu o braku dostępu dodaję link “Poproś o dostęp”, który generuje e-mail z informacją do zwierzchnika. On może mu nadać, może go olać, może mu nadać na 24h. Na drugą nóżkę wyświetlam listę pracowników jakoś związanych z nim (np. dział) posiadających uprawnienia. Czasem starczy się przejść biurko obok i zapytać, czy kolega może Ci coś sprawdzić.¹

Wszystko żeby mniej pracować. “Mniej pracować” powinno być twoim motto. Nie “techniczna doskonałość w służbie klienta”, tylko coś egoistycznego. Nie spierdol dziś, aby nie naprawiać jutro.

1. Może nie przejść w supermegakorporacji. [↩]

« Dwa litry napoju | Łódź moim miastem »