Nejčastější chyby při vývoji mobilních aplikací

• Otázka platformy
• Příliš funkcí
• Neúměrný požadavek na nadmíru volného místa
• Podcenění aktualizační složky
• Přílišné reflektování webové stránky
• Zvýšená pozornost na vizuální prvky

Otázka platformy

Celá věc se přeceňuje. „Dogmatici“ budou vždy orodovat za jedno řešení, tedy iOS, nebo Android. Dříve to dávalo smysl (nedostatek technologických možností), ale dnes se to mění. Proč nevyužít obě platformy za stejnou cenu? Souběžný vývoj jak v prostředí iOS, tak Android (platforma Windows je dnes už spíše minoritní záležitostí, nebo takto aspoň my vnímáme) může v rámci ceny/výkonu parametrů dávat moc dobrý ekonomický smysl a kvalita aplikace bude více než dostačující (příklad je např. vývoj interní úzce oborově praktické pracovní aplikace pro firmu). V takovém momentu se dobře hodí kupříkladu technologie Xamarin, která dokáže relativně snadno přenést jednou vytvořený kód pro všechna požadovaná prostředí, nebo javascriptový framework React Native. V čem se technologie liší, se dočtete v tomto článku.

Je též pravdou, že při vývoji herních aplikací je ale rozhodně dobré vývojový proces dělat paralelně, na to se Xamarin dle úsudku našich vývojářů moc dobře nehodí a bylo s ním v takovém případě více škody než užitku.

Příliš funkcí

Otřepané, ale za každého počasí pravdivé přísloví říká, že v jednoduchosti je síla. Představte si následující situaci -  jste uprostřed vývoje a dostanete zajímavou myšlenku, že aplikace XY by vlastně mohla umět zároveň XZ funkci, když už vlastně de facto pracuje ZYX funkcí. Chápete, kam tím mířím? Není samo o sobě špatně, že vývojáři dostanou v průběhu procesu vzniku aplikace od klienta zbrusu novou myšlenku, co by vlastně aplikace mohla ještě umět, nebo ji sami klientovi vnuknete. Špatně ale je to, když myšlenky na další „doplňující“ funkce a vychytávky aplikace strhnou na sebe veškerou vývojářovu pozornost.

Začátečníci (bez ofenzívy k jejich schopnostem, o ty teď ani nejde, ani o jednotlivce, nebo začínající vývojářské startupy) ve světě aplikačního vývoje se mohou být svým „elánem“ snadno náchylní k takové – z jejich pohledu vnímáno - nevinné ztrátě pozornosti na hl. důležitou funkci a její rozředění na možná hezké věci, ale v tento moment ne třeba tak důležité z hlediska provozu a výkonu aplikace.

Udržovat požadovaný počet funkcí, který bude souběžně korelovat s jednoduchosti „user experience“ a logickým průchodem aplikace je tím správně nastaveným mind-setem.

Neúměrný požadavek na nadmíru volného místa

Více než běžná chyba. Mobil je odlišné prostředí než klasický desktop a to je mít vždy na vědomí. Ukládání dat, využívání paměti nebo práce s baterií funguje na mobilu i PC prostě zase jinak, i když to může být ledačems stejné. Ale právě odlišnostem je třeba věnovat pozornost a vědět o nich.

Jaká má být adekvátní velikost aplikace? To je pro vývojáře vždy palčivou otázkou, na kterou nelze odpovědět dvakrát stejně. Najít jasně formulovanou univerzální odpověď - to by ani ničemu neprospělo. Možná, že správným směrem jde ta odpověď, která říká, že pokud aplikace v telefonu zabírá na uživatelův vkus mnoho místa, tak vzniká větší pravděpodobnost, že bude i odinstalovaná.

Ale jasně dá rozum, že když vyvíjíte pořádně našláplou a rozsáhlou hru s parádní grafikou, tak prostě ta velikost tomu bude zajisté úměrná. Ale pokud se bavíme o klientských a byznysových aplikací, tak jsou skutečně velikostně v realitě zbytečně velikostně „přebombených“. A přitom by to stačilo dát si jen trochu více času např. s tím, že vývojář odebere nevyužité zdroje, minimalizuje využití prostředků z knihoven, komprimuje soubory PNG a JPEG a provede redukci přebytečného kódu aplikace.

Podcenění aktualizační složky

Ať se vyvíjí interní aplikace pro firmu, nebo aplikace plnící byznysové účely zadavatele, tak v každém v tomto zmíněném případě by vývojáři měli být vždy schopni poskytnout součinnost při aktualizačním procesu.

Jedině při testování a nasazení v ostrém provozu mohou (a také často se tak děje) vzniknout pravoplatné požadavky na zlepšení běhu a výkonu aplikace z uživatelské strany – fotbalista se také nejlépe osvědčí, jak na tom skutečně je se svým umem jen na hřišti, než poposedáváním na příjemně zateplené střídačce. Proto ražení hesla “jednou naprogramujeme a na výsost věků na to už nemusíme šáhnout“ není úplně tím správným krédem pro tolik požadovanou praktičnost. Vývojáři musejí umět požadavky identifikovat a nabídnout vhodné řešení.

Přílišné reflektování webové stránky

Ok, společnost má webové stránky a chce, aby i nová aplikace to patřičně ctila a odrážela jejich charakteristické prvky. To znovu samo o sobě nemusí být chybou. Co už ale chybou bývá, že se tato myšlenková linie často vyvine do podoby, že společnost/zadavatel začne podvědomě chtít, aby aplikace vlastně disponovala stejnými vlastnostmi a prvky jako stránky. To svým způsobem pak nedává smysl tvořit novou mobilní aplikaci. Tady musí vývojář trpělivou cestou vše klientské strany vysvětlit a znovu se podívat a případně přehodnotit na cíle a uživatelské skupinu lidí, kteří budou nově vyvíjenou aplikaci využívat.

Zvýšená pozornost na vizuální prvky

Dělat provozuschopné aplikace nemusí nutně znamenat mít v ní ty nejkreativnější vizuální části na věci. Kreativa je dobrý sluha, ale špatný pán (o tom něco málo s mou kolegyní víme). Kreativa a vizuálno obecně musí mít své hranice a pomáhat plnit hl. cíle. Je to jako s vařením a kořeněním jídla, stačí špetka a je to fantastické, stačí špetka navíc a je to…No, víte kde.

Když už si chcete „okořenit“ aplikaci vizuálními parádami, tak zkusit s nimi pracovat spíše konvenčnější cestou (přeci jen, asi vývojáři nedělají na každém kroku aplikace na hledání vodu na Jupiteru apod., kde kreativní vizuální složka bude naopak zřejmě příjemným zpestřením), a to tak, aby jim uživatel aplikace mohl jen podle samotného obrázku snadno porozumět. Don’t make me think od Steva Kruga, doporučuji přečíst, jedná se dnes už o kultovní záležitost v oboru UX.