nav line

Mobilní web: návrh vs. realita

Po nemalém úsilí jsem odřídil a v rámci Lundegaardu jsme dokončili obsáhlý mobilní projekt pro společnost CETELEM ČR, který v sobě zahrnoval i několik slepých vývojových uliček, ale také mnoho zajímavých technických řešení. Pojďme se podívat na to, čemu je dobré dle mého názoru předejít, co je dobré v základu zachytit a jak postupovat pro dosažení nejlepšího výsledku.

Když se řekne mobilní web, většina lidí si představí optimalizovaný běžný web, který se dá nějak smysluplně ovládat na mobilním zařízení. Z části je to pravda, která ovšem ve velkém platila před několika lety. Situace se ovšem vyvíjí a moderní mobilní weby se dělají prakticky jako samostatné projekty, které mohou (ale nemusí) využívat stejné informační zdroje jako „běžný“ web.

Prakticky roční vývoj řešení se v mnoha aspektech projevil i na samotném konceptu, použitých technologiích a samotné integraci ke stávajícímu webu. Byl prvotní návrh v pořádku či se ve finální podobně již diametrálně změnil? Byly použité technologie ty správné nebo bylo možno zvolit s ohledem na vývoj projektu jiné? Ne na všechno existuje jednoznačná odpověď a ne každá slepá ulička je vyloženě špatná.

Zadání, návrh, analýza a vzájemné potvrzení scope projektu

Na začátku stálo samozřejmě klasické zadání od klienta, které popisovalo důvody, přínosy a očekávání klienta od mobilní verze webu. V tomto případě byl brief velmi jasný, konstruktivní a byly v něm popsány i některé funkce mobilního řešení, které tam klient chce nebo naopak nechce. Na nás bylo sestavit koncept, který vše ucelí, popíše a dle kterého dílo může vzniknout.

Důležitá rozhodnutí

Když se ohlédneme, tak je dobré si říci, která nejdůležitější rozhodnutí byla správná, chybná a proč. Prvním důležitým rozhodnutím bylo stavět mobilní web jako zcela samostatnou a na „velkém“ webu nezávislou aplikaci, která ovšem bude/musí využívat stejné rozhraní interních systémů klienta jaké používá běžný web.

Tyto fakta pro nás znamenaly tři věci:

  1. Použití vhodného CMS jako robustního základu, využitelného i v blízké budoucnosti (V tomto případě CMS LARS Vivo), bez ohledu na CMS, na kterém běží klasický (desktopový) web
  2. Volnost návrhu, designu a funkčnosti aplikace, která není vázaná na standardy běžného webu.
  3. Znalost prostředí backend systémů klienta, které jsou nezbytné pro chod podstatné části řešení.

Druhým důležitým rozhodnutím se stala definice podporovaných zařízení a s tím souvisejících používaných technologií. Tento bod se ukázal ve finále jako nejkomplikovanější a nejdůležitější pro rozhodování, výrobu a řízení projektu. Grafy ukazující rozvrstvení chytrých telefonů na českém mobilním trhu, jednoznačně dovolují volit technologie pro „chytřejší“ zařízení s tím, že „hloupější“ zařízení budou mít omezenou funkčnost nebo vzhled aplikace, nicméně nebude se pro ně optimalizovat.

Toto rozhodnutí pro nás znamenalo:

  1. Jasný návrh technologií a podporovaných zařízení.
  2. Realizace „light“ verze se vůbec nebude řešit („hloupé“ telefony nejsou podporovány)
  3. Vykreslování ovládacích prvků bude realizováno za pomoci jQuery Mobile frameworku.
  4. Díky užití frameworku bude seznam podporovaných zařízení jednoduše aktualizovatelný.

Další dílčí rozhodnutí nejsou tak důležitá a nijak zásadně se ve finálním řešení neodráží jejich změna.  Zaměřím se na výše dvě popsaná rozhodnutí/premisy a jejich vliv na vývoj, integraci a projekt jako celek.

Ujistěte se, že uvedená podporovaná zařízení opravdu fungují

Prvním nemilým překvapením při užití frameworku byl fakt, že uvedený seznam podporovaných zařízení není tak aktuální jak bychom si představovali. Velmi často se stává, že výrobci mobilních telefonů aktualizují systémy v tak rychlých vývojových cyklech, že na to nelze adekvátně reagovat. Rozdíly byť mezi minoritními aktualizacemi bývají nad očekávání velké. Bohužel ve fázi testování na mnoha a mnoha různých zařízeních nutně dojdete k tomu, že uvedený model, ač je podporován – něco zobrazuje jinak/hůře/špatně atd. Vzhledem k pečlivé práci na tomto projektu jsme my ani klient nebyli spokojeni s tím, že některý model zobrazovat to samé tlačítko o několik pixelů jinde než jiný…  V tu chvíli začalo piplavé ladění interních CSS a javascriptu samotného frameworku.

V tuto chvíli to ovšem vypadalo pouze na pár drobných úprav a rozhodli jsme se u frameworku zůstat. Jenže posléze se okruh nepodporovaných zařízení, která je potřeba podporovat, začal neplánovaně rozšiřovat.

Ujistěte se, jaké zařízení používá vedení společnosti!

Ano je to tak, vedení společnosti používá na tyto projekty víceméně helicopter view – o projektu ví, ale detaily nejsou podstatné. Při prezentaci v rámci vedení se ovšem narazilo na to, že z mnoha důvodů se používají zařízení, která mají se zobrazením tohoto projektu zásadní problémy.

Ano tyto zařízení nebyly na kompatibility listu, takže z projektového hlediska je vše v pořádku, ale samozřejmě vyvstal neoddiskutovatelný požadavek na dopracování podpory pro tyto zařízení.

Standardní možnosti vs. požadavky

Dalším velmi problematickým bodem byly různé grafické úlitby, které framework neuměl, ale klient si je přál. Hlavní a velikou výhodou frameworku je samozřejmě jednoduchost aplikace různých ovládacích prvků napříč všemi podporovanými zařízeními. Existuje sada vzhledů, které se dají barevně přizpůsobit, ale to jestli mají kulatý nebo hranatý roh již řídí cílové zařízení.

Pokud si v projektu začnete hrát s myšlenkou, že chcete kulaté rohy všude anebo že chcete piktogram vpravo místo, ve zvoleném frameworku, standardního vlevo nebo snad přidat dodatečný text na tlačítko, které to předtím neumožňovalo…. Začněte navrhovat systém mimo  framework!

Bohužel poptávka po těchto detailních změnách přišla v podstatě až ve finálních fázích projektu a tedy nebylo dost dobře možné celý systém opustit a zahodit tak několikaměsíční práci. Ovšem po zkušenostech s detailními úpravami sebemenšího pixelového rozdílu na různých zařízeních je mnohem efektivnější si vše udělat úplně od znova inhouse.

Samozřejmě přijdete o snadnou integraci nových věcí a o aktualizace v rámci frameworku, teoretickou velmi širokou základnu testerů – což se nám ale příliš neosvědčilo, protože podporovaná zařízení nepracovala zcela korektně, ale především se vyhnete mnoha a mnoha technologickým omezením, které framework skýtá.

Řízení a náklady

Od začátku projektu, již v prvních fázích bylo jasné, že se jedná o komplikovanou problematiku a že bude potřeba řídit projekt více z pozice jasných dokumentů, akceptací a oboustranného několikanásobného odsouhlasení. Části projektu byly, v případě, že to umožňoval čas, řízeny i více agilně, abychom vycházeli vstříc požadavkům zadavatele. Ovšem striktní řízení není dobré jen pro dodavatele, ale také pro zákazníka, který má ucelený přehled o tom co se děje a je informován, že takový nebo takový požadavek bude v nákladech znamenat nezanedbatelnou položku.

Odchylky od původního záměru a nově vymezené podpoře dalších zařízení projekt nejen natáhly v čase, ale také výrazně navýšily náklady na samotnou realizaci.

Zásadní změnou filozofie v konečné fázi projektu dostal tento projekt zcela jiný rozměr především z pohledu řízení zdrojů a celkové náročnosti úkolů, které před námi stály.

Výsledek

Projekt mobilního webu společnosti Cetelem nebyl lehký, jak z technologického, tak z řídícího pohledu, ale ve finále je výsledek pozitivní. Integrace na současné webové řešení je nenásilná především díky naprosté oddělenosti platforem, na kterých jednotlivé části běží, ale zároveň jsou velmi úzce provázány přes interní systémy klienta, aby spolu spolupracovaly.

Multichannel řešení v tomto směru dostává zcela nový rozměr, jelikož můžete akci začít na mobilu a dokončit klidně v počítači, nebo opačně. A to vše bez toho aby oba systémy běžely na společné platformě!

Za dobu realizace projektu jsme získali mnoho cenných ponaučení a dalších znalostí, které nám nyní pomáhají navrhovat podobné systémy efektivněji a především v prvních fázích bezpečně zafixovat použité technologie.

Ohodnoťte článek

Mobilní web: návrh vs. realita

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících