27.12.2023 05:31 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
24.12.2023 10: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!
21.12.2023 16:31 :has je funkční selektor, který můžeme mimo jiné použít jako selektor rodiče, tedy vybrat rodičovské prvky, obsahující potomky určitého typu: a:has Tento selektor cílí na všechny odkazy , které mají v DOMu jako potomka obrázek . Je to selektor rodiče. Ale taky nemusí být. Selektor :has od 19. 12. 2023, tedy vydání Firefoxu 121, podporován všemi prohlížeči. Fanfáry prosím! Nejen selektor rodiče Selektor :has je součástí návrhu specifikace W3C Selectors Level 4. Patří mu velká pozornost, protože jednou z možností jeho použití je právě selektor rodiče. Co je selektor rodiče? To je v CSS už asi dvacet let něco jako banány za komunistů. Lidé to strašně moc chtějí, stáli by na to fronty, ono se to občas někde objeví, ale zpravidla je to planý poplach. Tak teď už jsou banány na skladě a pro každého. Jenže :has ve skutečnosti selektor rodiče není. Doslovně, přesně podle specifikace, jde o relační pseudotřídu . Relační proto, že do závorek můžete napsat jakýkoliv relativní selektor, se vztahem k selektoru před dvojtečkou: a:has section:has img:has Všimněte si posledního případu. Vybírá prvního z bezprostředně navazujících sourozenců v DOMu. Tady o selektoru rodiče nemůže být řeč. Navíc je to užitečné a skoro stejně nedostatkové jako ty banány za komunistů. Nebo jako selektor rodiče v CSS. Ukázka se selektorem rodiče Podívejme se na následující CodePen. Jsou v něm dva prvky .box. Jeden obsahuje obrázek a jeden pouze text: Lorem ipsum… Quam doloremque… Relační pseudotřídou :has se pak snažím zacílit boxík s obrázkem: .box:has Výsledek uvidíte níže. Ukázka se selektorem předchozího sourozence V tomto demíčku se zaměříme na stylování prvků v textu, za nimiž následují jiné specifické prvky. Máme dva nadpisy, za jedním následuje odstavec, za druhým seznam položek: Lorem ipsum, dolor sit amet Lorem… Quam doloremque… Lorem… Pokud bychom ten druhý nadpis chtěli stylovat jinak, opět nemusíme složitě přidávat třídu. Prostě jen použijeme relační pseudotřídu :has: h2:has Na živo zde: Další možnosti, občas dechberoucí Když jsem procházel, co se selektorem :has vykouzlili jiní autoři, občas mě srdíčko poskočilo radostí. O jejich nápady se s vámi musím podělit, v tomto případě hlavně o nápady Matthiase Otta. form:has form:has figure img:has .grid:has :last-child) Všimněte si hlavně té poslední ukázky. Rozložení v CSS layoutu upravujeme počítáním prvků uvnitř. Jde o aplikaci takzvaných quantity queries, které už před lety popsal Heydon Pickering. Prostě můžete změnit layout podle toho, kolik je v něm položek. Kurnik šopa, proč já už vlastně nekóduju weby? Další zajímavé tipy přidal například na X/Twitteru Wes Bos u příležitosti plné podpory selektoru :has ve všech prohlížečích. Uvedu pár příkladů: The Anywhere Selector - Např. pokud je v zaškrtnutý checkbox, můžete vzít jakýkoli jiný prvek a nastylovat jej. Layout Targeting – Na základě struktury obsahu stránky mohu měnit rozvržení. All Siblings – Když na potomka najedete kurzorem, vybere všechny ostatní elementy. Máte jiný zajímavý příklad použití? Napište mi, přidám jej do článku. Podpora v prohlížečích Podpora je v prosinci 2023 plná. Firefox se přidal čerstvě, takže budeme muset chvilku počkat, než vymřou jeho starší verze. CanIUse: caniuse.com/css-has Pokud tedy začínáte nový projekt, nemusíte s použití příliš váhat. V mezičase může být užitečná detekce prohlížeče, které :has neumí. Prostě využijeme dotaz na podporu @supports: @supports selector ) Nevím jak vy, ale já mám z podpory :has v prohlížečích fakt radost. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
17.12.2023 12:00 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.
13.12.2023 08:00 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.12.2023 22:30 V této epizodě se společně s Pavlem a Michalem ponoříme do důležitého, ale málokomu vyhovujícího oboru řízení vývoje. Společně zkoumáme, proč dochází k nedorozuměním mezi vývojáři a těmi, kteří jim práci zadávají. Podcast Povídáme si o různých metodikách a nástrojích. Diskutujeme také o roli prostředníků jako jsou byznys analytici, ale shodujeme se i na několika praktických tipech. Co se dá z obou stran zlepšit při zadávání práce? Devět tipů, jak vylepšit proces zadávání práce Ideálně potřebujeme dva nástroje pro řízení dvou stavů: Product Discovery a Product Delivery , více též v článku. Velmi se hodí silný Product Owner, projektový vedoucí nebo někdo, kdo slaďuje potřeby různých stran. Přípravu zadání je vhodné dělat produktovém triu: produkt, vývoj, design . Při zadávání se soustřeďte na ne výstupy , ale výsledky . Dobré zadání může vypadat takto: jednoduché user stories, vizuální nebo jiný cíl, jak otestovat výsledek. Dobře si nastavte cíle , bez toho to nejde. Agile je dobrý cíl, ale je potřeba být pragmatik a zohledňovat realitu v týmu. Hodí se vám byznys analytik nebo někdo, kdo tu roli zastává a pomáhá dodefinovat zadání. Potřebujeme vývojáře, kteří se nebojí oponovat, ptát se. „Nespokojte se se špatným zadáním.“ říká Marek Čevelíček v článku UX pro vývojáře. Hosté Pavel Ungr Pavel je „těžký kalibr na vaše SEO“, expert na online marketing na volné noze. V oboru SEO pracuje od roku 2004. Pořádá školení a pravidelně publikuje odborné články. Baví jej experimenty a propaguje SEO jako vytvoření zajímavého a kvalitního obsahu, který je prospěšný především pro uživatele. K zadávání práce vývojářům přichází jako externí konzultant. PavelUngr.cz – LinkedIn – X.com Michal Voják Michal je produkťák, zavádí Product Discovery do firem a vede startup userUP, který má za cíl pomoc firmám právě s tímto tématem. Michal za sebou má bohatou webařskou kariéru od frontendisty přes UX designéra až po současnost. Navíc má zkušenosti se spolupráci s korporáty, proto dokáže problém organizace projektů vnímat z různých úhlů pohledu. DesignDev – userUp – LinkedIn – X.com Obsah Robinův tip: Kniha Fluent React od Tejase Kumara Martinův tip: PLUS pro monitoring rychlosti Jak to vidí Pavel Ungr? Jak to vidí Michal Voják? Zásadní téma: jak se čte „JIRA“? Jak to vidí Robin? Jak to vidí Martin? První problém: neřeší se to v jednom nástroji Druhý problém: slabý či neexistující Product Owner Triáda a raději výsledky než výstupy Potřebujeme prostředníka? Agile Manifesto a střet s praxí Sedět spolu v kanclu může být lepší Jak vypadá dobré zadání? Byznys analytik jako člověk nebo role Pomůže si dobře nastavit cíle Definice „seniora“ Je JIRA super nebo příšerná? Vývojáři, nebojte se oponovat Pozvánka na 19. 12. do Productboardu Jak probíhá autogramiáda podcastu? Ukázka: Agile Manifesto vs. praxe Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – RSS podcastů Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo kamkoliv jinam, hlavně, aby se to k nám dostalo. Děkujeme za spolupráci: Honza Michálek . Přejeme vám příjemný poslech!
02.12.2023 03:45 Subgrid umožní vytvořit zanořenou mřížku, která zároveň podědí layout rodičovského gridu. Je to velmi praktické a nově podporované ve všech prohlížečích. Subgrid je součástí specifikace CSS gridu. Grid je skvělý, ale dříve či později se s ním dostaneme do situace, kdy potřebujeme jeden grid zanořit do druhého. V takové situaci si pak pochopitelně přejeme, aby vnitřní grid dokázal podědit vnější layout. Jak vidíte na obrázku níže, subgrid mám to pomůže zařídit. Vnitřní části položek budou lícovat, i když mají různě velký obsah. Grid a subgrid. Táta a syn. Můžeme to samozřejmě zajistit i bez subgridu: Nastavit prvkům fixní rozměry na výšku nebo použít JavaScript . Staré páky mezi kodéry si vzpomenou na složité tabulkové layouty, kterými se toho dalo dosáhnout, ale ve kterých se nikdo nevyznal… Jak na to jít dobře, se subgridem? Příklad s kartou produktu Víte vy co? Ukážu vám to na jednoduchém příkladu. Na obrázku výše totiž vidíte layout podobný tomu, který používám na Vzhůru dolů. Mám seznam položek, říkejme jim karty produktu. Každá karta má složitější strukturu, ve které najdete nadpis, obrázek, text a tlačítko: Text… Tlačítko… Vnější rozvržení, tedy to, které se týká vodorovného umístění karet, udělám gridem. To žádný problém nebude: .container Umísťuji zde dvě položky ). Přeji si, aby nebyly užší než 250px a širší než 400px. Mezera mezi položkami je 4rem. To bude asi bez problémů, že? Ale když já chci, aby nadpisy, obrázky, texty i tlačítka jednotlivých karet byly vždy ve stejné výšce. Přidáváme layout pro jednotlivé karty Nejprve musíme změnit rodičovský layout. Uděláme to tak, že přidáme řádky pomocí vlastnosti grid-template-rows. .container Jak vidíte, nemáme příliš velké ambice položky layoutu nějak omezovat. Víme jen, že budou čtyři . A hodláme je pouze zarovnávat mezi sebou navzájem. A teď kouzlo, subgrid Zápis pro vnitřní mřížku u jednotlivých položek, který řešíme podmřížkou , bude: .item Prohlížeči dáváme tyhle instrukce: Budiž grid ! Umísti tuto položku do čtyř buněk gridu . Svislý směr mřížky nechť je subgridem, takže po gridu zdědí vnější mřížku . Je to jasné? Výsledek uvidíte na obrázku, který vám snad pomůže s pochopením celé věci, což je opět možné zkoušet na živé ukázce. Zelená podmřížka si hoví v modré mřížce a je spokojená. My také, protože vnitřní položky karet jsou navzájem zarovnané. Živá ukázka vám řekne více. Poznámky k subgridu V době aktualizace textu prohlížeče zvládají subgrid poměrně čerstvě, proto nepůjdu u této části CSS gridu úplně do hloubky. Pár poznámek zde ale uvedu: Vícerozměrnost sugridu V ukázce jsme pro podmřížku využili jen svislý směr rodičovského layoutu. Je ale samozřejmě možné využít i vodorovný nebo prostě oba směry najednou. Pak se z toho stává jeden velký tabulkový layout, jako z roku 2002. Dělám si legraci, je to samozřejmě daleko lepší než layout v . Dědění mezer Vlastnost gap se z rodičovského gridu samozřejmě dědí i na ten vnitřní. Je ale možné si mezery ve vnitřním layoutu změnit novou deklarací gap. Žádné přidávání implicitních řádků nebo sloupců V běžném gridu je možné pomocí vlastností grid-auto- definovat rozvržení pro řádky či sloupce. Ty se automaticky přidají, když se rozšíří obsah v HTML. Je asi pochopitelné, že toto v subgridu možné není. Vždy se jen umísťuje do mřížky, která je zděděná shora od rodičovského gridu. Podpora v prohlížečích Subgrid je součástí specifikace CSS Grid Layout Module již od Level 2, která se datuje do roku 2018. Zde je stav k září 2023: Firefox podporuje subgrid od verze 70 z prosince 2019. Safari subgrid přidalo v září 2022 do verze 16, od iOS 16 a v aktualizaci pro macOS Monterey a Big Sur. Jako poslední se v září 2023 přidal Chrome a Edge. Aktuální informace od podpoře hledejte na CanIUse.com/css-subgrid Podpora subgridu mě velmi těší a nemůžu se dočkat, až mi v komentářích napíšete, jak jej v praxi používáte. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
