Blogasek by Piotrek Reinmar Koszuliński

Tło

Próbując zdobyć papierek inżyniera i tę odrobinę sensownej wiedzy, którą można znaleźć na studiach z informatyki (Politechnika Wrocławska) dotarłem do semestru piątego i kursu Projektowanie Oprogramowania. Jest to kurs z tych ciekawszych, bo w tym semestrze mam jeszcze np. Technologie Przetwarzania Mediów Cyfrowych (montowaliśmy reklamę radiową oraz słuchowisko, później robiliśmy retusz zdjęcia, a teraz fotomontaż - tak WTF?!), czy Informatyczne Systemy Sterowania (kurs dość zaawansowany, a więc zupełne przeciwieństwo TPMC, z tym, że wiedza przyda się może kilku(nastu) osobom).

Dwa miesiące pisania sztucznej specyfikacji i rysowania diagramików UML utwierdziło mnie jeszcze bardziej w przekonaniu, że nigdy w przyszłości nie będę chciał tego robić. Nasza specyfikacja na tym etapie obejmuje jedynie malutki wycinek systemu, a poświęciliśmy na jej przygotowanie kilka dni roboczych. I nie – nie projektujemy systemu bankowego, a uproszczoną księgarnię internetową. I tak naprawdę skupiamy się tylko na procesie składania zamówienia.

W tej chwili dotarliśmy do etapu kiedy już trzeba ogarnąć architekturę aplikacji. Co prawda większość studentów zaprojektuje zapewne jakiś tam sobie diagram komponentów, sekwencji i co tam jeszcze obejmuje ten etap kursu, kompletnie nie interesując się jak to będzie współgrało z frameworkiem/technologią którą później zastosują (narzucona z góry Java). Ja jednak tak nie potrafię. Zacząłem więc szukać Java'owego frameworka do aplikacji webowych, który później zastosujemy. I w tym momencie szczęka mi opadła.

Każda potwora...

Na początku semestru, kiedy dowiedziałem się, że będziemy projektować, a później w małej części kodować, aplikację webową poszedłem do prowadzącego spytać się czy jest z góry narzucony język. Dowiedziałem, się że prowadzący proponuje Javę, ale że nie – jeśli ktoś z nas chce coś innego, to może spróbować. Choć prowadzący nie polecał takich prób (szczególnie jak usłyszał o PHP :). Wtedy odpowiedziałem, że w trakcie semestru się zastanowię, bo dobrze znam symfony i byłoby mi łatwiej, a nie słyszałem o żadnym sensownym i otwartym rozwiązaniu w Javie. Prowadzący odpowiedział, że jest sporo dobrych i otwartych frameworków. Zrobiło mi się wtedy głupio, bo moja wypowiedź nie była poparta żadnymi głębszymi doświadczeniami. Po prostu – taki stereotyp Javy.

W trakcie semestru uświadomiłem sobie, że ten rodzaj betonowej specyfikacji nijak nie pasuje do symfony, ani Railsów, czy Django, które w większym/mniejszym stopniu znam. Że jestem zbyt słaby w UMLu, aby przenieść magię tego frameworka, do tych wszystkich diagramów, które musimy stworzyć. Postanowiłem więc się nie wyłamywać z tłumu i jak wszyscy pozostać przy Javie.

Wczoraj zacząłem research w poszukiwaniu odpowiedniego frameworka. Przejrzałem wiele stron na wiki i nieliczne porównania. Stwierdziłem, że najlepiej prezentuje się Spring 3. Został nieźle oceniony w porównaniu, a do tego w Google'ach potrafiłem znaleźć coś co przypominało stronę nowoczesnego projektu, a nie przedpotopowej, zapomnianej kobyły.

Przyzwyczajony jestem do świetnej dokumentacji typu "Get started" (sf, railsy, django), którą można zlokalizować na stronie domowej projektu w minutę, a która trzyma mnie za rączkę, aż do momentu kiedy jestem w stanie korzystać ze słabej (w przypadku symfony – bardzo słabej) dokumentacji API i tutorialów związanych z bardziej zaawansowanymi rozwiązaniami.

Tego samego szukałem na stronie Springa. Po 5 minutach wiedziałem już, że tak prosto nie będzie. Autorzy frameworka stworzyli 800 stronicowy podręcznik, w którym jest pewnie opisane wszystko, o czym 100 jego twórców myślało przez ostatnie dwa lata. Stworzyli też dziesiątki stron, w których chwalą się jakie to fajne rozwiązania wprowadzili do swojego dziecka. Nie znalazłem na stronie domowej projektu jednak nic dotyczącego Springa 3 (ta wersja ma już ponad rok) co pomogłoby mi go uruchomić.

Postanowiłem jednak się nie poddawać i rozpocząłem przeszukiwanie nie tylko strony domowej, ale całego internetu. W ciągu dwóch godzin trafiłem w kilka miejsc, jednak... sami popatrzcie – tu, tu, tu, tu (nawet nieźle), tu, czy tu. Jednym słowem wielki śmietnik. Postanowiłem spróbować z innym frameworkiem.

Kolejny, któremu chciałem się przyjrzeć, to JavaServer Faces. Tutaj było jeszcze gorzej. W Google'ach nie potrafiłem znaleźć nawet czegoś co można by było nazwać "jednolitą stroną projektu". Nie wiem jaka jest geneza (i już mnie to nie interesuje) tego frameworka, ale moim zdaniem to wręcz niepoważne. Polecam obejrzeć przykładowe strony, które są w pierwszej 10tce w Google'ach.

Po drodze był też JBoss. Strona na którą trafiłem wyglądała jak strona korporacji, więc po 5 minutach dałem sobie spokój. Żal coś pisać w tym temacie.

Pod lupę wziąłem też Strutsa. Najpierw się załamałem, bo strona projektu przypomina typową Apache'ową. Trzeba jednak być twardym. Documantation -> Get started -> Tutorials -> Getting Started i jest! Coś znalazłem. Nie jest to co prawda poziom znanych mi frameworków, ale daje radę. Jednak ścieżka jaką musiałem przejść żeby trafić do interesującej mnie strony bawi mnie dalej :).

Na koniec wróciłem zrezygnowany jeszcze raz do Springa i znalazłem cykl artykułów dla początkujących oraz Spring Roo. I choć na początku Spring mnie załamał, to w tej chwili wraz ze Strutsem i jedną sensowną książką do JSF jest moim ostatnim punktem zaczepienia w tym temacie.

... znajdzie swojego adoratora

Wspomniałem na początku, że zrobiło mi się głupio kiedy, nie mając podstaw, powiedziałem, że nie znam żadnego sensownego javowego frameworka. Zasiadając do poszukiwań szczerze wierzyłem w to, że skoro są miłośnicy Javy, wśród których są przecież świetni programiści, to musi istnieć jakaś sensowny projekt związany z sensownym frameworkiem.

Teraz już wiem – ze spokojem mogę mówić, że nie znam sensownego projektu. Nie mogę za to nic powiedzieć o samych frameworkach, bo aby je ocenić należy ich użyć. Możliwe, że każdy z frameworków, któremu się przyglądałem jest świetny. Ich autorzy zapomnieli jednak, że nie na kodzie i technicznym manualu Świat się kończy.

Zawsze drażnili mnie (a może bawili) programiści twierdzący, że taki stan projektów im odpowiada. To moja wina, że nie potrafię znaleźć interesujących mnie informacji. Moja wina, że nie zamierzam przeczytać 400 stron w książce aby choć w najprostszym zakresie potrafić użyć narzędzia. Moja wina, że za szybko się zniechęcam – generalnie jestem słabym programistą i nie umiem szukać oraz czytać ze zrozumieniem.

Dlatego tak bardzo zainteresowała mnie idea UCD – projektowania zorientowanego na użytkownika. Choć swoją popularność zdobyła głównie w związku z projektowaniem interfejsów, bądź ogólniej – interakcji człowieka z komputerem, to lubię ją aplikować do każdej sytuacji kiedy istnieje jakiś produkt i jego odbiorcy. Do nikomu niepotrzebnych usług, które według ich twórców są rewolucją, przedmiotów codziennego użytku, które przyprawiają nas o ataki szału, czy... no właśnie – nie przychodzi mi żaden produkt, przy opracowywaniu którego programiści nie mieliby swojego destruktywnego udziału.

Programiści i innego rodzaju osobniki, które pojęły sposób działania komputera (sieciowcy, administratorzy) to najbardziej zakute łby na naszej planecie. Wyłączam tutaj polityków, których ciężko ocenić, bo nigdy nie wiadomo kiedy kłamią. To natura informatyki, ze wszystkich dziedzin, najdalej odbiegła od natury człowieka. Dlatego osoby trudniące się pojmowaniem tej nauki są najbardziej aspołeczne. Nie mam tu na myśli sposobu ubierania się (bądź nie), zachowywania, czy poruszanych tematów rozmów. Mam na myśli sposób myślenia i wnioskowania.

Java Centered Design

Wracając do Javy od której to zacząłem. Jest to najbardziej odczłowieczony język jaki dany mi było poznać. Jego społeczność nie wywołuje we mnie żadnych uczuć. Nawet nie wiem czy istnieje. Nie znam żadnego programisty Javy, który by ten język lubił. Odnoszę wrażenie, że w ogóle wszyscy z niego korzystający zamknęli się w swoich bankowych, księgowych i ubezpieczeniowych gettach. Zaraz, zaraz. Przecież to właśnie te najbardziej nieprzyjazne człowiekowi systemy...

Oczywiście Java wpłynęła też na frameworki, które w niej powstały. Tak jak pisałem, znalazłem wiele artykułów napisanych przez autorów Springa ukazujących jakie wspaniałe wzorce projektowe zastosowali, jakimi dobrymi są programistami, jaki wspaniały techniczny podręcznik napisali. Zapomnieli jednak co jest wyznacznikiem jakości ich pracy.

Jest takie powiedzenie w piłce nożnej, że za podanie odpowiada podający, a nie jego odbiorca. Tak samo jest w w przypadku dokumentacji frameworków. To nie ja jestem głupi jeśli nie potrafię znaleźć interesujących mnie informacji i nie rozumiem tego co napisaliście. To Wasza wina. Ja oczywiście mogę szybciej pobiec do piłki i może jakimś cudem zdążę, ale tak naprawdę to wyście skopali swoją robotę tak beznadziejnie podając.

Dzisiejsza walka jeszcze głębiej utwierdziła mnie w przekonaniu, że Java jest smutna, zakuta i nieprzyjazna użytkownikowi końcowemu. Będę się dalej trzymał jak najbliżej frontendowych technologii webowych, aby mieć jak najbliżej do użytkownika końcowego. Dzięki temu mam nadzieję, że nigdy nie zapomnę dla kogo tak naprawdę co jest wyznacznikiem jakości mojej pracy. Zadowolenie użytkownika końcowego.

Opublikowane na licencji CC przez Roberta Thomsona.

Tytułem tym chciałem nawiązać do ubiegłotygodniowego wpisu Dlaczego frameworki CSS ssą?. Niech tradycją się stanie, że kiedy używam słowa "ssać" to chcę coś nieobiektywnie pojechać. Piszę "nieobiektywnie", żeby mnie ktoś znowu nie próbował przekonać, że wpis ten w mych oczach miał pretendować do bycia obiektywnym. Nie — to jest blog i publikuję tu moje odczucia, a nie badania naukowe (które notabene, po wpadce klimatologów, wiemy już jak są prowadzone).

Wpis ten zacząłem pisać wczoraj wieczorem, jeszcze zanim miałem okazję przeżyć dzisiejsze przygody (które wymieniam na liście). Tak więc czara goryczy przelała się już wcześniej, a to co stało się dzisiaj tylko mnie przekonało, że bardzo chcę opublikować ten tekst.

Żeby było jasne — iPhone (wersja 3G) jest oryginalny, zakupiony w Erze półtora roku temu, nigdy nie jailbrake'owany, nigdy nie przytrafiło mu się też nic strasznego. Windows do którego go podłączam włączany jest tylko w celu synchronizacji telefonu z iTunesem, bądź odpalenia kilku gier (kupionych w sklepie, nie ściąganych). Można więc przyjąć, że jest w miarę czysty.

Co przydarzyło mi się dzisiaj:

• dwukrotnie miałem już następującą sytuację — iPhone staje się trochę niestabilny (coś tam pada, coś tam laguje), postanawiam więc go wyłączyć i włączyć — wiadomo, że czasami dobrze jest odśmiecić pamięć. Wyłączam iPhone'a, włączam... nie — nie włączam — słodki ekran z jabłuszkiem zawisa na czas nieskończony (ostatnio jak zawisł mi przed seansem w kinie, to po seansie nadal się włączał). Wtedy trzeba pokombinować jakoś żeby go na twardo zresetować, ale stop — nie da się do cholery wyciągnąć baterii. Wciskam więc wszystkie jego dwa klawisze i za którymś razem (żeby nie było zbyt prosto — kilka razy mogę dusić te przyciski po kilka minut i nie ma reakcji) udaje mi się go wyłączyć. Ponowna próba włączenia kończy się sukcesem, o ile sukcesem można nazwać stan, w którym przestają działać wszystkie doinstalowane aplikacje i wymagana jest synchronizacja z iTunesem,
• tak jak pisałem — sytuacja ta przytrafiła mi się dwukrotnie. Za pierwszym razem udało mi się przy pomocy iTunesa przywrócić słuchawkę do normalnego stanu. Dzisiaj jednak czterokrotnie już zawiesił mi się iTunes, wgrywanie nowego softu na telefon zostało przerwane, później synchronizacja, później nie udało mi się w 100% przywrócić iPhone'a z kopii zapasowej (to po kiego grzyba ta urocza, trwająca wieki synchronizacja przy każdym podłączeniu do komputera?). W skrócie — telefon po kilku godzinach działa, ale nie mogę wgrać na niego muzyki, bo po 3 minutach od podłączenia i rozpoczęcia synchronizacji iTunes nagle stwierdza, że jednak dzisiaj nie ma na nią siły i bez jakiegokolwiek komunikatu kończy (nie powiadamiając o tym iPhone'a) synchronizację,

To wszystko zabolało mnie jednak w głównej mierze dzisiaj. Poprzednia akcja ze zwiechą podczas włączania telefonu zakończyła się udaną synchronizacją i przywróceniem akceptowalnego stanu. Tak więc co natchnęło mnie wczoraj do rozpoczęcia pisania tego wpisu?

• ten sprzęt jest niemożliwie, czasami aż do bólu groteskowo wolny,
• na początek, przez pierwszy rok (to tak jak w małżeństwie ;), było naprawdę spoko — nie miałem telefonowi nic do zarzucenia. Jednak po każdym upgradzie softu system staje się wolniejszy. Najgorzej było kiedy dziadek Dżobs postanowił wypuścić iPhone'a 3GS — wtedy odczułem bardzo duży spadek wydajności. Jeśli dziadunio myśli, że nakłoni mnie tym do kupienia jego młodszego dziecka, to grubo się myli — nie cierpię takiego cwaniactwa,
• wyciszenie iPhone'a czasami trwa ponad 4s — mam na myśli czas od zmiany ustawienia suwaka do jakiejkolwiek reakcji telefonu (wibracja, ekran),
• odblokowanie iPhone'a (takie codzienne — z trybu uśpienia) czasami trwa ponad 10s — najpierw trzeba poczekać aż pojawi się suwak, później aż zareaguje na ruch palca, później pojawia się klawiatura, która też potrzebuje czasu żeby sobie przypomnieć, że jest klikalna, a na koniec ikonki, które muszą sobie wyskoczyć z wszystkich rogów ekranu, zamiast po ludzku się pokazać,
• włączenie smsów, książki kontaktowej, ostatnich telefonów, czy listy alarmów... nawet nie chce mi się myśleć ile to potrafi zabrać czasu, ale i tak wielcy jabłkowi programiści "zoptymalizowali" te programy, bo było gorzej,
• iPhone lubi sobie co jakiś czas (tak raz na miesiąc) zgubić sieć — czasem podczas rozmowy, czasem podczas stanu uśpienia,
• czasem ten stan zgubienia sieci zamienia się w stan niemożliwości dodzwonienia się do mnie i zadzwonienia ode mnie (operator się buntuje) przez dłuższy czas,
• paczka z iTunesem ma 90MB. Co oni tam za przeproszeniem ładują? Zestaw animowanych emotek w formacie 128px na 128px na każdą porę dnia i nocy?,
• Synchronizacja trwa pół godziny (fakt faktem, że robię ją rzadko),
• iTunes jest niestabilny, nieużyteczny, ekstremalnie powolny, zasobożerny (wolę słuchać muzyki z Youtube'a — mniej ciągnie z proca) i nie rozumie oggów. Na dodatek zamiast napisać, że coś mu się nie podoba, że czegoś nie może znaleźć, czy że ma zły dzień, to milczy,

Wszystko to co mnie irytuje w tym telefonie nie zmienia jednak jednego — Apple ma niesamowitych projektantów interfejsów. Kiedy wreszcie pozbędę się tego bezużytecznego narzędzia, to nie sądzę żebym w jakimkolwiek innym systemie czuł się tak dobrze. Szkoda.

Powstrzymałem się w tym tekście od użycia naprawdę wielu brzydkich wyrazów, więc na koniec tylko podsumuję całą sytuację — kurwa, nigdy więcej sprzętu, którego nazwa zaczyna się od "ip".

Ciekawy jestem czy tylko ja mam takie problemy z tym telefonem. Przeszło mi rzecz jasna przez myśl, że słuchawka może być uszkodzona. Wolę jednak wierzyć, że pozostali też mają problemy, ale boją się to przyznać, bo przecież tak kiedyś zachwalali iPhone'a ;). Szkoda tylko, że kiedyś to był naprawdę fajny sprzęt.

Zadałem jakiś czas temu na blipie pytanie dotyczące artykułu Label Placement in Forms. Interesowało mnie czy może jest jakiś powód dla którego niektórzy (np. Marek Kasperski w swojej książce Projektowanie stron WWW) piszą aby labele do pól formularzy umieszczać na lewo od samych pól i wyrównane do prawej, a dlaczego inni (choćby autor tego artykułu) uważają, że najlepiej opis pola umieścić ponad polem, zmniejszając tym samym liczbę fiksacji wzroku? Czy Ci pierwsi nie znają badań? Czy kierują nimi jakieś inne przesłanki (np. praktyczne), o których ja nie wiem? Rzecz jasna, nie udało mi się tak doprecyzować pytania (ciężko się było w 160 znakach zmieścić :D).

Dostałem dwie odpowiedzi. Skopiowałem sobie kiedyś tylko ich treść, nie podam niestety linka, bo w blipowym archiwum nie mam szansy tego znaleźć. Tak wyglądała rozmowa:

reinmar: #usability labele nad inputami, czy na lewo od nich (wyrównane do prawej)? Za każdym razem piszą inaczej (choć to pewnie bez znaczenia)

PanA > reinmar: nie bez znaczenia, zależy co chcesz osiągnąć. U góry się szybciej czyta niż obok, mniej fiksacji

PanB > reinmar: [blip] tak jak mówi ^PanA, najlepiej nad ale pola muszą być udzielone, mogą też być po lewej ale z wyrównaniem do prawej

Zaciekawiło mnie co miał PanA na myśli pisząc: zależy co chcesz osiągnąć:

reinmar > PanA: To co mogę osiągnąć umieszczając je po lewej? Więcej fiksacji, więc umieszczać je tam jak chcę zniechęcić użytkownika? ;P

PanA > reinmar: czasami użytkownikowi nie ma być łatwiej - możemy chcieć zmusić go do zastanowienia się nad tym co wpisuje, etc.

reinmar > PanA: Dlatego odciągamy go od zastanawiania utrudniając ogarnięcie formularza? Czy dajemy mu więcej czasu na zastanowienie się

Uhh... Urocze powtarzanie usłyszanych od branżowych guru i wyczytanych z książek zdań. Zresztą - już moje pytanie było zadane złośliwie, bo po zależy co chcesz osiągnąć w miarę wiedziałem czego się mogę spodziewać.

Jednak nie do samej rozmowy chciałem bić w tym wpisie (dlatego też ocenzurowałem rozmówców - nie chcę tu dyskusji :P), a do dwóch błędów, które moim zdaniem wiele osób popełnia podczas projektowania.

Jestem specjalistą - przeczytałem 20 książek

Generalnie sytuacja ta odnosi się do każdej branży. Młodzi adepci Czegoś siadają do książek, chłoną, chłoną i napuchli wiedzą stają się w ich mniemaniu pełnowartościowymi specjalistami od Czegoś. Znają dziesiątki strasznie brzmiących terminów, mogą toczyć poważne dyskusje z ważnymi osobami ze świadka Czegoś. Zabawa kończy się jednak kiedy "specjalista" wkracza w granice praktyki. I tutaj, w zależności od osobowości i życiowej mądrości, z pokorą zbiera doświadczenie i weryfikuje posiadaną już wiedzę, bądź też dalej wygłasza znaną sobie teorię, która zupełnie nie ma zastosowania w praktyce.

Żeby była jasność - nie neguję wartości znajomości teorii i nie twierdzę, że ktoś kto poznał teorię może być dobrym praktykiem.

Tort, znaczek Nike i płyta DVD

PanB > reinmar: osobiście nad daje gdy jest mało pól, przy większej ilości daje z lewej

O. I to jest ciekawa odpowiedź. Rzeczywiście - ciężko przy 20 polowym formularzu dawać opisy ponad pola, ponieważ formularz ten rośnie nam do ogromnych rozmiarów. Przypomniała mi się jednak przenośnia (?), którą kiedyś wymyśliłem aby zobrazować w firmie jaki popełniamy błąd projektując funkcjonalności jednego serwisu. Wiele osób działa tak:

Weźmy tort, bo przecież każdy lubi tort. Tort jest fajny!

Weźmy znaczek Nike. Przecież jest teraz trendy, na pewno każdemu się spodoba.

Ja chcę jeszcze płytę DVD. Przecież jest taka funkcjonalna. Płyta DVD jest fajna!

I co dostajemy? Tort z przyklejonym z boku znaczkiem Nike i wbitą na sztorc płytą DVD. Dzieło sztuki po prostu. Niestety tak działa wiele osób - dobierając funkcjonalności serwisu wybierają (np. z konkurencyjnych rozwiązań) te, które są fajne, nie myśląc o tym, czy razem będą tworzyły spójną całość. Projektując interfejs zagłebiąją się w statystyki, badania, wybierają atomowo najlepsze, najszybsze, najczytelniejsze rozwiązania i nie patrzą na ogół serwisu. Nagminne.

Nim mnie zjedziesz

Nie, nie uważam się za specjalistę od użyteczności, nie przeczytał nawet 5 książek. Co więcej - możliwe, że PanA ma rację, a ja jestem zbyt ograniczony by go zrozumieć.

Tak samo - sam nie jestem wolny od wyśmiewanych przeze mnie błędów. Niestety ;)

BTW. muszę wreszcie stworzyć sobie jakiś design do tego blogaska.

Przez mój czytnik i mojego blipa przewija się masa linków. Część ze znalezionych informacji dodaję do swojego del.icio.us, jednak mimo to o tych najważniejszych / wartych najwięcej uwagi czasem zapominam. Pomyślałem więc, że będę publikował co jakiś czas najciekawsze moim zdaniem znaleziska z zakresu web developowania i usability. Raz, że samemu będzie mi łatwiej do tych informacji wrócić, dwa, że może komuś zaoszczędzę trochę czasu i podsunę coś czego jeszcze nie czytał.

Wiele z poniższych linków macie szansę znać, wiele to starsze informacje, ale to pierwszy wpis w tym cyklu (tak, jeśli będę miał o czym pisać, to może zacznę to robić regularnie :) - następne będą aktualniejsze i zgrabniejsze. Na dodatek aby znaleźć te linki niestety musiałem przeglądać historię i wiele ciekawych rzeczy mogłem pominąć.

Usability vel użyteczność

• AB Tests – strona zbiera wyniki testów A/B podsyłane przez czytelników. Nie zawsze są to wiarygodne testy (ze względu na zbyt małe próbki), ale jest też wiele wartościowych badań, z których można nauczyć się czegoś na przyszłość.
• 10 przydatnych wskazówek związanych z użytecznością – jak to w Smashing Magazine – krótko, treściwie, ładnie i z głową.
• Jak wygląda raport z audytu użyteczności – by Robert Drózd.
• UI Flow Shorthand Notation – prosty sposób na graficzne przedstawienie "flow" serwisu. Czyli podstrony, akcje użytkownika i ścieżki między nimi.
• Dlaczego zatrudnię do mojego startupu programistę gier – trochę mniej związane z usability, ale nadal.
• Google Analytics w kontekście użyteczności – prezentacja przeprowadzona przez Roberta Drózda na WUD Tour. O tym, że nie wystarczy odpalenie statystyk - trzeba jeszcze umieć ich użyć.
• Lista lektur o użyteczności – wrzucam ją chyba sam dla siebie, żeby się motywować do czytania :).

Łebowe i niełebowe programowanie

• Python - pomoce, kursy, ćwiczenia – zacząłem się ostatnio uczyć Pythona i tu znalazłem sporo ciekawych materiałów. Polecam Python Challenge – najbardziej praktyczna nauka języka :).
• O tym dlaczego chowanie elementów interfejsu przez display:none jest złe – Sam odpowiedzi nie znałem. Artykuł o tym jak to zrobić lepiej.
• Falsy values i operatory porównania w Javascriptcie – dla mnie same falsy values były oczywiste, gorzej jednak z operatorami porównania - warto zapamiętać.
• ECMA zatwierdza ECMAScript 5 jako standard – więcej informacji na ten temat.
• Słownik HTMLa 5 – bardzo wygodny i przejrzysty spis tagów. Do każdego elementu mamy opis i przykładowy kod (brakuje mi listy atrybutów). Warto do niego zaglądać (jak i na całego HTML5 Doctora).
• HTML5 WTF? – prezentacja w komiksowym stylu o HTMLu 5. W sam raz dla szefa :)
• Jak powinien wyglądać śliczny kod HTML – nie z każdym elementem się zgadzam, ale to temat na osobny wpis. W skrócie - HTML5 w praktyce.
• JS Ninja – kilka przykładów ataków XSS. Przydatne do samokontroli podczas pisania Javascriptu.

Inne

• Komiksy o świecie twórców stron – z humorem o naszej pracy i środowisku :)
• Klienci z piekła rodem – bez komentarza. Trzeba poczytać. W każdą z tych sytuacji jestem w stanie uwierzyć :P

Póki co na tym koniec. Od teraz co ciekawszy znaleziony link będę sobie odkładał, więc następne wydanie przeglądu prasy będzie aktualniejsze.

W zeszły czwartek (tj. 12 listopada) odbyła się Wrocławska część WUD Tour, na której miałem przyjemność być. Nawiasem mówiąc była to pierwsza konferencja poświęcona usability, na którą dotarłem, bo naście poprzednich albo przegapiłem, albo z przyczyn niezależnych dotrzeć nie mogłem. Tym razem też nie było idealnie, bo po kilku pierwszych prezentacjach musiałem udać się na zajęcia.

W skrócie co widziałem

• Wprowadzenie do tematyki usability - nic szczególnego, ani tym bardziej zaskakującego - raczej dla tych, którzy pomylili salę i potrzebowali wprowadzenia od zera.
• Akcelerator Designu - prezentacja pracowników Urzędu Miasta Wrocławia dotycząca inicjatywy mającej na celu promowanie idei wzornictwa przemysłowego i użyteczności wśród przedsiębiorców (itd., itd.). Temat póki co mnie nie prawie nie dotyczący, więc było trochę nudno. Sytuację poprawił dopiero trzeci z prowadzących będący z pochodzenia Włochem, który swoją łamaną polszczyzną bardzo zgrabnie przedstawił nam pewnego włoskiego designera. Kto był ten wie o czym mówię ;D
• Co chcą zobaczyć klienci sklepów elektronicznych? - O tej prezentacji za chwilę. W skrócie powiem tylko, że była całkiem ciekawa i tak "politechnikowo" przedstawiona :P
• Możliwość używania - drugi biegun względem poprzedniej ekipy (prosta graficznie prezentacja, ale ładnie opracowana typograficznie versus prezentacja "specyfikacyjna" :). Prelekcja przeprowadzona przez Krzysztofa Kubaska - pracownika ASP i projektanta wzornictwa zawodu, dotycząca łączenia użyteczności z designem. Krzysztof z powodzeniem pokazywał, że te dwie rzeczy mogą iść ze sobą w parze i współpraca designera z inżynierem jest jedną z podstaw dobrego produktu. Przy okazji pokazał kilka przykładów zabawnie zaprojektowanych przedmiotów codziennego użytku, jak np. widelec w kształcie samolotu (leci samolocik... AM! :P), czy kubków z dziobami/pyskami zwierząt. Krzysztof zrobił dobre wrażenie i myślę, że taki był główny cel tej prezentacji. Według mojej spiskowej teorii - śmiech -> dobre wrażenie -> więcej klientów ;). Zwróciłem też uwagę, że specjalistów od usability uważa za informatyków. Ciekawe :)

Później niestety musiałem już sobie iść. Najciekawsze prelekcje opuściłem i czekam z niecierpliwością na video z konferencji.

Czy użytkownik jest złym projektantem?

Wracając do prelekcji dotyczącej sklepów internetowych. Marcin Kuliński przedstawił nam narzędzie służące do badania preferencji użytkowników dotyczących rozmieszczenia elementów interfejsów (w tym przypadku sklepów internetowych). Narzędzie to składało się z dwóch części - pierwszej - bardzo prostej, pozwalajacej za pomocą drag&dropa zaprojektować z dostępnych elementów własny interfejs. Druga służyła do przeglądania wyników tego badania. Nie pamiętam wszystkich funkcji tego narzędzia, ale na pewno można było filtrować badanych, porównywać wyniki dla grup, itd.

Drugą część prezentacji prowadziła Katarzyna Jach, która przedstawiła wyniki badań na grupie, jeśli dobrze pamiętam, 500 studentów IZetu. Zostali oni zapytani gdzie umieściliby przedstawione im elementy interfejsu. Dla każdego z predefioniowanych elementów serwisu (logo, kategorie, zdjęcie produktu, itd) zobaczyliśmy "mapę cieplną" gdzie badani widzieli tę funkcjonalność. Wyników nie pamiętam i nie udało mi się ich znaleźć. Dotarłem tylko do screenów i dema aplikacji nazwanej pieszczotliwie microSzu.

Na zakończenie z sali padły dwa pytania. Jedno dotyczyło tego po co powstała ten system skoro można przeprowadzić testy A/B przy pomocy Google Website Optimizera (który jest bezpłatny, w przeciwieństwie do microSzu). Dla mnie odpowiedź jest oczywista (a pytanie bez sensu) - testy A/B pozwalają nam jedynie udoskonalać istniejącą już stronę i tylko element po elemencie. Wcześniej trzeba przecież tę stronę zaprojektować, czyli między innymi rozmieścić na niej elementy interfejsu. Badanie przeprowadzone przez microSzu pozwala nam na optymalne dla użytkowników zaprojektowanie strony. No właśnie - czy na pewno optymalne?

Tego dotyczyło kolejne pytanie, a w zasadzie stwierdzenie - "użytkownik nie jest dobrym projektantem". W pierwszym momencie stwierdziłem, że i to pytanie jest bez sensu. Nie dajemy przecież użytkownikowi projektować, tylko badamy jego preferencje. To przecież część UCD. Później (między innymi po przeczytaniu relacji Agnieszki Matysiak-Szóstek, której prelekcji nie widziałem, czego bardzo żałuję) zacząłem się zastanawiać, czy na pewno mam rację. W końcu badanie polegało nie tylko na odpowiedzi na pytanie gdzie szukałaby Pani/Pan listy kategorii?, ale na zaprojektowaniu całej strony na raz, czyli zmierzeniu się np. z problemem - ten róg mam już zajęty, gdzie ja teraz ciapnę to to?.

Myślę, że właśnie w treści pytania i zadaniu do wykonania leży cały problem. Gdyby udało się uzyskać od badanego wszystkie informacje, bez zmierzenia go z problemem całej strony jednocześnie, to uzyskane dane byłyby bardzo przydatne. Możnaby stworzyć proste wytyczne, w którym miejscu (bądź miejscach) możemy umieścić dany element by był łatwo znajdowalny (jeśli chodzi o region, bo pozostają użyte nazwy, czy kolor/wielkość/etc.) przez użytkownika. I nie musi to od razu ograniczać inwencji i talentu projektanta, który może zawsze zaryzykować jakąś zmianę względem szablonu. To jest tylko propozycja, a czy skorzystam, to zależy np. od ilości czasu jaką mogę projektowaniu poświęcić.

Tak przynajmniej myślę ja u początków mojej przygody z użytecznością :)