26.10.2023 14:30 Text původně vyšel v newsletteru ze Vzhůru dolů. Milé čtenářky, milí čtenáři, tentokrát to bude vcelku osobní. Nominovali mě na osobnost českého digitálu a díky tomu vám musím napsat, co vám chci napsat už dlouho. Mám totiž v plánu pár změn, a potřebuji vědět, co si o nich myslíte. Nominace ve WebTop100 je fajn. Na zadek si nesedám, doma mi nemuseli začít vykat, ale lidí, kteří mě nominovali si vážím, a stejně tak mám respekt ke společnosti nominovaných, ve které jsem se ocitl. Nominaci jsem si prý zasloužil „za kontinuální práci na zrychlování českého internetu”, ale myslím, že se trošku přihlédlo i k vedení komunity Frontendisti.cz, což je moje, už téměř desetiletá, dobrovolnická aktivita. Jsem přesvědčený, že se přihlédlo i ke Vzhůru dolů, což je důvod, proč vám píšu. Vy jako čtenáři, posluchači a diváci tvoříte komunitu, která mě dělá radost a motivuje si sednout a zase něco vytvořit. Nyní se Vzhůru dolů nachází v bodě zlomu a já dost přemýšlím, jak s tímto projektem naložit. Budoucnost Vzhůru dolů No a teď k tomu ožehavému tématu. Od doby covidu vrhám stále větší část sil do projektu PageSpeed.cz, kde firmám radíme s rychlostí webu a vyvíjíme nástroj na monitoring rychlosti. Na Vzhůru dolů mě v nabitém kalendáři zbývá docela málo času, takže přemýšlím, kam jej efektivně vložit. Zcela jistě už to nebudou školení, ty si ponecháme jen v rámci PageSpeed.cz, nebudou to pravděpodobně ani videa. Velmi málo pravděpodobné je, že budu schopný psát v původním tempu CSS a kódeřině, protože mou hlavní oblastí zájmu je právě rychlost. Kromě prodeje knížek je tedy aktuálním hlavním zaměřením Vzhůru dolů podcast, který natáčíme s parťákem Robinem už pátým rokem. Články na Vzhůru dolů však chci psát dál. Když zbude čas. Protože mě to prostě baví. :-) Lze ode mě očekávat méně textů kolem kódeřiny a více „soft” témat, jako úvaha, zda AI bere vývojářům práci nebo text o metodice Inbox Zero. Proč vám píšu? Protože mě zajímá, co vy na to. V čem vám Vzhůru dolů pomáhá a co byste od něj chtěli do budoucna? Zdraví vás Martin Michálek PS: Pro nominované osobnosti českého digitálu je možné hlasovat do 27. 10. a seznam je plný krásných lidí, kteří dělají skvělou práci. webtop100.cz/osobnost
23.10.2023 19:45 V novém dílu podcastu se zaměříme na aktuální trendy v tvorbě design systémů a problémy, které nás v této oblasti stále trápí. Figma přichází s novinkami, které by vás neměly minout. Přinášíme i praktické tipy pro začátečníky a pokročilé. Nenechte si to ujít. Podcast Hosté Jan Toman Director of Design v Supernova.io, kde pracuje na nástrojích, které pomáhají snadno budovat, rozvíjet a rozšiřovat design systémy. Pracoval na design systémech v Productboard nebo Kiwi. Organizuje komunitu DSCC Czechia. LinkedIn – X.com Adam Kudrna UI developer/designer na volné noze s důrazem na robustnost, výkon, responzivitu a přístupnost. S design systémy pomáhá značkám jako LMC nebo Racom. Založil také Frontend Garden, magazín o frontendu. LinkedIn – X.com – Web O čem se bavíme? Robinův tip: Knížka Software Engineering, The Soft Parts Martinův tip: Knížka 75 tipů, jak si říct o web …a ještě jedna knížka, která slaví pětiletku Představení Adama Představení Honzy Aktuální stav design systémů Otázka za milion: synchronizace Figma/Storybook… Problémy, co se řeší: nejednotnosti a tak dále Sjednocení Reactu Twigu: TwigX Management je klíč Složení týmů Dopad design systémů a jejich obhajoba Tailwind, obecné design systémy Co bude s design systémy za rok? Automatizace? Pokud toho nemáte dost, mohou vás zajímat starší dva díly: S Honzou Tomanem o tvorbě systému designu v Kiwi.com O Figmě s Adélou Dostálovou a Honzou Černým Všechny podcasty na jedno místě. Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz, do Spotify nebo do komentářů. Děkujeme za spolupráci: Honza Michálek . Přejeme vám příjemný poslech!
16.10.2023 19:45 Každý vývojář má minimálně dvě povolání. Kromě psaní kódu ještě děláme IT podporu pro své okolí. Opravujeme rodině tiskárny, zapojujeme modemy, čistíme počítače od nepořádku, který si tam zanesli přílišným sledováním ehm… erotických webů… Ať chceme nebo ne, jednou za čas nám zazvoní telefon a máme prácičku. Na začátku FrontKonu jsem zeptal, kdo v sále se cítí jako frontendista nebo frontendistka. A pak kdo dělá IT podporu své rodině. Zdálo se mi, že na druhou otázku zvedlo ruku více lidí… Naše společné dva džoby znamenají dvě věci. Za prvé – máme záložní kariéru. A za druhé? Všechny nás to spojuje a díky tomu máme rádi stejný humor. „Nestřílejte, já jsem programátor.“ – „Výborně, tak nám pojď opravit naše tiskárny.“ – „OK, zastřelte mě.“ Kolem vývoje webů se motám kolem čtvrt století. Za tu dobu došlo k mnoha razantním změnám, ale o revoluci nikdy nešlo. Revoluce ale probíhá teď. Přináší ji aktuální vlna umělé inteligence. Přišla AI a všechno změní Příchod velkých jazykových modelů a dalších forem AI můžeme vnímat jako příležitost, ale také jako hrozbu. Pokud se bavíme o hrozbách, je zábavné a poučné odkazovat se na díla autorů sci-fi, kteří mysleli za nás a dopředu. V naší kultuře se nejvíc nosí odkazy na filmy, ty všichni známe. Zlý Skynet z Terminátora, který hodlá vyhladit lidsko, si umíme představit. Moje neoblíbenější zlá AI ale pochází z geniální Vesmírné odyssey Stanleyho Kubricka. Superpočítač HAL-9000 v určité fázi letu vesmírné lodi vyhodnotí lidskou posádku jako hrozbu pro dokončení naprogramované mise. Postupně téměř všechny zlikviduje. Zbývající hrdina s HALem svádí boj na život a na smrt. I já v sobě cítím znepokojení ohledně vývoje AI. Všechny novinky jsou skvělé, to určitě. Ale nelze nevidět i hrozby pro lidi. Zaměřme se na ty v našem oboru. Přijdou všichni frontendisti o práci a budou nahrazení AI píšící kód? Je užitečné si občas představit budoucnost jako temnou vizi. Abych se na něco takového připravil, v jednom ze svých častých experimentů s ChatGPT jsem si jej napromptoval jako zlou, cynickou a k lidem arogantní vesmírnou superinteligenci. Dal jsem jí za úkol sarkasticky komentovat můj kód. Začalo to pěkně zvostra: Tvůj kód je tak ošklivý, že bych si přál mít oči, abych je mohl obracet v sloup. Uf… Nové možnosti AI jsou úžasné Moje nevýhoda je, že pořád něco čtu. Takhle jsem se dočetl, že 46 % kódu uživatelů GitHub Copilot ve všech programovacích jazycích už tvoří umělá inteligence. V případě uživatelů Javy to je o polovinu více, což se nemůže nikdo divit… Šéf GitHubu navíc odhaduje, že dříve nebo později bude podíl AI kódu přes 80 %. Znamená to, že stroje nám vezmou čtyři pětiny naší práce? Do toho píšu kód pro webík kamarádky a můj sarkastický HAL-9000 jej komentuje slovy: Tohle nazýváš funkcí? Je tak nafouklá, že by mohla mít vlastní gravitační pole. Chce se mi s tím praštit… Ze světa ovšem přichází další zprávy o skvělých chystaných vlastnostech AI, které usnadní vývojářům práci. Nebo je prostě možná nahradí, že… Chystaný ChatGPT 4-V bude umět zpracovat textový obraz. Například tedy převede náčrtek rozhraní do docela dobře použitelného HTML kódu. v0.dev od Vercelu zase vezme práci kóderům uživatelského rozhraní v Reactu. Generuje komponenty prostě na základě textových promptů. A zdá se, že mu docela jde. Co tedy budou frontendisti a frontendistky dělat, když jiní do rukou dostanou takhle silné nástroje? Do přemýšlení mi ale zase skočí můj HAL-9000 a při pohledu na můj kód prohlásí: Logika tvého kódu je tak složitá, že kvantová mechanika u toho vypadá jako hračka. Kašlu na to, psát kód nemá cenu. Budou ještě vývojáři k něčemu? Čtu, že zaměstnance StackOverflow ovládla panika, protože po zveřejnění ChatGPT začal prudce padat počet shlédnutých stránek tohoto kdysi nepostradatelného webu: Od zveřejnění ChatGPT poklesly page views na StackOverflow o jednu třetinu. Tady už jde prostě do tuhého a reální lidé přicházejí o reálnou práci. K tomu se vynoří moje zlá AI a říká: Ach, vývojáři. Jste jako dinosauři, jen s klávesnicemi. Začínám tomu věřit. Další špatná zpráva přichází v grafu od Economistu, což je zdroj, který se nedá jen tak zpochybnit: Pracovní místa, která budou nejvíc postižená nástupem velkých jazykových modelů. Soudě podle grafu je vliv na naši profesi více než padesátiprocentní. Hůř na tom budou jen pojišťováci a lidi, kteří dělají nesmyslně komplikované smlouvy. Podívejme se ale na graf detailněji. Nemluví se tam o ztrácení práce. Mluví se tam o zrychlování práce. To zní nadějně. Že bychom ten nástup AI jako profese přecejen zvládli? Hrozby jsou hrůzné, ale data jsou data Na začátku jsem se zmiňoval o hrozbách a příležitostech. Dokud nebude trh webů a webových aplikací plně saturovaný, nás frontendistů a frontendistek bude potřeba stále více. AI nám pomůže dělat více práce za stávajícího počtu lidí. Vliv AI na frontendový vývoj je tedy možné podobně jako u StackOverflow odsledovat z jediné statistiky – počtu vývojářů na světě. Ten každým rokem vyroste o tři až pět procent. Šel jsem tedy zkoumat, co se stalo mezi lety 2021 až 2022. To přišel Github Copilot a ChatGPT. Vývoj počtu vývojářů na světě. Jak to, že furt roste? Stalo se něco nečekaného. Počet vývojářů v roce 2023 narostl rekordně, o celých osm procent. Jsme zachráněni!? Nevím. Zlá AI by k tomu totiž mohla dodat: Zrychlení práce? To je jen první fáze. Druhá fáze je, když vás zcela nahradím. Na závěry je brzo. Jak to celé dopadne, teprve uvidíme. Teď už ale vím, na jaký graf se mám koukat, když chci zahánět nervozitu z vývoje pracovního trhu frontendistů a frontendistek. I když ale graf nakonec nabere opačný směr, na nás si AI nepřijde. Prostě skočíme na naši druhou kvalifikaci a budeme svému okolí opravovat tiskárny.
11.10.2023 04:30 E-mail nemusí být zlo. Elektronickou poštu nemusíte mít plnou reklamních newsletterů, ani ji nemusíte mít plnou nevyřízených a nerelevantních zpráv. Nemusíte ji mít plnou vůbec. Nemusíte pořád na něco nebo na někoho zapomínat. Nemusíte se cítit blbě pokaždé, když si vzpomenete na svůj e-mail. Řešení znám dvě. První je se tvářit, že e-mail neexistuje. Druhé je Inbox Zero, metodika pro systematické zpracovávání e-mailů. Tohle chceme všichni. Někdy stačí jen vypnout odznáček z ikony aplikace. Někdy je potřeba víc, metodiku. Výhody e-pošty E-mail u některých profesionálů získal tak špatné renomé, že utíkají k nástrojům pro komunikaci v reálném čase nebo úplně zbytečně kvůli každé blbině telefonují. To ovšem dříve či později vede k zapomínání, nedostatečné informovanosti zúčastněných a komunikačnímu chaosu. Elektronická pošta má své výhody. Příjemce by neměl očekávat okamžitou reakci, takže máte čas na rozmyšlenou. Konverzace v něm poskytují prohledávatelný a trvalý záznam. E-mail není tak předurčený k vyrušování jako IM a díky tomu více podporuje režim hluboké práce. E-mail mají všichni, i ti, kteří jej nepoužívají, takže jde o jedinou skutečně univerzální platformu. E-mail prostě jiné způsoby komunikace skvěle doplňuje. Skoro bych řekl, je to nutný základní kámen online komunikace. Má špatnou pověst, ale možná jen proto, že jej lidé nepoužívají správně. Pro mě se návod na správné použití e-mailu jmenuje Inbox Zero. Překvapilo mě, jak málo je tato metodika známá a používaná. Američtí vědci prokázali, že 83,8 % lidí ocení článek o Inbox Zero. I proto vznikl tenhle text. Pojďme na to. Co je Inbox Zero? Inbox Zero je metodika, jejímž cílem je efektivní zpracování a organizace příchozích e-mailů. Cílem je mít schránku příchozí pošty pravidelně prázdnou nebo blízkou tomu stavu. Inbox Zero vymyslel a v nultých letech propagoval Merlin Mann, expert na produktivitu. V praxi Inbox Zero vypadá dle definice asi takto: Alespoň jednou denně věnujete čas své elektronické poštovní schránce. Procházíte zprávy a akce se řídí metodikou čtyř D . Každou zprávu následně buď archivujete nebo smažete. Profit! Inbox je čistý. Hlavním cílem Inbox Zero prostě je snížit stres spojený s elektronickou poštou, zvýšit produktivitu a udržet si pocit kontroly nad e-mailovou komunikací. Reklamní slogan říká, že cílem je udržovat vaši mysl a inbox čistými. To sedí. Fakt. V následujícím textu toto rozvedu a doplním svými zkušenostmi. Já osobně Inbox Zero používám kolem deseti let. Odhaduji, že jsem na metodiku přešel s příchodem Google Inbox, dnes už neexistující inovativní alternativy Gmailu, která šla mimo jiné naproti nadšencům do Inbox Zero. Dnes jsem zůstal u Gmailu, ale více či méně to bude fungovat s jakýmkoliv e-mailovým klientem. Co mi Inbox Zero přináší? Méně stresu z přeplněného inboxu, méně obav z nestíhání, méně zapomínání, efektivnější dohledávání informací. Snadnější a systematičtější organizaci práce. Jak pracuji a jaké nástroje pro komunikaci používám? Než se pustíme do konkrétních praktických tipů, cítím potřebu uvést svou verzi metodiky Inbox Zero do širšího kontextu. Jak pracuji? Jsem sice freelancer, odborně se zaměřuji na poradenství k rychlosti webu, ale hlavní část mé práce je dnes více méně management. Se třemi kolegy děláme konzultace pod značkou PageSpeed.cz, kde máme zhruba padesát klientů. V rámci dalšího týmu pomáhám vyvíjet tester rychlosti. Spolupracuji také na managementu komunity Frontendisti.cz a občas tvořím články nebo knížky v rámci své značky Vzhůru dolů. Denně mi přijde kolem stovky e-mailů a nějaké ty zprávy na sociální sítě, do IM nástrojů… Je toho vcelku docela dost a bez metodiky bych byl v čudu. Komunikačních kanálů používám mrak, asi jako všichni. Zde nastíním svůj vztah k nim v kontextu s mým pojetím metodiky Inbox Zero. E-mail Elektronická pošta je pro mě hlavní komunikační centrála. Všechny notifikace, které tak šly nastavit, hlavně z Basecampu, nástroje pro řízení projektu, mi chodí do e-mailu. Sem ale nechodím často, jen párkrát denně. Notifikace mám vypnuté. Používám Gmail. IM Slack používáme v týmu pro pracovní komunikaci v reálném čase. IM je zásadní pro případné záseky a problémy, které nepočkají. Máme zde ale i kanály jen tak pro tlachání s nižší prioritou. Notifikace ze Slacku mám zapnuté jen odpoledne, když se nevěnuji hluboké práci, ale občas se tam podívám i dopoledne. Totéž platí pro Whatsapp, Messenger, iMessages… v rámci soukromé komunikace. Pokud to nehoří, neodpovídám hned. S výjimkou ženy a dětí, samozřejmě. Telefon Telefon používám velmi málo, ale občas se hodí okolí dovysvětlit složitější nebo spíše středně složité témata. Někteří klienti jsou hodně telefonní, snažím se to respektovat. Hořáky a průšvihy naštěstí v práci nemívám, takže telefon obvykle můžu vzít bez strachu z velkého vyrušení a bez stresu. Po dlouhodobější komunikace e-mailem může mít člověk pocit, kterému říkám „emoční odpojení“, takže někdy je dobrý se vidět nebo si alespoň zavolat. Telefon je pro mě, kromě osobního setkání, nejlidštější forma komunikace. Ale raději se s lidmi setkávám, než telefonuji. Online schůzky Online meetingy v mém oboru prakticky úplně vytlačily osobní schůzky, ale v zásadě mě to vyhovuje. Pravidelně se slýcháváme s většinou klientů. Jednou za čas preferuji osobní setkání. Ale je stále těžší osobní pracovní setkávání prosazovat, nemyslíte? Tolik k širšímu kontextu mého způsobu elektronické komunikace. A teď už k e-mailu a metodice Inbox Zero. Než začneme, musíme splnit určité předpoklady. Předpoklad první: vyhrazený a omezený čas, třeba po obědě Bude vás to stát čas. Bez toho to nepůjde. Se s tim smiřte. E-maily v Inboxu čekají a nemají nožičky. Neodejdou a nevyřeší se samy, aniž byste jim věnovali čas. Ten si musíte vyhradit. Některé metodiky doporučují věnovat se e-mailu co nejrychleji nebo třeba jednou za hodinu, ale mě osobně by to zabilo. E-mailu se věnuji jen párkrát denně. Funguje to asi takto: Dopoledne do inboxu vůbec nekoukám. Jsem zahloubán v hluboké práci, sorry. Po obědě věnuji e-mailu půl hodiny až tři čtvrtě. To je můj hlavní čas na Inbox zero. Odpoledne dělám už více manažerskou práci, do e-mailu občas kouknu, občas odpovím, aby na mě něco nestálo, ale většinu z nich stejně odložím na další den. Tu půl hodinu až tři čtvrtě hodinu po obědě mám každý den v časovém plánu a počítám s ní. Není možné ji vytvořit z ničeho, pokud bych měl den nabitý jinými úkoly. Zpracování e-mailů si normálně počítám v Toggl jako práci: Komunikaci v rámci projektů PageSpeed.cz měřím jako management týmu. Složitější, poradenské e-maily klientům trackuji jako placenou práci pro ně. Pro ostatní e-mailovou komunikaci mám štítek „Komunikace“ a snažím se, aby nepřesáhla tak těch 30 minut denně. Sem patří neplacená komunikace s klienty, různé newslettery, komunikace kolem Vzhůru dolů, občasný soukromý e-mail, a tak dále. Všimněte si, že se e-mailům věnuji po obědě. Ano, to jsem většinou nejunavenější z celého dne a e-maily zároveň nepotřebují tolik mých mozkových kapacit. A co další předpoklady? Chce to trochu pošolíchat nastavení e-mailu Pojďme na další krok, přenastavit si všechno tak, aby to bylo co nejméně otravné a aby to bylo na jednom místě. Žádné notifikace Jsem fakt velký odpůrce notifikací přicházejících v reálném čase a otročině při jejich vyřizování. Chodí mi vlastně jen telefonická smsková upozornění a občas něco důležitého z IM, jako třeba rodina. E-mail nemá žádnou výjimku. Čistá mysl s tímhle v mobilu? Kde se to zařízení safra vypíná?! Vypl jsem si i odznáčky hlásící počet příchozích e-mailů na ikonkách všech aplikací. Díky Inbox Zero ale i tak většinu e-mailů vyřídím do 24 hodin. Všechno v jednom Všechny svoje e-mailové schránky, i ty historické, mám přesměrované do jediné, té nejaktuálnější, kterou používám. V Gmailu jsem si zrušil záložky jako Promotions, Social… Pokud mi to má chodit, ať to chodí rovnou do inboxu. Včetně newsletterů, kterých odebírám něco mezi pěti až deseti, a pořád mi to připadá hodně. Promo neodebírám vůbec a e-maily s notifikacemi ze sociálních sítí taky ne. Co se děje na sociálních sítích, ať tam zůstane. Občas se tam podívám, to ne, že ne. Vlastně nezdravě často, ehm. Téměř také v Gmailu nepoužívám štítky a kategorie. Jedinou výjimkou jsou automatické zprávy z různých nástrojů, jako je Google Search Console, protože ty nejde přesměrovat do Slacku nebo na jiné rozumné místo, kam nám chodí pracovní notifikace. Rozumná délka e-mailu Kdysi jsem psal dlouhé zprávy. Všímám si, že to je u vývojářů časté. Dneska mám vůči tomu odpor a tak když mi napíšete dlouhý e-mail, asi budete chvilku čekat na odpověď nebo vám prostě zavolám. Snažím se to držet i na své straně. Líbí se mi tedy metodiky nebo spíše popis ideálního stavu znění e-mailu jako Five.sentenc.es. Zkuste vše nacpat do pěti vět. Vždy se to nepovede, ale je to super výuka stručnosti. Pro méně zkušené je dobré si zkusit osvojit metodu pěti W. Jak tedy postupovat každý den při procházení příchozí pošty? Různí lidé to dělají jinak a nechci nikomu nic vnucovat, takže mohu jen nabídnout svůj vlastní postup. Pro inspiraci. Krok 1: prioritizace Projdu očima e-maily a začnu od těch nejjednodušších. Proto, aby to zkraje odsejpalo. Co si totiž budeme povídat – vyřizování e-mailů obvykle není nejúžasnější část dne. Obecně nejprve procházím interní zprávy týmu, což znamená vyřídit všechny e-mailové notifikace z Basecampu. To eviduji jako samostatní časový úsek. Druhé na řadě jsou ostatní e-maily, které se dají vyřídit rychle, tak do minuty jeden. To eviduji jako samostatnou položku „Komunikace“. Přitom často ještě vyřídím různé notifikace ze sociálních sítí. Třetí jsou konkrétní složitější e-maily, které můžu trackovat jako samostatný čas, obvykle pro konkrétního klienta. Jde většinou o rychlou radu, připomenutí priorit nebo rychlé vytěžení nějakých dat a dodání ilustrace. Čtvrté na řadě jsou e-maily, u kterých vím, že se na ně nedostane. Většinou mají nízkou prioritu. Ty odkládám na další den. Je jich každý den tak desetina. Krok 2: Akce S každým e-mailem je potřeba něco udělat a smazat je všechny nemůžeme, že ano… Zjednodušený a pořád složitý graf. A přitom taková blbost, že? Původní metodika Inbox Zero počítá s těmito akcemi od „D“, trošku jsem to doplnil o své zkušenosti: Smazat Pokud e-mail není relevantní nebo nevyžaduje akci, prostě ho smažte. Asi přišel jen pro info nebo ani to ne. U mě se to ještě rozdvojuje na dvě různé akce: Smazat – e-maily, které nebudu potřebovat archivovat. Neobsahují důležitou informaci nebo jde jen o duplikát zprávy z Basecampu nebo jiného nástroje, kde bude zpráva dohledatelná. I tak se ale hodí nějak reagovat, aby lidé na druhém konci drátu věděli, že jste zprávu viděli. K tomu jsou dobře hodí emoji v Basecampu. E-mail toto zatím nenabízí. Archivovat – zprávy nebo vlákna zpráv, které obsahují důležité informace. Většinu zpráv archivuji, ale nemažu. Díky tomu vím, jaké blbosti jem komu napsal před osmi nebo desíti lety. To chcete. Delegovat Pokud e-mail vyžaduje akci, ale vy nejste správná osoba, která by se tím měla zabývat, delegujte jej na vhodnou osobu nebo tým. U mě to znamená přidat nebo aktualizovat adekvátní úkol u kolegů. Obvykle ale moc nedeleguji, protože máme docela dobře rozdělené kompetence a všichni víme, co máme dělat. Vyřídit Pokud e-mail vyžaduje rychlou a jednoduchou akci, kterou můžete dokončit během několika minut, vyřídím jej hned. Odpovězte, proveďte požadovanou akci nebo tak něco. Tady budete mít pocit, že jste něco udělali. Je to složitější než na minutu či dvě? Měřím si čas pro klienta. Odsunout Pro e-maily, které vyžadují více času nebo úsilí na zpracování, ale nemůžete se jimi zabývat okamžitě, odstavte je na později. Použijte svůj úkolníček nebo funkci odkladu ve vašem e-mailovém klientovi. Zmizí vám z očí, alespoň pro teď. Odmítnout E-maily, které jsou spam nebo nerelevantní prostě označte jako spam nebo se odhlaste. Tohle je obzvlášť zábavné. Krok 3: Profit! Máte hotovo. Každý den pak budete odměňováni pohledem na prázdný inbox: Tady je klid. Je to fajn. Nemusí to být hned dokonalé. U mě to taky není dokonalé, ani po těch letech. Ale pomáhá to. Zkuste Inbox Zero. Budu rád, když mi do komentářů napíšete své vlastní zkušenosti. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
11.10.2023 04:30 Ve 45. epizodě podcastu jsme s Liborem, který momentálně působí jako Head of Front-End Development v CDN77, probrali aktuální směřování javascriptových frameworků. Naše povídání se netočí jen kolem SSR, ale také dalších známých problémů frameworků, jako je hydratace. Jak si s tím pokouší poradit moderní frameworky typu SvelteKit nebo Qwik? Podcast Host: Libor Vaněk Head of Front-End Development v CDN77, kde poskytují infrastrukturu pro globální internet. Fanoušek World Wide Web platformy a rozumného přístupu k web developmentu. Má rád všechny JS frameworky, ale ještě radši je podrobuje kritickému pohledu. Kdysi dělal meetupy Vue.js, dneska migruje většinu věcí z Nextu na SvelteKit. Ve volném čase dělá pro bono projekty, jako např. web a newsletter pro novináře Davida Klimeše a konzultuje architekturu a výkon webových aplikací. LinkedIn – Twitter O čem se bavíme? Robinův tip: 20 let od CSS Zen Garden Martinův tip: 6 CSS snippets every front-end developer should know in 2023 Představení Libora Historický kontext: proč dříve převažoval server, architektura MPA Svět webových aplikací, nikoliv webů, a SPA architektura Nevýhoda SPA: totální závislost na JS Nová generace „client-side“ vývojářů Pojďme tam přidat server Izomorfní aplikace vs. SSR Další problém: hydratace na klientovi Diskuze o budoucnosti, reflexe v komunitě Reactu Odkazujeme na podcast o trendech pro ‘21 a Hotwire – vracíme se zpět? Tipy na zdroje: Alex Russell, Rich Harris, Ryan Carniato, Mishko Hevery Děkujeme za spolupráci: Honza Michálek . Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo do komentářů. Naslyšenou příště!
07.10.2023 00:16 V novém dílu podcastu se zaměříme na aktuální trendy v tvorbě design systémů a problémy, které nás v této oblasti stále trápí. Figma přichází s novinkami, které by vás neměly minout. Přinášíme i praktické tipy pro začátečníky a pokročilé. Nenechte si to ujít. Podcast Hosté Jan Toman Director of Design v Supernova.io, kde pracuje na nástrojích, které pomáhají snadno budovat, rozvíjet a rozšiřovat design systémy. Pracoval na design systémech v Productboard nebo Kiwi. Organizuje komunitu DSCC Czechia. LinkedIn – X.com Adam Kudrna UI developer/designer na volné noze s důrazem na robustnost, výkon, responzivitu a přístupnost. S design systémy pomáhá značkám jako LMC nebo Racom. Založil také Frontend Garden, magazín o frontendu. LinkedIn – X.com – Web O čem se bavíme? Robinův tip: Knížka Software Engineering, The Soft Parts Martinův tip: Knížka 75 tipů, jak si říct o web …a ještě jedna knížka, která slaví pětiletku Představení Adama Představení Honzy Aktuální stav design systémů Otázka za milion: synchronizace Figma/Storybook… Problémy, co se řeší: nejednotnosti a tak dále Sjednocení Reactu Twigu: TwigX Management je klíč Složení týmů Dopad design systémů a jejich obhajoba Tailwind, obecné design systémy Co bude s design systémy za rok? Automatizace? Pokud toho nemáte dost, mohou vás zajímat starší dva díly: S Honzou Tomanem o tvorbě systému designu v Kiwi.com O Figmě s Adélou Dostálovou a Honzou Černým Všechny podcasty na jedno místě. Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz, do Spotify nebo do komentářů. Děkujeme za spolupráci: Honza Michálek . Přejeme vám příjemný poslech!
04.10.2023 06:00 „Page Experience“ bylo pojmové zarámování snah Googlu o zhodnocení uživatelské zkušenosti se stránkou. Dnes, tedy v květnu 2023, se už tento pojem přestává používat. Šlo v podstatě o dvě věci: Stejnojmenný update algoritmu Google, který se týkal rychlosti načítání stránek atd. Sekci v Google Search Console, kde se dalo hodnocení uživatelské zkušenosti se stránkami sledovat. První i druhé je dnes už historií. Důraz na rychlost webů platí, jen se tomu dnes už říká jinak. Google začal více tlačit pojem Core Web Vitals jakožto základních metrik rychlosti. Updaty algoritmu Google v letech 2021-2022 Google od června 2021 postupně nasazoval aktualizaci algoritmu zvanou Page Experience. Kluci a holky v největším vyhledávači ji navrhli tak, aby zvýrazňovala stránky, které nabízejí výborný uživatelský prožitek. Během roku 2021 se to začalo projevovat v mobilním vyhledávání a od února 2022 naplánoval Google nasazení také nasazení do hodnocení desktopových webů. Page Experience v Google Search Console V Google Search Console šlo zobrazovat počet stránek, které splňují celou oblast Page Experience. Dnes už tam najdete upozornění na to, že sekce bude zrušena: Notice: The page experience report will be changing in the coming months. Tento report kombinoval už dříve přidanou stránku Core Web Vitals s dalšími složkami signálů uživatelského zážitku, jako je zabezpečení HTTPS, stav bezpečného prohlížení nebo přívětivost pro mobilní zařízení. Google Search Console: Report „Kvalita stránky“. Na obrázku je nejdůležitější hodnota pro „Adresy URL s dobrými výsledky“, protože vidíte, kolik stránek podle GSC nevyhovuje z pohledu signálů Page Experience. Tato část tedy bude zrušena. Zhodnocení zabezpečení nebo přívětivosti pro mobilní zařízení už v Search Consoli nenajdete. Hodnocení rychlosti však zůstává v části „Rychlost“ : Google Search Console: Report stránek, které vyhovují nebo nevyhovují metrikám Core Web Vitals. Odtud už se pak proklikáme na konkrétní ukázkové URL a můžeme začít hledat konkrétní problém. Google Search Console: Příklady stránek, které nevyhovují konkrétní metrice. Search Console zobrazuje pro každý typ problému podmnožinu adres URL. Tyto URL představují různé typy stránek, které váš web může mít. Účelem této zprávy je pomoci uživatelům odhalit problematické typy stránek tak, aby je bylo možné ladit v nástrojích, jako je Page Speed Insights nebo Lighthouse. Vzorky stránek jsou vybrané tak, aby se jejich opravou zlepšilo celkové hodnocení typu stránky. Jak Google posuzuje rychlost webu? Když Google přišel se signály Page Experience, kladl jsem si otázku, jak přesně to budou měřit a vyhodnocovat. Platí to myslím, po menších úpravách, dodnes. 0) Obsah je stále král, zůstaňte v klidu Signály z oblasti Page Experience platforma používá spolu se stovkami dalších a nikdy nebudou silnější než signály pro kvalitní obsah. Říká to sám Google: we will prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn't override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search. Prostě obsah zůstává králem, i když cvrlikání na sítích někdy může působit jinak. Podle studie Sistrixu ze září 2021 to vypadá, že vliv signálu Page Experience byl menší, ale postupně rostl: Zjištění Sistrix o vlivu Page Experience na SEO:– Weby, který splňují PX mají nyní v průměru o 1 % lepší pozice v SERP, ale průběžně se rozdíl zvyšuje.– Weby, které některé z požadavků nesplňují, mají pozice o 3,7 % horší. – Twitter Moje zkušenost z praxe poradenství k rychlosti webu je taková, že rychlost k vyšší návštěvnosti z Googlu pomůže jen ve specifických případech, jako je vysoce konkurenční prostředí a specifické typy webů. 1) Měří se u uživatelů Důležité je zmínit, že se využívají data od skutečných uživatelů, z Chrome UX Reportu . Vyhodnocuje se stav metrik Core Web Vitals, tedy LCP, FID a CLS. Explicitně raději uvádím, že Google v hodnocení nezajímají syntetická měření v Lighthouse a už vůbec ne Lighthouse skóre. Tato syntetická měření slouží vývojářům ke zjednodušení optimalizací, nikoliv pro zjištění, jak na tom web je u Googlu. Důležitý je také proces počítání: Google vezme hodnoty u všech návštěv dané stránky za posledních 28 dní. V distribuci těchto čísel vytáhne hodnotu na 75. percentilu. Posledních 28 dní znamená, že skokové aktualizace se projevují klouzavě, nikoliv hned. Zajímavé je soustředění na 75. percentil, nikoliv například na průměr nebo medián. Je to ale dle mého správně – většina návštěv na webu pak má lepší než v percentilu uvedenou hodnotu metriky. Co například URL, která byla nedávno zveřejněna a ještě nemá data z 28 dní? Dojde pak k seskupení stránek, které jsou si podobné, píšu o tom dále. Stránka dostane skóre podle skupiny stránek nebo podle celé domény. Data od uživatelů můžete vytáhnout: Nejjednodušším způsobem z PageSpeed Insights Podrobněji a s vývojem v čase pak v našem testeru na PageSpeed.cz Doplňujte to vždy pohledem do Google Search Console. Další aspekty, které byly uváděny u příležitosti spuštění hodnocení Page Experience skvěle v tweetu shrnul Fabian Krumbholz, takže z něj vyjdu. 2) Každá metrika samostatně jako signál V rámci Page Experience Google hodnotí každou z Web Vitals samostatně jako signál pro hodnocení. Chápu to tak, že nemusíte mít všechny zelené, ale pro každou jednotlivou metriku budete porovnáváni s konkurencí. Takže pokud konkurence nebude mít zelené LCP a vy ano, můžete za tuto oblast získat zvýhodnění. 3) Zvýhodnění dostanete za zelené metriky Systém je postavený na zvýhodňování. Pokud máte metriku v červené oblasti hodnot, nezískáváte žádné plusové body. Pokud jste v oranžové oblasti hodnot, čím blíže bude hodnota optimu, tím vyšší zvýhodnění získáte. Nejvyšší „boost“ získáváte s metrikou v zeleném škále hodnot. 4) Lepší než zelené už to být nemůže Google dále píše: Dopad na hodnocení stránek bude stejný pro všechny stránky, které jsou v dobrém rozsahu u všech základních ukazatelů Web Vitals, bez ohledu na jejich individuální skóre v Core Web Vitals. To znamená, že když už máte zelené skóre, nemůže to být lepší. Google píše, že například stránka s metrikou LCP na hodnotě 1750 ms a jiná stránka s 2500 ms by se na základě signálu LCP nerozlišovaly. Mimo zelený rozsah skóre by rozdílné hodnoty metriky Core Web Vitals u dvou stránek mohly vést k rozdílnému hodnocení v rámci Page Experience. Jen připomínám, že podstatná motivace pro zrychlení webu je především ve zlepšení uživatelského prožitku. Takže ano, hodnoty metrik lepší než zelené mohou být pro uživatele a konverze lepší. Jen na SEO to už pak nejspíš nemá žádný vliv. 5) Doména > Skupina stránek > URL Možná už víte, že z CrUX dat často nejde vytáhnout informace pro konkrétních URL. Je zajímavé, že Google v tom případě nesáhne po datech pro celou doménu, ale po datech pro „skupinu stránek“. Skupinu stránek osobně chápu podle seskupení, které Google dělá v reportu Web Vitals v Search Console. Na jednu hromadu tam dává stránky, které jsou si podobné a zároveň vidí, že mají problémy s podobnými metrikami. Takže, když nejsou data pro URL, vezmou se data pro skupinu stránek. Když nejsou data pro skupinu stránek, vezmou se data pro doménu. Přesně jak říká Babica. A co když nejsou data pro doménu? I to se stává, zejména u méně navštěvovaných webů. Myslím, že pak prostě výhodu na základě Page Experience signálů získat nemůžete. A rychlost jen pro SEO řešit nemusíte. 6) Data se berou globálně Zajímavé také je, že data se z CrUX nevezmou podle aktuální lokality, takže například pro Česko nebo Slovensko, ale z globální návštěvnosti. Takže pokud v ČR a SR máte dobré hodnoty Web Vitals, ale kazí vám je malá část návštěvníků kdesi na druhém konci světa, budete to muset vyřešit. 7) Data se berou za posledních 28 dní Google nepracuje s měsíčními daty, která např. na PageSpeed.cz zobrazujeme v záložce Domény, ale se stavem za posledních 28 dní . 8) Data od všech stránek, včetně blokovaných v robots.txt? Docela zmatek je v jedné věci: URL, které mají blokované indexování roboty pomocí direktivy „noindex“ nebo uvedením v souboru robots.txt. Budou hodnocené v rámci Page Experience nebo ne? Z principu by, dle mého názoru, mělo jejich skóre ovlivňovat minimálně skóre domény. Vyplývá to z prostého faktu, že hodnocení stránky se nesbírá robotem, ale od uživatelů. Google sám ale ve své nápovědě uvádí, že případě měření přes PageSpeed Insights se zobrazují pouze informace o veřejně indexovatelných stránkách, které zároveň splňují určitý práh návštěvnosti. V případě tahání dat přímo z Chrome UX Reportu pak mohou být zahrnuty souhrnné údaje ze všech veřejných i neveřejných stránek. Navíc se zdá, že v Google Search Console data o Page Experience z těchto stránek vůbec nejsou. Můj odhad? Pro tyto stránky se skóre počítá, výsledky v SERPu to ovlivňuje, ale měřící nástroje od Googlu v tom zatím dělají zmatky. Na závěr Zpětně se ukázalo, že Google svým updatem Page Experience nespustil žádnou velkou revoluci, spíše postupné zlepšení hodnocení, které odskákaly hodně pomalé weby, ale naprosté většiny webů se to nijak nedotklo. Důvodů, proč řešit rychlost webu ale najdete celou řadu. To, že ji prosazuje Google, je jen důsledkem faktu, že pro návštěvníka i provozovatele je mít rychlý web prostě dobré. Co tedy dělat, pokud se chystáte na optimalizaci? V Google Search Console sledujte report Core Web Vitals. Snažte se odstraňovat problémy zde uvedené. Dlouhodobě sledujte rychlost typových stránek webu, i celé domény pomocí testeru PageSpeed.cz. Naučte se, jak správně měřit rychlost webu a ladění metrik CLS a LCP. Třeba pomohou mé webináře. Tyto tři webináře teď můžete pořídit i najednou. Optimalizujte, optimalizujte, optimalizujte. Pomůže vám checklist z PageSpeed.cz nebo moje tipy na novinky - jak zrychlit web. Vzdělávajte se v oblasti rychlosti webu. Pokud si nevíte rady, ozvěte se. Přeji vám rychlé weby a dobré pozice v Googlu. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
02.10.2023 20:00 INP je nová metrika rychlosti webu, se kterou přichází Google v rámci své sady Core Web Vitals. V březnu 2024 má nahradit dnes už neuspokojivou metriku FID . Tato změna se dotkne celé řady z vás, protože INP je metrika daleko přesnější a k webům přísnější. Poznámky k nadcházející výměně FID za INP Lidé z Googlu oznámili, že metrika INP nahradí FID v Core Web Vitals už v březnu 2024. Prodlevy způsobené JavaScriptem budou více vidět. A pro některé vývojáře to může znamenat docela bolehlav. INP je totiž daleko přísnější. Například Tim Kadlec změřil, že z webů postavených na Reactu vyhovuje této metrice jen 17 %. Weby postavené na Next.js jsou na 12 % úspěšnosti. Tim Kadlec doslova píše, že INP bude pro javascriptové vývojáře „tvrdým budíčkem“. A já s ním souhlasím. Vzal jsem 100 nejnavštěvovanějších českých e-shopů z naší studie o rychlosti webů českých e-shopů. Je to mazec. Na mobilu jich novou metriku rychlosti reakce INP splňuje pouhých 17. To jsou důvody, proč mě oznámení o tom, že INP bude už za méně než rok metrikou Core Web Vitals, překvapilo. Google sice v rámci projektu Aurora pomáhá autorům javascriptových frameworků mimojiné s optimalizací INP, ale to je jen malá část problému. Velký balvan bude ležet na ramenou vývojářů konkrétních webů a já vím, že optimalizovat JavaScript pro ně nebude snadné. Pojďme si teď něco povědět o samotné metrice Interaction to Next Paint. Metrika rychlosti odezvy Metrika Interaction to Next Paint zaznamenává prodlevu veškerých interakcí v průběhu celého životního cyklu stránky. Interaction to Next Paint je podobně jako právě FID metrikou interaktivity. Stránka se vám načte a vykreslí, vy můžete provádět interakce z myši, z dotykové obrazovky nebo z klávesnice, ale stránka nereaguje. Hlavní příčinou bývá samozřejmě JavaScript a probíhající dlouhotrvající úlohy , které zablokují vykreslovací vlákno prohlížeče. Metriky jako INP a FID se snaží tyto nepříjemnosti v uživatelském prožitku změřit a tím nám umožnit je odstranit. Odezva vpravo je dobrá, protože indikátor načítání se zobrazí okamžitě po vstupu uživatele, který chce zobrazit obrázek. Autoři z Googlu v případě INP namísto pojmu „interaktivita“ používají pojem „responsiveness“, tedy víceméně schopnost rychle reagovat. Zjednodušeně řečeno je INP metrikou rychlosti odezvy na uživatelské interakce. Ukazuje na to i samotný název. Interaction to Next Paint by se dalo přeložit jako „od interakce do dalšího vykreslení“. Překládat do češtiny se tento název bude špatně, a ani já o to tentokrát nebudu usilovat. Nicméně – v původním názvu se přesně odráží fungování tohoto nového ukazatele. Co INP měří a jak se liší od FID? Metriku First Input Delay už dlouho považuji za nevyhovující. Problém s odezvou na interakce u webů, které jsou plné reklam nebo špatně postavené na moderních frontendových frameworcích, zde máme dlouhodobě. Ale FID žádné problémy ani u těchto webů neukazuje. Důvody, proč metrika FID už z dnešního pohledu nevyhovuje, jsou tři: Měří jen prodlevu při první interakci, nikoliv celou dobu pobytu uživatele na stránce. Neměří celou prodlevu, ale jen její první část. FID je málo přísné, podle dat Googlu metriku splňuje 95 % webů. Asi nikoho nepřekvapím, když napíšu, že INP toto všechno řeší: 1) Měří se celou dobu pobytu na stránce INP měří odezvu všech interakcí až do změny URL a vybere tu nejhorší odezvu se všech interakcí. Pokud je interakcí více než 50 , nevybere se nejhorší hodnota, ale percentil, nejčastěji 98. Měřením po celou dobu pobytu na URL se řeší velká slepota metriky FID, protože podle propočtů Googlu zhruba 90 % interakcí probíhá až po úvodním načtení stránky. INP si tak můžete připodobnit k metrice Cumulative Layout Shift , která se také měří po celou dobu pobytu na stránce. 2) Počítá se celá prodleva FID měří jen první část prodlevy reakce – než reakce probublá do JavaScriptu, který ji musí zpracovat. Vůbec se ale nepočítá s dobou zpracování v samotném JS kódu, která může být opravdu dlouhá. Dále se nepočítá s dobou vykreslení. FID změří odhadem jen třetinu až polovinu reálného zpoždění po akci uživatele. Metrika INP a tři části, kde může nastat průšvih Na schématu vidíme tři části možného zpoždění interakce: Zpoždění vstupu – to, co nyní měří FID. Zpracování vstupu – události, ale hlavně zpracování JS. Zpoždění prezentace – většinou bývá v pohodě, mohou ale pokazit špatné CSS animace atd. Už z tohoto je jasné, že weby, které dříve v pohodě procházely přes metriku FID, teď projít nemohou. 3) Větší část webů přes INP neprojde Jak jsem psal, FID splní 93 % webů. Google deklaruje, že u INP to má spočteno zhruba na dvě třetiny splňujících webů. Hodnoty metriky INP a jak je změřit? Interaction to Next Paint má, stejně jako jiné Web Vitals, od výroby nastavené třístupňové hodnoty, kdy stránka vyhovuje více či méně: V tabulce to pak vypadá následovně: Metrika Dobrá Vyžaduje zlepšení Špatná INP ≤ 200 ms 200 - 500 ms > 500 ms Měření INP Hodnoty nové metriky odezvy interakcí můžete pro své weby získat už teď, protože Google ji už nějakou dobu pro uživatele Chrome sbírá v rámci svého Chrome UX Reportu a poskytuje ve svých měřících nástrojích. Podobně jako u CLS nebo FID bude složitější ji naměřit pomocí syntetických měření typu Lighthouse, protože metrika se sbírá až na základě uživatelských akcí. Ale je zde světlo na konci tunelu, totiž nové režimy fungování právě u nástroje s majákem ve znaku. Takže jak novou metriku změřit? Data od uživatelů vašeho webu získáte například z PageSpeed Insights: pagespeed.web.dev. Můžete použít knihovnu web-vitals nebo extension Web Vitals . V Lighthouse je možné INP změřit v novém režimu Time Span. Nová verze rozšíření Web Vitals umí změřit prodlevy jednotlivých interakcí uživatele. Optimalizace INP Asi byste ode mě rádi dostali rovnou návod, jak tuto metriku snadno optimalizovat. Ale bohužel, tak jednoduché to nebude. Z praxe pro klienty vím, že obecné rady u jakékoliv metriky málokdy zafungují, vždy je potřeba analyzovat konkrétní web a konkrétní stránky. U této metriky to bude ještě složitější. Samozřejmě vás ale zkusím alespoň trochu navést. Zaměřte se na TBT Metriky jako FID nebo nově INP jsou velmi citlivé na takzvané long tasks v JavaScriptu. Pokud má totiž prohlížeč práci s dlouhým zpracováním JS kódu, nemůže reagovat na vstupy od uživatele. Zaměřit byste se tedy měli na optimalizaci metriky TBT , kterou jde změřit snadno všemi možnými nástroji. Podle údajů Googlu koreluje TBT dvakrát lépe s INP než s FID, což je dobrá zpráva, protože optimalizace FID byla často docela peklíčko. Obecná rada? Optimalizujte JavaScript Obecně samozřejmě pomáhá mít ve stránce co nejméně JS, který něco provádí: odstraňovat nevyužitý kód, správně bundlovat, odkládat stahování a spouštění kódu, který v daném uživatelském kontextu není potřeba. Dávat pozor na třetí strany. Důležitá v případě INP může být také volba JS frameworku. Např. weby běžící na Next.js na mobilu splňují metriku jen z 20 %. Lidé z Googlu sice deklarují, že s autory těchto knihoven budou pracovat na zlepšení, ale tipuji, že některé autory webů běžících na těchto frameworcích čekají zajímavé časy. Více o optimalizaci INP najdete jako vždy v materiálech přímo od Googlu Co s tím teď? Pokud vám můžu poradit, zatím si INP pro své weby změřte hlavně změřte. Jestliže vám vyjdou velmi špatná čísla a chcete-li do budoucna Web Vitals splňovat a hlavně mít rychlý web, pak raději začněte připravovat plán na nápravu . Z mé zkušenosti je totiž právě optimalizace JavaScriptu jedna z nejsložitějších a nejdéle se táhnoucích prací na rychlosti webu. Pokud INP splňujete, nezbývá než vám gratulovat. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
