Category Archives: pisanie prac

Pisanie prac z informatyki

User Experience: Obsługa profilu w e-commerce

Do napisania tej notki skłoniły mnie dwie rzeczy:

  1. UX to nie usability, a przynajmniej nie tylko – o czym już i Tebe wspominał swego czasu. Jest tu np. miejsce na kreatywne rozwiązywanie problemów użytkowników, a nie tylko analizy stron WWW – co trudno wyjaśnić niektórym osobom, przyzwyczajonym dla klasycznej wersji usability.
  2. Jestem zagorzałym fanem gier komputerowych oraz z uwagą od wielu lat obserwuję poczynania i rozwój CD Projekt. Stąd wymiękłem jak okazało się, że jedna z moich ulubionych firm, chcąca wchodzić na giełdę i przygotowująca się do sprzedaży Wiedźmina na całym świecie (piszę w czasie przyszłym gdyż rzecz, którą opisuję ma już swoją historię), nie potrafi obsłużyć sprzedaży w swoim kraju.

Wiedźmin

CD Projekt chcąc podgrzać i tak gorącą atmosferę wokół swojego flagowego aktualnie produktu, przygotowało sprzedaż gry tak, że na stronie swojego sklepu znajdował się licznik odmierzający czas do godziny 0. O godzinie 0 klienci mieli przystąpić do składania zamówień – w gorączce przypominającej świeżo otwierany lokalny Media Markt oferujący przecenione o 75% odtwarzacze DVD (co z tego, że dwa na cały sklep, skoro ludzie czekający przed sklepem dowiedzą się o tym dopiero później).

Tamtego pamiętnego wieczora, sprzedaż gry – z perspektywy użytkowników – dla wielu okazała się być… klapą! Powód? Serwery nie wytrzymały i sklep podnosił się ładne kilka godzin. Ale… po wpisach zawiedzionych fanów i przeprosinach założycieli CDP, otrzymałem informację, że od teraz znów można składać zamówienia na zestaw kolekcjonerski, co też zaraz uczyniłem.

Teraz jedna uwaga o zestawie – ważnym jego elementem (kluczowym dla opisanej tu sytuacji) jest koszulka z logiem gry Wiedźmin. Koszulka, która mi, jako osobie kupującej, jeśli chodzi o rozmiar, została przydzielona z automatu (?): dostałem z przydziału rozmiar M i nikt nawet nie zadał sobie trudu bym miał możliwość zmiany tego przydziału (łącznie z panią z Call Center, która po prostu na moje żale się wypięła twierdząc, że ona nic nie może, że to system i tyle (prawie jak za PRL-u)).

Z punktu widzenia użytkownika problem był tu większy:

  1. jako zamawiający, podczas dokonywania zakupu, nie miałem możliwości wyboru rozmiaru koszulki,
  2. kiedy otrzymałem e-mail potwierdzający zamówienie, nie miałem możliwości zmiany szczegółów tego zamówienia – w tym przypadku rozmiaru koszulki.
  3. Generalnie, chociaż zostawiałem w sklepie ponad 200 zł (z kosztami przesyłki) za grę (co jeśli chodzi o gry na PC nie jest tanio), nikomu jakoś nie zależało bym otrzymał to, co zamawiałem – nie dano mi nawet możliwości skonfigurowania zamówienia.

Po rozmowie z osobą z Call Center zacząłem się zastanawiać co poszło nie tak, jak można by obsłużyć tego rodzaju scenariusze, jak poprawić sprzedaż tego rodzaju produktów.

User EXperience

W pierwszej kolejności zadałem sobie pytanie, co powinien mieć system, by w przypadkach tzw. „wyboru z automatu”, wykazać się czymś w rodzaju inteligencji i zminimalizować tego rodzaju sytuacje, gdy klient dostaje nie w pełni funkcjonalny towar. Wszak UX ficzerami stoi! 🙂

Ciepły prysznic (gorąca woda pobudza szybkość krążenia krwi po krwiobiegu, dzięki czemu mózg jest lepiej dotleniany, co przekłada się na efektywność pracy umysłu, w tym myślenia) i jest. Profil. Zaniedbywana część rozwiązań e-commerce.

Pomyślałem tak, gdyby sklep gram.pl wiedział jaki noszę rozmiar koszulek, w przyszłości, gdybym dokonywał zakupów pakietów rozszerzonych zawierających ten asortyment, mógłby domyślnie zamawiać taki zestaw, w którego skład wchodziłaby koszulka mojego rozmiaru – z możliwością edycji, w przypadku, gdybym np. chciał dany produkt kupić z myślą o prezencie.

Idąc dalej tym tropem stwierdziłem, że jeszcze lepiej by było, gdyby sklep miał dane mojego komputera, mógłby mi wówczas podpowiadać, z którymi grami mój komputer nie będzie miał problemów, bo spełnia wymagania twórców, a w przypadku których musiałbym spełnić warunki dodatkowe (np. dokupić jeszcze pamięć RAM).

To jest największa zmora graczy, że nawet oni – kupujący wszelkie nowinki technologiczne i posiadający w swoich domach małe superkomputery służące tylko do eksterminacji potworów – sami się już gubią w tym, czy ich karta graficzna pociągnie grę, czy nie. Gdybym mógł w sklepie podać parametry swojego komputera, system sklepowy prócz wyświetlania produktu, informowałby „Ta gra pójdzie na Twoim komputerze”, a „Ta nie”. Mało tego, opierając się na tego typu danych system mógłby umożliwiać filtrowanie produktów tak, by wyświetlane by mi były tylko te, które dopasowane są do moich potrzeb / możliwości.

Później pomyślałem, czy tego rodzaju rozwiązanie, kładące nacisk na możliwość zdefiniowania istotnych parametrów w moim profilu (istotnych z punktu widzenia prezentowanego towaru przez dany sklep), mogłoby znaleźć zastosowanie w przypadku sprzedaży produktów innych. I tak na przykład: jakże lepiej by było, gdybym w sklepie z bielizną mógł zdefiniować moje rozmiary, bądź/i rozmiary mojej żony. System nie tylko, że byłby czymś w rodzaju przedłużenia mojej pamięci długoterminowej (ja nigdy nie pamiętam rozmiarów, nawet swoich), więc częściej mógłbym dokonywać zakupów, bo miałbym pewność, że te, któe kupię będą mojego rozmiaru. Dodatkowo także, dzięki tego rodzaju zdefiniowanym informacjom w profilu miałbym rodzaj filtra – np. w ramach wyszukiwania, sklep wyświetlałby tylko te wyniki, które byłyby dopasowane do moich wymagań – tylko tę część bielizny, która by była w zdefiniowanych rozmiarach, co w niektórych przypadkach znacznie skróciłoby listę wyników, dzięki czemu dawałoby większe prawdopodobieństwo, że użytkownik zapozna się ze wszystkimi i w rezultacie coś wybierze (po co oglądać to, co nie jest na mnie?).

***

PS pozytywny: Brak przygotowania ludzi zajmującymi się realizacją zamówień na Wiedźmina miał objawić się jeszcze raz. Pomimo tego, że listem e-mail zostałem poinformowany, że z przydziału otrzymam koszulkę rozmiaru M, to przyszła rozmiaru L – na szczęście. Widocznie tym razem taki rozmiar był od ręką…

PS negatywny: Jakież było moje zdziwienie gdy okazało się, że rzekoma wersja kolekcjonerska polega na tym, że do wersji standard zostały dodrukowane gadżety dodatkowe i sprzedawane o 100 zł drożej – wizualizacja wersji pierwotnej wersji kolekcjonerskiej znacznie się różni od aktualnie sprzedawanej wersji kolekcjonerskiej, chociażby w ramach wykonanego etui na płyty (porównaj obydwa obrazki z niniejszego postu).

Banner blindness: ślepota na bannery

Jakiś czas temu chciałam zainstalować tlenofon. Zwykle korzystam ze Skypa, więc komunikator tlenu nigdy nie był mi potrzebny. Otworzyłam pełną pop – up’ owych reklam stronę o2 i kliknęłam w ikonkę tlenofonu. Hm… trochę mi czasu zajęło zanim zorientowałam się w co kliknąć. Dopiero po dłuższej chwili dostrzegłam ten szary boks z żółtym przyciskiem „Zainstaluj”.

Oglądając tą stronę zaczęłam zastanawiać się nad zjawiskiem opisanym już prawie 10 lat temu nazywanym „Banner Blindness” (ślepota na banery). Polega ono na nieświadomym ignorowaniu reklam przez użytkowników internetu. Twórcy reklam, coraz częściej zdają sobie sprawę z istnienia tego zjawiska. Ostatnio zamiast tradycyjnych bannerów i pop-upów pojawiają się linki kontekstowe oraz hasła wpisane w pola wyszukiwarki prowadzące do stron reklamowych.

Reklama kontekstowa Googla jest już od jakiegoś czasu bardzo popularne. Użytkownicy nie ignorują tej formy reklamy, traktują ją jako tekst, w który czesto klikają. Ślepota na reklamę jest jednak zjawiskiem, z którego istnienia powinni sobie zdawać sprawę również projektanci stron internetowych.

Odwołam się teraz do źródeł i przypomnę, co Jan Panero Benway i David M. Lane z Rice University napisali w artykule „Banner Blindness: Web serchers often miss „Obvious” Links” . W 1998, gdy autorzy pisali ten artykuł panował pogląd, że najważniejszy link lub informacja na stronie powinny znajdować się u góry strony i wyróżniać się od pozostałej części interfejsu wielkością i kolorem. Autorzy artykułu testując funkcjonalność wielu witryn zauważyli, iż tak wyróżnione linki są przez użytkowników nie zauważalne. Podobne zjawisko odnotowali również Spool, Scanlon, Schroeder, Snyder i DeAngelo (1997). Zauważyli oni, że uczestnicy testów funkcjonalności mają problemy ze znalezieniem informacji umieszczonych w animowanych banerach.

Spostrzeżenia te zainspirowały P.Benweya i D.M. Lane do przeprowadzenia kontrolowanych badań. Uczestnikom eksperymentu prezentowali oni stronę i prosili o znalezienie 24 informacji (takich jak adres e-mailowy hotelu). Osoby biorące udział w eksperymencie były poinformowane, iż nie wszystkie z poszukiwanych informacji znajdują się na stronie. Badani po ukończeniu poszukiwań, mieli wskazać informacje, które udało im się znaleźć i ocenić na 5 stopniowej skali trudność dotarcia do nich.

Zadania kontrolne polegały na znalezieniu informacji, do których można było dotrzeć za pomocą menu tekstowego. W zadaniach eksperymentalnych zaś, uczestnicy mogli dotrzeć do poszukiwanych informacji jedynie po kliknięciu w link na banerze.

Okazało się, iż zadania kontrolne (czyli znalezienie informacji poprzez menu tekstowe) zostały wykonane w 94%. Informacje do których można było dotrzeć poprzez kliknięcie w link na banerze (zadania eksperymentalne) zostały znalezione jedynie w 58%.

Ponadto informacje, które wymagały kliknięcia w baner były znajdowane w dłuższym czasie, niż informacje wymagające kliknięcia w menu tekstowe. Badani oceniali również zadania eksperymentalne jako trudniejsze.

Badacze przeprowadzili jeszcze jeden, bardziej zmodyfikowany eksperyment. Tym razem uczestnikom prezentowano różne obiekty, niektóre z nich wyglądały jak typowe banery reklamowe, inne nie przypominały powierzchni reklamowej. Osoby badane proszono o znalezienie informacji o książce „Coaching Youth Basketball” , do której można było dotrzeć klikając w link umieszczony w różnych obiektach.

Okazało się, iż wszystkie prezentowane obiekty były tak samo mało zauważane. Nie odnotowano istotnych statystycznie różnic między odnalezieniem informacji, do których prowadziły linki w banerze reklamowym jak i do tych, do których prowadziły linki w tabelach. Jednak wspólną cechą tych obiektów, było odseparowanie ich od nawigacji.

Użytkownicy poszukujący konkretnych informacji w internecie, ignorują nie tylko obiekty przypominające banery (na co wskazało pierwsze badanie), ale wszystko, co wizualnie jest odseparowane od całego interfejsu i nie ma widocznego związku z menu.

Podsumowanie

Użytkownicy internetu podświadomie filtrują obiekty, które przypominają swoim wyglądem reklamy. Poszukując istotnych informacji na stronie, nie rejestrują świadomie wszystkich form przekazu wyglądających inaczej niż nawigacja. Zatem, istotne linki na stronie powinny być maksymalnie uproszczone i przejrzyste, spójne i naturalne dla użytkowników. Elementy interfejsu należy odróżnić od banerów reklamowych i nie wykorzystywać przy projektowaniu stron estetyki charakterystycznej dla form reklamowych.

Książki o projektowaniu z: Google Books

Jak pokazał zorganizowany we Wrocławiu tegoroczny WUD (slajdy z wystąpień; materiały filmowe), jednym z głównych tematów wygłoszonych referatów była kwestia projektowania menu.

A ja właśnie znalazłem w Sieci ciekawą pozycję: The Psychology of Menu Selection: Designing Cognitive Control at the Human/Computer Interface autorstwa Kenta L. Normana. Jak głosi opis:

„Menu selection has emerged as an important mode of human/computer interaction. This book, the first entirely devoted to this important form of human/computer interaction, provides detailed theoretical and empirical information of interest to software designers and human/computer interaction specialists and researchers. A new theoretical approach to menu selection is taken by developing a psychological theory of cognitive control by the user. A comprehensive review of empirical research on menu selection is presented in an organized fashion to aid in the design and evaluation of systems. Finally, information is given on how to protype and evaluate menu selection systems using both performance data and user ratings.

The volume has three parts. Part One is conceptual and theoretical in nature. In Part Two, experimental research on menu selection stemming from paradigms developed in experimental psychology and more recently human factors and cognitive psychology is discussed. The last part of the book deals with the topic of implementation and evaluation. Chapters discuss principles of when and how to use menus, cover topics of prototyping and evaluation, and attempt to plot some of the future directions of menu selection. Throughout, graphs and illustrations are included. Examples of good and bad designs are shown in a number of illustrations while empirical data from experiments are desplayed in graphs.

The reader will benefit from the discussion of the many issues, design possibilities and insights regarding menu slection. The empirical research at times supports and at other times refutes existing guidelines. The reader will want to know what the current state of knowledge is about how to design menu selections and why the design choices are important.”

Obszerne fragmenty książki można przeglądnąć w ramach systemu Google Books; a całą książkę znalazłem na stronie jej autora.

***

Ale, ale… Na Google Books można znaleźć i inne interesujące pozycje z działki UX, AI i usability. M.in.:

  • H. Rex Hartson, Advances in Human-computer Interaction
  • Stuart K. Card, Thomas P. Moran, Allen Newell, The Psychology of Human-computer Interaction
  • Jakob Nielsen, Web usability
  • Joseph S. Dumas, Janice C. Redish, A Practical Guide to Usability Testing
  • C. Marlin Brown, Human-Computer Interface Design Guidelines
  • Hugh Beyer, Karen Holtzblatt, Contextual Design: Defining Customer-Centered Systems
  • David J. Ritter, LabVIEW GUI: Essential Techniques

Ja zaś, po zakończeniu lektury biografii Jima Clarka (założyciela m.in. Silicon Graphics oraz Netscape Communications), powracam do czytania Microsoft Story (w końcu to jeden z klientów w mojej rodzimej firmie :)).

Amazon.com: historia pewnego menu

Pod koniec 1983 roku, cztery lata po prezentacji pierwszego systemu GUI, który powstał dzięki możliwościom języka programowania Smalltalk, jeden z architektów tego systemu (zresztą ojciec terminu architekt w ramach projektowania oprogramowania), wówczas już były pracownik Xerox PARC (przeszedł do Microsoft), Charles Simonyi, wypowiedział się na łamach „PC World” na temat źródła pochodzenia terminu menu:

„Lubię posługiwać się pewną analogią. Przypuśćmy, że jestem we Francji w restauracji, a nie znam francuskiego. Znajdując się w nowym miejscu, nie czuję się pewnie: boję się ośmieszenia. Nagle kelner mówi coś do mnie w języku Moliera. Od razu mam ręce lepkie ze zdenerwowania. To samo prawdopodobnie odczuwa buchalter, kiedy zasiada po raz pierwszy do komputera. Jak sobie poradzić? W restauracji zawsze mogę wziąć do ręki menu i coś wskazać palcem. Być może nie dostanę tego, co bym chciał – i kelner przyniesie mi ślimaki – ale nie będę czuł się ośmieszony. Tak samo jest z programami – muszą oferować użytkownikowi menu. Każdy moża zobaczyć, jakie opcje są możliwe i wybrać jedną z nich, po prostu wskazując ją (na przykład za pomocą myszki). Nie ma potrzeby wtykać nosa w podręcznik, aby zorientować się, co należy zrobić.”

Zatem, menu to nic innego jak „karta” umożliwiająca użytkownikowi zapoznanie się z oferowanymi możliwościami danej aplikacji.

Sklep internetowy Amazon.com, to chyba najbardziej rozbudowana aplikacja internetowa, a z pewnością najbardziej rozbudowana aplikacja e-commerce (przy okazji, moja ulubiona strona). Jego znakiem rozpoznawczym – przynajmniej do niedawna – był system menu, oparty o zakładki. System, który tak świetnie się sprawdza(ł?), że wraz za królem branży, wprowadziły go kolejne sklepy, a potem i serwisy, i systemy poczty, komunikatory, i… Microsoft w ramach Office 2007.

W tym roku webowy innowator (Amazon prócz systemu menu zakładkowego wprowadził i upowszechnił wiele innych ficzerów, np. wish listy) zrezygnował z systemu menu zakładkowego na rzecz… menu kaskadowego, wielokrotnie krytykowanego w ramach szkoły usability wywodzącej się od J. Nielsena.

Stwierdziłem, że to dobry moment, by przypomnieć sobie bieg rozwoju koncepcji menu w Amazon.com. W związku z czym timline poniżej.

1998

1999-2000

Problem roku 2000…

…humorystycznie przedstawiony przez serwis duck.com.

2000-2002

2003-2004

2005-2007

I przychodzi rok 2007, w którym Amazon rezygnuje ze swojego znaku rozpoznawczego – z zakładek.

Podczas gdy menu zakładkowe tak bardzo się sprawdza, że aż doprowadziło do powstania tzw. menu wstążkowego i wkroczyło do oprogramowania desktop (MS Office 2007).

Pytanie: Czemu Amazon zdecydował się na taki ruch? Czemu zrezygnował z menu zakładkowego i to w dodatku na rzecz menu kaskadowego? Teorie, przypuszczenia, przecieki, … – mile widziane.

***

Źródła:

  • Wypowiedź Simonyi’a ukazała się pierwotnie w listopadowym numerze magazynu „PC World” w 1983 r. Przekład za: D. Ichbiah, Microsoft Story, 1995, s. 78.
  • Fragmenty menu Amazon.com za: Functioning Form.

Paper Prototyping: recenzja

Właśnie otrzymałem paczkę z kilkoma książkami. A w środku m.in. „Paper Prototyping” autorstwa Carolyn Snyder.

***

Carolyn jest chyba największą znawczynią tematu prototypowania przy użyciu papieru. W Internecie większość artykułów z tego tematu jest jej autorstwa. Podtytuł książki głosi: „The Fast and Easy Way to Design and Refine User Interfaces” i w zasadzie tak można podsumować same PP.

Pierwszy raz paper prototyping jako metoda projektowania interfejsów programów komputerowych pojawiła się w latach 80. ubiegłego stulecia. Ale swoją popularność zyskała dopiero 10 lat później, gdy zaczęto jej używać jako standard w procesie projektowym w takich firmach jak IBM czy Microsoft; rozgłos nadali jej m.in.: Jared Spool, Jakob Nielsen, Bob Virzi czy Tom Tullis. Chociaż początki prototypowania na papierze są dużo starsze i sięgają starożytności, choć rzecz jasna nie dotyczyły wytwarzania interfejsów oprogramowania.

Książka Snyder ma blisko 400 stron, co – jeśli chodzi o temat – nie jest mało. Z początku zastanawiałem się co można napisać na tylu stronach o PP, by nie lać wody – artykuły Snyder, któe znałem, były zwięzłe i na temat, mieściły się maksymalnie na kilkunastu stronach, 400 zatem na pierwszy rzut oka może się wydawać lekką przesadą. Ale książka w mig rozwiała moje wątpliwości. Autorka pokazała PP jako metodę na tyle szeroką, że znajdującą zastosowanie np. przy projektowaniu interfejsów telefonu, czy radia samochodowego. Zatem nie ograniczając się do opisania metody, ale i przytaczając case study konkretnych produktów, w tym również tych historycznych, jak w przypadku maszyny sortującej pocztę firmy NCR (1971) czy też translatora scenograficznego firmy Xerox (1974). „PP” to kompendium wiedzy nt. PP.

W ramach PP można wyróżnić dwa zasadnicze sposoby wykonywania prototypów:

  • rysowane – wystarczy kartka i coś do pisania (ołówek, długopis, kredka – najlepiej mieć do dyspozycji kilka kolorów),
  • wycinane – najlepiej wtedy mieć ze sobą „bibliotekę” podstawowych elementów interfejsu (np. pola zaznaczone pola tekstowe, zdjęcia, itp.), albo wydrukowany i rozłożony na elementy pierwsze zrzut wcześniejszej wersji strony,
  • dodatkowo – forma mieszana: rysowanie + wycinanie – którą preferuję jak używam PP – w przypadku gdy najpierw narysujemy elementy strony (albo wydrukujemy, gdy dysponujemy np. zrzutem wcześniejszej wersji strony), a potem je wycinamy w celu ich przestawiana na żywo w czasie rozmowy z klientem.

PP ma zarówno zalety, jak i wady.

Zalety PP:

  • łatwość wykonywania prototypów,
  • szybkość ich wykonywania,
  • możliwość prototypowania zawsze i wszędzie, gdzie tylko będziemy mieli coś do pisania, bez odpalania komputera i instalowania oraz uczenia się niekiedy skomplikowanego oprogramowania.

Główną wadą jest to, że nie najlepiej sprawdzają się podczas testowania interakcji – tak jak można na papierze zaobserwować czy rozkład poszczególnych elementów jest ok. – przejrzysta struktura i czytelna architektura informacji – tak już przejścia i wywoływanie kolejnych ekranów jest wysoce nienaturalne.

Kiedy używać PP i w jakim celu?

Najlepiej PP sprawdza się w przypadku:

  • Rozmowy z klientem – zarówno na wstępnym etapie, jak i w ramach późniejszych spotkań, gdy przychodzimy już w prototypem w wersji elektronicznej (ja, dla przykładu, lubię wtedy mieć ze sobą wydrukowaną wersję strony i pociętą na elementy pierwsze tak, by móc w razie czego poprzestawiać je przy kliencie i sprawdzić czy ew. wersja konkurencyjna dobrze by wyglądała, czy też ma jakieś wady (testy A/B).
  • Posiedzenie działu projektowego – w czasie spotkania zespołu nie ma czasu by rysować dokładne interfejsy na komputerze, zresztą spotkaniu sprzyja jak uczestnicy w ogóle w tym czasie nie zajmują się komputerami; kartka i ołówek powinny wystarczyć, a notatki sporządzone na spotkaniu spokojnie mogą posłużyć jako szkice do dalszych prac.
  • Testy projektowe – sporządzone prototypy, jeśli masz jakieś wątpliwości, już na etapie papierowych szkiców możesz pokazać potencjalnym użytkownikom by dowiedzieć się czy wszystko jest ok., czy projekt jest dla nich czytelny.
  • Projektowanie architektury informacji – PP jest niezastąpione jako uzupełnienie card sorting: wypisz na kartce nazwy działów, jakie powinny się znaleźć w witrynie, którą projektujesz, a potem potnij je na równej wielkości karteczki. Daj do ułożenia uczestnikom testu tak, by pogrupowane mogły stanowić podstawę architektury strony. Gdy będziesz miał menu, będziesz mógł dorysować resztę. Zobaczysz, żę w ciągu kilku godzin możesz stworzyć pierwszy prototyp, nad którego udoskonalaniem będziesz mógł dalej pracować.

Carolyn Snyder wymienia jeszcze testy funkcjonalności, w ramach których papierowe prototypy wykorzystywane są jako elementy interfejsów. Chociaż ja osobiście uważam, że efekty PP poprzez swoją nienaturalność w użyciu nie nadają się do tego (choć nadają się do testów projektowych).

Więcej…

  • wcześniejsza moja notka nt. paper prototyping wraz z filmami na ten temat,
  • książka: C. Snyder, „Paper Prototyping”, (Morgan Kaufmann Publishers, Elsevier 2003),
  • oficjalna strona książki,
  • oraz – niebawem – w książce: M. Kasperski, A. Boguska-Torbicz, „Prototypowanie: metody i narzędzia”, Helion 2008.

***

PS 1: W paczce otrzymałem także wydane w tym roku:

  • J. Arnowitz, M. Arent, N. Berger, „Effective Prototyping for Software Makers” oraz
  • D. Brown, „Communicating Design. Developing Web Site Documentation for Design and Planning”.

Ale o tych pozycjach przy zgoła innej okazji.

PS 2: Ruszyła oficjalna wersja Profeo. Nie byłoby w tym nic specjalnego gdyby nie fakt, że w tej wersji formularz logowania posiada opcję „Zapamiętaj mnie” – o której to opcji w kontekście właśnie logowania do Profeo pisałem jakiś czas temu. Jeszcze gdyby coś zrobić z jasnością tego żółcienia, który jest nieczytelny na szarym, to w ogóle byłoby nieźle.