Android — wzorce projektowe a user experience

Android jest już od dłuższego cza­su dojrza­łą plat­for­mą a udzi­ał w rynku urządzeń z tym sys­te­mem wynosi obec­nie w USA 38%, w Polsce około 17% . Wer­s­ja Androi­da 1.0 pojaw­iła się w 2008 (pier­wszym urządze­niem wyposażonym w ten sys­tem oper­a­cyjny był HTC Dream sprzedawany w więk­szoś­ci kra­jów Europy od początku 2009) i od tamtego cza­su była sukcesy­wnie rozwi­jana. Mimo tego, brakowało przez dłuższy czas ofic­jal­nych wyty­cznych doty­czą­cych pro­jek­towa­nia inter­fe­jsów na tą plat­for­mę, podob­nych do tych jakie zapew­nia Apple w swoich iOS Human Inter­face Guide­lines. Zawarte tam infor­ma­c­je i wskazów­ki pozwala­ją na tworze­nie aplikacji, których wygląd i zachowanie jest spójne i zgodne z wiz­ją firmy – takie holisty­czne pode­jś­cie do pro­jek­towa­nia na tą plat­for­mę jest dobrym rozwiązaniem, jeżeli chce się zapewnić użytkown­ikom pewien kom­fort użytkowa­nia urządzenia i korzys­ta­nia z aplikacji stwor­zonych przez różne firmy.

W przy­pad­ku Androi­da częs­to narzekano na brak tego typu doku­men­tacji, którą moż­na się wspomóc pod­czas pro­jek­towa­nia aplikacji. Wraz ze wzrostem znaczenia tej plat­formy na rynku, pojaw­iła się potrze­ba usankcjonowa­nia pewnych stan­dard­ów doty­czą­cych pro­jek­towa­nia – co w kon­sek­wencji może zre­dukować pojaw­ia­jące się roz­bieżnoś­ci. Sytu­ac­ja zaczęła się zmieni­ać od 2010 (rozpoczę­cie prac nad uspójnie­niem wiz­ji plat­formy z punk­tu widzenia użytkown­i­ka) i na ofic­jal­nej stron­ie developers.android.com wid­nieją już wyty­czne doty­czące pożą­danych dla tej plat­formy sposobów inter­akcji oraz wyglą­du inter­fe­j­su. Z drugiej strony wprowadze­nie tego typu wyty­cznych może jaw­ić się jako narusze­nie otwartoś­ci plat­formy i swo­body pro­jek­towa­nia.

Moż­na więc postaw­ić pytanie, która dro­ga jest właś­ci­wa: peł­na otwartość czy restryk­cyj­na poli­ty­ka pro­jek­towa­nia UI? Apple może się jaw­ić jako ‘tyran’ ogranicza­ją­cy swo­bodę i kreaty­wność twór­ców. Jed­nak, jak  zauważył Simon White: „you don’t become a brand with such UX impact with­out hav­ing strict con­trols on what appli­ca­tion devel­op­ers can do on your plat­form. Google is arguably more open than Apple, but they pay the price in a slight­ly less coher­ent user expe­ri­ence in their third-par­ty apps.”

Głównym prob­le­mem jaki pojaw­ia się pod­czas pro­jek­towa­nia aplikacji na Androi­da jest zróżni­cow­anie urządzeń w obrę­bie plat­formy – HTC, Sam­sung i inne firmy wypuszcza­ją smart­fony o różnych wielkoś­ci­ach ekranu i rozdziel­czoś­ci­ach. Dochodzi do tego pozornie banal­na sprawa wyglą­du samego urządzenia, dostęp­nych przy­cisków, sposobu ich oznaczenia itp.

W artykule opub­likowanym w UXMat­ters wyróżnione zostały trzy poziomy mobil­nego user expe­ri­ence: sprzę­towe, sys­te­mowe i aplikacji. W przy­pad­ku Androi­da moż­na zauważyć przede wszys­tkim niespójność na poziomie sprzę­towym (różnorod­ność urządzeń pocią­ga za sobą wspom­ni­ane wcześniej zróżni­cow­anie w wyglądzie i funkcjon­al­noś­ci­ach, różnych rozmi­arach ekranu, dostęp­nych przy­ciskach) – powodu­je to, że częs­to zmi­ana urządzenia jest związana z drasty­cznie odmi­en­nym doświad­cze­niem pod­czas korzys­ta­nia z niego (czego nie moż­na powiedzieć zmieni­a­jąc  iPhona 3 na  4 – ok, są różnice ale nie trze­ba się uczyć na nowo jak posługi­wać się urządze­niem).

Nie to jest jed­nak najwięk­szym prob­le­mem Androi­da. Prob­le­mem jest brak spójnoś­ci UI pomiędzy aplikac­ja­mi dzi­ała­ją­cy­mi na tej plat­formie,  co w dużej częś­ci było wynikiem braku ofic­jal­nych guideline’ów  doty­czą­cych sposobu pro­jek­towa­nia.  Nieograniczani przez wyty­czne pro­jek­tan­ci i dewelop­erzy potrafili w rezulta­cie tworzyć na Androi­da skra­jnie odmi­enne pod wzglę­dem inter­fe­j­su aplikac­je, których obsłu­gi musieli się za każdym razem na nowo uczyć skon­fun­dowani użytkown­i­cy (celowo trochę prze­jaskraw­iam sytu­ację, ale porównu­jąc UI różnych aplikacji na iOS i Androi­da nie sposób nie zauważyć spójnoś­ci UI tego pier­wszego). Zaw­iodło więc w przy­pad­ku Androi­da to, co jest bard­zo pil­nowane od początku w przy­pad­ku pro­duk­tów Apple’a – dostar­cze­nie użytkown­ikowi przewidy­wal­nego (w pozy­ty­wnym sen­sie) inter­fe­j­su i spójnego zachowa­nia różnych aplikacji w obrę­bie plat­formy.

Co więcej – w kon­sek­wencji  braku reguł pro­jek­towych, pod­czas pro­jek­towa­nia częs­to wyko­rzysty­wano rozwiąza­nia z innych plat­form np. iOS. Nie zawsze jest to dobre pode­jś­cie, ponieważ kon­wenc­je w Androidzie są inne. Przykła­dem może być cho­ci­aż­by przy­cisk ‘back’, który zawsze jest widoczny i dostęp­ny w urządzeni­ach z tym sys­te­mem – jako fizy­czny lub cyfrowy przy­cisk. Nie jest więc konieczne umieszczanie go w aplikac­jach np. na górnej belce, tak jak ma to miejsce w aplikac­jach na iPhone’a.

Ważnym ele­mentem usta­la­nia stan­dard­ów pro­jek­towa­nia inter­fe­jsów są wzorce pro­jek­towe. Czym one są? Pod­czas tworzenia inter­fe­j­su pro­jek­tant napo­ty­ka szereg prob­lemów związanych z różny­mi ele­men­ta­mi aplikacji – mogą one być związane np. z wprowadzaniem danych lub naw­igacją. Wzorzec jest pewnym ogól­nym rozwiązaniem częs­to wys­tępu­jącego prob­le­mu.  Kiedy warto korzys­tać ze wzroców? Wtedy, kiedy pojaw­ia się prob­lem na który dany wzorzec jest odpowiedz­ią. I nie częś­ciej – nie należy rozwiązy­wać prob­lemów, które nie ist­nieją;)

Dlaczego warto korzys­tać z wzor­ców? Choć­by dla utrzy­ma­nia spójnoś­ci między aplikac­ja­mi , aby użytkown­ik intu­icyjnie wiedzi­ał czego może się spodziewać, jakie akc­je pod­jąć, co może zro­bić. Wyko­rzys­tanie wzor­ców spraw­ia, że aplikac­ja wyda­je się użytkown­ikowi znana i przewidy­wal­na. Poza tym zna­jo­mość wzor­cowych rozwiązań jest dobrym wstępem do zrozu­mienia specy­fi­ki danego środowiska i pro­jek­towa­nia opty­mal­nego user expe­ri­ence dla użytkown­ików.

Poniżej lista wybranych wzor­ców, których wyko­rzys­tanie jest rekomen­dowane przez Google:

Dash­board – punkt star­towy aplikacji. Rozwiązu­je prob­lem naw­igowa­nia do głównych sekcji w obrę­bie aplikacji.  Infor­mu­je użytkown­i­ka co moż­na zro­bić w tej aplikacji. Powin­ny się tam znaleźć skró­ty maksy­mal­nie do 6 sekcji. Ponieważ jest to jeden z pier­wszych ekranów jakie widzi użytkown­ik, ważne jest aby dashb­o­rad był atrak­cyjny wiz­ual­nie –o tym, że pier­wsze wraże­nie jest istotne, już kiedyś pisal­iśmy.

Action­bar – wzorzec charak­terysty­czny dla Androi­da — podob­ny do pas­ka naw­iga­cyjnego na stronach inter­ne­towych (umieszc­zony u góry ekranu, z logo po lewej oraz glob­al­ny­mi ele­men­ta­mi naw­iga­cyjny­mi po prawej). Zapew­nia mech­a­nizm powro­tu do strony głównej/startowej (poprzez logo) i pod­kreśla główne funkcjon­al­noś­ci. Nie powinien być uży­wany do kon­tek­stowych akcji.

Quick Actions – wyskaku­ją­cy pop-up z menu kon­tek­stowym. Do wyko­rzys­ta­nia w przy­pad­ku poje­dynczych ele­men­tów takich jak np. zdję­cia z który­mi moż­na coś dalej zro­bić – dodać do ulu­bionych, podzielić się ze zna­jomy­mi itp.

 

Wid­get – wspo­ma­ga aplikację pozwala­jąc na wyświ­etle­nie określonych powiadomień/informacji na pulpicie użytkown­i­ka. Pozwala użytkown­ikowi dos­tosować pul­pit do swoich pref­er­encji.

Search­bar – pasek wyszuki­wa­nia zakotwic­zony u góry ekranu daje użytkown­ikowi możli­wość szy­bkiego znalezienia pożą­danej infor­ma­cji

Więcej infor­ma­cji zna­jdziecie na http://developer.android.com/index.html. Ale koniec końców, aby stworzyć coś ory­gi­nal­nego, częs­to trze­ba pewne schematy i wyty­czne łamać:)

3 odpowiedzi
  1. Ulotki
    Ulotki says:

    A ja będąc przez kil­ka lat wierny noki uważałem że Sym­bian nie jest taki zły jak go opisu­ją i że zach­walanie Androi­da jest lekką prze­sadą. Po jakimś cza­sie uznałem że warto spróbować czegoś nowego — zmieniłem tele­fon na HTC. I przyz­na­ję rację — Android to najlep­szy sys­tem jaki do tej pory wymyślono. Widzi­ałem już Winows Mobile czy Bade ale od Androi­da są duu­u­użo gorsze. A sym­bian z którym zżyłem się przez lata to jeż his­to­ria. Czy wychodzą jeszcze jakieś tele­fony Noki z tym sys­te­mem ? 🙂

    Odpowiedz

Odpowiedz

Want to join the discussion?
Feel free to contribute!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *