Front-Trends 2010 - część 3

Ostatnia część mojej subiektywnej relacji z Front-Trends 2010.

Wcześniejsze części są tutaj i tutaj. Artykuły te dzisiaj nieco uzupełniłem - dla części wykładów pojawiły się slajdy i postarałem się je powstawiać lub podlinkować.

A poniżej piszę przede wszystkim o dwóch bardzo interesujących prezentacjach.

Końcowe wykłady konferencji

Mobile Ux and current trends in mobile design

Wykład o używalności aplikacji mobilnych zaczął się od serii żarcików i docinków związanych z ... hmm, nienajlepszym psychofizycznym stanem wykładowcy. Niemniej jednak Antony Ribot zdołał przeprowadzić swoją prezentację i mówił ciekawie.

Teoria

Pierwszym słowem kluczowym był kontekst. Powinniśmy znać warunki, w jakich będzie funkcjonować aplikacja - tj. cechy i możliwości urządzeń mobilnych.Ograniczenia są dobre dla Ciebie ale musisz je dobrze rozumieć, inaczej produkt nie będzie używalny.

Następna rzecz to zachowania użytkowników. Jaką emocję chcemy wzbudzić (I want user to smile, I want user to salivate, ...), kim jest typowy użytkownik, jaki schemat zachowań będzie prezentował (Glance and go, Data snacking, Peek and Dig, ...), jak ma wyglądać jego pierwszy kontakt z aplikacją (jeśli w ciągu pierwszych 30 sekund nie odkryje jej przydatności, mało prawdopodobne, by ją ponownie uruchomił). In mobile it's the little things that count - drobne ułatwienie lub utrudnienie może zdecydować o powodzeniu całości.

Choć ludzie z doświadczeniem desktopowym mają tendencję do zliczania funkcji, w świecie mobilnym ich ilość nie ma znaczenia. Mobile is not about features, it is about experience. Dobrym przykładem są czytniki ebooków, skoncentrowane na perfekcyjnej obsłudze jednej funkcji - czytania. Planując aplikację mobilną powinniśmy wybrać co najwyżej 5 funkcji (czy też zmusić do ich wybrania biznes). Gdy już zostaną wybrane, mamy wybrać z nich tą jedną najważniejszą i zorganizować wokół niej cały projekt i schemat zachowań (pozostałe funkcje dodając jako uzupełnienie).

Docelowe urządzenia są różnorodne i ich specyfikę musimy uwzględniać (użytkownik Nokii być może zaakceptuje projekt z interakcjami w stylu iPhone, użytkownik iPhone na pewno odrzuci aplikację obsługiwaną a'la Nokia) ale rdzeń funkcjonalności powinien być wspólny i przenośny (ze względu na koszt stworzenia i utrzymania aplikacji). Pomocne będą tu narzędzia takie jak PhoneGap czy Appcelerator Titanium.

Projektowanie powinniśmy zaczynać od szkiców robionych na papierze - powstają szybciej (I am a Photoshop guru but I need at least 5 minutes to draw an idea, on paper it takes me 30 seconds) i nie jest żal ich odrzucić. Powstały szkic jak najszybciej pokażmy innej osobie. A później prototypujmy, przy użyciu dowolnych narzędzi (Flash, HTML+JavaScript, ...) - byle jak najszybciej pozwoliły zobaczyć jak pomysł wypada na prawdziwym urządzeniu.

Proces

Antony pokazał, w jakich etapach w jego firmie powstaje projekt aplikacji. Na początku ma miejsce burza mózgów.

Potem powstają papierowe wireframe - celowo rysowane na papierze i celowo bez użycia koloru (choć zdarza się, że klient spyta why it is so black and yellow?).

Kolejna faza to cyfrowe wireframe, ciągle jeszcze pozbawione koloru i szczegółów graficznych:

Wreszcie powstaje właściwy projekt graficzny:

a po nim dokumentacja. Przy tym prezenter akcentował wagę bardzo drobiazgowego udokumentowania wszystkich elementów graficznego projektu - dokładnych rozmiarów, zapisanych numerycznie kolorów, użytych czcionek wraz z wielkością itp (pozwólmy programistom skoncentrować się na tym, co lubią i umieją robić - na programowaniu, nie zmuszajmy ich do podejmowania decyzji związanych z wyglądem aplikacji).

Na koniec prezentacji Antony opowiadał o aplikacji jaką jego firma tworzyła dla Tesco (obsługa zakupów z komórki). Zapamiętałem kilka ciekawostek.

• Wielu użytkowników zaczyna zakupy od zarezerwowania terminu dostawy (np. w poniedziałek rezerwując termin niedzielny) po czym przez cały tydzień po kilka razy dziennie uruchamia aplikację dorzucając po jednym produkcie (czasem po parę), by wreszcie sfinalizować zakupy w sobotę. Dlatego aplikacja umożliwia natychmiastowy wybór terminu dostawy nawet przed włożeniem czegokolwiek do koszyka i stale ten termin prezentuje, koszyk oczywiście jest trwały a dodatkowo optymalizowany jest przebieg dorzucania pojedynczego produktu do koszyka (can you add to cart in 10 seconds?).

• Koszyk często bywa uzupełniany w okolicznościach dalece odległych od spokojnego skupienia się na zakupach, np. w trakcie jazdy komunikacją miejską, w trakcie prac domowych, z WC czy (przekąski) po wypiciu kilku drinków.

• Każda z platform mobilnych wymagała stworzenia zaadaptowanego projektu (były to kolejno, w parumiesięcznych odstępach, Nokia, iPhone i Windows Phone 7). Przykładowo, testy wykazały, że użytkownicy Windows Phone są przyzwyczajeni do trybu panoramy i nie akceptują nawigacji w stylu iPhone.

Poleciłbym powyższe (a zwłaszcza schemat pracy rozpoczynający się od terminu dostawy i uwzględniający wielokrotne uzupełnianie koszyka) uwadze polskich sklepów internetowych, zwłaszcza handlujących produktami spożywczymi...

JSON over SMS

Peter-Paul Koch poprowadził prezentację poświęconą przewidywanemu rozwojowi aplikacji mobilnych. Opowiadał z ogromną werwą i naturalnym humorem zarazem budując przekonującą wizję przyszłości.

Desktopowy web jest już stabilny i wręcz nudny. Pięć coraz bardziej zgodnych i dobrze znanych przeglądarek, ustalone metody rozwiązywania problemów. Świat telefonów to 15 przeglądarek (i perspektywy pojawienia się kolejnych), duże różnice funkcjonalności, przedziwne błędy i braki (np. parę wersji Opery niewłaściwie obsługuje font-style: italic co wynika z braku takiego fontu na Motorolach) ale także ... wkrótce trzykrotnie więcej użytkowników niż weba desktopowego. Lada chwila pierwsze wrażenie o firmie gros klientów będzie odnosiło na podstawie interfejsu mobilnego. iPhone w 2008 roku kosztowało 700 euro, dziś 250, w 2018 roku będzie kosztować 10.

Peter eksploatował symboliczny obrazek rybaka z egzotycznej wioski, który już ma telefon komórkowy bądź niedługo będzie go miał. Po czym zacznie go używać we własnych interesach - najpierw dzwoniąc by sprawdzić na którym targu dostanie najlepszą cenę, potem przeglądając je przez sieć, wreszcie korzystając z aplikacji która automatycznie podpowie najkorzystniejsze oferty i powiadomi w razie nagłych zmian sytuacji. A następnie będzie się starał zrobić wrażenie na znajomych a nieraz i podzielić z nimi używaną aplikacją przesyłając ją via Bluetooth (i dobrze, by było to możliwe nawet jeśli rybak będzie miał Nokię a jego przyjaciel Samsunga).

Pisanie takich aplikacji już zaczyna być możliwe, a niezbędnej technologii dostarczają HTML, JavaScript, CSS i API definiowane w ramach specyfikacji W3C Widgets (patrz też wprowadzenie na blogu PPK) - przy czym wszystkie one są traktowane jako narzędzia budowy aplikacji natywnych a nie webowych.

To już zaczyna działać (PPK przesłał widget z Symbiana na Windows Mobile), możliwości instalacji to min. W3C Widget, Palm WebOS, iPhone cached site, PhoneGap (patrz też dłuższy artykuł wspomniany na poniższym slajdzie). Uniformizacja napotyka jeszcze na opory ale gdy Nokia, Samsung i RIM zaczną wspierać standard, wszyscy będą musieli go zaakceptować.

W aplikacji HTML5 HTML i CSS definiują wygląd aplikacji, skrypty uruchamiają się lokalnie i obsługują interakcje, ani jedno ani drugie nie musi być pobierane po (często zawodnej) sieci. Aplikacja może się uruchomić bez pobierania czegokolwiek. Zdalnej komunikacji wymaga wyłącznie wymiana danych.

Jak może do niej dochodzić? Sieć GSM jest niepewna i (dla masowego odbiorcy) droga, Wi-Fi rzadko dostępne, realnym praktycznym rozwiązaniem może być SMS - który przy okazji zapewni możliwość notyfikacji w trybie push (np. powiadomienie naszego rybaka o nagłej okazji). Owymi SMSami przesyłane mogą być komunikaty JSON, być może uproszczone (np. bez zbędnych klamr).

Monetyzacja aplikacji będzie się prawdopodobnie opierała nie na opłatach za programy (którymi min. użytkownicy będą się dzielić) ale na opłatach za dostęp do danych, za treść. A w zbieranie opłat w końcu zaangażują się operatorzy, którzy już przecież i tak obciążają użytkowników.

Model sklepów z aplikacjami dobiega końca, chmara ponad czterdziestu appstore jest coraz mniej przydatna (min. ich rola promocyjna w sytuacji, gdy oferowane są dziesiątki tysięcy aplikacji, jest już znikoma, zamiast specyficznych API potrzebne są standardy), web will interpret App Store as damage and route around it.

Prezentację zakończyła dyskusja o aktualnych otwartych wyzwaniach. Istotny problem stanowi bezpieczeństwo (jak zweryfikować, czy przesłana Bluetoothem przez kolegę aplikacja nie wykradnie mi danych) a przede wszystkim standaryzowanie potrzebnych API, tak dotyczących obsługi płatności, jak rozmaitych funkcji smartfonów (dostęp do kamery, książki adresowej, GPS, miernika ruchu/przyspieszenia, realizacja połączeń telefonicznych, ...). Obecnie powszechnie wspierana jest jedynie obsługa geolokacji. Jedną z ciekawych zabaw jest definiowanie nowych zdarzeń odpowiadających funkcjom telefonu (ononline/onoffline, onorientationchange, onshake, oncameraopen, onmove (GPS), onphonecall, ....). Paul zachęcał zainteresowane osoby do dołączania do grupy Mobile Web.

Innym wyzwaniem jest opracowywanie modelów interakcji odpowiednich dla mobilnych użytkowników. O użytkowniku desktopowym można zakładać, że siedzi. Mobilny może iść ulicą, jechać pociągiem, stać w windzie ale też siedzieć w fotelu lub leżeć w łóżku i zależnie od sytuacji wymagać różnej obsługi. Samo wykrywanie z jaką sytuacją mamy do czynienia też stanowi znaczący problem.

Slajdy:

Zaległości

Dla trzech wykładów na których nie byłem pojawiły się slajdy, dla kompletności podlinkowuję.

You know webOS

Slajdy z wykładu Markusa Leutwylera są dostępne w formie HTMLowej prezentacji na stronie autora.

JavaScript and HTML - brave new world

Slajdy z wykładu Roberta Nymana:

JavaScript performances vs common good practices

Slajdy z wykładu Andreai Giammarchiego są dostępne tutaj (PDF), a tutaj jest dostępny artykuł Andrei z krótkim omówieniem.

Następna konferencja

Organizatorzy chcą kontynuować polskie spotkania specjalistów od frontendu, następną konferencją ma być - skupiona bardziej na technicznych aspektach programowania w JavaScripcie - konferencja FalsyValues.

Moje pragnienia i postanowienia

Chciałbym spróbować napisać jakąś, nawet prostą, aplikację mobilną używając techniki HTML+JavaScript - i spróbować ją uruchomić na różnych telefonach (zapewne przy pomocy PhoneGap). Wygląda na to, że tych technologii nie można już ignorować.

W wolnej chwili postaram się wrzucić na bloga i/lub mekk.waw.pl strukturalne tagi HTML5 (a może też jakieś drobne efekty CSS3).

Gdy następny raz przyjdzie mi pisać jakiś znaczący kawałek JavaScriptu, postaram się zaprząc do pracy JsTestDriver i Sinon.JS. Poważnie zastanawiam się też nad zakupem książki Christiana Johansena.

Obejrzę dostępne nagrania i slajdy z wykładów Jake Archibalda i Christiana Heilmana.

Będę pamiętał o enhance.js.

Ciekawe co z tego naprawdę mi się uda zrobić...

Na koniec

Dziękuję organizatorom za konferencję, szefowi za umożliwienie uczestnictwa w niej, prezenterom za sporo użytecznej wiedzy a osobom, które doczytały aż dotąd za cierpliwość. I cieszę się, że w Polsce dochodzi do tak znaczących wydarzeń.

Jeszcze może dygresja: Scott Berkun napisał bardzo ciekawą, praktyczną książkę o publicznym występowaniu, szczerze polecam każdemu, komu grozi regularne prowadzenie prezentacji.