Zakładki:
Inne moje "rzeczy"
Inne rzeczy
Innych "rzeczy"
Książki
Możliwości i wzorce projektowe
Po godzinach
Rządzą... Gry
Zobacz mnie na GoldenLine
ThinkLab: moja firma

MOJE KSIĄŻKI - AUTOR

Użyteczność w praktyceM. Kasperski, A. Boguska-Torbicz Projektowanie stron WWW. Użyteczność w praktyce, Helion 2008.

Moja książkaM. Kasperski, Sztuczna Inteligencja, Helion 2003.

REDAKTOR MERYTORYCZNY

UmysłD. Casacuberta, Umysł. Czym jest i jak działa, Świat Książki 2007.

100 sposobów...T. Stafford, M. Webb, 100 sposobów na zgłębienie tajemnic umysłu, Onepress 2006.

Istota inteligencjiJ. Hawkins, S. Blakeslee, Istota inteligencji, Onepress 2005.

RSS
poniedziałek, 30 marca 2009

To drugi wpis z serii Wielogłos (poprzedni dotyczył ścieżki rozwoju osobistego w działce Usability). Tym razem tematem przewodnim jest Projektowanie Zorientowane na Użytkownika.

Zagadnienie ogólne, co - jak mam nadzieję - pozwala na spojrzenie wielowymiarowe do zagadnienia i odkrywa indywidualny sposób podejścia Autorów.

Wśród zaproszonych znaleźli się: Robert Drózd (WebAudit), Joanna Kotala (Ideacto), Krzysztof Piwowar (ADV, blog Usability On Air) i na końcu moja wypowiedź - a ja nazywam się Marek Kasperski :) (ThinkLab).

 

Robert Drózd (Webaudit)

Projektować będziemy tak czy inaczej. Jak zorientować to projektowanie na użytkownika? Użytkownik musi być na początku, w środku i na końcu tego projektowania. Tylko wtedy mamy pewność, że projekt nie wymknie się nam spod kontroli.

Na początku – na użytkownika musimy przemapować wszystkie cele, jakie stawiane są przed projektowanym produktem. Z różnych technik, które pozwalają nam dowiedzieć się czegoś o naszych użytkownikach (i znaleźć ich cele) najbardziej lubię jakościowe: indywidualne wywiady bezpośrednie i obserwacje. Typowe techniki badań marketingowych, jak fokusy, ankiety, CATI będą już mniej przydatne, bo po prostu możemy nie trafić z pytaniami – i dowiemy się zupełnych banałów. Następnie wyniki musimy sobie przerobić na narzędzia z których da się skorzystać – przede wszystkim profile użytkowników i przypadki użycia. Jedna rzecz, o której nie wolno zapomnieć – to są narzędzia dla nas, a nie dla klienta czy programistów. Jeśli nie potrafimy z nich skorzystać podczas projektowania, straciliśmy czas.

W środku procesu projektowania musimy wciąż czuć oddech użytkownika na plecach. Niedosłownie – przez ciągłe odwoływanie się do przygotowanych wcześniej person i scenariuszy. I dosłownie, przez konfrontowanie z użytkownikami kolejnych iteracji projektu, na przykład makiet i prototypów.

Pamiętać trzeba jednak o tym, że wiedza o użytkownikach ma nam pomagać, ale nie może determinować naszych decyzji. W wielu przypadkach nie jesteśmy w stanie przewidzieć, czy użytkownik na pewno nie zachowa się tak jak zapowiadał, czy jak to wynikało z poprzednich badań. Czasami innowacyjność wymaga pewnego zignorowania przyzwyczajeń użytkownika, a nowy produkt na początku wywoła szok i zagubienie. Byleby tylko na początku! Tylu ludzi narzekało na wstążki w Office 2007 i nie umiało wykonać w nowym Wordzie podstawowych operacji. Przyzwyczaili się i polubili wstążkę, a jej metaforę przejęły po Microsofcie inne firmy.

Na końcu projektowania są testy użyteczności. I jeśli ich nie udało się przeprowadzić w czasie trwania projektu, teraz są już niezbędne. Jeśli bieżącego projektu już nie zdążymy poprawić, to będziemy mieli podstawy do jego następnej wersji. Jeśli nie przypomnieliśmy sobie o użyteczności dopiero teraz, nie będzie raczej wielkich problemów. W innym przypadku nową wersję będziemy czasami musieli wykonać bardzo szybko. Tak stało się w przypadku systemu blogowego WordPress, gdzie nieudana wersja 2.5 została zastąpiona wersją 2.7 w ciągu pół roku.

Testy to jednak nie wszystko – powinniśmy określić metryki, które – w oparciu o zachowanie czy satysfakcję użytkownika – pozwolą nam ocenić skuteczność naszego projektu i wprowadzanych w nim zmian. Na przykład dla serwisów internetowych podstawą jest wykonywanie pożądanych akcji, lojalność i częstość odwiedzin dla osób powracajacych. Statystyki w serwisie zorientowanym na użytkownika mówią bardzo wiele o jego „pulsie” i pomagają wychwycić problemy, zanim jeszcze doniosą nam o nim sami użytkownicy, lub dowiemy się w teście.

 

Joanna Kotala (Ideacto)

Na projektowanie produktu patrzę zawsze z perspektywy wszystkich ludzi zaangażowanych w jego tworzenie – od sponsorów, analityków, projektantów, grafików, programistów aż do testerów. Produkt końcowy, z którego korzystają użytkownicy, jest rezultatem pracy całej grupy, a nie jedynie twórcy interfejsów, zwolennika Projektowania Zorientowanego na Użytkownika. Nawet przy starannie przygotowanym projekcie wpada on w ręce ludzi często mniej entuzjastycznie podchodzących do zagadnień użyteczności. Jak sobie z tym poradzić? Dobrą radą na początek jest staranne zaplanowanie zadań związanych ze zdobywaniem i analizą wiedzy o użytkownikach, projektowaniem, prototypowaniem itp. od strony zarządzania całym projektem. Inną zasadą, zaczerpniętą z Projektowania Kontekstowego – dla mnie jest to właśnie UCD w praktyce – jest angażowanie pozostałych członków zespołu w proces projektowania. W ten sposób pokazujemy im, że produkt będą używali konkretni ludzie, którzy mogą mieć zupełnie inne potrzeby niż my sami. Co więcej obecność dodatkowej osoby w procesie projektowania interfejsu daje nam nowe spojrzenie na to co robimy.

Pamiętam jak pierwszy raz w Ideacto zrobiliśmy wspólną sesję interpretacyjną danych o użytkownikach. Początek był trudny, ale rezultaty inspirujące. Nagle ci, którzy tylko słyszeli o UCD, zaczęli patrzeć na cały projekt przez pryzmat porozkładanych na stole karteczek z notatkami o użytkownikach. Co więcej, zaczęli kreować pomysły na rozwiązania interfejsowe, które jak się później okazało, odpowiadały potrzebom użytkowników. A przecież o to właśnie chodzi…

 

Krzysztof Piwowar (ADV, Usability On Air)

Pełen teoretyczny model UCD w praktycznym zastosowaniu występuje równie rzadko, jak Yeti. Bardzo wielu o nim słyszało, kilku miało szczęście widzieć go na własne oczy, pojedynczym udało się zrobić zdjęcie. I to nie dlatego, że model UCD to wymysł teoretyków. Po prostu jego realizacja wymaga bardzo specyficznych warunków, które niestety przyrodzie nie występują zbyt często. Oczywiście, wcale nie oznacza to, że należy się zrażać na starcie i prawdą jest, że należy walczyć o każdy jeden klocek z modelu – jeśli jego wykorzystanie ma służyć dołożeniu kolejnego właściwego puzzla do układanki projektowej.

Dzięki metodologii UCD w rękach zespołu projektowego mamy do wykorzystania m.in. takie narzędzia jak: grupy fokusowe, wywiady, ankiety, sortowanie kart i testy z użytkownikami, ale o tym czytelnicy tego bloga zapewne bardzo dobrze już wiedzą (jeśli nie, warto przywołać pamiętny plakat autorstwa Tomka Karwatki). Istotne w tych narzędziach jest to, że każde angażuje użytkownika końcowego i to dzięki niemu zespół uzyskuje dane do podejmowania decyzji – a im więcej jakościowej wiedzy, tym lepsze rozwiązania można zaproponować.

W praktyce jednak każdemu zespołowi przychodzi skonfrontować świadomość i potrzebę wykorzystania tychże narzędzi z rzeczywistością, gdzie dochodzą do głosu takie obszary jak: rentowność i budżet projektu, cele biznesowe klienta oraz deadline. To głównie one okrajają teoretyczny UCD, jaki znamy. I to właśnie z ich powodu można w takiej sytuacji poczuć się odrobinę schizofrenicznie.

Ale i na to jest sposób – praktyczny oczywiście :). Model teoretyczny UCD nie mówi nic o celowości wykorzystania wyżej wymienionych narzędzi. Mówiąc prostym językiem – praktyce nie wszystko zawsze musimy stosować. Model praktyczny (życiowy) dopuszcza ustalenie wartości narzędzi i umożliwia wybór tych, z których uzyskamy najbardziej wartościowy feedback oraz wiedzę – z punktu widzenia projektu i jego realiów. Po drugie - praktyczne podejście wymaga popatrzenia na projekt nie tylko z punktu widzenia użytkownika (user-centered) ale i z poziomu biznesowego klienta. I to właśnie w tym tkwi magia praktycznego wykorzystania projektowania zorientowanego na użytkownika. Aby uzyskać konsensus pomiędzy celami i potrzebami użytkowników a celami i potrzebami biznesowymi klienta. W inną stronę się nie da.

UCD w praktyce z mojego punktu widzenia to właśnie szukanie i znajdowanie takiego złotego środka. Jest on ciężki do osiągnięcia, ale gdy się go raz skosztuje, chce się go znowu spróbować – nie teoretycznie, ale właśnie praktycznie. Dlatego też pozwolę sobie na następujące stwierdzenie: UCD praktyczne jest jak uzależnienie – z tą różnicą, że wychodzi na dobre i więcej niż jednej osobie.

 

Marek Kasperski (ThinkLab.pl)

W jednej z książek, które miałem okazję czytać - bodajże w "Projektowanie nawigacji strony WWW" Kolbacha - autor definiuje pojęcie Projektowania Zorientowanego na Projektanta (PZnP). To po Projektowaniu Zorientowanym na Klienta (PZnK, osoby z działu marketingu, sprzedaży, prezesa, ...) bodajże najbardziej rozpowszechniona metoda pracy projektowo-badawczej w interesującym nas obszarze.

Na początku książki „Projektowanie stron WWW. Użyteczność w praktyce” opisuję elementy związane z projektowaniem w metodyce UCD (s. 12-16) – zarówno w ramach budowania interdyscyplinarnego zespołu projektowego, jak i elementów szerszego procesu jakim de facto jest Projektowanie Zorientowane na Użytkownika (PZnU). Nie będę chciał się tutaj specjalnie powtarzać, ale zwrócę uwagę na kilka istotnych z mojego punktu widzenia elementów.

1. PZnU nie stoi w żaden sposób w sprzeczności z interesami PZnK. Jeśli w wyniku analizy danych zebranych w ramach statystyk, wywiadów z użytkownikami, clicktrackingu, tak by wynikało, to mamy poważny problem. Tak jak nie należy ignorować głosu użytkowników, tak interes klienta powinien być dla Ciebie równie istotny. Staraj się nie dopuszczać do sytuacji, w której stajesz się advocatus diaboli użytkowników i zwracasz się przeciwko interesom klienta. Co będą warci użytkownicy, gdy biznes klienta będzie zagrożony?

2. Zbieraj dane od użytkowników. Ile się da. Wykonaj, jeśli możesz:

  • Badania satysfakcji klientów z aktualnie istniejących rozwiązań (bądź w ramach strony WWW klienta jeśli to redesign, bądź w ramach analizy konkurencji). Możesz to zrobić online na przykład w formie ankiet (w książce też pisałem o badaniu ankietowym, które przeprowadziłem w swoim czasie na GoldenLine), albo w ramach grup fokusowych.
  • Badania potrzeb grupy docelowej. Może się okazać, że aktualna strona WWW nie spełnia wszystkich potrzeb użytkowników; zresztą podobnie jak strony konkurencji (ostatnio często powtarzam, że rozwiązania webowe są daleko w tyle za tymi, który zostały wykształcone w świecie rzeczywistym i jeśli chcesz sprzedawać elementy wyposażenia łazienek, to wcale nie oznacza, że powinieneś użyć do tego klasycznego sklepu internetowego).
  • Badania zachowań użytkowników na stronie WWW. Niestety, jest to możliwe tylko w przypadku, gdy pracujesz nad rozbudową bądź modyfikacją istniejącego już serwisu. Ale przeglądnij dane ze statystyk (skonfrontuj je ze stroną, by zobaczyć na ile wiarygodne są te dane – zob. jeden z przypadków, które opisuję na blogu Ideas2Action), mapy cieplne z clicktrackingu (coraz powszechniej wykorzystywane i słusznie), testy z użytkownikami, z użyciem scenariuszy użycia plus – jeśli możesz – z eyetrackerem (teraz miałem taki przypadek, gdzie dane z eyetrackingu stanowiły świetne uzupełnienie danych z clicktrackingu, dzięki czemu uniknęliśmy z klientem pójścia na łatwiznę przy interpretacji danych).
  • Zbierz i zanalizuj dane krytyczne. Określenie ‘dane krytyczne’ ukułem na potrzeby rozmów z klientami. Są to elementy z obszarów Pomocy, FAQ, pytania zadawane w ramach korespondencji, kliknięcia w części Mapa serwisu czy logi zapytań do wyszukiwarki. To ważne, a pomijane bardzo często, tropy, które pokazują z czym użytkownicy mają kłopoty.

3. Zbieraj dane od klienta. To się rozumie samo przez się. Ważne, że nie wszystkie Twoje pomysły i pomysły użytkowników będą stały w zgodzie z interesami klienta. Nie warto tym sobie zaprzątać głowy – zawsze będzie mógł je wykorzystać w ramach kolejnych prac z innym klientem.

4. Myśl... krytycznie. No właśnie. Doświadczenie uczy, że prawda leży gdzieś po środku, a w ramach UCD niejednokrotnie jeszcze zostanie zmodyfikowana :). Na końcu jesteś Ty, jako projektant, bądź Twój zespól. Musicie podjąć decyzję co jest ważne, a co nie – zarówno dla klienta, jak i dla użytkowników. W ten sposób powracamy do PZnP – Projektowania Zorientowanego na Projektanta... chociaż już z inną specyfiką danych wejściowych :).

13:06, marekkasperski
Link Dodaj komentarz »
poniedziałek, 09 marca 2009

Bywa, że jestem pytany o to, na co zwrócić uwagę w kształceniu kadry związanej z problematyką UCD (zarówno projektowaniem, jak i analizami z zakresu usability).

Gdy jeszcze pół roku temu prowadziłem dział User Experience w MRM Worldwide, zastanawiałem się dość często w jaki sposób stymulować moich pracowników i na co zwracać uwagę, przy rozwoju ich kompetencji. Najczęściej rzecz jasna do każdej z osób należy podejść indywidualnie tak, by wyciągnąć to, co ma najlepsze i popracować bardziej w tym obszarze, z którym ewidentnie pracownik sobie nie radzi.

Nie istnieje chyba nic takiego jak przepis na kształcenie zdolności projektowych; chociaż jest to wypadkowa wiedzy, doświadczenia i naturalnych skłonności (dla przykładu spotkałem się z osobami, które miały wybitnie rozwinięte myślenie analityczne, jednakże przeszkadzało im to wyraźnie w spostrzeganiu projektu jako całości).

Nie zamierzam się tutaj wymądrzać nt. tego, co w procesie edukacji (samoedukacji?!) jest ważne, a co nie - sam codziennie uczę się czegoś nowego - ale chciałbym zaspokoić potrzebę udzielenia odpowiedzi. Do tego zadania poprosiłem także moich kolegów po fachu - osoby, które cieszą się świetną (i zasłużoną) opinią (w kolejności alfabetycznej): Roberta Drózda, Tomka Karwatkę oraz Eryka Orłowskiego, by bazując na swoich doświadczeniach zechciały podzielić się obserwacjami. (Generalnie, jeśli idea się przyjmie, to będę chciał wprowadzić element wielogłosu na blogu, częściej prosząc innych specjalistów o podzielenie się wiedzą).

Ja pozwolę sobie na krótkie podsumowanie na końcu (poza porządkiem alfabetycznym :).

 

Robert Drózd (Webaudit)

Jak zostać dobrym fachowcem od usability?

Musisz umieć dwie rzeczy. Po pierwsze, spojrzeć na stronę czy aplikację oczami użytkownika. Po drugie, spojrzeć na użytkownika oczami systemu, którego częścią jest ta strona.

Wcielenie się w rolę użytkownika jest najtrudniejszym - psychologicznie - elementem całej pracy. Bo ta perspektywa wcale nie jest oczywista i co chwilę będziemy od niej odciągani - czy to przez innych ludzi, czy przez nasze przyzwyczajenia. Przy systemie jako całości oraz każdym najmniejszym elemencie, trzeba zawsze odwoływać się do doświadczeń pojedynczej osoby, która na ten element trafi w interakcji.

Spojrzenie "oczami systemu" wymaga z kolei znajomości tego systemu - czyli najczęściej po prostu biznesu, który prowadzą nasi klienci. Nie zapłacą nam za akademickie dywagacje. To co przygotujemy ma działać w ich otoczeniu, dla ich klientów, budżetu czy innych zasobów.

Od czego zacząć?

  1. Naucz się najważniejszych zasad, jakie rządzą interakcją człowieka z komputerem. Znajdziesz je w najpopularniejszych książkach na ten temat (Krug, Nielsen itd.). Nigdy nie traktuj ich jak dogmatów, ale za każdym razem próbuj zrozumieć dlaczego są takie, a nie inne.
  2. Pamiętaj o "trzech filarach użyteczności": marketingu, psychologii oraz informatyce. Pisałem o nich rok temu na swoim blogu. Użyteczność jest właściwie nauką interdyscyplinarną. Jeśli kuleje jeden z tych obszarów, możesz na przykład proponować świetne rozwiązania, które nie będą nadawały się do wdrożenia.
  3. Naucz się metod oceny i projektowania, ale zawsze pamiętaj, że sama metoda nie da nam gotowych wniosków. Wnioski zawsze zależą od nas.
  4. Miej jak najwięcej styczności z użytkownikami. Rozmawiaj, obserwuj, testuj, pytaj. Nigdy nie zakładaj, że nauczyłeś się już wszystkiego.

Co jeszcze? Ani projektowanie, ani ocenianie użyteczności nie dadzą się zamienić na suche procedury. To co na pierwszy rzut oka wygląda banalnie, w rzeczywistości jest i sztuką i nauką. Trzeba poszukiwać w sobie pasji, która będzie potrafiła połączyć wiedzę oraz intuicję.

 

Tomek Karwatka (Divante)

Pracowałem z wieloma ludźmi od usability i generalnie dzielę ich na dwa typy osobowości / umiejętności.

Analitycy - osoby specjalizujące się w rozbijaniu rzeczy na atomy i znajdowaniu niuansów, osoby te potrafią najbardziej przerażający projekt rozłożyć na atomy z pomocą łyżeczki i kilku miesięcy. Projektanci - z trochę wizjonerskim podejściem i parciem na kreatywne wymyślanie nowego, niekiedy mają problemy z zamykaniem spraw. Sam należę chyba do tej drugiej grupy. Nie sprawia mi przyjemności zagłębianie się w detale i zawsze jest w moim zespole ktoś kto jest w tym dużo lepszy ode mnie. Obecnie w zasadzie w moim zespole jest ktoś lepszy ode mnie w każdej dziedzinie na jakiej się znam - polecam, to doskonałe uczucie pracować z ludźmi, od których możesz się tyle nauczyć!

Wracając do usability - wydaje mi się, że w pierwszej fali zainteresowania tematem (powiedzmy w okolicach 2004) osób z duszą audytora było zdecydowanie więcej i większa część rynku właśnie tak pojmowała usability. Sami robiliśmy wtedy dużo audytów - miały swoją wartość, ale z perspektywy czasu widzę, że mogliśmy pracować efektywniej. Wszyscy się uczyli tematu.

Dziś coraz częściej mówi się o projektantach interakcji i podkreśla się połączenie tej dziedziny z marketingiem, tworzeniem produktu jako takiego. To dobrze, bo dobry zespół musi mieć szerokie kompetencje, a weryfikacja jego pracy dokonuje się na rynku, a nie w laboratorium.

Co bym poradził osobom, które chcą wejść do branży? Zacząć coś robić. I mam tutaj na myśli nie tyle czytanie książek i blogów, co po prostu projektowanie produktów. Zamiast wytykać błędy Merlinowi czy Allegro, lepiej zaprojektować coś samemu i zrozumieć, jak radzić sobie w świecie pełnym ograniczeń (jak poprawić usability darmowego OS Commerce, jak dogadać się z grafikiem, co zrobić aby odwiedzający serwis wrzucili coś do koszyka).

Ja zaczynałem po prostu od robienia serwisów - zacząłem na poważnie w 1999. Robiliśmy między innymi niekomercyjny magazyn internetowy, który nazywał się NoName. Wszyscy dużo się uczyliśmy i nikt nie myślał wtedy o „monetyzacji ruchu”. Później zacząłem pracę w firmie informatycznej, potem w agencji reklamowej (projektowałem między innymi stoiska targowe i nawet wygrywaliśmy konkursy :)). Zajmowałem się też tworzeniem programów edukacyjnych i gier. Później przyszedł czas na agencję interaktywną. W międzyczasie zostałem współudziałowcem sklepu internetowego. Dziś pracuję w Ideacto jako konsultant pomagający firmom budować biznes w Sieci oraz prowadzę własną firmę IT. Angażuję się też w projekt Biznes20.pl, który ma służyć wymianie wiedzy (już niedługo także pomiędzy branżami). Jak widzisz, przede wszystkim staram się zbierać doświadczenia, bo to jest szalenie pomocne w pracy projektanta.

Przedłożyłbym doświadczenie i zaangażowanie nad każde formalne wykształcenie. Sam pracuję z bardzo wszechstronnymi ludźmi o bogatych doświadczeniach i widzę jak wielki potencjał to wytwarza.

Jeśli chcesz zostać projektantem interakcji - znajdź swój zespół i zacznijcie coś robić, najlepiej coś co sprawi wam dużo frajdy.Wwszystko inne przyjdzie samo - szybciej niż myślisz.

 

Eryk Orłowski (Komitywa)

Nie chciałbym odnosić się do siebie, jako wzorca - tego nawet moje ego nie zniesie ;) Wolę dwa słowa o tym, co zrobiłbym sam, gdybym zaczynał od zera.

Zacznijmy od edukacji. Dziś na rynku mamy już kilka uczelni i kierunków, które pomogą adeptom projektowania dla użytkownika - SPiK w Szkole Wyższej Psychologii Społecznej, kognitywistykę na UAM. Osobiście zacząłbym od kierunku, który pozwala zarówno zrozumieć użytkownika na poziomie procesów poznawczych, jak również wprowadza studentów w świat dostępny dotąd wyłącznie dla informatyków - mowa o kognitywistyce.

Poza wiedzą na poziomie akademickim, bardzo ważne jest nabyte możliwie najprędzej praktyczne doświadczenie. Nadal mamy na rynku zbyt duży rozziew pomiędzy codzienną pracą w organizacjach komercyjnych, a podejściem wyniesionym z uczelni. Na szczęście, to się powoli zmienia, choć mam wrażenie, że głównie za sprawą tych zainteresowanych, którzy nie czekają do dyplomu z podjęciem pracy bądź praktyk.

To wszystko to podstawy. A dobrym fachowcem zostaje się poprzez krytyczne podejście do powszechnie wyznawanych pseudozasad i wykorzystanie posiadanej, bądź nabytej, skłonności do myślenia "out of the box". Na początek przyda się wiedza wyniesiona ze szkoły plus szczypta zdrowego sceptycyzmu. W sumie - jak w każdej chyba branży.

 

Autora Podsumowanie :)

Dla mnie cały czas nie tracą na ważności 10 przykazań projektowych, które w swoim czasie udało mi się spisać.

Generalną zasadą jest znalezienie źródła nieustających stymulacji - jeśli nie dostarczają Ci ich w Twojej firmie, sam sobie je organizuj i PATRZ (z otwartością poznawczą). Staraj się oglądać kilka-, kilkadziesiąt serwisów dziennie - nie pod kątem ich zawartości merytorycznej, ale zasad na jakich działają, zarówno na poziomie ogólnym (strategii) jak i w detalach (rozwiązań interfejsowych).

Zgadzam się z moimi przedmówcami co do istotności wiedzy. Zdobywa się ją zasadniczo na dwa sposoby: projektując na co dzień, bądź czytając / podglądając jak projektują inni. Wątek związany z podglądactwem jest dość istotny, gdyż uczysz się jak rozwiązywać problemy (czasem też jak ich nie rozwiązywać, co też jest nie do przecenienia) plus zdobywasz informacje, którymi możesz się posłużyć przy kolejnych projektach.

I najważniejsze - nie śpiesz się! Nie myśl o szybkich awansach (to zmora), bo niczego się nie nauczysz; a jak się nauczysz, to awanse przyjdą same :) Powoli, ale konsekwentnie. Opanuj terminologię; wytyczne z guidebooków popularnych systemów operacyjnych; nie zamykaj się na nowości; staraj się myśleć poprzez analogię a zobaczysz, że na pewnych poziomach nawet innowacyjne rozwiązania, czy wydawałoby się zupełnie nowe problemy, można uchwycić w ramach klasycznych rozwiązań.

A ostatecznie: projektując nie myśl o interfejsach - myśl o ludziach i ich potrzebach, to dla nich w końcu projektujesz.

14:02, marekkasperski
Link Komentarze (5) »
poniedziałek, 02 marca 2009

Siatki (ang. grids) to niezbyt popularny temat w krajowym środowisku projektowym, a który pojawia się czasem w dyskusjach, niekoniecznie oddając swój sens (zdarzyło mi się już kilkukrotnie słyszeć od klienta, bym mu poprawił siatki, mając na uwadze, że rozchodziło mu się o architekturę informacji).

Architekturę informacji - ale i layout - można opierać o siatki, ale nie jest to niezbędne dla czytelnej prezentacji danych (toczyłem zresztą w swoim czasie spór o to z jednym grafikiem). Podstawową przesłanką projektowania w oparciu o siatki jest teoria wywodząca się ze szkoły Pitagorejskiej (bliskiej mojej umysłowości), wg której u podstaw świata stały liczby i związki między nimi.

By pozwolić zrozumieć podstawy teorii siatki, spróbuję dokonać rekonstrukcji mojej wiedzy z zakresu studiów z filozofii :)

 

Elementy teorii piękna

Pitagorejczycy wierzyli, że najwyższym dobrem w świecie jest ład, który określali mianem harmonii (wcześniej ten termin nie istniał i to właśnie Pitagorejczycy nadali mu sens). Harmonia była wyrazem stosunków między poszczególnymi bytami, w tym stosunków w ramach elementów bytów. Teoria ta dotyczyła całej wiedzy na temat świata - zarówno spraw związanych z metafizyką jak i natury piękna, która jest przedmiotem estetyki. Wedle teorii tej by móc stwierdzić, czy dane dzieło jest piękne, należało zbadać stosunek poszczególnych części dzieła określanych mianem modułów. Dotyczyło to tak architektury, jak i sztuki sakralnej i użytkowej.

***

Na marginesie: na podstawie teorii piękna opartej o badanie stosunków modułów do siebie, powstał kanon (zapożyczony zresztą ze sztuki starożytnego Egiptu), w tym słynny kanon Leonarda da Vinci, zilustrowany jako mężczyzna z rozłożonymi ramionami, wpisany w kwadrat i koło.

***

Dążąc do określenia podziału idealnego, Pitagorejczycy odkryli liczbę φ (fi), wyznaczającą złote - czy też boskie - proporcje:

"boska proporcja (łac. sectio aurea) - podział odcinka na dwie części tak, by stosunek długości dłuższej z nich do krótszej był taki sam, jak całego odcinka do części dłuższej (stosunek ten nazywa się złotą liczbą i oznacza grecką literą φ)."

Liczba ta odegrała kolosalne znaczenie w architekturze, wyznaczając m.in. ślimaczycę głowicy jońskiej (na rysunku poniżej).

Złoty podział.

 

Na jej bazie wzniesiono także m.in. Partenon (studium proporcji), wyrzeźbiono słynne posągi - Apolla Belwederskiego (zdjęcie, studium proporcji) czy Afrodytę z Milo. Ma także ona znaczenie w ramach tego co wiemy z zakresu teorii widzenia: otóż oko ludzkie ulega wielu złudzeniom optycznym i tak na przykład, by uniknąć deformacji widzianej ludzkim okiem kolumny, leciutko pogrubia się ją w 1/3 wysokości.

 

Teoria siatki

W formie uproszczonej złote proporcje oddaje się w ramach trójpodziału, dzieląc płaszczyznę na trzy części, w celu wydzielenia ram dla kompozycji: 2/3 + 1/3 (poniżej).

Złoty podział o liczba Fi.

Jak widać na powyższych rysunkach, stosując zasadę trójpodziału tworzymy coś w rodzaju siatki, na bazie której będziemy mogli zakomponować podstawowe bloki treści (zdjęcia, video, tekst), określić ich szerokości, odstępy między nimi, a czasem nawet i wysokości tak, że w ten sposób powstała kompozycja będzie spełniała warunki harmonii (w sensie teorii Pitagorejczyków rzecz jasna).

W malarstwie sztukę opartą o studium siatek rozpropagował holenderski malarz, Piet Mondrian (poniżej przykładowy obraz).

Oczywiście nie wszystkie siatki zbudowane są o zasady złotego podziału. Czasem efektem końcowym ma być dynamiczna kompozycja, albo taka, która wywołuje w widzu rozdrażnienie, a nie poczucie harmonii.

Piet Mondrian: obraz.

 

Metoda kompozycji na bazie siatek przyjęła się także w ramach składu prasy, książek i drukowanych produktów reklamowych (rysunek poniżej). Jeśli zaś chodzi o WWW, to pierwszą bodajże stroną internetową zbudowaną w oparciu o siatkę była witryna New York Times. Ale o tym będzie już w osobnym wpisie, poświęconym praktyce stosowania siatek.

Siatki w składzie czasopsim.

 

Polecam uwadze knigi:

W języku polskim chociażby:

21:46, marekkasperski
Link Komentarze (6) »