Nie róbcie tego w domu!

Jeśli ktokolwiek z was korzysta z Firefoxa (a wg Google Analytics to 80% z odwiedzających ten blog!), wie, że od czasu do czasu ludzie oglądają kilka stron na raz. Ot przykłady:

• porównują ceny w kilku sklepach online,
• czatują w kilku zakładkach,
• czytają newsy na przemian z pocztą,
• piszą bloga i oglądają nagie kobitki.

No i możnaby mnożyć. Stąd bierze się pytanie: czy to, w z jakimi innymi stronami nasz wytwór jest oglądany powinno mieć wpływ na to, jak go zaprojektujemy?

Kilka przykładów rzeczy, na które należy zwrócić uwagę od razu przychodzi mi do głowy:

Na co zwracać uwagę przy projektowaniu dobrze współistniejących

Dźwięk… Nie ma nic gorszego niż dźwięk który nagle zacznie się wydobywać z niewiadomej zakładki, gdy właśnie jesteśmy w połowie oglądania filmu na YouTube. Jeszcze gorzej, jak jest to flashowa reklama. Nie dość, że przeszkadza, to jeszcze musimy przejrzeć wszystkie zakładki, by go wyłączyć.

Wymuszony rozmiar strony. Do dziś spotykam strony, które w chwili ich otworzenia zmieniają rozmiar okienka z przeglądarką np. maksymalizując je (szczególnie fajne na 30″ monitorze!). Jeszcze gorzej jak pomysłowy dyrektor do spraw kreowania strategii ekspansji marki na rynki środkowej europy stwierdzi, że jego animacja flashowa powinna być oglądana w rozdzielczości 768×512, bo tak jest najbardziej sexy. No i otwierasz stronę takiego dyrektora [..] w zakładce w tle i zdanie które właśnie czytałeś ląduje poza ekranem.

Alert, confirm… Powinno sie ich zabronić, naprawdę. Rzadko wnoszą coś do usability, można ich zadanie emulować w samej aplikacji (tylko lenistwo programistów to utrudnia) a jak już wyskakują z niewiadomej strony w tle, można naprawdę zwariować. Przykład: czytasz bloga i widzisz nagle wyskakujący przed oczami komunikat “Brak aktywności od 10 min., nastąpi automatyczne wylogowanie.” Gdybym nie wiedział, że to komunikat ze strony banku, pomyślałbym, że ten blog mnie nie lubi.

Wszystko, co wymieniłem powyżej jest oczywiście błędem w usability także w kontekście jednej strony. Jednak w przypadku, gdy oglądamy strony w zakładkach, staje się tyle razy bardziej irytujące, ile zakładek mamy otworzone w danej chwili.

JavaScript stał się ostatnio całkiem modnym językiem. Ustraja się nim strony internetowe, a coraz częściej pisze w nim całe aplikacje. Przykłady można mnożyć: Zimbra, Zoho, ThinkFree czy Google Docs&Spreadsheets.

W związku z tym coraz częściej osobom, które starają się o pracę przy projektach nastawionych głównie na JavaScript stawia się poważne wymagania. Dla przykładu, warto mieć pojęcie o tym, jak działają pewne struktury danych oraz jak źle można zaprogramować gargbage collector i jak się to ukrywa przez lata, by potem cicho wypuścić łatkę.

Naprawdę wiedza człowieka, który w chwili obecnej pisze aplikacje w JavaScripcie powinna dorównywać wiedzy tych, którzy na codzień zajmują się “poważnymi” językami, jak Java czy C#. W niektórych przypadkach powinna nawet ją przerastać. Jest w końcu pewna umiejętnością napisanie efektywnego programu, działającego na platformie, w której czas odśmiecania jest kwadratowy lub głębokość rekursji jest ograniczona do stu wywołań (ostatnia beta Apple Safari).

Sylwetka programisty JS

Więc tak — po pierwsze, trzeba znać terminy: AJAX, Web2.0, community powered software, wiedzieć co to jest PHP5, JSP i ASP.NET i MySQL 5.1.0.2. Znać CSSa od podszewki a wogóle to pisać bloga z regularnym tutorialem nowych trendy javascriptowych bibliotek.

Oczywiście żartowałem. W ośmio-dziesięcio osobowym zespole wystarczy jedna osoba, która zna wszystkie przeglądarkowe hacki i tricki oraz wie co nowego niesie z sobą najnowsza wersja biblioteki/języka/platformy X.

Człowiek, który nigdy nie widział JavaScriptu na oczy za to potrafi dobrze programować w którymkolwiek z imperatywnych języków jest w stanie nauczyć się wszystkiego, co wymieniłem w tydzień. Może nie w stopniu eksperta, ale w stopniu wystarczającym do efektywnej pracy.

Niestety nie zadziała to w drugą stronę — człowiek, który doskonale zna wszystkie hacki i tricki nie nauczy się w tydzień, jak zaprojektować dużą aplikację, podzielić program na współpracujące z sobą obiekty. Nie nauczy się też, co to jest wzorzec projektowy (ang. design pattern), jak efektywnie zaprogramować kolejkę priorytetową. Heh, prawdopodobnie nawet nie zrozumie rekusji.

Nie zrozumie więc dowodu (z bloga Steve’a Yegge), że rekurencja i iteracja nie są równoważne:

The anonymous author of the paper has found that there is in fact one thing you can do using recursion that you can’t do using iteration, namely: “You can use it to weed out stupid fugging interview candidates.”

No i nie przejdzie standardowej rozmowy u Joela Spolskiego (Guerilla Guide to Interviewing):

1. Introduction
2. Question about recent project candidate worked on
3. Easy Programming Question
4. Pointer/Recursion Question
5. Are you satisfied?
6. Do you have any questions?

Wniosek

Tym, którzy jeszcze studiują gorąco polecam sprawić sobie książki o algorytmach, wzorcach projektowych i może np. konstrukcji kompilatorów, a potem porządnie je wszystkie przestudiować. Będzie to bardziej owocne w przyszłości niż poznanie jeszcze jednego hacka w cssie na buga w internet explorerze wersji….