V dnešní době se software vyvíjí různými způsoby. Někteří vývojáři se často snaží našroubovat vývoj čehokoliv na již jednou vymyšlený postup a ten metodicky (až notoricky) dodržovat krok za krokem. Já osobně vidím v každé metodologii určitý smysl a snažím se naopak pro každý projekt použít to nejideálnější ze všech. V tomto článku bych chtěl obecně popsat fáze vývoje mobilních aplikací a jejich návaznost tak, je mně to funguje.
Nápad
V případě Windows Phone je sice velký prostor pro realizaci nových nápadů ale aktuálně nejsnazší cestou je okopírovat nápad cizí. Pokud jste četli můj předchozí článek Stavební kameny dobré WP aplikace, zřejmě již tušíte, kam tím mířím. Na WP Store je celá řada zajímavých aplikací, které nemají pěkný design, mnohdy špatný UX nebo jindy sice mají dobrý nápad ale nerealizují jej ideálně. Inspiruji se aplikacemi pro konkurenční platformy ale i aplikacemi pro Windows 8 desktop. Líbí se mi aplikace jednoduché a méně nákladné, které potřebuje co největší skupina uživatelů. Je-li aplikaci možné přeložit a distribuovat pro další trhy, je naprosto jasným kandidátem.
Cílová skupina
Srdcem aplikace jsou uživatelé. Pokud nevím jakou aplikaci vytvořit, snažím se najít nějakou zajímavou uživatelskou skupinu. Podívejte se třeba na své přátele a jejich záliby. Zjistíte, že někdo z nich hraje golf? Zkuste se zamyslet nad uživatelskou skupinou, která hraje například amatérsky golf.
Cílová skupina Vám pomůže identifikovat problémy, které mají a narýsovat zhruba koncept aplikace. Budete mít základní představu o tom, co by měla aplikace řešit. Pokud se sejdete s jedním dvěma lidmi z takové skupiny osobně, dá vám to velké množství zkušeností. Měly byste mít odpověď na zásadní otázku: Jste schopni vyřešit nějaký problém této skupiny, za který bude Vaše cílová skupina ochotná zaplatit? Nebo alternativně: Jste schopni nalézt obchodního partnera, který Vám aplikaci “zaplatí”? O business modelu píšu okrajově níže v tomto článku.
Doménový expert
Doménový expert je Vaše pravá ruka. Je to inovátor, který patří do Vaší cílové skupiny a důvěřujete jeho znalostem z dané problémové domény. Můžete ho najít na Internetu, může to být člověk, s kterým jste se sešli osobně nebo to můžete být vy – pokud skutečně spadáte do cílové skupiny a považujete se za doménového experta. Pokud jste v životě nehráli golf, zřejmě se bez doménového experta neobejdete. Doménový expert reprezentuje celou Vaší cílovou skupinu. V extrémním programování se často používá termín “zákazník na pracovišti”. Doménový expert Vám také často poradí, jak získat algoritmus, kde získat relevantní data aj. Zkrátka Vám ledacos hloupého dokáže rozmluvit a ledacos chytrého poradit.
Během poznávání cílové skupiny možná zjistíte, že problematika, kterou chcete řešit se rozděluje na více “táborů”, kdy každý vidí daný problém jinak. Pak je na Vás, na kterou skupinu se zaměříte nebo zda Vám dává smysl pokrýt vše. V takovém případě bych ale zvolil doménové experty dva, kvůli zásadně odlišnému pohledu na věc.
Hlavní tester
Hlavní tester je pro mě osoba, která patří do cílové skupiny. Pokud mám svého doménového experta, je to právě on. Jsem-li doménový expert já, nutně musím najít někoho, kdo bude můj hlavní tester. Není dobrý nápad aby hlavním testerem byl člověk, který aplikaci vyvíjí ani první člověk, který si ji stáhne z WP Store. V konečné fázi si samozřejmě nevystačíte s jedním testerem ale u rozsáhlé aplikace jich budete potřebovat více. A opět zdrojem bude Vaše cílová skupina. Hlavní tester je vždy první, kdo mi vše pomůže otestovat aniž bych musel plánovat hromadné testování s více uživateli.
Protože vždy potřebuji buď testera nebo doménového experta, dávám přednost právě hledání experta, který je mi po ruce a aplikaci mi testuje a pomáhá profilovat. I když dané problematice rozumím, stojí za to najít více lidí se stejným zájmem (kvůli zkušenostem, odlišným názorům a řešením).
Míra abstrakce
V mobilu mám poznámky o připravované aplikaci, na stole se povalují papírky s dalšími nápady na vylepšení, na nástěnce jsou nakreslené první vizuály aplikace… je třeba všechno to spojit dohromady a udělat si jasno.
Aplikace může být nekonečně rozsáhlá nebo skutečně detailně zaměřená na jeden detail. Představte si Zimní olympijské hry 2014. Můžete udělat aplikaci, která zobrazuje všechny sporty, sportoviště, program, sportovce, výsledky atd. Můžete se ale zaměřit jen na lední hokej a zobrazit program, týmy, výsledky a tabulky. A nebo se zaměříte jen na samotné zápasy a každý analyzujete do detailních podrobností včetně online zpravodajství. Můj cíl je najít konkrétní úroveň abstrakce a tu si ohraničit.
Pokud uděláte aplikaci Nutriční atlas, málokdo bude předpokládat, že její součástí je i nákupní seznam, byť to s problémovou doménou souvisí. Stejně pokud uděláte aplikaci Nákupní seznam a její součástí budou i ceny v supermarketech, v podstatě nikdo s takovou funkcionalitou vzhledem k jednoduchosti stejně pojmenovaných konkurenčních aplikací nebude počítat. Tak trochu platí, že název aplikace by měl výstižně pojmenovat celou problémovou doménu včetně jejích hranic.
V tomto kroku už mám vždy jasno
- kdo je moje cílová skupina
- jaké má tato skupina potřeby
- kdo je můj doménový expert
- co bude aplikace řešit
- jak bude aplikace problémy řešit
Následně si volím jaké potřeby budu nakonec řešit (míra abstrakce a její hranice).
Business model
Když už mám jasno, co bude aplikace dělat, je také potřeba vymyslet, jak od uživatele dostat zaplaceno. Pokud chci zisk maximalizovat, na metody typu “zaplaťte a odstraní se Vám reklama” zapomeňte. Je celá řada způsobů, jak na aplikaci vydělat. Já mám rád následující tři:
Bezvýchodná situace
Osobně se mi líbí metoda, kdy nějakým způsobem uživatele dostanete do bezvýchodné situace (kromě toho, že si aplikaci koupí). Je to agresivní řešení ale hodně efektivní. V podstatě uživateli dáte kompletní produkt, který v jednu chvíli nebude schopen používat bez toho aniž by zaplatil. Představte si například, že si uživatel zapisuje nějaké své poznámky do aplikace “Deníček”. V momentě, kdy si bude chtít přečíst záznam vložený před měsícem mu ale aplikace napíše: “pro zobrazení záznamů starších 1 měsíc si kupte novou verzi”. Studená sprcha.
Závislost
Jednodušší koncept je klasická závislost, kdy jednoduše omezíte aplikaci na počet spuštění nebo na určitý čas používání. Nevýhodou takového řešení je, že uživatel nemá důvod jednoduše přejít ke konkurenční aplikaci. Druhou nevýhodou je, že uživatel může aplikaci odinstalovat a poté znovu nainstalovat (neberu v potaz, že byste si nějak uživatele identifikovali a informace o použití aplikace odesílali do nějaké webové služby).
Externí business
Business se nemusí odehrávat přímo ve Vaší aplikaci. Například, budete-li mít free aplikaci se seznamem fitcenter v Praze, kterou již využívá alespoň 1000 uživatelů, můžete vytvořit v aplikaci úvodní stránku “doporučená fitcentra” a tyto výhodné pozice nabídnout přímo provozovatelům fitcenter. Vzhledem k chabé ochotě uživatelů platit za aplikace je toto řešení velmi efektivní.
Data
Zásadní otázkou je také rozhodnutí, odkud získáte data, případně algoritmus. Pomoci může nejen doménový expert ale i Vaše zápisky ze schůzek s cílovou skupinou. Ta Vám zřejmě sdělila, jak řeší své problémy a odkud čerpá informace. V této oblasti doporučuji být maximálně opatrný a vždy si ověřit původ dat a zda nepodléhají autorskému zákonu a můžete je volně šířit.
Prototyp
Už vím kdo je moje cílovka, jaké problémy budu řešit a jak na nich vydělat. Mám k ruce ideálně experta, který mi bude pomáhat aplikaci vytvářet a testovat. A mám kontakt na pár uživatelů, kteří aplikaci otestují před publikací. Je na čase promyslet, jak to bude vypadat na displeji.
Vytvoření prototypu je pro mě spíše záležitostí UX. Snažím se promyslet provázanost stránek, určit prioritu funkcí, zvolit způsob, jak budou data poskytována. Rozhoduju se, jestli budu používat panorama nebo pivot, volím jaké prvky se budou jak chovat, rozhoduji se jaké standardní prvky na co použiju nebo jaké ikony budou v Application baru. Neřeším barvy a snažím se ani nemyslet na to “jak to v tom kódu napíšu”. Věnuju se jenom tomu, abych měl na papíře tužkou načmáraný koncept aplikace. Koncentruju se na to, aby všechno dávalo smysl a aby se aplikace dobře používala. Je to klíčový proces, při kterém komunikuju hodně s doménovým expertem.
Snažím se, aby vzniklý prototyp byl i kontraktem, do kterého už nebudu sahat. Pokud dělám velkou aplikaci, jejíž funkcionalitu jsem se rozhodl rozdělit do více fází (chci vydat první osekanou verzi a pak ji rozšiřovat), pak se stejně snažím, aby prototyp odrážel celek. Mým cílem je totiž celá aplikace a chci se vyhnout tomu, že kvůli abstrahování od celého řešení na něco zapomenu kvůli zaměření se na určitou část.
Design
Když mám posvěcený prototyp aplikace (chápejte hromadu pokreslených papírů), je na čase dát všemu skutečný vzhled. Poprvé sahám na nějaký kus softwaru. Upřednostňuju Adobe Photoshop (kvůli mnohaleté zkušenosti se mi v něm dělá snadno a rychle) ale použít lze cokoliv, co umožňuje do detailu nakreslit vzhled aplikace. Do detailu!
Mnoho vývojářů tento krok přeskakuje, jelikož jej považuje za zbytečný. Pokud mezi ně patříte, skočte na můj článek Stavební kameny dobré WP aplikace, kde objasňuju význam designu jako jednoho ze tří stavebních kamenů dobré mobilní aplikace. Dobrou aplikaci podle mě tvoří detaily. Raději vytvořím málo ale dokonalejšího než hodně ale nedopracovaného. V případě designu volím nejprve barevné schéma, poté obarvuju hlavní prvky celé aplikace. To ostatní přijde tak nějak samo. Občas se daří a vymyslím dobrý design za den, jindy i po třech dnech nemůžu sestavit nic smysluplného. Tak už to chodí.
Znovu připomínám zlaté pravidlo – když dělám grafiku, neprogramuju… K designu se často vracím. Občas zjistím, že něco v aplikaci na reálných datech nesedí. Vždy se ale snažím nechat si veškerou grafiku na jeden zátah. Z minulosti vím, že když buším kód a odskočím si něco dokreslit do Photoshopu, vznikne obrovský shit. Mozek není příliš kreativně naladěn a paměťový moduly jsou naplněný proměnnýma. Člověk spěchá aby už dopsal aplikaci a mezikrok - design – pak odflákne.
Ve fázi designu je důležité myslet i na marketing. Spolu s designem aplikace by měly být vytvořené i různé ikonky pro WP Store, případně různé promo materiály. Když nebudete mít ikony na WP Store připravené, při publikaci aplikace samozřejmě zpanikaříte, budete chtít mít aplikaci rychle venku a nejspíš spácháte designérské zlo podobné jako v předchozím odstavci.
Tip: začínám pracovat na jednoduchém toolkitu pro grafiky, který usnadní návrh WP aplikací v Photoshopu. Sledujte GitHub projektu.
Vývoj
Vývoj aplikace dělám často souběžně s grafikou. Jeden den kreslím, druhý den píšu kód. Snažím se to nemíchat do jednoho dne ale osvědčilo se mi iterovat tyhle dvě fáze, protože mě často něco v souvislosti s tím druhým napadlo. U vývoje je toho hodně k řešení, hlavně ze začátku. Rozhoduju se, jestli použiju nějakou webovou službu, jak bude probíhat komunikace, kde se budou ukládat data nebo jaká bude architektura. Když to má smysl, používám MVVM, když to smysl nemá – nedělám to.
Snažím se psát čistý kód, abych jej po sobě po čase přečetl, byl jsem schopný nalézt chyby a aplikaci případně snadno rozšiřovat. Práci si usnadňuju Telerik komponentami a Windows Phone Toolkitem. Vzhledem k šílenému kódu a neskutečně obskurní konfiguraci a dokumentaci už Teleriky používám jenom na grafy. WP Toolkit pak na všechny ostatní prvky. Šetří mi to čas a pomáhá udržet jednotný styl.
To, jakým způsobem vývojář píše kód, má v konečném důsledku vliv i na UX. Ukázalo se, že často stojí za to přemýšlet nad dvěma světy (svět offline a svět online). Když jsou data online, dělám vše proto, aby byly aktuální ale z externích zdrojů se tahaly jen když je to nutné. Když uživatel přejde do režimu offline, snažím se, aby měl k dispozici alespoň historická data (třeba den stará). Situaci, kdy je uživatel offline a aplikace mu nejde, přestože by se dala použít historická data, považuju za UX fail.
Testování
Aplikaci jako celek testuje v první řadě můj hlavní tester nebo doménový expert. Chyby opravuju zase od designu až po vývojářské bugy. V této fázi už jsou chyby relativně “malé” a souvisí spíše s různým prohazováním prvků, doplněním informací nebo jinými detaily. Aplikace, která projde hlavním testerem by měla být ještě otestována nějakými dalšími uživateli z cílové skupiny. Jinak je tu pořád velké riziko chyby. A chyby se na tlustém klientovi opravují dost mizerně, když si uvědomíme, že jen schválení aplikace trvá 5 dní.
Konečnou aplikaci se snažím ještě před publikací zhodnotit. Můj názor je, že dobrou aplikaci tvoří detaily a aplikace je z mého pohledu tak dobrá jako nejhůře provedená fáze vývoje.
Publikace
Publikace je pro mě rituál. A často docela dost únavný. Osobně začínám tím, že si vytvářím screenshoty z dokončené aplikace a kontroluji, jestli mám opravdu všechny podklady připravené. Kromě splashscreen přidávám screenshoty aplikace v akci. Snažím se vyhnout nevyplněným polím a nevypovídajícím screenshotům. Obrazovku snímám v takovém stavu, aby se uživatel vžil do své role a viděl sám sebe jak aplikaci používá. Pokud aplikace obsahuje více jazykových verzí, dělám screenshoty pro každou verzi samostatně. Trvá to dlouho! Ukrutně! Moje aplikace gTranslate je v 11 verzích (cca 45 screenshotů). Ale stojí to za to. Uživatel z Ruska tam tu cyrilici prostě potřebuje vidět…Vzhledem k tomu, že WP Store je hlavní místo prodeje, je potřeba aby texty byly krátké a plně vypovídající. Ano, pokud mám aplikaci v 11 jazycích, musím si popis 11x přeložit.
Nedokonalost
Uvědomuju si, že všechny moje aplikace jsou nedokonalé. Čím více se učím a čím více přečtu článků o designu od různých odborníků a čím více si čtu o UX, uvědomuju si, že je nezbytný se ke všem aplikacím neustále vracet a oživovat je. To co se mi dnes líbí mi za měsíc bude vadit, protože v tom uvidím něco, co jsem tam dnes neviděl.
Shrnutí
- najdu cílovou skupinu pro kterou chci dělat aplikaci
- hledám problémy cílové skupiny, které by mohla aplikace řešit
- dohodnu se s jedním člověkem z cílové skupiny, který bude můj doménový expert
- volitelně si z cílové skupiny zvolím hlavního testera (může to být doménový expert)
- zvolím si míru abstrakce a hranice toho, co chci řešit
- vybíram core funkcionality a definuju si název aplikace
- rozhoduju se jak bude fungovat business
- vytvářím prototyp aplikace na papírech
- prototyp se snažím udělat jen jednou
- překresluju prototyp do grafického návrhu v PSD
- grafický návrh v PSD implementuju
- snažím se buď dělat design nebo programovat, nepřebíhám mezi fázemi
- vše co naprogramuju otestuju
- vše co udělám konzultuju s doménovým expertem
- konečnou aplikaci nechávám otestovat více lidí z cílové skupiny
- uvědomuju si, že aplikace je tak kvalitní jako nejhůře provedená fáze vývoje
- před publikací aplikace si ověřuju jestli mám vše potřebné připravené
- snažím se, aby aplikace na WP Store vypadala co nejlépe
- k aplikacím se neustále vracím