Pozvánka: Večer o službách, designu a inovacích

funny-beans

Zveme vás na přátelské setkání skupiny K vašim službám. Ta se již dva roky zabývá designem služeb, inovacemi a mapuje skvělé nápady v oblasti zákaznických služeb doma i venku. Právě jsme dosáhli 400 členů, takže je načase se sejít.

Cílem akce je potkat podobně smýšlející lidi, podívat se na nejnovější projekty na trhu a především se pobavit.

Setkání hostí LMC, s.r.o., které stojí za projekty Jobs.cz, Práce.cz a Teamio.

Vystoupí

Kdy, kde?

Středa 24. června od 18 do 21

V LMC s.r.o., Lighthouse Tower (10. patro), Jankovcova 1569/2c, Praha Holešovice

MHD zastávka Maniny, nejbližší metro Palmovka či Vltavská

Chci se zúčastnit

Přidejte se do skupiny, máme tam vytvořený event. Účast zdarma.

sponzori

Titulní fotka z 3oneseven.com.

Evoluce banneru

evolution_by_wikipedia

Právě jsme dotestovali nový balíček brandové podpory. Jedná se o kombinaci banneru na titulní straně Jobs.cz, PR článku a hromadného e-mailu. Funguje to dohromady velmi dobře, hlavně e-mailing, ale i tak jsme si potvrdili bannerovou slepotu.

Od myšlenky k pilotu

Začalo to na konferenci v Londýně, kde se hodně mluvilo o tom, že zaměstnavatelům už nestačí zveřejnění inzerátu. Chtějí se uživatelům prezentovat v dobrém světle a představit jim značku, práci, kolegy a další věci hlouběji než jen přes odrážky typu Požadujeme/Nabízíme. Dává to smysl i z druhé strany: výzkumy nám ukazují, že smysluplná práce pro dobrou firmu představuje jeden z klíčových parametrů při výběru zaměstnání, hlavně u mladších lidí.

První návrh z konference JobG8

První návrh z konference JobG8

Už v Londýně jsem kreslil první návrhy, které akcentovaly příběh konkrétní firmy či náboru. Žádné databázové fotky, ale budoucí nadřízený, jeho skutečná slova a příběh firmy či náboru. Náš uxák Marek Cais myšlenku dopracoval a grafik Petr Šolín jí dal finální podobu. Záhy jsme se dohodli na pilotu s personální společností Adecco, která zastřešuje nábor Area Managerů pro logistické centrum Amazonu v Dobrovízi.

banner_jobs_final

Finální návrh Marka Caise a Petra Šolína

Hned od začátku bylo jasné, že nemůže jít pouze o trochu jinak pojatý banner. Na tak malé ploše značku nevysvětlíte a navíc je to i přes všechnu snahu komerční sdělení, které je ignorováno (viz opakovaný test Norman Nielsen Group). Ani hromadný e-mail nemusí mít sám o sobě velký zásah, pokud chybí atraktivní obsah.

Proto od počátku šly služby v balíčku. Banner odkazuje na PR článek na Jobs.cz/Inspirace , který tvoří de facto landing page pro ostatní kanály. V něm vysvětlujeme, koho firma hledá, jaké je to v ní pracovat, doplňujeme videa atd. Článek jsme následně zařadili do pravidelného týdenního newsletteru.

Banner funguje, ale výkon jde z e-mailů

Výsledky testu pro vás asi nebudou překvapivé. Nejvíce návštěv a konverzí nám přinesl newsletter, banner na titulní straně má sice dvojnásobný výkon než bannery umístěné jinde na našich stránkách, ale za newsletterem i tak pokulhává. Je součástí balíčku spíše z brandových důvodů, které se ale těžko měří (velice pozvolna se nám daří zavádět prodej přes výkon u takovýchto věcí, historicky je stále zájem o to „být vidět“ i za cenu nižších konverzí).

Článek v sekci Inspirace fungoval dobře, byl nejčtenějším za poslední měsíc. V polovině testu jsme ho ještě doplňovali o výraznější konverzní tlačítko, dříve tam byly pouze ztučněné odkazy a jeden pomocí H2 na konci. Po stránce konverzí měla samotná pozice řádově vyšší počet zobrazení i odpovědí.

Během pilotu jsme přidali výraznější konverzní tlačítka do článku.

Během pilotu jsme přidali výraznější konverzní tlačítka do článku.

Shrnuto podtrženo, balíček služeb na podporu brandu zafungoval, děláme další kroky a přibližně do měsíce by měl být běžně k dispozici všem našim klientům.

Pár obecnějších úvah na závěr

Zdá se, že klasické bannery skutečně nemají moc smysl. Obhajoba typu: „To je hlavně brandová záležitost“ se těžko pokládá daty (podle průzkumu si 60 % lidí vůbec nevybaví žádnou poslední reklamu, kterou na webu viděli). Obsah a zejména e-mail fungují dobře.

Výhledově bychom tedy mohli vlastně nabízet pouze obsahové kampaně, trochu nadbytečný banner zabít a dělat brandovou podporu chytřeji – třeba jak nyní již děláme při Měsíci absolventů či jak dělá GlassDoor na titulce pomocí fotek kanceláří vybraných firem.

Vede to ale k další úvaze: podobnou výkonnost jako banner mají i další komponenty titulky kromě našeho základního scénáře – hledání práce. Proč tedy zdržovat uživatele zobrazováním titulky, když chtějí práci (rozuměj výsledky či doporučení)? I do SERPu se dá zakomponovat něco navíc (rozuměj propagace našich dalších produktů), není potřeba tomu dělat specifické sekce na průchozí stránce.

Inspirovat nás může třeba Slevomat, který titulku vůbec nemá.


 

Za postřehy děkuji Robertovi Plemátlovi, business ownerovi Jobs.cz.

(Úvodní fotka převzata dle licence CC BY-SA 3.0 z Wikipedie)

Testujete? Zkuste to v terénu, dozvíte se mnohem víc

photo 2-2

S připravovaným redesignem Prace.cz potřebujeme získat od uživatelů co nejvíce podnětů,  jak by budoucí podoba měla vypadat. K tomu nám, kromě standardního testování v LMC, slouží i testování v terénu.

Osobně jsem k němu byl zpočátku velmi skeptický. Říkal jsem si, že když nemáte notebook, online přenos, ani oční kameru, nebude takové testování moc přínosné. Pak jsme na první testování s kolegy vyjeli a od té doby ho považuji v ranné fázi vývoje za přínosnější, než testování v LMC.

Proč?

Pražští uživatelé jsou jiní

Pokud si zvete uživatele na testování v Praze, pravděpodobně budou také z Prahy. A chování pražských uživatelů je dost specifické, zejména pokud jde o potřeby při hledání práce.

V Praze jsme několikrát testovali koncepty nového vyhledávání. A pořád jsme nebyli přesvědčeni o tom, že to, co máme před sebou na monitorech, je ono. Pak nám stačilo pár hodin v Děčíně. Povídali jsme si s lidmi o tom, jak hledají práci, třeba v místech, kde je jí málo. A když jsme odjížděli domů, už jsme měli jasno.
Od té doby prochází uživatelé při testování naším připravovaným vyhledáváním jako nůž máslem.

Vyslechnete si spoustu životních příběhů

Během kampaně, při které jsme vyjeli za lidmi po celé zemi a rozdávali jim naše noviny s nabídkami práce, jsem měl možnost setkat se s mnoha lidmi, kteří mi vyprávěli svůj životní příběh. O tom, jak přišli o práci. O tom, jak nemohou sehnat novou. O tom, jak si vydělávají, kde se dá. Po takové zkušenosti se budete na svou práci koukat trochu jinýma očima.

Paper prototyping funguje

Když ukážete lidem papírový prototyp, chvilku na vás budou koukat nedůvěřivě. Stačí jim ale vysvětlit, že takhle to potom bude vypadat i na počítači.

Chcete otestovat dva různé způsoby výběru z nějakých možností? Stačí mít obě dvě varianty připravené na dvou různých papírech. Podle rozhovoru většinou poznáte, kterou variantu uživatelé očekávají. A tu jim pak můžete předložit. Dle mých zkušeností na konci můžete tu druhou variantu vyhodit :-)

Testování v terénu určitě není samospásné. V pozdějších fázích vývoje ho budete muset zcela jistě doplnit i klasickým testováním. Nicméně pro „výkop“ vám poslouží velmi dobře.

Oční kamera. Váš další smysl při uživatelském testování.

An-Eye

Nikdy jsem nebyl velkým zastáncem oční kamery. Vždycky mi přišlo, že oční kamera maskuje neschopnost designéra dobře naslouchat a pozorovat, co člověk na stránkách dělá.

Postupem času se ale eyetrackingové “železo” radikálně zlevnilo a v tu chvíli mi začalo dávat smysl začít ho používat jako doplněk. Jako další smysl pro designéra.

U nás v LMC při testování:
Pozorujeme, jak lidé pohybují myší a na co klikají.
Díváme se, jak se u toho tváří.
Zjišťujeme, jak obtížné je pro lidi vykonat na stránce nějakou akci.
Nebo jak těžké je nalézt určitou informaci.
Posloucháme, co nám lidé říkají.
A teď dokonce víme, na co se dívají 😉

Každá z těchto věcí sama o sobě je jen dílek skládačky. Nikdy nevíte, pomocí kterého “smyslu” zjistíte podstatnou informaci nebo chybu vašeho návrhu. U nás takto celé testování přenášíme online přímo na stůl designérovi, který v reálném čase využívá všechny tyto “smysly”. Vidí, jak člověk pracuje se stránkou, jak se u toho tváří, co při tom povídá a co na stránce poutá pozornost jeho očí.

Vybavení, které používáme:
http://www.techsmith.com/morae.html
http://www.gazept.com/

A jaké máte zkušenosti s oční kamerou vy?

Zajímavosti z konference Jobg8

hilton-london

S Hankou Kostovičovou, marketérkou Práce.cz, jsme na konci listopadu vyrazili na Jobg8 London, největší setkání jobboardů v Evropě. Přijeli dvě stovky lidí z desítek zemí a webovek, většinou produkťáci, marketéři, majitelé apod. Diskutovalo se samozřejmě o mírném oteplování na trhu, LinkedInu a dalších tématech. Tady je výběr toho, co mi i po více než týdnu zůstalo v hlavě.

Sofistikované produkty pro sofistikované uživatele

„Nechci jen kupovat inzeráty, chci, abyste mi pomohli budovat značku,“ prohlásila recruiterka z ADP na jednom z workshopů. Pojmenovala tím trend patrný v dnešních internetových službách: přechod od jednoduchých nástrojů, které uživatelé již ovládli, k pokročilejším. I klienti jobboardů mají svá stále rostoucí KPI a chtějí po partnerech výkon. Čekají, ze druhá strana bude přemýšlet nad jejich potřebami a dodávat chytrá řešení brzy a levně; pak u nich nechají své rozpočty. Jsem proto rád, že Jobs.cz nasazuje některé metody Human Centered Design (více o HCD), a věřím, že se to brzo promítne do našich služeb.

Madgex

Britská firma Madgex staví jobboardy na klíč. Má platformu a na ní seká jeden web za druhým. Dělají job sekce velkých medií (Guardian, Independent, Telegraph), staví jednoduché samoobslužné vertikální webovky jako onlymarketingjobs.com. Stojí také za jedním z posledních britských jobboardů: Manpower.co.uk.

Hovořili o dvou zajimavých tématech. Zaprvé, komplet migrují na responsive a zbavují se aplikací a to zejména z technických důvodů (údržba jednoho kódu). Ačkołi s tím plně nesouhlasím, protože se domnívam, že apky dodavají poněkud jinou experience než mobile web (zkuste třeba číst zprávy přes apku iDnes a redesignovaný mobilní web iHNed), jsem rád, že toto téma pro mnohé v sále otevřeli. Podle čísel napříč jejich weby vyrostl mobile za poslední rok o 400 % (a tablety překvapivě klesly o 25 %) a 40 % přístupů je přes mobilní zařízení. U nás situace zatím není stejná, ale růst je velmi podobný.

Zadruhé, zaujala mě diskuse pricingu, kdy zdůrazňovali jednoduchý jazyk a cílení ceníku na potřeby. Pro ilustraci si porovnejte jakýkoli trojsloupcový ceník typu Standard – Gold – Enterprise s tím, který má Careers in Audit.

Ceník jinak (Careers in Audit)
zdroj: Careers in Audit Media Pack & Rate Card 2014, str. 7 [PDF]

Odborníků bude ubývat

Poslední věcí byl vývoj trhu. Očekává se pozitivní trend, který ovšem velmi záhy začne narážet na nedostatek odoborníků. Pomalu přicházejí slabší ročníky, takže bude méně inženýrů a vývojářů, po kterých je a bude hlad. V Německu očekávájí zlom už v r. 2015, u nás to bude o pár let později ale i tak podobné (viz ČSÚ).

Věcí na Jobg8 zaznělo mnohem více, přesvědčte se sami v přehledu prezentací. Celkově to bylo i přes organizační mouchy (první den nebyl internet) zejména obsahově povedné. Těším se na další ročníky a doporučuji návštěvu.

Funkční systémové testování: když unit-testy nestačí

Quality assurance v praxi

Při dlouhodobém vývoji větší a komplexnější aplikace se zvyšuje šance, že změna na jednom místě rozbije nebo jinak ovlivní fungování aplikace na místě nějakém úplně jiném. Tato rizika můžeme snižovat řadou způsobů (důsledná kontrola a code-review, dobře dekomponovaná aplikace apod.), ale ani tak není nikdy možné je snížit na nulu. Proč to tak je a co se s tím dá tedy dělat?

Rozbíjíme si aplikace

Pro uvedení do kontextu stručně k tomu, jak u nás v LMC vývoj probíhá: vyvíjíme naše vlastní webové produkty prostřednictvím několika agilních týmů. Průběžně tak dochází v aplikacích k množství změn, na úpravách jedné aplikace pracuje souběžně několik vývojářů z daného týmu, a to v rámci různých a často nesouvisejících issues (ticketů). Produkty jsou to rozsáhlé, mají za sebou několikaletý vývoj, a je tak téměř nemožné, aby některý vývojář znal nazpaměť všechny části aplikace.

Aplikace jsou samozřejmě do rozumné míry pokryté unit testy a každou issue před dokončením testuje kromě samotného vývojáře obvykle v rámci code-review i alespoň jeden další vývojář, stejně tak funkčnost kontroluje ještě produktový manažer. Jenomže – ani jedna z těchto vrstev testování nemusí odhalit některé problémy. Zvláště ty, které se zdánlivě vůbec netýkají upravované části aplikace. Jakto? Může napovědět pár příkladů, ať už z naší praxe či teoretických:

  • Oblíbené „odstranění nepoužívaného kódu“ odstranilo kód používaný na místě, kde o něm vývojář nevěděl, a způsobil tím nefunkčnost jiné části aplikace.
  • Úpravou v globální šabloně se na jedné stránce přestal načítat externí javascript, takže nefungovaly žádné javascriptové interakce (modální okna, taby, AJAX…).
  • S aktualizací jQuery přestal v jednom prohlížeči fungovat jQuery plugin používaný na jedné „zapadlé“ podstránce.
  • Odkaz zasílaný v potvrzovacím e-mailu přestal fungovat.
  • Změna v databázi (nový sloupec) kvůli potřebě rozšíření API způsobila nemožnost ukládat položky přes jedno zapomenuté GUI.

Podobné „rozbíjení“ aplikací je víceméně přirozenou a nevyhnutelnou součástí vývojového procesu. Důležité ale je umět tyto problémy účinně a co nejdříve nacházet.

Funkční systémové testování

Cestou k tomu je systémové testování, konkrétně jeho funkční část (proto „funkční systémové testování“). Tedy testování, které probíhá nad celým již integrovaným systémem a které testuje nějaký funkční požadavek či očekávání. Jedná se tedy o vrstvu testů, která je nad unit testy a těsně nad integračními testy. Svým způsobem se tak jedná o výstupní kontrolu produktu před jeho předáním zákazníkovi. (U nás děláme vlastní produkty, takže máme tzv. „interního zákazníka“ – stakeholdery, nicméně na podstatě to nic nemění.)

Na straně zákazníka by pak mohlo následovat ještě akceptační testování, tedy testování, zda aplikace splňuje např. smluvně zadané funkční scénáře. Na rozdíl od akceptačního jsou ale při systémovém testování ověřovány i různé podscénáře, chování, které zákazník očekává (a nemusí být ani ve specifikaci) a celková bezporuchovost dané webové aplikace. A jak bylo uvedeno výše, má navíc automatizace tohoto testování neocenitelnou hodnotu v průběhu vývoje. Funkční testy jsou tedy nezbytnou součástí fungujícího continuous integration – vrchol testovací pyramidy.

Laicky se dá v případě webu funkční systémové testování označit jako „klikací testy“, protože o tohle převážně jde: v prohlížeči – ať již skutečném (např. Firefox) nebo v headless (PhantomJS) – se automaticky projde nějaký scénář a podobně jako v unit-testech se zkontroluje, že očekávané chování odpovídá tomu, které skutečně nastalo. Může se jednat o podobně jednoduché scénáře s jednoduchými očekáváními:

  • Po kliknutí na odkaz „Přihlášení“ se dostanu na stránku s přihlašovacím formulářem, kde mě po zadání přihlašovacího jména a hesla aplikace přihlásí.
  • Když naopak zadám špatné heslo, zobrazí se chybová hláška.
  • Když zadám něco do vyhledávacího políčka a formulář odešlu, zobrazí se stránka s výsledky.
  • Přiložený soubor (CV) v odpovědi na nabídku pracovní pozice nemůže být spustitelný a větší než 5 MB (a v obou případech se uživateli zobrazí chybová hláška).

Může jít ale i o komplexní scénáře podobného typu:

  • Jako firma vytvořím inzerát s nabídkou pracovní pozice. Po zaplacení kartou se mi zobrazí potvrzení a e-mailem mi přijde faktura. Notifikační e-mail přijde také fakturačnímu oddělení. Do několika minut (po zaindexování fulltextem) pak bude bude pozice vystavená a fulltextem vyhledatelná.
  • Zaměstnavatel založí v personálním systému nového zaměstnance. E-mailem mu pošle výzvu, aby nahrál do systému svou fotku prostřednictvím jednorázového odkazu. Zaměstnanci přijde na jeho e-mail během 5 minut (tj. až projde message queue) zpráva s tímto odkazem. Na uvedeném odkazu nahraje svoji fotku, nastaví její ořez a fotku uloží. Jeho nová fotka se od této chvíle začne personalistovi správně zobrazovat. Jednorázový odkaz navíc nejde znovu použít.

Pokud bychom kontrolu podobných scénářů dělali ručně, zabralo by nám to spoustu času. To by kromě nákladů a zdržení nasazování (když se najde a pak opraví chyba, je třeba celou aplikaci opět přetestovat) znamenalo, že bychom ji ani nemohli testovat průběžně, a na chyby bychom přicházeli až v okamžiku „těsně před předáním“. A jak známo, čím dříve chybu najdeme, tím nás stojí méně.

Co používáme v LMC

Pro automatizaci tohoto testování dnes existuje řada nástrojů. Některé jsou postavené pouze nad jedním headless prohlížečem (Casper JS a další), čímž mimo jiné testerům ztěžují psaní i kontrolu testů, jiné možná zbytečně přidávají vrstvu abstrakce (Behat + Mink) a pro funkční testování se vlastně ani nehodí.

Po špatných zkušenostech s proprietárním nástrojem Squish jsme se letos rozhodli přejít na Selenium WebDriver (mimochodem – WebDriver se stává W3 specifikací a tedy de-facto průmyslovým standardem pro automatizaci ovládání prohlížečů).

Testy píšeme v PHP (kde používáme implementaci php-webdriver), a spouštíme skrze vlastní nástroj Steward postavený na PHPUnitu. O jejich automatické spouštění oproti různým vývojovým prostředím se stará Jenkins CI server. Samotné Selenium pak testy vykonává ve Firefoxu, Chromiu, PhantomJS a zkoušeli jsme i MSIE. I přes určité porodní bolesti se nám to zatím vcelku osvědčuje, což dokládá mimo jiné i snížení množství WTF za minutu při psaní a kontrole testů (v porovnání s předchozí platformou).

 

Ve chvíli, kdy neděláte jenom aplikace zakázkovým low-end stylem „nasadit, vyfakturovat a zapomenout hesla k ftp“ ale naopak se k aplikaci vracíte, nebo se třeba jako v našem případě jedná o vlastní vyvíjené produkty, byl by život bez systémového testování hodně na hraně. Testy se dají rychle napsat i spustit a z praxe musím říci, že nám zachránily řadu i velmi vážných produkčních incidentů.

(Autorem úvodního obrázku je NATO a podléhá licenci CC-BY-2.0)

DevFest 2014: Responzivní obrázky tečka Dart [video]

devfest2014-publikum-jan-zalsky

Na letošní DevFest jsme z LMC vyrazili pouze v malém týmu tří lidí. Přednášek a workshopů navštívil každý z nás přibližně stejně; o podobě záchrany lidstva jsem však bojoval pouze já. (Palec nahoru organizátorům za zábavu při celodenní hře!)

Darrrt

Tématem, které rezonovalo celou konferencí, byl jazyk Dart – nepokrytě pak v sugestivně nazvané přednášce Jany Moudré Dart, Darrt, Darrrt. Mluvilo se o něm na mnoha dalších prezentacích a workshopech přímo zmiňující jeho jméno v názvu. To nebylo překvapivé. Kdo by ale odhadl, že při povídání o Polymer.js bude většina dotazů mířit na Polymer.dart; nebo že se o něj budou čile zajímat lidé, kteří nevyvíjí front-end a běžně píší v Javě nebo C#? Nejjistějším důkazem však byla moje konverzace s personalistkou, zajímající se nakolik je „znalost jazyka Dart výhodou“ výhodou.

Osobně jsem byl z Dartu velmi nadšený. Byl, když se poprvé objevil. Od té doby mé nadšení ochladlo a čekalo na znovunastartování do doby, než se virtuální stroj Dartu dostane do Chrome, a raketově vystřelí až se prosadí i jinde. Po diskuzi s Filipem Hráčkem o tom, jak pokrořila kompilace Dartu do JavaScriptu, si dokáži představit praktické použití již dnes. Stále to ale nestačí, abych pro Dart opravdově zahořel.

Diskuze s Filipem (a dalšími) proběhla u piva na večerní after party, kterou můžu s klidem označit za nejlepší z těch, které za poslední tři roky po pražských vývojářských konferencích proběhly.

Pokročilé responzivní obrázky

Já sám jsem v podvečer přednesl svou zatím nejúplnější prezentaci o responzivních obrázcích, kterým jsem tento rok věnoval mnoho pozornosti. Díky velkorysému prostoru – 45 minut – jsem měl možnost projít vše podstatné.

Začal jsem motivací a představil případy užití definované skupinou RICG. Dále jsem se snažil abstraktně popsat, který rozpor mezi prohlížečem a vývojářem je třeba vyřešit. Samozřejmě jsem vyložil syntaxi přijaté specifikace elementu picture a atributů srcset a sizes. Nakonec jsem ukázal, jaký algoritmus výběru toho správného obrázku používá Google Chrome.

Podívejte se na záznam, nebo si jen projděte – ilustrativně pojatou – prezentaci:

(Úvodní obrázek je výřez z fotografie Jana Žalského)

Facereader: Sci-fi UX Research v LMC [video]

můj Edík

Všichni pořád říkají, že UX není jen interakční desing, že je to o emocích. Kdo z nás opravdu měří nebo alespoň zkoumá emoce? Existují různé techniky, ale většina z těch, s kterými jsem se setkal, jdou na emoce oklikou (např. Product reaction cards).

V LMC jsem na podzim 2013 zkoušel nástroj, jako vystřižený ze seriálu Lie to me – z mikrovýrazů tváře čte emoce. Šikovní lidé v holandsku udělali program, který zužitkoval výzkum Dr. Paula Eckmana. Z výsledků jsem si sednul na zadek (videoukázka je v článku).

Na Jobs.cz jsem koukal na homepage a četl jsem článek. Rozesmutnil mě náborový baner se seznamem benefitů jedné česko-německé automobilky (a to přesto, že v LMC máme masáže, čajovnu, jógu atp.). Pak jsem četl článek o českém absolventovi, který po škole nastoupil do Ebay. V článku nebyl název pozice, na kterou absolvent nastupoval zmíněný a to mě trochu naštvalo. Facereader všechny mé emoce odhalil.

Facereader poznal smutek, rozčílení nejen u mě, ale i u mých kolegů, se kterými jsem nástroj zkoušel.

Závěr:

Nástroj je to zajímavý a dle mého zkoušení přesný, ale za 10 000 euro, je ještě dost drahý. Třicet dnů trialu uteklo jako voda a já se musel s Facereaderem rozloučit.

A jak zkoumáte emoce vy?

Tipy pro práci s Bowerem aneb pokročilý lemčík

Lemčík ve svém loubí

Lemčík je australský ptáček, který je známý tím, že jeho samec ze svého okolí vybírá větvičky a jiné rozličné předměty, ze kterých staví komplikované stavby zvané loubí (více na Wikipedii). Lemčík je anglicky nazývá bowerbird a loubí je anglicky bower. A ano, přesně takto přišel Bower – nástroj, který z okolí vybírá nástroje a jiné rozličné komponenty – ke svému názvu.

Pokud znáte základy Boweru, možná byste ocenili některé tipy k ulehčení tvorby vašeho loubí. Sepsal jsem ty, které považuji za nejužitečnější.

Lokální vývoj komponent

Typická situace: mám závislost, kterou potřebuji vyvíjet v rámci jiného projektu. Jak na to? Mohu každou změnu přidat do gitu, publikovat ji, stáhnout v projektu, případně použít buildovací nástroj a pak konečně otestovat. To je ta zdlouhavá a otravná varianta.

Bower nabízí přímý přístup pomocí volby link. Stačí v adresáři s komponentou zadat bower link a poté v adresáři projektu tuto komponentu vnitřně zaregistrovat spuštěním bower link nazev-komponenty. V projektu vznikne symlink, takže jakákoli úprava v komponentě bude ihned viditelná v projektu. Pro načtení verze z bower.json a přepsání symlinku stačí zadat v projektu bower update.

Definice balíčku

Jak boweru řeknete, který modul má stáhnout? No přeci jeho názvem: jquery, bootstrap, emerald atd.!

Jistě, to je pravda, ale jde to i jinak. Důležité je uvědomit si, že Bower pracuje s git repozitáři. Jako balíček ke stažení lze zadat libovolnou git adresu. Taková adresa může být dokonce privátní. Při zadání názvu se ve skutečnosti stane jen to, že se Bower podívá do své databáze, který git repozitář je pod tímto názvem zaregistrovaný.

Adresa repozitáře se zadává do bower.json na místo, kde se obvykle uvádí verze balíčku. Za ní může následovat znak # a označení tagu, název větve, nebo hash konkrétního commitu. Text na místě názvu balíčku bude odpovídat názvu adresáře v bower_components. Díky tomu umí Bower naistalovat dvě různé verze stejného balíčku.

Různé možnosti a kombinace jsou demonstrovány v této ukázce:

Podrobněji o tomto pojednává sekce install v dokumentaci.

Změna cílového adresáře

Často se vývojáři ptají, jestli a jak mohou změnit adresář, kam Bower instaluje komponenty z výchozí app/bower_components. To je velmi jednoduché, stačí do adresáře s bower.json přidat soubor .bowerrc s následujícím obsahem:

Tento soubor je samozřejmě nutné přidat do repozitáře, aby se tato změna projevila všem spolupracovníkům. Doporučuji .bowerrc vytvořit vždy, mezi jednotlivými verzemi Boweru se totiž cílový adresář mění z bower_components na app/bower_components.

Drobnost na závěr

Každý se občas potřebuje podívat do dokumentace balíčku, s kterým pracuje. Při zadání bower home nazev-balicku se v prohlížeči zobrazí domovská stránka daného balíčku bez pátrání mezi výsledky hledání.

(Úvodní obrázek je výřez z originálu a podléhá licenci CC BY-SA 2.0)

Placeholdery vs. popisky: A/B test

Dvě varianty testované v rámci A/B.

Jednou větou: A/B test nám ukázal, že umístění popisků nad hledací pole, byť je to po stránce designu méně elegantní, přináší více konverzí než umístění textu v placeholderech.

Re-design nové titulky Jobs.cz byl u nás v posledních dvou měsících velké téma. Snažili jsme se to nepodcenit, hodně jsme diskutovali a načítali. Jednou z diskutovaných otázek bylo i zda pro hlavní vyhledávání umístit popisky přímo do polí formou placeholderů. Otázku vyvolal nedávný článek na NN Group.

Dvě varianty testované v rámci A/B.

Obě testované varianty, vlevo aktuální titulka

První prototyp, UX-ově produktový, počítal s popisky. Následující grafický návrh už to přetavil do placeholderů a my jsme vzhledem k blížícímu se termínu jeli podle návrhu.

Co se ale nestalo, první analýza čísel nám ukázala, že hlavní hledací pole nejsou na nové titulce zdaleka tak viditelná, jak jsme si mysleli. Jednak jsme do návrhu už asi moc dlouho koukali a druhak se zřejmě projevila výrazná fotka v hlavičce. V UX testování se to neprojevilo.

Nu což, jde o business, museli jsme to řešit. Udělali jsme A/B test, kde jsme pouze vypsali popisky nad hledací pole. Použili jsme Visual Web Optimizer a pustili na 10 % návštěv. Výsledek byl jasný po třech dnech. Verze s popiskami měla o 17 % lepší konverze, v tomto případě využití hlavních polí k hledání vůči ostatním odkazům na stránce.

Graf s výsledky AB testu ve VWO.

Oranžově stávající verze, modře verze s popisky

Potvrdili jsme tedy závěry NNG a dali zapravdu našemu kolegovi Milanu Krylovi, který byl od začátku proponentem tohoto řešení. V dohledné době umístíme popisky nad hledací pole a po skončení probíhající kampaně počátkem prosince nasadíme novou hlavičku, kde bude kladen vyšší důraz na hledání.

PS. A/B testy obvykle pouštíme na doporučovanou dobu jednoho týdne kvůli reprezentativnosti. Tentokrát jsme museli vypnout dříve kvůli tomu, že nám kód testu rozbil jinou část rozhraní. Další náklady směrem k testování jsme vzhledem k výsledkům nevynakládali. Výsledky po třech a půl dne jsou výrazné a stačí.

Za postřehy děkuji Petru Havlíkovi.