Poniższa publikacja jest związana z Pierwszym zjazdem architektów informacji Polish IA Summit, który to zjazd jest wspierany przez autora niniejszego blogu.
Zacznijmy od odrobiny teorii. W czasach blogosfery nikogo chyba przekonywać nie trzeba o rosnących trudnościach w docieraniu do treści. Lawinowy przyrost informacji, rozpoczęty w XX wieku proporcjonalnie zwiększył potrzebę organizowania – klasyfikowania, nadawania odpowiednich etykiet. Peter Morville, autor obowiązkowej lektury Information Architecture for the World Wide Web, podaje kilka powodów, dla których organizacja nie jest prosta, wśród których wymienia niejednorodność.
O co chodzi? Otóż klasyczne katalogi biblioteczne zawierały zawsze ten sam, homogeniczny zestaw metadanych dla każdej pozycji – autor, tytuł, temat, data wydania, etc. Za pośrednictwem karty katalogowej nie ma możliwości uzyskania dostępu do treści wolumenu. W internecie metainformacje nie są już oddzielone od opisywanej informacji. W efekcie gromadzimy więc w jednym worku zarówno treść, jak i metadane, które w założeniu pomagać nam mają w odnajdywaniu interesujących nas kwestii. Oczywiście paradoksalnie powiększa to cały bałagan, choć w założeniu chodzi o uporządkowanie.
W jaki sposób wykorzystuje się metadane (zobacz także zestawienie Dublin Core Metadata Element Set)? Opisanie treści we właściwy sposób pozwala na właściwe klasyfikowanie dokumentu. Dzięki odpowiedniemu oprogramowaniu, obsługującemu tzw. słowniki kontrolowane i tezaurusy, w tej samej kategorii serwisu www odnajdziemy odnośniki do zbliżonych znaczeniowo tekstów. Znacznie ciekawsze jednak mogą być aplikacje nietypowych systemów klasyfikacyjnych, opartych na analizie znaczeń publikowanych w internecie treści. Zanim jednak do tego przejdziemy, jeszcze dwa słowa o “tradycyjnych” sposobach organizacji informacji.
Architektura informacji w Sieci
W jaki sposób zatem organizuje się informacje w sieci WWW? Każda organizacja wymaga jakiegoś klucza, wedle którego poukładamy treści. Może to być klucz:
alfabetyczny,
chronologiczny,
geograficzny,
tematyczny (prawdopodobnie najbardziej rozpowszechniony),
zadaniowy,
audytorium (do kogo skierowana jest informacja?),
metaforyczny,
hybrydowy, łączący kilka kryteriów.
Rozwój serwisów społecznościowych dodał do powyższej listy kategoryzację folksonomiczną, znaną szerzej jako tagi. Z ciekawszych koncepcji warto wymienić także tak zwaną nawigację fasetową, zwaną gdzieniegdzie dynamiczną taksonomią. Umożliwia ona łączenie wielu kluczy przeglądania/wyszukiwania w celu zawężenia wyświetlanych wyników
Ilustracja: bardzo ciekawe demo nawigacji fasetowej pod nazwą elastic lists z serwisu well formed data.
Zorganizowana informacja wymaga odpowiedniej prezentacji, umożliwiającej użytkownikom poruszanie się po strukturze. Prezentację stanowi warstwa nawigacji – widoczne dla internautów systemy przeglądania treści. Poza systemami nawigacji serwisów internetowych, mamy dodatkowo do dyspozycji wbudowane mechanizmy przeglądarek, w teorii ułatwiające poruszanie się po przeglądanych treściach.
W teorii, ponieważ wszyscy znamy efekty konfliktu pomiędzy nieumiejętnie skonstruowaną nawigacją serwisu, a intuicyjnie naciśniętym przyciskiemwstecz w przeglądarce.
W poszukiwaniu sensu, czyli Semantyczna Sieć raz jeszcze
Od klasyfikacji informacji ciekawsze mogą być algorytmy umożliwiające analizę samego znaczenia treści. Systemy typu data-mining czy też content intelligence mogą mieć kilka zastosowań w internecie - od nawigacji opartych na opiniach użytkowników, po aplikacje wspomagające decyzje biznesowe.
Data mining nabiera być może szczególnego znaczenia w czasach masowych publikacji przez miliony pojedynczych użytkowników internetu. Pozwala bowiem na syntezę informacji z wielu rozproszonych źródeł, niemożliwych do przetworzenia w rozsądnym czasie przez człowieka. Najogólniej rzecz ujmując, taka semantyczna analiza treści polegać może na:
dopasowaniu poszukiwanych wzorców – polegającym na zliczaniu odpowiednich określeń w analizowanych tekstach,
badaniu lingwistycznym struktury wypowiedzi – opierającym się m.in. na słownikach kontrolowanych z analizowanej dziedziny.
Zautomatyzowane przetwarzanie treści internetu pozwala chociażby poznać opinie klientów na temat marki i produktów firmy oraz jej konkurentów – wykorzystując tzw. sentiment analysis. Możliwe jest badanie wpływu komunikacji marketingowej na odbiorców – przeprowadzone chociażby na forach konsumentów, niekoniecznie powiązanych z zainteresowaną marką. Także za pomocą tej techniki na zlecenie Cisco wykonano analizę korelacji pomiędzy wypowiedziami zarządu a kursem akcji, co pozwoliło wyodrębnić osoby o największym pozytywnym wpływie.
Określenie data mining związane jest z pojęciem sieci semantycznej. Niewielu internautów pamięta zapewne hasło semantic web z początku tego wieku. Na długo przed Facebookiem pojęcie Web 2.0 oznaczać miało właśnie pomysł semantycznej sieci – odpowiedź na rosnący chaos informacyjny. W nowym internecie treści miały łączyć się nie za pomocą dosyć przypadkowych (jak obecnie) hiperłączy, lecz poprzez połączenia znaczeniowe, semantyczne.
Poniżej na poły żartobliwe wyjaśnienie, czym ma być Sieć semantyczna.
Na obecnym etapie rozwoju internetu zbudowanie bazy wiedzy opartej o relacje semantyczne wymaga stosowania wyspecjalizowanego oprogramowania, wykonującego właśnie data mining ogólnodostępnych w internecie źródeł.
Internet opinii
Co to wnosi dla przeciętnego zjadacza internetu? Na powszechne potrzeby powstają tymczasem niezbyt zaawansowane aplikacje dokonujące statystycznej analizy publikowanych informacji.
Ilustracja: statystyki opinii o Apple iPad, prezentowane przez twitrratr.com na podstawie analizy statystycznej treści mikroblogu Twitter.
W chwili obecnej zasięgnięcie opinii na temat interesującego nas produktu wymaga mozolnego, ręcznego wyszukiwania po rozlicznych serwisach. W zasadzie niemożliwe jest sięgnięcie do większej liczby źródeł, porównanie kilku produktów i dokonanie syntezy informacji na własną rękę. Pracę tę jest w stanie wykonać za użytkownika właśnie aplikacja stosująca sentiment analysis. Jej zaletą, poza zdolnością do przetwarzania znaczącej ilości informacji jest także wykrywanie spamu, w tym przypadku oznaczającego fałszywe opinie – dodawane w celu wypromowania danego produktu.
Więcej…
…na temat warstwy nawigacji w Sieci dowiecie się z prezentacji Jamesa Kalbacha podczas zorganizowanego przez UseLab Polish IA Summit, na którą to prezentację osobiście czekam i w imieniu organizatorów serdecznie zapraszam. Ruszyła już sprzedaż biletów, zachęcam do śledzenia mojego blogu – niebawem do wygrania wejściówka.
W sobotę zadebiutowałem jako wykładowca w Wyższej Szkole Europejskiej im. ks. Józefa Tischnera w Krakowie. Obiecałem studentom, że przygotuję listę narzędzi służących do tworzenia ekranow interfejsu (ang. wireframing). Ponieważ zapewne przydać się może nie tylko studentom, publikuję listę na blogu. Uznałem jednak, że wyszukiwarki użyć potrafi każdy, dodam więc kilka słów recenzji. Zainteresowani pełnymi listami tego rodzaju odnajdą źródłowe zestawienia na końcu notki. W ramach poniższej notki zamieszczam wyłącznie recenzje kilku wybranych narzędzi.
Skupiam się przede wszystkim na narzędziach darmowych bądź o stosunkowo niskiej cenie, jako najbardziej dostępnych dla każdego – nie tylko osób zajmujących się projektowaniem na codzień. Ci ostatni jak sądzę, są zorientowani w możliwościach, mają ponadto inne potrzeby. Przyznam jednak, że podczas przeglądu trafiłem na kilka ciekawostek, które mogłyby zainteresować także “zawodowców” – polecam przyjrzenie się choćby Protoshare. Zestawienie zawiera głównie narzędzia obsługiwane przeglądarkę, do niektórych można pobrać oprogramowanie typu desktop.
Przejrzałem narzędzia pod kątem następujących możliwości:
dostępne narzędzia formatowania obiektów interfejsu
Największy problem – brak obsługi polskich znaków, co w zasadzie dyskwalifikuje użycie tego narzędzia dla polskiego projektanta. Z obowiązku wymieniam, choćby ze względu na wykorzystanie interaktywnych paneli i ograniczonych instrukcji warunkowych. Aktualnie Hot Gloo dostępne jest w darmowej wersji beta, planowane wprowadzenie opłat.
Po uruchomieniu “repozytorium” (konia z rzędem temu, kto po uruchomieniu wersji trial i zamknięciu okna przeglądarki kliknie ten akurat odnośnik), dostępny jest czytelny tutorial.
Okno edytora Pidoco, widok tutoriala (kliknij, aby powiększyć)
Pierwsze wrażenie – bardzo wygodnie używa się kontekstowych kontrolek, wyświetlanych przy każdym obiekcie wstawionym do prototypu.
Kontrolka wyświetlana przy obiektach interfejsu (kliknij, aby powiększyć)
Chwilę później, przeciągnięcie wybranego obiektu z przybornika powoduje błąd przeglądarki – Safari zamyka się nie zapamiętując historii sesji. Przywrócenie wszystkich otwartych okien jest niemożliwe – to może być nieprzyjemne, jeżeli mieliście ich otwartych sporo.
Daję Pidoco kolejną szansę. Wykonując kilka kroków tutoriala stwierdzam, że interfejs przypomina mi edytory WYSIWYG w systemach CMS. Manipulowanie obiektem tą drogą jest o wiele wygodniejsze, niż przy użyciu paneli właściwości, wykorzystywanych przez konkurencyjne narzędzia. Bardzo przydają się kontekstowe podpowiedzi, wyświetlane nienachalnie podczas edytowania prototypu.
Na pierwszy rzut oka podoba mi się koncepcja globalnego zasięgu warstw, ułatwiająca wyświetlanie poszczególnych elementów na więcej niż jednej stronie. Jak rozumiem, ma to być forma szablonów typu “master”. Zastanawiam się tylko, na ile wygodne jest zarządzanie wieloma warstwami w większym projekcie – nie zauważyłem możliwości grupowania warstw w katalogach. W odróżnieniu od klasycznych masterów, na pewno łatwiej jest modyfikować wyświetlanie wybranych elementów na poszczególnych stronach, gdzie zastosowano warstwy.
Warstwy w projekcie tworzone są automatycznie dla każdej nowej strony (kliknij, aby powiększyć)
Pidoco umożliwia wyeksportowanie dwóch widoków – “plain” oraz “sketch”. Przeglądający prototyp mogą komentować dowolną część ekranu, do której przypinana jest notka. Po zaproszeniu współpracowników notka zamienić się może zapewne w zapis interaktywnego czata. Niestety, dla tej części nie przewidziano obsługi polskich znaków.
Strona wyeksportowana w widoku szkicu (kliknij, aby powiększyć)
Strona wyeksportowana w widoku tradycyjnym (kliknij, aby powiększyć)
Minusy Pidoco – przede wszystkim brak możliwości projektowania własnych bibliotek oraz ograniczona ustawieniami dostarczonych obiektów interakcja. Nie ma mowy o odpowiednikach paneli Axure czy nawet Hot Gloo. Jest to narzędzie przeznaczone głównie do projektowania prostych makiet, ułatwiające w zamierzeniu komunikację koncepcji w zespole projektowym. Zaawansowanych prototypów HI-FI raczej za pomocą Pidoco nie zbudujemy.
Abonament w wersji miesięcznej, półrocznej bądź rocznej. W zależności od wybranego pakietu (basic, classic, advanced, expert), ceny od 10 do 90 euro miesięcznie, najwyższy abonament umożliwia korzystanie z modułu zdalnych testów. Możliwe rozwiązanie hostowane. Dostępna 30-dniowa wersja próbna.
Kolejne narzędzie, reklamowane jako “the only tool”, służące do komunikacji w zespole w czasie rzeczywistym. Rejestracja konta w wersji próbnej wymaga podania danych karty kredytowej, co mnie osobiście zawsze irytuje. Rzecz jasna mogę “zrezygnować w każdej chwili” – choć wolałbym, żeby to raczej decyzja o zakupie wymagała ode mnie podjęcia działania. Formularz rejestracji składa się swoją drogą ze zbyt wielu kroków jak na wersję próbną, co zniechęca.
Okno przykładowego projektu w Protoshare (kliknij, aby powiększyć)
Już domyślny widok przykładowego projektu wskazuje na znaczny stopień rozbudowania. Biorąc pod uwagę zbliżony do Pidoco pułap cenowy, możliwości Protoshare są nieporównywalnie większe. Za jego pomocą można konstruować znacznie bardziej skomplikowane, interaktywne prototypy. Niestety, idzie za tym konieczność nauczenia się przebogatego interfejsu użytkownika. Jest to o tyle istotna kwestia, że Protoshare traci rację bytu jako narzędzie do projektowania ad hoc – po prostu wymaga inwestycji czasowych. Może mieć sens wyłącznie w przypadku wdrożenia do codziennej pracy nad wieloma (pod)projektami.
Poniżej jeden z widoków edytora oraz kilka zrzutów ekranu z ciekawych funkcjonalności.
Widok edytora ekranu w Protoshare (kliknij, aby powiększyć)
Widok symulacji komunikatów o błędzie formularza (kliknij, aby powiększyć)
Ekran komunikatów o błędzie formularza (kliknij, aby powiększyć)
Na plus Protoshare należy zapisać to, że udostępnia obiekty niedostępne nawet w drogich pakietach typu Axure czy Visio – pliki Flash czy moduły zasilane z kanałów rss, możliwe jest także wklejanie własnego kodu html. Dodatkowo, każdy z elementów prototypu może zostać ostylowany przy użyciu standardowego CSS. Modyfikowanie własności obiektów dodanych do projektu jest dokonywane za pomocą panelu właściwości – zbliżonego do Visio.
panel właściwości obiektu (kliknij, aby powiększyć)
Polecam obejrzenie kilku tutoriali w formie filmów, dla zorientowania się w możliwościach. Poniżej przykładowy film z instrukcją tworzenia postawowych szablonów.
Serwis przewiduje trzy wersje abonamentu – od 29 USD w górę za miesiąc, różniące się m.in. możliwą do uruchomienia liczbą projektów, miejscem na dysku oraz liczbą współpracowników. Droższy abonament (49 USD za stanowisko miesięcznie) przewiduje możliwość eksportu projektu do HTML. Dostępna 30-dniowa wersja próbna.
Grzechem byłoby nie wspomnieć o rodzimym justproto, ale nie wymieniam narzędzia wyłącznie z obowiązku.
Po lekkim niesmaku związanym z podawaniem danych karty w przypadku Protoshare nareszcie dobre podejście – aby przedłużyć używanie konta po upływie wersji próbnej, muszę wyrazić swoją wolę w tej sprawie.
Już na pierwszy rzut oka interfejs justproto różni się od pierwszej, zgrzebnej wersji, z którą miałem do czynienia około roku temu. Niestety, liczba kontrolek dostępnych w bibliotece jest mało imponująca, brak jakichkolwiek gotowych komponentów nawigacyjnych. Na plus zapisać należy natomiast sporą kolekcję ikon, choć zawsze zastanawiam się, czy właściwe dla szablonów są właśnie kolorowe obrazki.
Tak wyglądają clipart’y:
biblioteka ikon w justproto
A oto – pokazana praktycznie w całości – biblioteka komponentów:
biblioteka komponentów justproto (kliknij, aby powiększyć)
Justproto nie umożliwia tworzenia interakcji opartej na interaktywnych panelach, jego możliwości są wciąż ograniczone do prostych schematów. Makiety można udostępniać do podglądu w formie HTML, nie odnalazłem możliwości wyeksportowania prototypu.
Ceny abonamentu są uzależnione od wielkkości zespołu, liczby projektów i dostępnej dla nich przestrzeni dyskowej. Plan “Standard” to 59 PLN miesięcznie, “Plus” i “Unlimited” odpowiednio – 199 PLN i 399 PLN. Ceny to niewygórowane, porównanie jednak możliwości Protoshare (droższy abonament za 49 USD miesięcznie) do justproto (powiedzmy – abonament “Plus” za 199 PLN) wypada zdecydowanie na korzyść tego pierwszego. Liczba dostępnych funkcjonalności różni się niestety diametralnie. Kibicuję mimo to polskiemu projektowi i liczę, że będzie poszerzał udostępniane możliwości.
Aplikacja wyposażona w stosunkowo bogatą liczbę elementów, w tym interaktywnych, a dzięki obsłudze skrótów klawiaturowych – stosunkowo łatwa w obsłudze.
Dla każdego prototypu wygenerować można adres url, który wysyłamy następnie do zainteresowanych członków zespołu – co jest możliwe przy użyciu wewnętrznej funkcji powiadamiania. Dodatkowo, projekt wstawić można do innej strony (funkcja embed). Dostępny eksport do plików jpg, png i pdf, a także wygenerowanie specyfikacji. iPlotz umożliwia także zapraszanie członków zespołu do współpracy nad projektem.
Darmowa wersja umożliwia stworzenie jednego projektu zawierającego do pięciu stron. 15 USD miesięcznie kosztować będzie nieograniczona liczba projektów i 1GB powierzchni, a za 99 USD rocznie dodatkowo wyposażymy się w aplikację desktopową do edycji.
Poza szablonami ekranów gliffy – podobnie do Visio – może być wykorzystywany do tworzenia diagramów (m.in. UML, Flowchart, ERD), planów pomieszczeń czy wizualizacji analiz SWOT.
Narzędzie jest obsługiwane przez przeglądarkę, a także jako wtyczka do Confluence oraz Jira. Dodatkowo, twórcy udostępniają API, pozwalające na tworzenie diagramów w serwisach zewnętrznych.
Niestety, także w tym przypadku biblioteka kontrolek interfejsu jest trochę uboga i ogranicza się do kilku prostych bloków i elementów formularza.
kontrolki formularzy w gliffy
Podstawowa, darmowa wersja gliffy jest ograniczona do pięciu udostępnianych publicznie diagramów. Jednostanowiskowa licencja dla jednej osoby to wydatek rzędu 5 USD (płatne kwartalnie). Wypróbowanie nie wymaga nawet rejestracji, co chwalebne.
Darmowa wtyczka do przeglądarki Firefox. Używanie tej aplikacji nie należy niestety do przyjemności – samo zaznaczenie i przesunięcie obiektu może nastręczać pewnych trudności.
Poniżej zrzut ekranu z przykładowego produktu pracy z narzędziem Pencil. Zamieszczam dla zilustrowania teoretycznych możliwości – przy odpowiednim nakładzie pracy można uzyskać przyzwoity efekt, nawet wykorzystując stosunkowo ubogie i niewygodne aplikacje. Ta sama uwaga dotyczy oczywiście wszystkich ocenianych tu narzędzi.
efekty pracy z wtyczką Pencil (Firefox)
Pencil umożliwia wyłącznie budowanie statycznych schematów i eksport tychże do równie statycznych plików png.
Narzędzie, w którym formatowanie tekstu i wstawianie kontrolek odbywa się za pomocą znanego choćby z aplikacji 36signals textile markup language. Tworzymy szablony wstawiając odpowiednie znaczniki przy użyciu edytora. Osobiście uważam, że stosowanie znaczników textile nie efektywną metodą budowania szablonów interfejsu. Zestaw tagów jest bardzo ubogi i w praktyce uniemożliwia wygodne rozmieszczanie elementów na stronie.
Jumpchart jest dostępny w wersji darmowej, ograniczonej do jednego projektu składającego się z maksymalnie 10 stron, w ramach 1MB na dysku. Płatny dostęp to – w zależności od wersji (od 5 do 50 USD miesięcznie) – odpowiednio większa liczba projektów, użytkowników, zabezpieczenia (SSL) i eksport do mechanizmu Wordpress.
Jeszcze jedna aplikacja stworzona w Adobe Air, służąca do tworzenia szkiców LO-FI.
Oto prezentacja możliwości, przygotowana prez producenta – niskiej niestety jakości.
Przyznam, że mam problem ze stosowaniem podobnych narzędzi do szkicowania. W założeniu służyć mają szybkiemu zilustrowaniu koncepcji przy użyciu gotowych kontrolek, bez konieczności rysowania od zera. Teoretycznie, bo w praktyce nakład pracy niezbędny do stworzenia sensownego ekranu nie sprowadza się do szybszego bądź wolniejszego posługiwania się narzędziem. Najwięcej czasu zajmuje tak naprawdę wymyślenie koncepcji, co w moim przypadku wspiera przekładanie modułów w tę i z powrotem po ekranie. Samo narysowanie kontrolki to rzecz wtórna… Być może inni projektanci pracują inaczej, ale ja nie potrafię rozdzielić wizualizowania koncepcji od jej wymyślania.
Drugi problem to odbiorcy szkiców tego rodzaju. Próbowałem swego czasu przekazać pomysł klientowi przy użyciu efektów pracy w Balsamiq i wywołało to pewne zdziwienie. Mam wrażenie, że to się nie sprawdzi jako metoda komunikacji pomysłu na linii agencja interaktywna – klient. Być może na wewnętrzne potrzeby, ale do tego osobiście wolę malowanie flamastrem po tablicy.
Aplikacja typu desktop, napisana w Javie – a co za tym idzie – niezależna od systemu operacyjnego. Biorąc pod uwagę stosunkowo niski, jednorazowy koszt zakupu licencji, ForeUI oferuje całkiem niezłe możliwości. Osobiście używam Axure do budowy interaktywnych prototypów, które – mimo że o wiele droższe – nie posiada pewnej istotnej funkcji. Chodzi o tworzenie rozbudowanych instrukcji warunkowych, które ułatwiają obsługę bardziej skomplikowanych procesów. ForeUI umożliwia nie tylko budowanie warunków przy użyciu wizualnego interfejsu, ale także – poprzez podanie instrukcji w polu tekstowym. Co więcej, poza wielokrotnymi if-then (jak w Axure), możliwe jest używanie konstrukcji switch, co jest naprawdę przełomowe. Niestety, nie funkcjonalność nie została dopracowana – na możliwość ręcznego wprowadzenia warunków wpadłem metodą prób i błędów. Wygląda na to, że niemożliwe jest obsłużenie w ten sposób instrukcji switch, a systemu pomocy brak. Być może jednak moje oczekiwania idą za bardzo w stronę narzędzia typu RAD, co odrobinę kłóci się z założeniami aplikacji do prototypowania.
ForeUI udostępnia kilka podstawowych kształtów, niewielką bibliotekę kontrolek formularzy, nawigacji i prezentacji danych, a także kilkadziesiąt ikon.
Okno ForeUI (kliknij, aby powiększyć)
Poza w miarę standardowymi opcjami eksportu do obrazków (png, jpg, bmp, gif, wbmp) oraz pdf, ForeUI oferuje eksport prototypu do html, co należy oczywiście zapisać na plus. Niestety, aplikacja w wersji 2.0 beta na OS X ma żywotny problem z zapisem plików, proces zatrzymuje się w połowie i na tym koniec.
Interesującą opcją jest możliwość uzyskania nieodpłatnej licencji przez blogerów – w zamian za opublikowanie recenzji. Zakup standardowej licencji kosztować nas będzie 79 USD.
Aplikacja służąca do projektowania ekranów w klasycznym widoku kontrolek bądź jako szkice. Ciekawostka – możliwy jest import szkiców przygotowanych w Balsamiq. Jeszcze jedno narzędzie w Adobe Air, w którym przemieszczanie niektórych obiektów po ekranie przyprawia o ból głowy.
Udostępniana biblioteka komponentów interfejsu może być wystarczająca, niektóre obiekty wyposażyć można w interakcję, bez użycia instrukcji warunkowych.
Biblioteka komponentów Flairbuilder (kliknij, aby powiększyć)
Prezentacja aplikacji:
Koszt pojedynczej licencji – 99 USD.
Krótkie podsumowanie
Wypaczony korzystaniem z Omnigraffle czy Visio, umożliwiających łatwe tworzenie kontrolek od zera, oczekiwałem podobnych możliwości po recenzowanych aplikacjach. Po przejrzeniu możliwości kilku narzędzi, zastanowiłem się nad sposobem, w jaki sam pracuję. Doszedłem do wniosku, że także używając droższych programów nie posługuję się narzędziami w rodzaju “ołówka”, lecz korzystam z gotowych, prostych obiektów – figur geometrycznych i paneli tekstowych. Owszem, istnienie bibliotek kontrolek bardzo ułatwia życie, bo zamiast zmieniać właściwości prostokąta i nakładać kilka warstw na siebie, wolę przeciągnąć nawigację zakładkową z przybornika. To z całą pewnością skraca proces projektowania. Jednak najbardziej efektowny wygląd projektu uzyskuje się modyfikując kilka własności tych najbardziej podstawowych elementów, co nie wymaga wyposażenia aplikacji w szczególnie skomplikowane rozwiązania.
Przede wszystkim jednak – jak już wspomniałem powyżej przy okazji Balsamiq – osobiście tworzę koncepcję przemieszczając moduły po ekranie, zgodnie z projektowaniu hierarchią ważności. Nie ma większego znaczenia, na ile wyrafinowane będzie narzędzie, którego używam, skoro najwięcej czasu spędzam na wymyślaniu koncepcji. Oczywiście jest to stwierdzenie prawdziwe tylko do pewnego stopnia – jeżeli konstruuję interaktywny prototyp o wysokim poziomie komplikacji, już po zbudowaniu szkieletu pomysłu długie godziny schodzą na mozolnej dłubaninie w każdym ekranie. Niemniej jednak, wszędzie tam, gdzie projekt nie wymaga zasymulowania każdej możliwej interakcji (bo szybciej będzie ją opisać, niż zbudować w Axure), wystarczy użyć prostszych narzędzi, bez bogatych bibliotek. Oczywiście im więcej wydamy na oprogramowanie, tym mniej czasu spędzimy przeklinając z powodu drobiazgów, utrudniających nam życie. Kwestia czasu, jaki na codzień spędzamy przy makietach.
Poza funkcją budowania prototypów, znaczenie mogą mieć możliwości eksportu, wyświetlania podglądu, czy w wersji bardziej rozbudowanej – ułatwienia dla prowadzących testy z użytkownikami. Osobiście nie korzystałem nigdy z komunikacyjnych możliwości platform tego typu, ale być może dla kogoś ma to znaczenie. W moim przypadku najlepiej sprawdza się prezentacja na żywo w zespole, ale w czasach udostępniania ekranu i szybszych łącz, kto wie.
Nie wskażę w tym podsumowaniu jakiegoś pojedynczego lidera, nie było moim celem tworzenie rankingów. Wybór aplikacji zależy od potrzeb projektanta i czasu poświęcanego w ramach obowiązków na projektowanie. Osoby projektujące dużo większych aplikacji interaktywnych, które mogą przeznaczyć trochę czasu na wdrożenie większego systemu stosunkowo niskim kosztem, wybiorą być może Protoshare. Wszyscy ci, którzy potrzebują prostego narzędzia do naszkicowania mniejszego serwisu ad hoc, mogą wybrać po prostu darmową wtyczkę Pencil. Spośród pozostałych aplikacji, iPlotz czy Pidoco to coś pośredniego – stosunkowo tani abonament na poziomie kilku-kilkunastu dolarów ułatwi pracę przy małym i średnim projekcie.
Źródła
Źródłowe listy rozmaitych “top tools”, narzędzia mogą się powtarzać:
Świat przyspiesza. Ktoś nawet wykonał badania, z których wynika, że ludzie w wielkich miastach chodzą ulicami szybciej niż 10 czy 15 lat temu. Pośpiech jest dobrze znany branży interaktywnej, w przypadku której oczekiwanie klienta, iż agencja pracować będzie w weekend i wieczorami, nie należy niestety do rzadkości. Kolejnym z objawów jest dążenie do dostarczenia produktu interaktywnego szybciej niż konkurencja, co akurat nie dziwi. Moim zamiarem nie jest jednak snucie rozważań nad czasem, ale przyjrzenie się niedostatkom procesu projektowania zorientowanego na użytkownika – UCD (ang. User-Centered Design). Chodzi między innymi o wpływ na czas wytwarzania, ale nie tylko.
Swego czasu Tomek Bienias polecił na Goldenline artykuł o prowokacyjnym tytule Getting to the customer – why everything you think about User Centered Design is wrong. Szczerze mówiąc, treść niespecjalnie mnie porusza, warto jednak wymienić kilka celnych uwag. Piszę o tym z pewnym opóźnieniem – do podjęcia tematu skłoniła mnie lektura kilku innych tekstów (zobacz listę źródeł na końcu notki). Oto wybrane kwestie.
Pierwsza zasada: wydawaj wcześnie i często
…po angielsku – release early and release often. Innymi słowy, hasło-klucz ery internetu w wersji beta. Eric Ries stawia sprawę jasno – lepiej popełnić “błąd biznesowy” – publikując wczesną wersję serwisu, niż przechodzić przez wieloiteracyjny proces projektowania.
Wypuszczając nawet niedoskonały serwis, jesteśmy w stanie bardzo szybko uzyskać reakcję potencjalnych odbiorców i zorientować się, czy projekt ma sens od strony biznesowej. Ries przytacza przykład strony docelowej (landing page), zapowiadającej dany produkt i zawierającej odnośniki do informacji o tymże produkcie – w które to odnośniki nikt nie kliknął. Miałoby to być przyczynkiem do stwierdzenia, że czas zwijać żagle, bo interes nie ma szans wypalić. Gdyby ta sama strona była przedmiotem testów, projektanci staraliby się wprowadzić zmiany, zamiast z miejsca zrezygnować z projektu w ogóle. Szybciej i w domyśle – taniej – przetestować na żywo i podjąć zdecydowane decyzje.
Każdy projekt interaktywny powinien być zatem doprowadzany do stanu “minimalnego produktu zdolnego do życia” (minimum viable produt, mvp). Produkt takowy powinien zawierać tylko te funkcjonalności, które odpowiadają na problem klienta – i nic więcej. Ma to pozwolić na ocenę, czy efekt naszej pracy sprawdził się na rynku w możliwie najwcześniejszej fazie.
Przyznam, że rozumowanie to wydaje mi się odrobinę dziwaczne i niepozbawione dziur. Diagnozowanie problemu ogranicza się do stwierdzenia symptomów choroby, bez dociekania przyczyn. Wszystko pięknie, jeżeli z dużą dozą prawdopodobieństwa jesteśmy w stanie stwierdzić, że powód niepowodzenia tkwi w samym produkcie. Rozstrzygnięcia z pewnością nie przynoszą proste statystyki klikalności. Tu dochodzimy do zasady drugiej.
Korzyść dla użytkownika miarą sukcesu biznesowego
Kura czy jajo? Czy projekt może być efektywny biznesowo bez bycia “pożądanym” przez odbiorców? Czy wystarczy produkt minimalnie oczekiwany (Minimum Desirable Product), aby osiągnąć sukces biznesowy? Pytania niemal retoryczne, jednak biorąc pod uwagę podejście Minimum Viable Product, zorientowane na szybką ewaluację efektywności biznesowej, być może wymagające jasnej odpowiedzi.
Minimum Desirable Product (zobacz źródła) to doświadczenie produktu wystarczające do stwierdzenia, jaką wartość ów produkt przynosi użytkownikom. Do zbudowania MDP nie może wystarczyć pojedynczy landing page, nie wystarczy także zliczać statystyki ruchu do stwierdzenia, że czy używanie serwisu przynosi rzeczywistą korzyść użytkownikom. Andrew Chan proponuje zastosowanie miar zorientowanych na korzyści (benefit-driven metrics). W przeciwieństwie do tradycyjnych pomiarów konwersji, powinniśmy skupić się na stwierdzeniu, czy produkt realizuje cele użytkowników. Jeżeli zbudowaliśmy serwis randkowy, pytanie brzmi, czy udało się doprowadzić do pożądanego przez użytkowników efektu (nie pytajcie proszę, na której randce).
A więc MVP kontra MDP. Produkt pożądany kontra zwrot z inwestycji, sztuka (copyright by Rafał Agnieszczak) vs biznes. Wydawałoby się oczywiste, że jedno nie istnieje bez drugiego, pytanie tylko o kolejność. Minimalnie biznesowo zdolny do oceny projekt niekoniecznie zaakceptowany zostanie przez grupę docelową, choć jest to stan wystarczający do dokonania takiej oceny. Z drugiej strony, projekt, którego wartość dla użytkownika można sprawdzić, ma szansę stać się przebojem rynkowym. Czy ktos ma wątpliwości, że należy zeswatać tę parę? Jak doprowadzić do szczęśliwego małżeństwa?
UCD i agile
User-Centered Design (UCD) zakłada zaangażowanie użytkowników do do wypracowania wizji projektu. Zdaniem autora artykułu “Getting to the customer – why everything you think about User Centred Design is wrong”, UCD jest podejściem zbyt abstrakcyjnym, mało uwagi poświęca praktycznej realizacji projektów. Inna wada to eksportowanie odpowiedzialności przez zleceniodawców. Na pewno duża część praktyków zetknęła się z problemem zatrudnienia zespołu badawczego dla usprawiedliwienia określonych decyzji biznesowych i projektowych. Zbyt często zdarza się, że nasze raporty są wykorzystywane jako przysłowiowa “podkładka” – przecież przestestowaliśmy prototyp, więc problem mają koledzy po drugiej stronie budynku…
Wreszcie, zarzut najpoważniejszy: użytkownicy – uczestnicy badań w procesie UCD – to nie klienci. Użytkownik to twór statystyczny, który wedle Jacoba Nielsena nie przewija stron, na co z pewnością autor badań ma liczne dowody (Grzegorz, czytasz to?). Klient z drugiej strony, to ktoś, kto wybrał Twój produkt i jest zdeterminowany dostatecznie do przewijania wbrew wszelkim regułom, choćby ekran był zaprojektowany nie do końca właściwie.
Jakie miałoby być lekarstwo? Co zapewni, że użytkownicy staną się rzeczywistymi klientami, dostarczającymi wartościowych informacji zwrotnych, zanim biznes skonsumuje budżet? Stajemy przed koniecznością sprawnego i efektywnego kosztowo wytworzenia produktu dobrze dopasowanego do potrzeb użytkowników. Odpowiedzią, której osobiście szukam, jest skuteczne połączenie metodyki UCD z filozofią agile – podejścia strategicznego z taktyką realizacji. Od nowego roku zaplanowałem spotkania z praktykami Scrum, zobaczymy, co z tego wyjdzie…
Norman mnie zaskakuje. O ile dobrze pamiętam, to z jego książki pochodzi historyjka, którą uwielbiam zanudzać klientów. Chodzi o projekt nowej funkcjonalności, powstały w efekcie obserwacji użytkowników – w tym przypadku ekip sprzątających, obsługujących rozmaite urządzenia czyszczące. Do specyfiki usług należy wykonywanie pracy w nocy, kiedy biurowce są wyludnione. Nieodłącznym elementem warsztatu każdego sprzątacza jest kubek z kawą, co i rusz odstawiany na podłogę bądź meble. Wymaga to co i rusz powrotu po kawę po przejściu kilku metrów z odkurzaczem, rytuał powtarza się wielokrotnie. Projektanci doszli do wniosku, że najprostszym pomysłem na podniesienie wydajności pracowników jest zainstalowanie uchwytu na kubek przy odkurzaczu. Była to potrzeba, której nieświadomi byli sami zainteresowani, nie mogli jej więc wyartykułować wprost – przykład na to, że sami użytkownicy niekoniecznie wiedzą, czego potrzebują
(…) badania (ang. design research) sprawdzają się, kiedy chodzi o usprawnianie istniejących produktów, ale są bezużyteczne w przypadku innowacji. Doszedłem do tego wniosku, przeglądając się zarówno szeregowi przełomowych odkryć, które miały znaczący wpływ na społeczeństwo, jak i tych pomniejszych – ułatwiających życie codzienne. (…) Wolelibyśmy wierzyć, że te przełomowe są wynikiem szczegółowych badań nad potrzebami, w szczególności potrzebami nieuświadomionymi – ale tak się po prostu nie dzieje.
Jak wobec tego zdarzają się przełomy innowacji? Norman stwierdza, że są efektem powstania nowych technologii, umożliwiających zaprojektowanie rzeczy dotąd niemożliwych do wykonania. Niekoniecznie odpowiadają na rzeczywiste potrzeby, skoro ludzie obywali się bez określonych produktów często setki lat. To nie potrzeba jest matką innowacji, to często sami użytkownicy wymyślają nowe zastosowania dla technologii – zanim pojawi się problem do rozwiązania.
Na tym jednak nie koniec, bo rzeczywistą wartość dla biznesu zdaniem autora eseju generują małe kroki codziennych innowacji, usprawnień obniżających koszty czy podnoszących wydajność. Przede wszystkim dlatego, że w tej skali zmiany dokonane w produktach nie powodują przewrotu w cyklach życia produktu, nie wymagają nowych kompetencji. Wracamy do casusu uchwytu na kubek…
W dalszej części eseju Norman rozprawia się z mitem obserwacji etnograficznej jako warunku koniecznego do odkrycia ukrytych potrzeb użytkowników – w przypadku odkryć o charakterze przełomowym. To ważne rozróżnienie – warto pamiętać, że na codzień – jako projektanci interfejsów użytkownika – uczestniczymy przede wszystkim w projektach “małych usprawnień”, nie wynajdując odpowiednika telefonu w dziedzinie www.
Wśrod publicznie wygłaszanych opinii na temat zastosowania badań, pojawiają się od czasu do czasu różne smaczki. Bywa, iż zdaniem autorów publikacji czy wystąpień dana metoda w określonej sytuacji zastosowania nie znajduje, albo też jest kompletnie do niczego z uwagi na stosunek ceny do wartości. Mnogość opinii powodować może pewien zamęt w głowach najbardziej zainteresowanych – klientów poszukujących odpowiedzi na określone problemy. Sytuacji nie poprawiają rzecz jasna spory pomiędzy osobami zajmującymi się projektowaniem i badaniami. Jeżeli ktoś jeszcze nie widział, polecam prezentację Grzegorza Rusieckiego, ze szczególnym uwzględnieniem fragmentów na temat badań, a także gorącą dyskusję na blogu Robera Drózda i flakerze. Tekst nie ma być jednak podsycaniem sporu, w którym dyskusja przybrała różne formy. Spróbuję raczej odnieść się w kilku słowach do samej kwestii zastosowania badań w procesie projektowania.
Chcę jasno powiedzieć – nie pochwalam zbyt daleko posuniętych skrótów myślowych, zastosowanych przez Grzegorza w prezentacji. Piszę o skrótach myślowych, ponieważ ufam, że nie chciał literalnie przekazać, iż wyników badań przeprowadzonych przez osoby trzecie, czytać nie ma sensu. Odkładając to na bok, przyjrzyjmy się zastosowaniu takowych badań.
Podsumujmy kilka oczywistych oczywistości:
zbiorowość użytkowników Twojego serwisu czy aplikacji nie musi być reprezentatywna dla całej populacji. To truizm do bólu, z oczywistymi konsekwencjami – nie można wnioskować o istnieniu określonych cech w całej populacji na podstawie ich wykrycia wśród własnych użytkowników. Przekładając na język ludzki – jeżeli Twoi użytkownicy najbardziej na świecie lubią animowane różowe króliczki, nie musi być to zjawisko powszechne
Oczywiście działa to także w drugą stronę. Z prostego procesu wnioskowania dedukcyjnego wynika, że skoro wszyscy użytkownicy internetu lubią animowane różowe króliczki (załóżmy), a Twoi użytkownicy są jakąś podgrupą użytkowników, różowe króliczki polubić musisz jako projektant.
Co z tego wynika? Idźmy dalej… Załóżmy, że zastanawiamy się, czy w naszej grupie docelowej istnieje skłoność do płacenia kartą kredytową online, albo – z innej beczki – do jednoznacznego utożsamiania koloru czerwonego z sytuacją alarmową. Pytanie brzmi, kiedy warto wykonać własne badania pod kątem interesujących nas parametrów. Przyjdą nam z pomocą znane już prawidłowości, czy lepiej odnieść się do nich krytycznie i przeprowadzić odpowiednie eksperymenty?
Na pozór odpowiedź wydawać się może oczywista. Wyniki badań skwantyfikowane na całą populację mogą spokojnie stać się mocną podstawą do projektowania określonych rozwiązań. Urodziliśmy się z zakodowanymi wzorcami reagowania na określone sytuacje w sposób całkowicie przedświadomy i odkrywanie koła nie ma większego sensu. Z drugiej strony, pożądanie zachowanie użytkownika zależeć może od mniej oczywistych parametrów – i tu badać czasami warto.
Niestety, granica pomiędzy tym co oczywiste, a tym co godne zbadania, może być dosyć płynna. Przekonywanie klienta, że prawidłowości nie istnieją, to błąd w sztuce. Mówiąc krótko – jak zwykle nie znajdziecie prostej odpowiedzi na pytanie, czy zawsze badać, weryfikować prawidłowości. Jedne należy, na inne szkoda czasu. Stwierdzenie, że należy badać zawsze, jest niestety nieprawdziwe.
Zanim nagram komentarz do pełnej prezentacji, wrzucam nagranie wykonane przez Maćka Budzicha. Niestety, trochę się rozgadałem i musiałem skrócić wystąpienie.
Zapraszam na 43 odcinek Auli w najbliższy czwartek – zostałem zaproszony do wygłoszenia prezentacji na temat projektowania perswazyjnego. Jeżeli uda mi się uruchomić transmisję, puszczę live swoje wystąpienie. O ile do tego czasu dojdę do ładu i składu z technologią, zrobię konkurencję mediafun’owi i puszczę transmisję całości
W ogóle, to może dogadam się z Maćkiem i będziemy czasami na dwie kamery puszczać? Jedna z ekranu, druga z prelegenta?
Jestem notorycznie proszony o listy książek, które przeczytać w naszej branży warto, postanowiłem więc w końcu wrzucić kilka tytułów. Będę uzupełniał od czasu do czasu. Wszystkie adresy z amazon.co.uk, skąd polecam kupować wersje angielskie, w przypadku USA należy się liczyć co najmniej z VAT’em na granicy. Przed zakupem radzę sprawdzić w polskich księgarniach – część z tych pozycji mam na półkach już jakiś czas i być może zdążyły pojawić się w naszej wersji językowej.
Kolejność przypadkowa, wrzucam co mi wpadnie w oczy, poczytajcie recenzje i spisy treści – duży rozrzut tematów i poziomów abstrakcji. Oczywiście nie jest to w nawet w przybliżeniu pełna lista książek i publikacji, które należałoby przeczytać. Raczej naprędce sporządzona lista tego, co przewinęło mi się przez ręce.
Acha, nie wrzucam “Nie każ mi myśleć”, zakładam, że oczywiste oczywistości możemy sobie darować
Jedna bardzo ważna uwaga. Czytając pozycje-wytrychy, które mają pokazać Wam drogę do powszechnego szczęścia, bądźcie sceptyczni. Zastanawiajcie się, dlaczego niektóre zasady są pieczołowicie hołubione przez autorów – szukajcie przyczyn, myślcie zasadami – nie rozwiązaniami. Próbujcie dociec, co jest przyczyną problemu, nie tylko aplikując dobre rady anglojęzycznego wujka zza oceanu ;]
Poniżej moja prezentacja z konferencji Internet Beta 2009, wykonanana w Prezi. Polecam oglądanie na pełnym ekranie (More > Fullscreen), nawigując strzałkami poniżej ekranu. Polecam także zabawę samym interfesjem Prezi (spacja, rolka myszki, przesuwanie ekranu).
Zacznijmy od odrobiny teorii. W czasach blogosfery nikogo chyba przekonywać nie trzeba o rosnących trudnościach w docieraniu do treści. Lawinowy przyrost informacji, rozpoczęty w XX wieku proporcjonalnie zwiększył potrzebę organizowania – klasyfikowania, nadawania odpowiednich etykiet. Peter Morville, autor obowiązkowej lektury Information Architecture for the World Wide Web, podaje kilka powodów, dla których organizacja nie jest prosta, wśród których wymienia niejednorodność.
…na temat warstwy nawigacji w Sieci dowiecie się z prezentacji Jamesa Kalbacha podczas zorganizowanego przez UseLab Polish IA Summit, na którą to prezentację osobiście czekam i w imieniu organizatorów serdecznie zapraszam. Ruszyła już sprzedaż biletów, zachęcam do śledzenia mojego blogu – niebawem do wygrania wejściówka.
i szczerze mówiąc nie wiem kto przyjął i gdzie ale ja raczej spotkałam...