Android – wzorce projektowe a user experience

Andro­id jest już od dłuż­sze­go cza­su doj­rza­łą plat­for­mą a udział w ryn­ku urzą­dzeń z tym sys­te­mem wyno­si obec­nie w USA 38%, w Pol­sce oko­ło 17% . Wer­sja Andro­ida 1.0 poja­wi­ła się w 2008 (pierw­szym urzą­dze­niem wypo­sa­żo­nym w ten sys­tem ope­ra­cyj­ny był HTC Dre­am sprze­da­wa­ny w więk­szo­ści kra­jów Euro­py od począt­ku 2009) i od tam­te­go cza­su była suk­ce­syw­nie roz­wi­ja­na. Mimo tego, bra­ko­wa­ło przez dłuż­szy czas ofi­cjal­nych wytycz­nych doty­czą­cych pro­jek­to­wa­nia inter­fej­sów na tą plat­for­mę, podob­nych do tych jakie zapew­nia Apple w swo­ich iOS Human Inter­fa­ce Guide­li­nes. Zawar­te tam infor­ma­cje i wska­zów­ki pozwa­la­ją na two­rze­nie apli­ka­cji, któ­rych wygląd i zacho­wa­nie jest spój­ne i zgod­ne z wizją fir­my – takie holi­stycz­ne podej­ście do pro­jek­to­wa­nia na tą plat­for­mę jest dobrym roz­wią­za­niem, jeże­li chce się zapew­nić użyt­kow­ni­kom pewien kom­fort użyt­ko­wa­nia urzą­dze­nia i korzy­sta­nia z apli­ka­cji stwo­rzo­nych przez róż­ne fir­my.

W przy­pad­ku Andro­ida czę­sto narze­ka­no na brak tego typu doku­men­ta­cji, któ­rą moż­na się wspo­móc pod­czas pro­jek­to­wa­nia apli­ka­cji. Wraz ze wzro­stem zna­cze­nia tej plat­for­my na ryn­ku, poja­wi­ła się potrze­ba usank­cjo­no­wa­nia pew­nych stan­dar­dów doty­czą­cych pro­jek­to­wa­nia – co w kon­se­kwen­cji może zre­du­ko­wać poja­wia­ją­ce się roz­bież­no­ści. Sytu­acja zaczę­ła się zmie­niać od 2010 (roz­po­czę­cie prac nad uspój­nie­niem wizji plat­for­my z punk­tu widze­nia użyt­kow­ni­ka) i na ofi­cjal­nej stro­nie developers.android.com wid­nie­ją już wytycz­ne doty­czą­ce pożą­da­nych dla tej plat­for­my spo­so­bów inte­rak­cji oraz wyglą­du inter­fej­su. Z dru­giej stro­ny wpro­wa­dze­nie tego typu wytycz­nych może jawić się jako naru­sze­nie otwar­to­ści plat­for­my i swo­bo­dy pro­jek­to­wa­nia.

Moż­na więc posta­wić pyta­nie, któ­ra dro­ga jest wła­ści­wa: peł­na otwar­tość czy restryk­cyj­na poli­ty­ka pro­jek­to­wa­nia UI? Apple może się jawić jako ‘tyran’ ogra­ni­cza­ją­cy swo­bo­dę i kre­atyw­ność twór­ców. Jed­nak, jak  zauwa­żył Simon Whi­te: „you don’t beco­me a brand with such UX impact witho­ut having strict con­trols on what appli­ca­tion deve­lo­pers can do on your plat­form. Google is argu­ably more open than Apple, but they pay the pri­ce in a sli­gh­tly less cohe­rent user expe­rien­ce in the­ir third-par­ty apps.”

Głów­nym pro­ble­mem jaki poja­wia się pod­czas pro­jek­to­wa­nia apli­ka­cji na Andro­ida jest zróż­ni­co­wa­nie urzą­dzeń w obrę­bie plat­for­my – HTC, Sam­sung i inne fir­my wypusz­cza­ją smart­fo­ny o róż­nych wiel­ko­ściach ekra­nu i roz­dziel­czo­ściach. Docho­dzi do tego pozor­nie banal­na spra­wa wyglą­du same­go urzą­dze­nia, dostęp­nych przy­ci­sków, spo­so­bu ich ozna­cze­nia itp.

W arty­ku­le opu­bli­ko­wa­nym w UXMat­ters wyróż­nio­ne zosta­ły trzy pozio­my mobil­ne­go user expe­rien­ce: sprzę­to­we, sys­te­mo­we i apli­ka­cji. W przy­pad­ku Andro­ida moż­na zauwa­żyć przede wszyst­kim nie­spój­ność na pozio­mie sprzę­to­wym (róż­no­rod­ność urzą­dzeń pocią­ga za sobą wspo­mnia­ne wcze­śniej zróż­ni­co­wa­nie w wyglą­dzie i funk­cjo­nal­no­ściach, róż­nych roz­mia­rach ekra­nu, dostęp­nych przy­ci­skach) – powo­du­je to, że czę­sto zmia­na urzą­dze­nia jest zwią­za­na z dra­stycz­nie odmien­nym doświad­cze­niem pod­czas korzy­sta­nia z nie­go (cze­go nie moż­na powie­dzieć zmie­nia­jąc  iPho­na 3 na  4 – ok, są róż­ni­ce ale nie trze­ba się uczyć na nowo jak posłu­gi­wać się urzą­dze­niem).

Nie to jest jed­nak naj­więk­szym pro­ble­mem Andro­ida. Pro­ble­mem jest brak spój­no­ści UI pomię­dzy apli­ka­cja­mi dzia­ła­ją­cy­mi na tej plat­for­mie,  co w dużej czę­ści było wyni­kiem bra­ku ofi­cjal­nych guideline’ów  doty­czą­cych spo­so­bu pro­jek­to­wa­nia.  Nie­ogra­ni­cza­ni przez wytycz­ne pro­jek­tan­ci i dewe­lo­pe­rzy potra­fi­li w rezul­ta­cie two­rzyć na Andro­ida skraj­nie odmien­ne pod wzglę­dem inter­fej­su apli­ka­cje, któ­rych obsłu­gi musie­li się za każ­dym razem na nowo uczyć skon­fun­do­wa­ni użyt­kow­ni­cy (celo­wo tro­chę prze­ja­skra­wiam sytu­ację, ale porów­nu­jąc UI róż­nych apli­ka­cji na iOS i Andro­ida nie spo­sób nie zauwa­żyć spój­no­ści UI tego pierw­sze­go). Zawio­dło więc w przy­pad­ku Andro­ida to, co jest bar­dzo pil­no­wa­ne od począt­ku w przy­pad­ku pro­duk­tów Apple’a – dostar­cze­nie użyt­kow­ni­ko­wi prze­wi­dy­wal­ne­go (w pozy­tyw­nym sen­sie) inter­fej­su i spój­ne­go zacho­wa­nia róż­nych apli­ka­cji w obrę­bie plat­for­my.

Co wię­cej – w kon­se­kwen­cji  bra­ku reguł pro­jek­to­wych, pod­czas pro­jek­to­wa­nia czę­sto wyko­rzy­sty­wa­no roz­wią­za­nia z innych plat­form np. iOS. Nie zawsze jest to dobre podej­ście, ponie­waż kon­wen­cje w Andro­idzie są inne. Przy­kła­dem może być cho­ciaż­by przy­cisk ‘back’, któ­ry zawsze jest widocz­ny i dostęp­ny w urzą­dze­niach z tym sys­te­mem – jako fizycz­ny lub cyfro­wy przy­cisk. Nie jest więc koniecz­ne umiesz­cza­nie go w apli­ka­cjach np. na gór­nej bel­ce, tak jak ma to miej­sce w apli­ka­cjach na iPhone’a.

Waż­nym ele­men­tem usta­la­nia stan­dar­dów pro­jek­to­wa­nia inter­fej­sów są wzor­ce pro­jek­to­we. Czym one są? Pod­czas two­rze­nia inter­fej­su pro­jek­tant napo­ty­ka sze­reg pro­ble­mów zwią­za­nych z róż­ny­mi ele­men­ta­mi apli­ka­cji – mogą one być zwią­za­ne np. z wpro­wa­dza­niem danych lub nawi­ga­cją. Wzo­rzec jest pew­nym ogól­nym roz­wią­za­niem czę­sto wystę­pu­ją­ce­go pro­ble­mu.  Kie­dy war­to korzy­stać ze wzro­ców? Wte­dy, kie­dy poja­wia się pro­blem na któ­ry dany wzo­rzec jest odpo­wie­dzią. I nie czę­ściej – nie nale­ży roz­wią­zy­wać pro­ble­mów, któ­re nie ist­nie­ją;)

Dla­cze­go war­to korzy­stać z wzor­ców? Choć­by dla utrzy­ma­nia spój­no­ści mię­dzy apli­ka­cja­mi , aby użyt­kow­nik intu­icyj­nie wie­dział cze­go może się spo­dzie­wać, jakie akcje pod­jąć, co może zro­bić. Wyko­rzy­sta­nie wzor­ców spra­wia, że apli­ka­cja wyda­je się użyt­kow­ni­ko­wi zna­na i prze­wi­dy­wal­na. Poza tym zna­jo­mość wzor­co­wych roz­wią­zań jest dobrym wstę­pem do zro­zu­mie­nia spe­cy­fi­ki dane­go śro­do­wi­ska i pro­jek­to­wa­nia opty­mal­ne­go user expe­rien­ce dla użyt­kow­ni­ków.

Poni­żej lista wybra­nych wzor­ców, któ­rych wyko­rzy­sta­nie jest reko­men­do­wa­ne przez Google:

Dash­bo­ard – punkt star­to­wy apli­ka­cji. Roz­wią­zu­je pro­blem nawi­go­wa­nia do głów­nych sek­cji w obrę­bie apli­ka­cji.  Infor­mu­je użyt­kow­ni­ka co moż­na zro­bić w tej apli­ka­cji. Powin­ny się tam zna­leźć skró­ty mak­sy­mal­nie do 6 sek­cji. Ponie­waż jest to jeden z pierw­szych ekra­nów jakie widzi użyt­kow­nik, waż­ne jest aby dash­bo­rad był atrak­cyj­ny wizu­al­nie –o tym, że pierw­sze wra­że­nie jest istot­ne, już kie­dyś pisa­li­śmy.

Action­bar – wzo­rzec cha­rak­te­ry­stycz­ny dla Andro­ida – podob­ny do paska nawi­ga­cyj­ne­go na stro­nach inter­ne­to­wych (umiesz­czo­ny u góry ekra­nu, z logo po lewej oraz glo­bal­ny­mi ele­men­ta­mi nawi­ga­cyj­ny­mi po pra­wej). Zapew­nia mecha­nizm powro­tu do stro­ny głównej/startowej (poprzez logo) i pod­kre­śla głów­ne funk­cjo­nal­no­ści. Nie powi­nien być uży­wa­ny do kon­tek­sto­wych akcji.

Quick Actions – wyska­ku­ją­cy pop-up z menu kon­tek­sto­wym. Do wyko­rzy­sta­nia w przy­pad­ku poje­dyn­czych ele­men­tów takich jak np. zdję­cia z któ­ry­mi moż­na coś dalej zro­bić – dodać do ulu­bio­nych, podzie­lić się ze zna­jo­my­mi itp.

Wid­get – wspo­ma­ga apli­ka­cję pozwa­la­jąc na wyświe­tle­nie okre­ślo­nych powiadomień/informacji na pul­pi­cie użyt­kow­ni­ka. Pozwa­la użyt­kow­ni­ko­wi dosto­so­wać pul­pit do swo­ich pre­fe­ren­cji.

Search­bar – pasek wyszu­ki­wa­nia zako­twi­czo­ny u góry ekra­nu daje użyt­kow­ni­ko­wi moż­li­wość szyb­kie­go zna­le­zie­nia pożą­da­nej infor­ma­cji

Wię­cej infor­ma­cji znaj­dzie­cie na http://developer.android.com/index.html. Ale koniec koń­ców, aby stwo­rzyć coś ory­gi­nal­ne­go, czę­sto trze­ba pew­ne sche­ma­ty i wytycz­ne łamać:)