WebExpo 2013 – poznámky
Velice mě v pátek zklamal organizátor v Development Hall, který uváděl ve své lámané „angličtině“ všechny přednášející. To mi od organizátorů nepřijde jako zvládnutý projekt.
V Design Hall měli technické problémy, které posunuli celý program o 15min, což nám trošku nabouralo naše plány.
Skvělý moderátor byl ovšem v Node5 Stage. Founder Stories od Fredrika Debonga a Jakuba Nešetřila jsem díky tomu náramně užil. Děkuji.
Část A: Pro vývojáře
Část B: Pro projektové a produktové manažery a designery
Pro vývojáře
Jakub Mrozek: Single-page applications (SPA)
- Apiary – nástroj pro vytváření a testování API
- machapito – nástroj pro Frontend First vývoj
- SPA mohou fungovat i offline
- PouchDB (offline JS DB inspirovaná CouchDB)
- existuje způsob generování URL pro Google i pro Seznam (ten je striktnější)
- Mocha – JS Test framework
- SuperTest – testovací nástroj pro Node.js HTTP server
- scenario test runner (jako selenium)
- travis (continuous integration)
- Bootstrap
- Yeoman (generátor …)
- Grunt – The JavaScript Task Runner
- summary
Ivan Potančok: Prototyping with bootstrap & less
- Bootstrap, Less
- předvedl svůj postup vytváření webů
- Specifikace
- Náčrt webu (ne wireframe)
- Místo wireframe vytváří prototyp pomocí Bootstrapu, což má uživateli přiblížit blíž k realitě (klikatelné formuláře) a zároveň ušetří práci při psaní HTML šablon
- Grafický návrh
- Šablony (pouze přizpůsobení grafickému návrhu, základ už je z prototypu)
- Vytvoření prorotypu musí dělat kódér (nedá se to naklikat)
Darcy Clarke (Canada): Documenting Interfaces
- dokumentace musí být snadno udržovatelná a standardizovaná, aby byla dobře čitelná
- stále existují bariéry v komunikaci mezi jednotlivými teamy/lidmi, kvalitní dokumentace může komunikaci zlepšit (ne nahradit)
- komunikace musí „žít“ spolu s projektem, ideálně aby se automaticky aktualizovala
- Parsování komentářů
- komentáře pro CSS
- KSS – nástroj pro generování dokumentace z CSS (used by github)
- DSS – nástroj pro generování dokumentace od D. Clarke
Seigerwald: Huge Web Apps
- vychvaloval staticky typované JS jazyky/frameworky
- zmiňoval Dart
- TypeScript je dobrý tah od Microsoftu, je velmi podobný jazykům PHP/C#/Java
- Polymer (evoluce Angularu)
- Facebook React – framework na podobné úrovni jako Angular. React vkládá HTML do JS kódu
- Angular/Embar vs React je jako HTML vs code … HTML nelze debugovat
- často se kombinuje Angular/React a Backbone, protože Angular/React nemá modely
- architektura nemá být typu rozdělena podle typu, ale podle vlastností/funkcí (design it by features)
- Closure Linter – nástroj na kontrolu stylu kódování
- wiring = factoring methods, logic = classes … separate logic and wiring
- Steida says it’s good to have kind of logic and markup (HTML) together … I guess he means logic of the view
- Moc mi z té jeho přednášky nevyplynulo, že by mluvil o rozsáhlých webových aplikacích
S.Battana: Dependency injection and dependency manager
- odstraňte cyklické závislosti
- RequireJS
- asynchronní načítání
- i pro txt, json, css
- client-side
- r.js is builder pro sloučení vložených souborů přes RequireJS do jednoho souboru
- browserify
- používá common.js
- funguje i na serveru
- synchronní
- npm
- package management (dependency between packages)
- server-side only
- bower
- front-end package management
- může používat i GIT repozitáře
- Neukládejte zdrojáky knihoven třetích stran, které máte nalinkované pomocí výše uvdených nástrojů
Nick Fisher (Germany, SoundCloud): Making the SPA work
- managing models … jedna instance každého modelu
- memory leaks … uvolňujte paměť
- css management … problémy: fragility, zvyšte rychlost, velikost, udržovatelnost
- SoundCloud řešení
- one view = one css
- konvence pojmenování css tříd s namespace__csstřída ale spoužitím gzip, takže nevadí při přenosu dlouhé názvy
- css to jss … pomocí JS modulu a importu CSS v JS
- waveform …. canvas using png as source, problems with drawing playlist (e.g. 800 tracks) … casching scaled images, typed arrays … at the end there is no reason to draw this exactly, so they just draw it somehow. Improved with server side calculation
- think about whats imprtontant and and think as user not like engineer
Honza Král, Karel Minařík – Elasticsearch
- nejen pro vyhlávaní ale poskytuje i analytické nástroje a úložiště pro logy
- pluginy (nic moc jsem nenašel)
- filtery (pro zúžení výběru vyhledávaných dokumentů) .. něco jako JSON
- dotazy např. přes URL q= … a podporuje to už i operátory
- vyhledávání i přes JSON request pro přesnější parametry vyhledávání
- ve výchozím stavu je „všechno“ nastavené k okamžitému použití
- používá to např. stackoverflow.com
- ověření vyhledávání např. přes CURL, výsledek pak lze zformátovat nějakou jejich CLI utilitou
- je tam logika např, že vyhledaný text v kratším políčku zvyšuje relevantnost výsledku
- cache snad i nějak na části filtrů
- zvýraznění vyhledaných slov (výchozí jsou HTML značky)
- umí to najít kořen hledaného slova a podle toho vyhledává různé tvary
- lze nastavit i vztahy mezi jednotlivými daty (např. rodič a potomek jako otázka a odpovědi)
- kibana … vizualizace log souborů
David Majda: Code Review
- SUSE Way: změna kódu … pull request … review …. zpátky nebo merge hlavní větve
- Řešení ala D. Majda:
- Rozumím tomu? Ne a proč?
- změny jsou příliš velké
- neznám kontext, stačil by kolikrát jenom komentář v kódu nebo v commitu
- Checklist
- High level
- Je to ten nejlepší způsov/návrh?
- Je to ve správné abstraktní vrstvě? Používá to zrdoje pouze z aktuální a nižší vrstvy?
- Je změna izovolovaná?
- Mid level
- Neviděl jsem to už někdy?
- Je to jednoduše udržovatelné? Nejsou tam závislosti?
- Je to jednoduše rozšiřitelné
- Není to moc “overengineered”?
- Pravidlo skautského tábořiště
- Low level
- Jsou obslouženy/zachyceny všechny chyby/výjimky?
- Jsou změny pokryté testy?
- Splňuje to styl kódování?
- Nezpůsobí to nějaký další bug?
- High level
- Socialální aspekty
- ten kdo dělá revizi někdy vůbec nezná ten kód ani autor nebo autora ani nemá rád
- žádné negativní komentáře proti autorovi nebo tomu kdo dělá revizi
- pokud kritizuješ, navrhni řešení
- než kritizuješ, zkus najít důvod/hodnotu, proč to autor napsal zrovna takhle (např. nějaký rychlý hack kvůli tomu, aby se stihlo vydání nové verze, a aby to nezpůsobilo zbytečné škody jinde)
Jakub Vrána: Code Review with Phabricator
- používá ho Dropbox
- podporuje GIT, SVN …
- komponenty
- dirrefential … code review
- diffusion … repository browser
- maniphest … tasks and bugs manager (for smaller company)
- herald … notifications (e.g. after changing your code)
- Owners, Calendar, Wiki, Blog, …
- Conduit … API
- Arcanist … command line interface
- inline komentáře (stačí vybrat kód a vložit komentář)
- má to vlastní jednoduchý značkovací jazyk např. na odkazy na jednotlivé části/revize v kódu
- detekce zkopírovaného a přesunutého kódu
- umožňuje poslat odkaz na konkrétní řádek na konkrétní revizi
- rozšířený blame na předchozí verzi (na původního autora myšlenky)
- lze nastavit, kdo může publikovat kód
- arcanist lint … pro kontrolu stylu kódování
- arcanist unit tests
- pište komentář, jak lze daný kód otestovat/spustit
- kód review dělejte během jednoho dne
- neptejte se na změny, které s problémem nesouvisí
- who reviews
- who lands it
- how to test it
- pre-commit
Pro projektové a produktové manažery a designery
Michal Hudeček: WebDirecting
- snažil se najít metaforu k vývoji webu a přirovnání vytváření webu k vytváření filmu
- Na příkladu Dropboxu a jiné služby uváděl, že nepotřebujete na webu uvádět technické parametry, ale je třeba najít správné posluchače. (Dropbox se nezabýval sdělením tech. parametrů)
- kvalitní design bez použití správných technologií už v dnešní době nestačí
- Pro vytvoření dobré služby/webu je spojit TECHNOLOGY + USERS + BUSINESS
- je potřeba rychlá zpětná vazba
- Pouhé kopírování Best Studies vám nepomůže, musíte se zaměřit na váš projek a ne pouze kopírovat existující produkt/služby/web
- Dnešní vzdělání nespojuje marketring, web-technologie a psychologii, což jsou obory potřebné pro vytváření kvalitních webů
- comparing web with a movie (visual, conversation, interaction)
- pracují na knize a video tutoriálech
- webdirecting.com
L. Plíhal: Web Design Pattern
- you have to start with a story to talk to clients
- you need to understand does (products, services)
R. Pavlíček: How to improve UX by implementing accessibility
- zaměřte se na hlavní obsah
- vylepšete formuláře … musí být intuitvní a jednoduché (propojené label a input, dostatečně velké v mobilní verzi)
- klávesové zkratky pro weby, které uživatelé používají častěji
- objednávky a platby musí být přístupné pro všechny, jinak se může člověk zaseknout např. na tom, že nedokáže zadat datum expirace platební karty klávesnicí, protože to je přes nějaký „speciální“ selectbox
- na přístupném webu dosáhne zákazník svého cíle rychleji
- přístupnost webu není vlastnost, je to obraz toho, jak nám záleží na lidech
P. Bonhard: Design Beyong the Screen (10 let UX designer)
- mnoho firem nabízí stejný produkt/službu … je nutné se odlišit poskytováním dalších služeb
- touchpoint je mezi zákazníkem a poskytovatel služby (pokladní, web, papírová faktura, …)
- digitální (SW, web)
- reálné (papírové dokumenty, lidi na telefonu, …) – tyto jsou často důležitejší než digitální
Nik Page – Emergent (vznikající/kamžitý) Service Design: Collaborating Towards
- UX Designer from Česká spořitelna
- navrhuje nový web pro csas.cz
- začal s průzkumem,
- otázky na lidi,
- zjišťování, jak je lidi přimět, aby přišli do jejich banky
- nemůže navrhnout zavedení všeho přes banking, protože ČS má prvenství v počtu poboček a z toho musí těžit
- Jako UX designer nenabízejte Service Design, nabízejte konkrétní řešení nebo vylepšení
- objevujte jak udělat věci lepší, spolupracujte s ostatními, abyste dosáhli lepších výsledků => lepší potěšení z práce
- spolupráce neznamená pouhé sdílení výsledků, ale je to týmová práce, kdy všichni společně pracují na daném projektu
- obvyklý den UX designera: komunikace s lidmi, vysvětlování, vzdělávání např. projektových manažerů, aby věděli v jakém případě by měli kontaktovat UX designera, UX designer dodává nové sesbírané informace produktovému manažerovi (např. půjčky přes web. aplikaci), aby vytvořil nový produkt nebo nějakou novou vlastnost/funkci
- pro měření existuje NPS (Net Promoter Score) metrika pro měření úspěšnosti služby na základě doporučení lidí, Nick tuto metriku nemá rád, protože někdy je mnohem lepší jeden konkrétní názor publikovaný v médiích než měření NPS
A. Hazdra: Service Design
- Service is journey (služba = „cesta“) … jako zúčastnit se webexpo od prvního rozhodnutí, přes nákup lístků, návštěvu přednášek, rautů a večírků až po feedback z konference
- ale není to jenom „cesta“, je to vlastně vystoupení/show (Performance)
- je to o lidech uvnitř i vně firmy (ne pouze o zákaznících) … musíte dělat průzkumy, mluvit s lidmi (zákazníci, ve firmě, zákazníci zákazníka)
- kniha Delivery Heapening / Štěstí doručeno
- při návrhu/realizaci služby máme zodpovědnost i za to, jak se postavíme ke změnám, které nastanou (ne jenom za dodržení termíny a samotný proces řízení projektu)
- kniha This is service design thinking
- kniha Skvělé služby
Wolf Becvar (Austria) – What you can’t wireframe
-
Najdi při návrhu svého projektu tzv. touchpoints
-
= cokoliv, přes co je zákazník spojen s námi
-
= jakákoliv interakce mezi námi a zákazníkem (telefonní hovory, marketing, web, jakákoliv další komunikace, sociální sítě, mobilní aplikace)
-
-
Jak najít touchpoints?
-
průzkumem (komunikujte se zákazníkem, dotazníky, ankety, přímé otázky, vžijte se do situace zákazníka)
- udělejte průzkum o survey about traveling satisfaction (little smile for each little thing … delivering tickets, buying tickets, traveling)
-
- howto transform touchpoints to project?
Carlo Frinolli – Visual Design Thinking
- vzdělávejte, vysvětlujte a sdílejte maximum inforamcí se svými zákazníky, aby rozumněli tomu, jak se projekt vyvíjí a aby si dokázali představit za co platí
- zákazník musí akceptovat to, že ho někdo bude vzdělávat
- nelze použít „vodopád“
- poměrně těžké u veřejných zakázek (pozn. RŽ.)
Thomas Sundberg – How to fail a project (Sweden)
- Jak udělat neúspěšný projekt
- hodně manažerů s různými cíli a prioritami a všem musíte vyhovět
- neutrácejte peníze za vzdělání
- všechno kritizujte a ideálně veřejně
- neinvestujte do nástrojů
- počítejte s lidmi jako se zdroji, tzn. dají se kdykoliv jednoduše nahradit
- mějme jednoho hrdinu, který všechno vyřeší
- veškerá komunikace v textové podobě
- dělejte dlouhé schůzky, které často rušte; a když je nezrušíte, tak tam nechoďte; a když už tam přijdete, tak buďte nepřipravení
- nedělejte krátké denní porady
- specifikaci vždy pouze psaná a bez příkladů
- nesnažte se najít společnou „řeč“ (jazyk, UML, způsob komunikace)
- nesnažte se mít zákazníka na naší straně
- všichni vědí, kdy je projekt hotový, takže to není potřeba nikomu říkat
- navrhujte všechno na dlouhou dobu dopředu a do posledních detailů a striktně
- jeden člověk zvládne všechno
- používejte neobvyklé frameworky (homemade, komerční)
- používejte globální proměnné a singletony
- zabývejte se bezpoečností až jako poslední
- když výstup tak ve všech možných formátech (XML, JSON, XLS, TXT, …)
- navrhujme věci velké a komplexní
- prvně nadefinujte styl kódování a použitý verzovací systém
- mějme právě jednu osobu, která bude vlastníkem všech kódů
- optimalizujte ihned … nejlíp ještě před tím než je aplikace hotová
- nepoužívejte continues integration (no continues integration)
- akceptujte rozbité buildy (accept broken builds)
- všechny buildy dělejte ručně a bude to dělat pouze jeden člověk ve firmě
- velké projekty jsou důležitější, takže ty malé vždycky počkají
- žádné párové programování
- žádný vývoj řízený testy
- vždycky 100% pokrytí testy
- vždycky 100% dokumentace ke všemu
- kontrola kvality a testy až jako poslední
- funkční testování ručně a pouze přes GUI (klik, klik)
- žádná automatizace
- snažte se vyhnout/oddálit nasazení nové verze … je to riskantní, nasazujte až v nejnutnějším případě a pouze obrovské změny
- žádné průběžné nasazování
- Úspěšný projekt
- kniha Agile manifesto
- Jednotlivci a interakce před procesy a nástroji
- Fungující software před vyčerpávající dokumentací
- Spolupráce se zákazníkem před vyjednáváním o smlouvě
- Reagování na změny před dodržováním plánu
- jeden projekt = jeden manažer
- správné nástroje
- pokrytí testy s ověřením výsledků v testech
- zkoumejte/kontrolujte a přizpůsobte se (inspect and adapt)
- lidé nejsou zdroje, jejich znalosti nelze jednoduše nahradit
- komunikace tváří v tvář je nenahraditelná
- dělejte krátké denní porady o stavu včera, plánu na dnešek + porkoky a problémy
- jednodušší komunikace vede k jednoduššímu návrhu
- specifikace vždycky s příklady (může k tomu pomoci Cucumber)
- komunikujte se zákazníky, setkejte se s nimi osobně a snažte se porozumět jejich potřebám
- architekt systému musí rozumět kódování (asi programování)
- žádné singletony a globální proměnné
- výstupy pouze ty nutné, ne všechny
- párové programování
- optimalizace až na konci, pokud je vůbec potřeba
- automatizovat (integrace, nasazení, …)
- kniha Agile manifesto
-
simple design
-
all test passes (there should be test)
-
good naming
-
no duplication
-
small everything
-
-
… something about git
-
work on development
-
books …. Agile programming, Extreme Programming
-
he doesn’t agree that anybody from the team shouldn’t be able to talk to the customer
