Rewolucja vs. ewolucja

„Nowy serwis jest czytelniejszy i bardziej uporządkowany, a nawigacja została uproszczona”, „witryna jest teraz dużo bardziej dynamiczna i zawiera nowe funkcjonalności” – znacie te wyświechtane frazesy, które pojawiają się w informacjach prasowych na temat redesignów stron internetowych? Takie press release’y zazwyczaj są puste, bo kompletna przebudowa rzadko wynika z całkowitej lub znacznej zmiany strategii. Częściej chodzi o potrzeby, których aktualna wersja strony nie jest w stanie zapewnić. Na przykład nowa funkcjonalność, której nijak nie da się wpisać w architekturę strony, albo menu, które nie może pomieścić nowej kategorii. Jeżeli takich potrzeb robi się coraz więcej, projektanci zazwyczaj nie mają innego wyjścia jak zaorać i zrobić od nowa. To właśnie brak skalowalności. Nieskalowalne strony wymagają rewolucji, aby coś sensownie zmienić.

Z rewolucjami jednak nieodłacznie wiążą się trzy rzeczy: gigantyczne ryzyko, duże pieniądze i stracony czas. Łatwo też w ten sposób trafić – w charakterze przykładu – do takiej dyskusji, jaka właśnie toczy się w serwisie Goldenline.pl (Najbardziej nieudane przebudowy popularnych portali). Redesigny są dodatkowo niezbezpieczne, bo wszystkich zadowalają. Management lubi redesigny, bo są widowiskowe i sam fakt ich dokonania – niewiedzieć czemu – zwykło się uważać za sukces. Projektant z kolei może wpisać do CV kolejną pozycję, a przy tym popisać się umiejętnościami, uzasadniając swoje istnienie w organizacji. To sprawia, że gruntowne przebudowy bywają strategią samą w sobie, swoistym modelem rozwoju. Modelem wygodnym, bo zwalniającym z myślenia o przyszłości („jak będzie trzeba, to się zrobi redesign”).

Biznesowo dużo efektywniejszą metodą rozwoju serwisów internetowych jest ich ewolucja. Wbrew pozorom jest to też metoda atrakcyjniejsza dla użytkownika. To co prawda temat na inną notkę, ale warto pamiętać, że dzięki ewolucji, będzie on stopniowo otrzymywał nowe bodźce. Będzie miał czas, aby nauczyć się nowych funkcjonalności. Stały, płynny rozwój jak nic innego buduje też lojalność. Użytkownicy nie tylko widzą, że w serwis się rozwija, a ktoś wkłada w niego pracę, ale i mogą na bieżąco próbować na tę pracę wpływać, kontaktując się z redakcją. W przypadku redesign’u bardzo rzadko mają taką możliwość. A nawet jeśli w planach są beta testy, to przecież dotyczą one już przerobionego serwisu. Tymczasem poczucie wpływu i kontroli czyni serwis bliższym, prawie własnym. Taki serwis odwiedza się codziennie.

Aby jednak móc stosować metodę ewolucyjną, trzeba najpierw mieć stronę, która to umożliwia. Kiedy już taka powstanie, wówczas czas i pieniądze normalnie poświęcane redesignom, można spożytkować na szczegółową pracę nad samym produktem i myślenie o wszystkim innym poza gaszeniem lokalnych pożarów (bo akurat nie ma gdzie wrzucić nowego linka do menu).

Rodzaje skalowalności

Dla własnych potrzeb wyróżniam trzy rodzaje skalowalności stron internetowych:

1. architektoniczna,
2. graficzna,
3. systemowa.

1) W ramach skalowalności architektonicznej mieści się na przykład elastyczna nawigacja, która jest przygotowana na ewentualny rozrost zawartości strony (case Amazona). To także rozplanowanie wszystkich flow w taki sposób, aby można było w prosty sposób dołączyć kolejny, nie zakłócając w żaden sposób już istniejących (np. w sklepie internetowym dodać osobny pseudo-koszyk z obserwowanymi przedmiotami). Na poziomie szczegółów chodzi przykładowo o projektowanie z myślą o tym, aby nie zakładać maksymalnych rozmiarów jakichkolwiek list. Kto wie, czy jutro nie okaże się, że trzeba do nich dodać jeszcze jeden element.

Istotnym elementem jest architektura poszczególnych stron. Aby lepiej zwizualizować ten punkt, posłużę się przykładami z doświadczenia. Zajmowałem się swego czasu serwisem FotoForum.Gazeta.pl. Pracowałem wówczas z Tomkiem Bieniasem nad zmianą architektury kilku kluczowych stron serwisu, m.in. strony galerii. Ten typ stron zawierał z lewej strony dość spory, niezagospodarowany white-space. TB radził wówczas, by zostawić go w spokoju, bo być może jeszcze nam się przyda.  Niedługo potem okazało się, że myśląc o skalowalności miał rację. Kiedy parę miesięcy później wprowadzaliśmy funkcjonalność albumów, dzięki tamtej decyzji nie mieliśmy żadnych problemów z zaprezentowaniem ich na stronie użytkownika.

Fotoforum.Gazeta.pl - widok galerii zdjęć

Innym przykładem jest serwis Auto-Świat.pl. Projektując go, długo zastanawiałem się nad wprowadzeniem stałej lewej kolumny na stronach artykułów. Było wiele za i przeciw. Jedną z kluczowych wad tego rozwiązania było to, że w chwili projektowania nie miałem treści, które mogłyby tę kolumnę wypełnić. Z myślą o skalowalności zostawiłem ją jednak w prototypie. Szybko okazało się, że to świetne miejsce zarówno dla kontekstowej nawigacji, autozarządzalnych boksów, treści sponsorowanych jak i reklam AdSense. Oczywiście gdybym nie zdecydował się zostawić miejsca z lewej strony, pewnie znalazłbym inny sposób na umieszczenie tych elementów. Musiałbym jednak poświęcić na to dużo więcej czasu. Zresztą nie tylko mojego. Zmiana wymagałaby także dodatkowej pracy grafików i IT. Koniec końców mogłoby wyjść z tego szpetne druciarstwo. Podobnego problemu starają się zresztą uniknąć producenci samochodów, umieszczając zaślepki w niektórych miejscach kokpitu, wiedząc, że użytkownik może chcieć coś tam wsadzić.

Auto-Świat.pl - strona artykułu. Z lewej prototyp strony, z prawej działający serwis. W menu znajdują się teraz dodatkowe elementy.

2) Skalowalnośc w grafice jest trudna do osiągnięcia przede wszystkim dlatego, że jest to zagadnienie z pogranicza projektowania funkcjonalnego i graficznego. Wymaga też dbałości o detale. W konsekwencji potrzebna jest ścisła współpraca między projektantem a grafikiem. Zadaniem tego pierwszego jest powstrzymywanie nadmiernie artystycznych ciągot drugiego. Zadaniem drugiego jest wzbogacenie szaroburej (bo zakorzenionej w prototypach) wizji pierwszego. Aby zachować skalowalność trzeba pamiętać o uniwersalności rozwiązań. Warto ustalić pewien stylebook nagłówków, boksów, menusów i innych elementów, a potem mocno się go trzymać (polecam prezentacje o przebudowie systemu transakcyjnego Pekao24 zrealizowanej przez K2). To daje szansę utrzymać spójność i przejrzystość. Pracując z grafikiem, warto zwrócić uwagę na rozmaite podlewy, gradienty, zaokrąglone rogi czy odstępy między elementami. Oni je uwielbiają, a nie zawsze są potrzebne.

Dobrze zaprojektowanym serwisem pod względem skalowalności graficznej jest Forum.Gazeta.pl. Zazwyczaj kojarzy się z polityką i dość ciężkimi tematami. Jest jednak zrobione na tyle dobrze, że w prosty sposób można je dopasować właściwie do dowolnego otoczenia. Poza swoją główną instancją, Forum działa z lekko zmodyfikowanym css’em m.in. na takich stronach jak Kotek.pl (serwis dla nastolatek), Gamecorner.pl czy Lula.pl (serwis o modzie). I za każdym razem jest z nimi spójne.

Forum Gazeta.pl w czterech odsłonach: podstawowym oraz w serwisach Kotek.pl, Gamecorner.pl, Lula.pl

Aby lepiej zrozumieć istotę skalowalności graficznej, warto porównać takie pary serwisów jak fotosik.pl z flickr.com, blip.pl z twitter.com czy nk.pl z facebook.com. Dość łatwo dostrzec, które z nich będzie łatwiej rozwinąć o nowe elementy.

3) Na skalowalność systemową składają się te rzeczy, które siedzą „pod maską” serwisu. Teoretycznie są niewidoczne dla użytkownika, ale konsekwencje zaniedbań w tych obszarach zazwyczaj mają bezpośredni wpływ na jego doświadczenie ze stroną. Chodzi przede wszystkim o szybkość wczytywania serwisu, elastyczność CMSa czy stabilność sesji.

Elastyczność CMSa ma największe znaczenie w serwisach kontentowych. Projektanci zazwyczaj mają wpływ na to, jakie możliwości będzie miał back office. Warto na samym początku przygotować się więc na rzeczy niecodzienne, np. dodając w serwisie newsowym możliwość stworzenia specjalnego main topica kiedy dzieje się coś nadzwyczajnego. W zwykłym serwisie tematycznym może być to z kolei możliwość redakcyjnego przygotowania dodatkowego modułu i osadzenia go przez redaktora na wybranych podstronach bez ingerencji zespołu IT. Nawet jeśli w momencie projektowania wydaje się, że jest to niepotrzebne, to lada dzień pojawi się artykuł lub cały dział, który będziemy chcieli zajawić w ponadstandardowy sposób na stronach serwisu.
Podobnie – choć z nieco innej strony – zachowują się producenci komórek. Zdarza się nierzadko, że hardware urządzenia oferuje więcej, niż jest w stanie obsłużyć software. Przykładowo telefon ma wbudowany czip radiowy, ale zainstalowany OS jeszcze nie umożliwia takiej funkcjonalności. Kiedy jednak system się rozwinie, wystarczy prosta aktualizacja, żeby zrobić prezent użytkownikom. Nikt nie będzie musiał wymieniać komórki.

Stabilność sesji z kolei ma szczególne znaczenie w serwisach społecznościowych lub transakcyjnych. Nie ma nic gorszego niż nieoczekiwane wylogowanie w czasie wykonywania przelewu czy pisania komentarza. Skalowalność systemowa może też oznaczać przenoszalność konkretnej webowej aplikacji (jak np. wspomnianego Forum).

Te elementy tylko pozornie nie leżą w gestii projektanta. Tak jak pisałem w notce o roli projektantów w strukturze korporacji, trzeba pamiętać, że wszystkie one mają ostatecznie wpływ na doświadczenie użytkownika, a na koniec dnia tylko projektant będzie się tym przejmował. Z tego powodu powinien to być – formalnie czy nie – obszar jego zainteresowań.

Efekty

Kiedy myślenie o skalowalności towarzyszy całemu procesowi projektowania, efekty pojawią się prędzej czy później. Poza pieniędzmi, zaoszczędzonymi zasobami i brakiem ryzyka, chodzi także o ogólne wrażenie artystyczne. Warto okiem projektanta spojrzeć na przykład na to, jak z reakcją na wydarzenia 10 kwietnia poradziły sobie największe portale. Przyglądając się screenom stron głównych widać, że najlepiej przygotowana od strony architektonicznej, graficznej i systemowej do obsługi tego, co się wtedy stało, była Gazeta.pl. Nie oznacza to, że jej zespół nie miał dużo pracy. Z pewnością miał, ale mógł się skupić na innych problemach niż te, z którymi mierzyli się wtedy inni wydawcy (jak zmienić kolor tła głównego boksu, jak go powiększyć, nie niszcząc układu strony, itp.). Warto zresztą przyglądać się na bieżąco jakie możliwości edycji strony głównej mają redaktorzy Gazety. To całkiem niezła inspiracja.

Strony główne portali po katastrofie prezydenckiego samolotu. Onet.pl, Interia.pl, Wp.pl, Gazeta.pl. Screeny pochodzą stąd: http://szydlo.eu/blog/portale-po-katastrofie-w-smolensku/

Strategia jest najważniejsza

W większości przypadków wysiłek włożony w myślenie o skalowalności z pewnością zwróci się już przy najbliższej modyfikacji strony. Długofalowo te korzyści będą stale rosnąć, powiększając przewagą konkurencyjną. Jednak jak ze wszystkim w życiu, tak i ze skalowalnością można przesadzić. Robiąc witrynę ogólnopolskiego dziennika trzeba myśleć o elastyczności serwisu w inny sposób niż kiedy chodzi o stronę z informacjami osiedlowymi. Przewidując zbyt wiele zaślepek, dodatkowych mechanizmów i możliwości, może się  okazać, że słono przepłacimy za projekt, a większości funkcjonalności i tak nigdy nie wdrożymy. Z tego powodu trzeba choćby mgliście znać strategię, aby wiedzieć, jak szerokiej skalowalności potrzebujemy. Rozległość elementów, które trzeba przemyśleć jest zależna od ambicji i celów serwisu, który projektujemy.  Rzeczywistość zazwyczaj jednak skrzeczy, a projektanci rzadko mają komfort w postaci wiedzy na temat długofalowej strategii swoich stron. Jeśli jej nie ma, trzeba zaufać wyobraźni, intuicji i zdrowemu rozsądkowi. Nic więc nie zastąpi doświadczonego projektanta. Jeśli takiego nie masz, pozostaje Ci zostać światłym menadżerem :-)

W tym temacie warto poczytać

• Designing for Scalability, Jeff Lash, Digital Web Magazine
• Design concepts to achieve scalability for your Web site, Kevin Brown, TechRepublic

Dla wygody podzielę typowy projekt internetowy na dwa etapy: biznes i realizację. Projektowanie intuicyjnie pakujemy do części realizacyjnej. Na tym etapie najwyraźniej widać pracę projektantów (choćby dlatego, że wtedy powstają owe makiety) i na nim skupię się najbardziej. Nie można jednak ani na chwilę zapomnieć, że głos projektantów powinien być słyszalny także na etapie decyzji biznesowych. Projektanci powinni w nich uczestniczyć w roli konsultantów. Są bowiem dobrym filtrem, umożliwiającym wykluczenie lub przedefniowanie pochopnych projektów, opierających się nie tyle na konkretnej potrzebie biznesowej, co pomyśle konkretnego rozwiązania (np. „dajmy na stronie głównej boks z kalendarzem imprez, najlepiej po lewej stronie„). Projektanci są także w stanie określić stopień trudności projektu, sygnalizując, co tak naprawdę oznacza pomysł proponowany przez biznes. Jednak ludzie od UX to nie tylko hamulcowi wszelkich zmian. Projektant biorący udział w określaniu strategii lub wyznaczaniu celów może znacznie wzbogacić projekt i zainspirować menadżerów lub sponsorów do innego niż pierwotne spojrzenia na projekt (np. za pomocą person i wiedzy na temat ich wykorzystania).

Główna część aktywności projektantów to jednak realizacja. Jest to obszerny worek i warto zadać pytanie o umiejscowanie w nim projektanta lub działu projektowania. Pierwszym odruchem jest umieszczanie projektantów na najwcześniejszym etapie realizacji. Tam, gdzie zbiera się wymagania i proponuje rozwiązania (na przykład w postaci makiet), które pozwolą te wymagania zrealizować. Potem ich rola nagle się kończy, a następuje etap projektowania graficznego oraz implementacji programistycznej (dla uproszczenia wrzucę tutaj od razu cały web developing). O projektantach pamięta wówczas już mało kto. A przecież to własnie Ci ludzie mają najlepsze kompetencje ku temu, aby oceniać i krytykować zarówno projekt graficzny, jak i wynik implementacji. Doświadczenie pokazuje, że kompromisy, które pojawiają się nieuchronnie w czasie projektu, najczęściej zdarzają się właśnie na etapie grafiki i implementacji. Powinno więc istnieć ciało, które będzie potrafiło te kompromisy ocenić i podjąć w ich kwestii decyzje. Tym bardziej, że nawet niewielka zmiana w stosunku do rozwiązania przygotowanego przez projektanta może zniweczyć sens funkcjonalności lub całej strony. Gdy jednak dochodzi do podejmowania decyzji pojawia się problem umocowania projektantów. Wydaje się, że modele są dwa.

Model 1: Projektanci jako audytorzy

W pierwszym specjaliści UX pełnią rolę audytora. Oceniają projekt graficzny i implementację programistyczną, forumłują rekomendacje, ale decyzje co do ich przyjęcia, odrzucenia lub zgody na kompromisy pozostawione są w rękach sponsora lub menadżera projektu. Ten model z pozoru wydaje się najwłaściwszy, jednak jest w nim ukryte pewne niebezpieczeństwo. Jeśli projektanci nie będą posiadali wystarczającego autorytetu lub umiejętności komunikacyjnych, ich rekomendacje nie będą na serio brane pod uwagę przez osoby decydujące. Internet to miejsce, w którym każdy zna się na wszystkim, a na projektowaniu w szczególności. Istnieje duże ryzyko, że project managerowie lub sponsorzy będą podejmować decyzje w oparciu o przeczucia lub stereotypowe przekonania. Mogą też zwyczajnie nie dostrzec pewnych konsekwencji albo je zbagatelizować.

Model 2: Projektanci jako nadzorcy

Odpowiedzią na ten problem wydaje się model drugi, który oznacza znacznie silniejszą pozycję projektantów. W tym (dość odważnym) rozwiązaniu pełnią oni rolę nadzorcy nad etapem projektowania graficznego oraz implementacji. Są uprawnieni do decydowania o zmianach na tych etapach oraz wyrażania zgody na kompromisy. Te uprawnienia wymagają od projektanta dużo więcej niż tylko wiedzy z zakresu swojej profesji. W tym modelu projektanci powinni posiadać jakiś poziom umiejętności zarządzania projektem, ale przede wszystkim mieć pewne wyczucie biznesowe. Jeżeli będą aktywnie uczestniczyć w etapie inicjowania projektu, a więc będą mocno osadzeni w strategii, celach i powodach powołania projektu, to na etapie realizacji będą w stanie skuteczniej od innych podejmować decyzje projektowe. W czasie robienia stron, coraz częściej kluczową rolę pełni bowiem wiedza, którą mają właśnie projektanci, a która jest zbyt rozległa, aby obarczać obowiązkiem jej posiadania także project managera. Oprócz tego właściwie tylko projektant będzie w stanie dostrzec wszystkie konsekwencje ewentualnych zmian na etapie realizacji. To on zaprojektował stronę, więc także on wie najlepiej, z iloma elementami powiązana jest zmiana.

Ten model pozwala także najlepiej dystrybuować w organizacji wiedzę i swoistą intuicję specjalistów UX. Praca projektantów w dużej mierze opiera się na wypływającym z doświadczenia wyczuciu. Można powiedzieć, że dobry projektant stale czuje na plecach oddech swojego użytkownika. Graficy i programiści na co dzień tkwią w nieco innych od projektanta obszarach wiedzy. Jedni i drudzy (szczególnie programiści) rzadko kiedy zastanawiają się nad odbiorcami. To nic złego, bo ich profesja polega na rozwiązywaniu innych problemów. Jednak to ich praca ostatecznie przekłada się na doświadczenia użytkowników, a owego wyczucia nie da się nauczyć inaczej, niż przez kontakt z ludźmi, którzy już je mają. Projektant umocowany do nadzorowania grafiki i implementacji będzie więc w stanie zadbać o to, aby z etapu realizacji nie umknął element myślenia o ludziach, którzy będą z tworzonej strony korzystać. Można powiedzieć, że zadaniem ludzi od UX jest tchnięcie „ducha użytkownika” do rzemieślniczego procesu produkcji. Z tego powodu ten model powienien szczególnie sprawdzić się w tych organizacjach, które poważnie traktują podejście User Centered Design.

Projektant jako asertywny przewodnik

W dużych organizacjach ogromne znaczenie ma historia. Robieniem stron w dużych korporacjach od zawsze zajmowali się wszyscy – redaktorzy, marketingowcy, itp. Każdy miał coś do powiedzenia. Większość ludzi, zajmujących się internetem, wie czym jest usability i zna podstawowe błędy, których nie należy popełniać. Problem w tym, że o ile każdy może narysować dom, o tyle tylko garstka jest architektami. Może być dość trudno budować kulturę, w której redaktorzy, graficy, programiści, moderatorzy, ale także dyrektorzy i menadżerowie zaufają w kompetencje projektantów. Niemniej trzeba to robić. Model drugi to ułatwia, tworząc faktyczne, silne umocowanie projektantów.

Oczywiście ludzie pracujący w działach UX tak czy inaczej powinni być obdarzeni pewnością siebie i silnym autorytetem. Te cechy są im niezbędne choćby po to, aby być asertywnym i po prostu móc się czasami nie zgodzić. Projektanci są bowiem chyba najczęściej narażeni na krytykę i propozycje kompromisów w trakcie całego projektu. Aby pozostać otwartym i nie okopywać się, a jednocześnie umiejętnie balansować pomiędzy interesami poszczególnych grup korporacyjnych lobbystów, a dobrem użytkownika (bo najlepsze rozwiązanie musi najczęściej godzić kilka punktów widzenia, jak pisał Marek Kasperski), trzeba przede wszystkim mocno wierzyć w swoje umiejętności. Dział projektowania, aby nie zakończyć swojej działalności na robieniu makiet, musi też znaleźć wsparcie i zrozumienie managementu. Jeśli tam go nie będzie, nie ma co liczyć, że pojawi się niżej.

Realizacja projektu internetowego przypomina drogę podzieloną na wiele etapów. Dział projektowania powinien pełnić rolę przewodnika, który zadba o to, aby nikt nie stracił z oczu, dokąd ta droga ma nas zaprowadzić. W czasie realizacji tylko projektant będzie zawsze myślał o użytkowniku i kontekstach, w jakich będzie on używał projektowanej strony. Na pytanie, na jakim etapie tej drogi organizacja powinna więc umieścić projektanta, najsensowniej jest odpowiedzieć – nad nią.

W tym temacie warto poczytać

• Usability, User Experience a struktura firmy, UX Labs
• How should a user experience designer be used?, Econsultancy.com
• Proces rozwoju w Allegro, Tebe Gada
• Jak to się robi w Apple?, User Experience Design
• Projektowanie: Z linii frontu, UI Blox
• Projektowanie: myślenie o konsekwencjach, UI Blox

Do tej notki zainspirował mnie tebe. Jakiś czas temu napisał, ile czasu tracimy na komunikację. Zazwyczaj zresztą niezbyt konstruktywną. Według jego obliczeń po odjęciu czasu na obsługę maila, komunikatorów, uczestnictwo w spotkaniach, przerwy i rozmowy zostaje… 7 godzin tygodniowo. W tym czasie możemy nad czymś realnie popracować. Jeśli zastanowić się nad tym trochę dłużej, to naprawdę robi wrażenie.

Ostatnio postanowiłem wpisać te przemyślenia w szersze ramy. I tu pojawia się pytanie: ile dni jest w roku? Chodzi oczywiście o dni pracujące dla pojedynczej osoby. Zacznijmy od banałów. Urlop. Tu nie ma problemu, bo sprawę jasno reguluje kodeks pracy. Zazwyczaj to 20 albo 26 dni. Święta. Tu z kolei ustawa o dniach wolnych od pracy. Było 12 dni, a w przyszłym roku dojdzie jeszcze jeden (swoją drogą to plasuje Polskę na 1. miejscu w Unii Europejskiej pod względem ilości dni wolnych od pracy, średnia unijna to 9,6 – dane za: EIRO, 2009). Do tego dochodzą weekendy, czyli 104 dni.

To jeszcze nie koniec, ale zobaczmy ile zostaje nam w tej chwili. Dwieście dwadzieścia dwa dni pracy. Na tej liczbie zazwyczaj kończą się podobne rozważania. Tyle tylko, że pracujemy z ludźmi, a środowskiem jest korporacja. Ludzie czasem chorują. Załóżmy, że to 10 dni w roku, czyli tydzień na grypę, a pozostałe pięć dni na jakieś nagłe sytuacje w rodzaju bólu głowy, zatrucia czy czegokolwiek innego. W każdej korporacji są też szkolenia, warsztaty, wyjazdy integracyjne itp. OK, to w jakiejś mierze też praca, ale umówmy się, że w tym czasie nic namacalnego zazwyczaj nie powstaje (co nie znaczy, że nie warto ich organizować). Dodajmy więc do naszego zestawienia jeszcze 10 dni (to mniej niż jeden dzień miesięcznie). I na koniec worek z napisem „inne”, do którego w „zryczałtowanej” formie wrzucimy wszystkie te rzeczy, które nie wypełniają zazwyczaj całego dnia, ale nijak nie są związane z naszymi projektami. Chodzi o takie wydarzenia jak firmowe wigilie, ćwiczenia przeciwpożarowe, korpo-przeprowadzki, awarie internetu, spotkania na temat ogólnej kondycji korporacji, itp. Niech będzie, że to łącznie 5 dni w roku.

Sumujemy… Wychodzi 197 rzeczywiście roboczych dni. Średnio to tylko 16,4 dnia w miesiącu. Z drugiej strony – przez 168 dni nie wydarzy się zupełnie nic, co przybliżyłoby nas do zakończenia realizacji jakiegokolwiek projektu. Dla mnie to mimo wszystko zaskakujące. Tym bardziej, jeśli nałożyć na te obliczenia filtr zaproponowany przez tebego. A kiedy oprócz tego uświadomimy sobie, jak w dzisiejszych korporacjach robi się internet, to aż chciałoby się zapytać, jak (i kiedy) my to właściwie robimy? :-)

Kompromisy

W dużych wydawnictwach wpływ na decyzje projektowe ma wiele osób. Wynika to przede wszystkim z mnogości „udziałowców projektu”. W korpo-rzeczywistości właściwie każda, nawet drobna zmiana, wpływa na wiele innych bytów. Każdy byt ma opiekuna, a każdy opiekun ma pomysł, jak ta zmiana powinna wyglądać. Nie wszyscy udziałowcy są oczywiście uprawnieni do decydowania. Niemniej jednak podejmowanie decyzji jest fajne (przynajmniej na tym poziomie), więc każdy chce wziąć w tym procesie jakiś udział. Lepszy lub gorszy. Niestety, tylko w idealnym świecie posiadacze słabszych argumentów ustępują miejsca tym z mocniejszymi. Korporacja, w przeciwieństwie do małego start-upu, robionego przez kilku kumpli, to suma sprzecznych ambicji i personalnych interesów. W końcu trzeba czymś uzasadniać swoje zatrudnienie. Tu rozgrywają się więc gry o uwagę szefa i własną pozycję zawodową. A najlepszym polem do tych gier jest projekt. Jasne, że gdzieś tam pojawia się merytoryka, ale charaktery grają ogromną rolę.

Przekroczyłbym granice upraszczania, gdybym jednak sprowadził problem jedynie do tego. Druga rzecz to codzienna polityka. Decyzje w projektach można skutecznie podejmować wtedy, gdy ma się za sobą możnych decydentów. Ich jakość i ilość w wielkim stopniu wpływa na prawdopodobieństwo korzystnego rozwiązania. Nic więc dziwnego, że korporacyjne życie bogate jest w subtelne gry o wpływy. Nie jest to może ten poziom, co na szesnastowiecznym dworze Henryka VIII, ale zawiłości bywają fascynujące :) Oczywiście na początku i końcu chodzi o biznes. Polityka toczy się w środku.

Jeden z moich byłych szefów powiedział kiedyś na małym spotkaniu, że najciekawsze projekty powstają pod stołem. Wtedy, gdy bierze się za nie kilku pracowników, nikomu nic o tym nie mówiąc. Mają jedynie gdzieś za plecami możnego patrona, który wie o niecnych planach, ale po cichu przymyka oko i przez jakiś czas udaje, że nic nie wie. Jego rola będzie rosnąć wraz ze wzrostem ukrywanego projektu, gdy tajemnica będzie się stawać coraz trudniejsza do utrzymania („Co to za aplikacja na serwerze produkcyjnym?„). Możny patron postara się wówczas, aby nie ziścił się poliszynelowski scenariusz. Zagadany przez innego możnego, co takiego dzieje się pod stołem, będzie wymownie machał w powietrzu ręką, dając do zrozumienia, że zupełnie nic ciekawego. Kiedy zaś projekt doczeka ukończenia, patron wyciągnie go na światło dzienne i siłą swego autorytetu nada mu odpowiednią pozycję w organizacji.

To oczywiście przypadek skrajny (choć czasem tak to właśnie wygląda), ale przekonanie mojego byłego szefa o tym, że dobry projekt w jego firmie można zrobić ukrywając go przez jakiś czas, dobrze pokazuje, jak trudno sprawnie coś zrealizować w rzeczywistości politycznych i osobowościowych rozgrywek. Ale przecież miałem chwalić, a nie wytykać błędy. Tak naprawdę jednak dopiero uświadomiając sobie specyfikę i atmosferę, w której ludzie z wydawnictw robią internet, można docenić ich pracę. Tym bardziej, że nasze korporacje radzą sobie z tymi problemami coraz lepiej. Kompromisy coraz rzadziej bywają zgniłe, a polityka ustępuje liczbom i twardym faktom. Powody są dwa: specjalizacja i project management.

Specjalizacja

Dzisiejsze wydawnictwa odchodzą od starych struktur, w których internet był dobudówką prasy. Szybkość tej zmiany zależy od miejsca, w którym internet w firmie zaczął się tworzyć (ciekawie pisze o tym TeBe). Oczywiście wiodące wydawnictwa już jakiś czasu temu wykształciły osobne segmenty, zajmujące się wyłącznie internetem. Ich niezależność nie była jednak jednoznaczna, a prasa zawsze miała do powiedzenia trochę więcej. Dziś z pewnością nie można powiedzieć, że jest wprost przeciwnie, ale pozycje printu i netu powoli się zrównują. Przynajmniej w strukturach liderów rynku.
Innym zagadnieniem jest specjalizacja w obrębie samych segmentów internetowych. Tu przed rodzimymi korporacjami jeszcze sporo pracy. Wyspecjalizowane działy projektowania, społeczności czy badań to wciąż rzadkość. Zazwyczaj dominuje struktura tematyczna (rozrywka, biznes, motoryzacja) + IT. Wewnątrz każdego tematu są redaktorzy i project manager. W IT zaś programiści i graficy, zajmujący się równocześnie webmasterką. Nie za bardzo wiadomo, kto w tej strukturze ma się znać na SEO, UX, architekturze informacji czy animowaniu użytkowników. Po wydawniczych korytarzach chodzi więc sporo wannabe in-house expertów, których kompetencje bywają dyskusyjne. Taki układ niewiele różni się od struktury start-upu. Wbrew obiegowej opinii korporacje nie są siedliskiem specjalistów z dowolnej dziedziny. Zdarzają się, owszem, i tacy, ale większość pracowników to ludzie, który liznęli po trochę z każdej dziedziny i jakoś starają się te sajty robić.

Project management

Internetowe struktury wydawnictw często przypominają struktury mafijne. Aby coś załatwić, trzeba znać ludzi, mających parę niespłaconych długów wdzięczności lub wiedzieć, jaka jest ich podatność na moralne lub materialne przekupstwo :) Wynika to głównie z odredakcyjnego pochodzenia internetu w wydawnictwach. W dziennikarskiej kulturze nigdy nie było miejsca na karty projektów, WBSy, harmonogramy czy ścieżki krytyczne. Rzeczy robiło się tu i teraz. Bo nowa gazeta wychodzi jutro. Potrzeba jednak spłodziła wynalazek. Ograniczony czas i zasoby spowodowały, że wydawnictwa po krótkim czasie radosnego chaosu, musiały nauczyć się całego zarządzania projektami. Nie było łatwo, bo przypominało to zawracanie tankowca. Środowisko mafijne jest bardzo przyjazne dla tych, którzy umieją w nim dobrze żyć. Próby wprowadzania project managementu powodowały więc ponadprzeciętne opory pracowników, oskarżenia o biurokratyzm („chcę zmienić jedną zajawkę, a muszę pisać brief?!„). Dziś jest o wiele lepiej – liderzy rynku stosują z powodzeniem lekkie metodyki (króluje Scrum), mają wykształcone biura projektowe i coraz lepszych managerów. Co prawda stanowisko „project manager” wciąż bywa sprawowane przez przypadkowe osoby, a przez to jest deprecjonowane w stosunku do jego faktycznej roli, ale przynajmniej sporo się w te kompetencje inwestuje.
W wydawnictwach z mniejszym stażem internetowym niektóre projekty (rzadko bo rzadko) też robi się już w pełni metodycznie. A ich sukcesy przemawiają do dyrektorów. Bo w korporacji nie ma takiej wygody jak w start-upie – „błąd? okej, zaraz poprawimy”. Kiedy 10 programistów, 3 grafików i 1 webmaster musi zająć się 20 projektami, to kolejki, masterplany i zarządzanie portfelowe są niezbędne. W porównaniu z tym start-up to kopalnia wolnych zasobów – ludzi, którzy mają czas, by dopieszczać każdy szczegół swojej aplikacji.

Klimat

To już ostatnie, o czym chciałbym wspomnieć. Rodzimym wydawnictwom często zarzuca się brak śmiałości i innowacyjności. To prawda, która przeszkadza także mi. To coś, czego nie da się zrobić wyłącznie za pomocą metodyk czy specjalizacji. Dużo się tu zmienia, ale wciąż nie wykształciliśmy takich tradycji jak np. burze mózgów czy prototypowanie 10-3-1, a na demach w ramach scrumowych sprintów rzadko pojawiają się tłumy. W korporacjach dużo częściej statwia się na sprawdzone, ale standardowe rozwiązania. Częstokroć kopie. I nierzadko są to sukcesy. Problem w tym, że prawie nigdy nie występują wspólnie z przymiotnikiem „spektakularne”.

Aby ryzykować, trzeba jednak wykształcić klimat, który pozwala to ryzyko podejmować. Dziś większość dyrektorów powtarza jak mantrę swoim podwładnym: bądźcie odważni. To fajnie, ale żeby nie brzmiało to jak utarta reguła z podręcznika zarządzania zasobami ludzkimi, muszą za tym iść konkrety. Paradoksalnie w polskich wydawnictwach wciąż niechętnie mówi się o porażkach (szczególnie na wyższych stanowiskach). Paradoksalnie, bo internet to w większości porażki. Nie ma w nich nic złego, o ile przyczyny nie wynikają z zaniedbań. Z drugiej strony jest też coraz więcej przekonywających liderów, którzy nie tylko pozwalają być odważnym, ale też pokazują jak to robić. Jeden z moich szefów wrócił kiedyś z wyjazdowego spotkania dyrektorów i na spotkaniu z nami powiedział: „Na sesji strategicznej powiedziałem, że w przyszłym roku ten serwis będzie miał 100 mln odsłon. To o 99 mln więcej niż dziś. Pomóżcie mi to zrobić„. Po czym ruszyliśmy do wymyślania przedziwnych rozwiązań, o których wcześniej nigdy byśmy nie pomyśleli. Mentalnie tkwiliśmy w zupełnie innym wymiarze, zastanawiając się, jak sprawić, by sajt urósł o 10 proc. Mój szef pokazał nam po prostu zupełnie inną perspektywę. 10 tysięcy procent. Nikt nie bał się zaryzykować, bo możny patron stał z nami w jednym szeregu.

Z drugiej strony nie chodzi oczywiście o bezmyślne podejmowanie ryzyka. Oprócz samej odwagi, trzeba też wiedzieć, co jest innowacyjne, a co jest tylko nie wartym zaangażowania bełkotem. Aby to rozróżnić, trzeba sporej wiedzy. Trzeba także znać misję firmy. A w polskich realiach różnie z tym bywa. Regułą jest brak takich programowych deklaracji (poza oczywistą „maksymalizacją zysków”), a przynajmniej nieodpowiednie dystrybuowanie ich wśród pracowników najniższych szczebli korporacyjnych drabin. Tam, gdzie ten internet rzeczywiście się robi.

Piszę o tym, aby dać do zrozumienia, że to w zasadzie żadna sztuka „zrobić klimat” w start-upie. Właściwie jest on dany już na wstępie – w końcu zazwyczaj za takie projekty bierze się grupka zapaleńców, mocno wierzących w swój pomysł. W realiach korporacji, w której żyje się codziennie od 9 do 17, a robi kilka lub kilkanaście projektów rocznie, stworzenie klimatu zaczyna być prawdziwym wyzwaniem. Nie wolno więc nie doceniać tego, że polskim wydawnictwom się to czasem udaje.

Ergo

Uważam, że warto chwalić polskie wydawnictwa, bo całkiem nieźle poradziły sobie z przekwalifikowaniem na internet. I stale się rozwijają. Oczywiście warto im (a właściwie – nam) czasem utrzeć nosa, bo nic nie buduje megalomani równie skutecznie co korporacja :) Niemniej jednak zachęcam – szczególnie tych, którzy na co dzień pracują w bardziej kameralnych warunkach – do wnikliwego spoglądania na duże wydawnictwa. One naprawdę muszą się napracować, by ich internet wyglądał tak dobrze, jak teraz.

Oczywiście mam na myśli telefony komórkowe z ekranami dotykowymi i tablety. Powiecie: żadna nowość, mobilne odpowiedniki stron www powstają już od dawna (choćby technologia WAP). OK, ale dzisiaj za pomocą iPhona, iPada czy telefonu z Androidem można przeglądać nie odpowiedniki, ale takie same strony internetowe i to w ten sam sposób, jak na zwykłym komputerze. A to oznacza, że prędzej czy później musimy nauczyć się projektować tak, aby to, co robimy, wyglądało dobrze na także na tych (i wszystkich innych) urządzeniach.

Oczywiście można rozpoznawać użytkowników surfujących przez iPada lub inne urządzenie i serwować im specjalnie przygotowaną wersję sajtu. To proste, ale nieuchronnie prowadzi do powstania czegoś w rodzaju alternatywnej Sieci. Z innymi stronami, choć tym samym kontentem. Z innym interfejsem, choć tymi samymi funkcjonalnościami. Do tego dochodzą podwójne koszty (utrzymania, produkcji), podwójne deploymenty, podwojne środowiska testowe, podwójny czas.

Zamiast tego, lepiej robić strony tak, żeby na dotykowych urządzeniach działały równie dobrze. Ale to jest wyzwanie. Nowe podejście rodzi problemy, które wciąż nie mają zbyt wielu dobrych rozwiązań. Musimy je dopiero odkryć.

Przejdźmy do konkretów. Zebrałem kilka najciekawszych lub największych problemów, jakie niesie za sobą projektowanie na dotykowe telefony i tablety.

Śmierć hoverów

Trochę pompatyczne, ale to prawda: ekrany dotykowe zabijają hovery. To wcale nie błahostka, jeśli zastanowić się, do czego dziś wykorzystuje się najazd myszką.

• Hovery stosuje się przede wszystkim do podświetlania linków. Dziś jak nigdy ważne staje się więc prezentowanie odnośników w taki sposób, żeby były jednoznaczne i widoczne. Skoro bowiem na touchscreenach nie ma hoverów i myszki w pobliżu, to nie można za ich pomocą „szukać” ukrytych klikalnych elementów, co robią czasem użytkownicy na źle zaprojektowanych stronach.

• Poważniejszy problem zaczyna się, gdy strona posiada nawigację zbudowaną na bazie rozwijanego przy hoverze menu. Na ekranie dotykowym nie można osiągnąć akcji rolloveru kursora. Można klikać, ale nierzadko kliknięcie wywołuje już inną akcję. A to powoduje, że nagle stajemy przed koniecznością zbudowania nowej nawigacji dla serwisu.

• Podobnie ma się sytuacja z wszelkimi javascriptowymi tooltipami. Z tym problemem zetknął się Basecamp, który wyświetla przyciski „usuń” i „edytuj” po najchaniu myszą na obiekt. W wersji iPhone’owej projektanci z 37signals zmodyfikowali swój sajt w taki sposób, że linki pojawiają się dopiero po tapnięciu palcem. To jednak niezbyt dobre rozwiązanie, bo nie jest intuicyjne. Lepszym pomysłem jest stałe pokazywanie wszystkich ważnych opcji i informacji (show everything – tak robi w touchscreenowej wersji WordPress)

Z lewej Basecamp na PC, z prawej na touchscreenie. źródło:trentwalton.com

Z lewej WordPress na PC, z prawej na touchscreenie. źródło:trentwalton.com

Sytuację hoverów na urządzeniach dotykowych może nieco odmienić patent Apple na touchscreen wykrywający zbliżanie (proximity-sensing touchscreen). Choć – jak pisze trentwalton.com – to nieco przerażające, bo może wkrótce będziemy wyglądali jak idioci bojący się dotknąć swoich smartfonów :)

Warto przeczytać:

• Non Hover, Trentwalton.com
• The end of :hover?, Andy Croll

Grube paluchy

Kursor myszy jest o niebo dokładniejszy od palców, które operują ekranami dotykowymi. To pociąga za sobą morze konsekwencji. Zaczynając od fundamentów – linki. Spójrz na opuszek swojego palca wskazującego. Ile może mieć pikseli? :) Mniej więcej o taką ilość musisz odsunąć od siebie odnośniki, aby strona pozostała użyteczna. To nie drobnostka, bo może kompletnie odmienić design strony. A jeśli tego nie poprawisz, może wręcz uniemożliwić nawigację. Część użytkowników będzie mimowolnie naciskać jednocześnie kilka linków. Nie dotrą do poszukiwanej treści i sfrustrowani porzucą stronę. Dopóki chodzi o Twój blog, nie ma sprawy. Jednak kiedy zaczynasz tracić na tym realną kasę, bo tak się składa, że prowadzisz sklep internetowy, a Twoi klienci przez swoje palce wypadają z flow zamówienia, to masz problem. Niektórzy projektanci proponują, by rozwiązywać ten problem, częściej stosując buttony zamiast linków tekstowych.

Fluid design vs. 960 px

Tablety, iPhone, iPad czy telefony z Androidem mogą być używane do przeglądania internetu w trybie wertykalnym i horyzontalnym. Oba te tryby są równoprawne. Tymczasem jesteśmy przyzwyczajeni do projektowania na monitory, którym raczej nie zdarza się obracać. Z tego powodu często (a może najczęściej?) wybieramy layouty o stałej szerokości (fixed design). Zakładamy, że strona ma 960 px szerokości i nie martwimy się o nic. To daje pełną kontrolę nad środkiem. Problem w tym, że na przykład na iPadzie o rozdzielczości 1024×768 te 960 px może okazać się problematyczne. Na szczęście akurat w tym przypadku mamy całkiem sporo wiedzy, jak stosować fluid/liquid design (gdzie szerokość określamy w procentach) lub elastic design (proporcjonalny do wielkości fontu).

Zmianę orintacji ekranu można zresztą obsłużyć jeszcze bardziej efektownie. Na przykład tak jak Sports Illustrated. Od razu zaznaczę, że nie jestem przekonany czy to akurat dobry pomysł (ważna zasada: unikaj radykalnych zmian layoutu):

źródło: http://graphicdesignblender.com

Warto przeczytać:

• Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You?, Smashing Magazine
• Adaptive CSS-Layouts: New Era In Fluid Layouts?, Smashing Magazine

Flash

Jak wiadomo, gdzieś na górze, między gigantami, toczy się wojna o przyszłość flasha. Fakty są jednak takie, że w wiodących urządzeniach (iPhone, iPad) tej technologii nie ma. Trzeba się z tym pogodzić i zastanowić, jak projektować w takiej rzeczywistości. Zastosowania flasha nie kończą się przecież na animowanych stronach. Flash jest stosowany w nawigacjach, playerach oraz przy wielu specyficznych operacjach, jak np. multiupload plików (np. zdjęć). Czasem nie ma dla niego sensownych zamienników i pewne funkcjonalności trzeba w dość dużym stopniu ograniczyć lub przeprojektować.

Specyficzne UX

Wciąż niewiele jest wiedzy na temat skutecznego projektowania UX na nowe platformy. Wiedziało o tym Apple, wprowadzając na rynek iPhone’a, a potem iPada. To ta firma przygotowała poradnik dotyczący user experience na iPadzie (iPad User Experience Guidelines). Warto się z nim zapoznać, nawet jeśli nie planujesz w najbliższej przyszłości projektować specjalnie na dotykowe platformy. Wskazówki zawarte w poradniku dobrze jest mieć z tyłu głowy, projektując standardowe sajty (np. de-emphasize User Interface Controls, minimize Modality).

Nie tak dawno miałem przyjemność rozmawiać z Andrzejem Sienkiewiczem, znanym polskim projektantem UX (m.in. Onet, Grono). Jego zdaniem sajt przygotowany z rozsądnym zastosowaniem wytycznych Apple znakomicie sprawdzi się też na standardowym monitorze z myszką i klawiaturą. Być może powinniśmy wręcz zacząć projektować strony z przekonaniem „multi-touch first” i dodawać takie elementy jak hovery jedynie dodatkowo (to nie mój pomysł, tylko lekka modyfikcja idei Luke’a Wroblewskiego - mobile first!).

Oczywiście można mieć obawy czy rzeczywiście warto zmieniać wszystko w swoim warsztacie z powodu tylko jednego nowego typu urządzenia. Może to strata czasu? Dla nieprzekonanych parę faktów:

• Apple sprzedało 3 mln iPadów w 80 dni, a oprócz tego prognozy iSuppli mówią, że jeszcze w tym roku klienci kupią ich 12,9 mln. W przyszłym – 36,5 mln. Do 2012 r. ta liczba ma wynieść 50 mln.
• 1, 03 mln telefonów z dotykowymi ekranami jest sprzedawanych codziennie
• Ponad połowa smartfonów ma dotykowy ekran

No i jak?

Warto przeczytać:

• Preparing Your Web Content for iPad, Safari Reference Library
• Will the iPad break web design?, Inteldesigner.com
• How iPad Affects the Way we Design Websites?, Inspiredm.com

Odwiedzone linki (:visited)

Oznaczanie odwiedzonych linków to jeden z najstarszych standardów użyteczności.

• Po pierwsze – łatwiej zdecydować, gdzie pójść, jeśli wiemy, gdzie już byliśmy.
• Po drugie – łatwiej wrócić tam, gdzie coś znaleźliśmy, jeśli wyraźnie widzimy, gdzie to było.
• Po trzecie – łatwiej uniknąć wchodzenia w to samo miejsce, jeśli wiemy, że tam byliśmy.

Proste jak konstrukcja cepa, a jednak jest to jeden z częściej łamanych standardów. Co gorsza – łamią go ze szczególnym namaszczeniem duże portale i sajty, na których – paradoksalnie – rola visited linków jest szczególnie istotna. Pomijając zresztą, że ułatwiają nawigowanie, są zgodne ze sztuką i po prostu fair, warto pamiętać, że dzięki nim można łatwo zwiększyć liczbę odsłon. Krótsze skanowanie strony zwiększa szansę podjęcia decyzji. A to skutkuje spadkiem exit-rate. Jeśli mi nie wierzycie, zróbcie test A/B albo test z użytkownikami.

A jeśli już się zdecydujecie, pamiętajcie, że odwiedzony link musi być intuicyjnie odbierany jako odwiedzony. Stary dobry Nielsen radzi:

„visited links should look used (dull and washed out)”.

Trudno się nie zgodzić. Przy okazji warto też zaznaczyć, że to wcale nie musi być „systemowy” fiolet. Kolor visited linków powinien być jednak bledszym odcieniem tego, którego używacie do normalnych odnośników. To wbrew pozorom dość ważne. Uświadamia to taki przykład:

• To jest zwykły link.
• To jest odwiedzony link.

Nieprawidłowo zastosowane odcienie (mocniejszy jest fiolet) sprawiają, że mózg ma wątpliwości czy aby na pewno fioletowy link jest odwiedzony. Na przeczytany wygląda przecież raczej blado niebieski odnośnik.

Najazd myszą (:hover)

Na początek parę słów od klasyka. Nielsen nie jest zwolennikiem hoverów. Pisze tak:

„There is no need to use special colors or other visualizations when the cursor hovers over a link. Doing so only makes the page appear more cluttered as the user moves the mouse across the screen”.

Szczerze mówiąc, nie podzielam jego argumentacji. Hovery są czymś niezwykle popularnym. Użytkownicy są przyzwyczajeni do takiego sposobu komunikowania klikalności, a ich przyzwyczajenia są często dobrą wskazówką.
Robiąc hovery trzeba się jedynie trzymać dwóch prostych zasad.

• Zasada pierwsza – jeden link to jeden hover. Żadnego zagnieżdżania hoverów.
• Zasada druga – hover powinien pojawiać się tam, gdzie faktycznie jest link. Tu mały przykład:

Sklep a.pl, w którym ostatnio robiłem zakupy, tak zorganizował swoje menu. Każdy element jest wyraźnie wyróżniony hoverem (i to dobrze). Niestety linkiem w całym tym hoverze jest tylko napis. Reszta jest nieklikalna. Hover wprowadza więc w błąd i może frustrować. W przypadku krótszych nazw i dużej rozdzielczości ekranu, trzeba dodatkowo całkiem nieźle celować.

Lepiej zrobili to projektanci Agory (pozdrawiam ;) w serwisie Wyborcza.biz:

Hoverami można się fajnie bawić i mogą one stanowić charakterystyczny element strony. Nie myślę tu o żadnych fajerwerkach. Podoba mi się na przykład szary background zastosowany w Tok.fm lub wspomnianej Wyborcza.biz. Jest wyraźny i dobrze wygląda, gdzieniegdzie tylko przydałoby się więcej konsekwencji (nie wszędzie hover jest ten sam). Więcej inspiracji i przykładów ».

Watch your cursor!

Oprócz hoverów, warto pamiętać o kursorze. Jest on nawet istotniejszym dowodem dla użytkownika, że ma on do czynienia z linkiem. Niewiele jest więc gorszych rzeczy niż sytuacja, gdy po najchaniu myszką na link ten podświetla się, ale kursor zamiast dłoni wciąż pozostaje strzałką. To się zdarza szczególnie często pod IE, więc warto mieć na to oko.

Na temat linków visited, hoverów i innych stanów odnośników warto poczytać:

• Change the Color of Visited Links, J. Nielsen
• Guidelines for Visualizing Links, J. Nielsen