30.04.2024 05:00 Milí provozovatelé webů, čím více ušetříte za platformu a vývojáře, tím více utratíte za konzultanty, kteří vám to všechno budou opravovat. Může to být v pohodě, pořád se to může vyplácet. Ale tuhle proměnnou byste si měli dát výpočtů. „Na platformě ušetříme X, na vývojářích Y, ale počítáme s konzultacemi k UX, SEO, přístupnosti nebo rychlosti ve výši Z. Ty konzultanty radši najmeme na začátku projektu, aby to ohlídali.” Asi tak nějak. Vezměme třeba Shoptet . Myslím, že to je opravdu skvělá platforma . Shoptet je ale zároveň velmi často špatně používaná platforma. „Uděláme to do Shoptetu. Podívejte kolik peněz měsíčně ušetříme…“, Oukej, ale už nepočítejte, že si tam budete něco upravovat na míru. Často vidíme na sílu upravený design původních šablon, který pak ale v důsledku zhoršuje UX a… rozbije rychlost. Nebo WordPress. Klasika. To už snad ani nemusím psát… Ale, musím, milé čtenářky a čtenáři, musím. Ano, i na WordPressu jde všechno udělat dobře. Ale často se to dělá, no vy víte jak… Najme se vývojář, který je levný a nerozumí tomu. I relativně velké weby jsou často jen neudržovaným slepencem pluginů. Levný vývojář je levný. Takže to udělá blbě, nekomunikuje, neřeší, je zrovna na Kanárech… V PageSpeed.cz to při poradenství k rychlosti vidíme často. Konzultace nebo analýzy mohou u být u levných řešení výrazně náročnější než u řešení na míru. Pořád to může vycházet ekonomicky, projektově nebo jinak dobře. Jasně, že může. Ale rozhodně si to dejte do kalkulace. Nenechte se překvapit. Já jsem vám to říkal. Text původně vyšel na LinkedInu, kde jej také můžete komentovat, lajkovat nebo jinak doplnit.
24.04.2024 14:15 V tomto díle se ponoříme do světa GraphQL s Michalem Sängerem z Trezoru. Probíráme v jakých situacích nemusí být „grafko“ ideální a naopak, kde jednoznačně našlo své místo. Prozkoumáme nástroje jako Relay a Apollo, podíváme se na složitosti kolem federace a Michal nabízí řadu zkušeností a zajímavých názorů na ekosystém kolem téhle technologie. Prostě GraphQL projdeme tak nějak sakum prdum. Doufáme, že se vám 52. díl podcastu bude líbit! Podcast Celá epizoda na videu Host: Michal Sanger Michal je milovník dobrého jídla a zkušený javascriptový vývojář, který sbíral ostruhy mimojiné v Kiwi.com a Pipedrive. S nadhledem říká, že se o GraphQL zajímá zhruba od roku 1990. Prostě dlouho. Nyní GraphQL a jiné technologie krotí Trezoru. LinkedIn – X – SangerNaTripu.cz K čemu jsme došli? GraphQL se výborně hodí pro mezivrstvu client/server, jakožto typované API. React ekosystém je pro to dělaný. Dále je skvělé pro sdílení API například pro mobilní web, nativní appku atd. Komunita, zdá se, naopak dochází k tomu, že GraphQL se nehodí pro potřeby veřejných API. Ani největší hráči do využití pro veřejná API nešli a například Github od toho ustupuje. Je to náročné na údržbu, ale důvodů je více. Další příkladem, kde se GraphQL neujalo je komunikace server/server. Backendisti ke GraphQL nemají zase tak blízko, a celkově je tato technologie pro tyto potřeby zbytečně komplikovaná. Podle Michala je nejlepší pojetí takové, že frontendisti si řeší jak frontend kód, tak GraphQL vrstvu, tedy nějakou formu přemapování dat z backendu. Frontend v tomto směru Michal bere jako „interního zákazníka“. Z klientských knihoven Michal upřednosťnuje Relay. Jak říká, „Relay je trochu své“, a nevýhodou je určitá komplexita zavádění. Vyplatí se prý ale do Relay zainvestovat čas a úsilí. Co se týká federace, podle Michala je to extra složitost, které nefandí. Říká, že ani Facebook nemá federaci. Určité alternativy nabídl Michal ve své nedávné přednášce na WebExpo. Michal ještě bonusově doporučuje podzimní konferenci GraphQLConf a newsletter GraphQL Weekly. O čem všem se bavíme? Martinův tip pro vynervované přednášející Robinův tip: Comic Agile Pozvánka na LIVE natáčení podcastu na WebExpo Představení Michala Sängera Co se dělo v GraphQL za posledních 5 let? Konsolidace Jaký způsoby využití jsou pro GraphQL vhodné a jaké méně Diskuze i „edge computingu“ pro data fetching Klientské knihovny: proč Relay a proč ne Apollo Proč Michal nemá rád federaci Facebook nemá federaciMichalova přednáška na WebExpu Defer, prioritizace a performance Subscriptions a proč jsou těžké Dotazy: tRPC vs GraphQL Dotazy: Dokumentace Děkujeme za spolupráci: Honza Michálek . Odebírejte podcast ze Vzhůru dolů Spotify – Apple Podcasts – 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. Přejeme vám příjemný poslech!
23.04.2024 04:15 INP je nová metrika rychlosti webu, se kterou přichází Google v rámci své sady Core Web Vitals. V 12. března 2024 nahrazuje 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ší. Metrika INP měří časový úsek, který trvá reakce uživatelského rozhraní na kliknutí nebo jiný vstup uživatele v rámci webové stránky. Měří se jen interakce, které uživatele nepřenášejí na nové URL, tedy klikání na UI komponenty typu tlačítka, modální okna, přidávání do košíku, karusely, filtrování v e-shopech… Těch problémových míst může být celá řada. Problém je samozřejmě hlavně v JavaScriptu a jeho pomalém vykonávání, občas také v Ajaxu nebo Fetch, tedy stahování dat ze serveru. Poznámky k nadcházející výměně FID za INP 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. V květnu 2023 jsem vzal 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, 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. Ukazatel FID je málo přísný. Podle dat Googlu jej 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 „sleduje“ 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ž nějakou dobu, protože Google ji od uživatelů 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 nebo našeho testeru PageSpeed.cz. 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. Pár konkrétních rad Některé konkrétní problémy se nám v rámci poradenství k rychlosti pod hlavičkou PageSpeed.cz opakují: Dlouhé prodlevy po klikání do filtrace na mobilech na e-shopech způsobené překreslením stránky, které je zbytečné, protože stránka není vidět. Prodlevy každého kliku způsobené analytikou . Dlouhé úlohy v JS při úvodním vykreslení webu, např. při provádění JS kódu v jQuery na document.ready . Hydratace v moderních JS frameworcích jako React nebo Vue. Pozdní indikace probíhajícího načítání v rámci Ajax/Fetch volání. Hodně nám při optimalizacích pomáhá trik se setTimeout . Mrkněte se na celý článek o INP, který připravila kolegyně Zuzana Šumlanská. Dále budu radit ještě obecněji. 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. Optimalizujte prostě 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, určitě si INP pro své weby pravidelně měř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: .
20.04.2024 09:15 Pojďme si projít základní množinu znalostí o využití písma na webu, zmínit pár častých chyb a dvakrát podtrhnout hlavní pravidlo pro stavbu responzivního rozvržení stránky. Předtím ale ještě zmíním jeden účel písma, na který se často zapomíná. Tento text je ukázka z knihy Vzhůru do webdesignu. Písmo v nás vyvolává emoce Než se začteme, může nám typ písma sdělit informaci, co od webu očekávat. Jsem na webu seriózního magazínu, užitného webu typu e-shopu, nebo na stránkách Déčka, určeného pro děti? Asi je jasné, že tohle všechno je možné sdělit nebo zpochybnit mimo jiné i volbou písma. Je toho ale mnohem více. Pro potřeby předání základní úrovně typografických znalostí mně tady připadá lepší začít z druhého konce. Chybami. Časté typografické chyby Vypadají triviálně, ale weby jsou jich plné. Příliš dlouhé řádky, špatný kontrast a nesprávné znaky. 1) Příliš dlouhé řádky Wikipedie je smutným rekordmanem v délce řádku. Řádek by obecně neměl obsahovat více než 75 znaků, aby oči nepřeskakovaly na řádky sousedící. Ještě o tom budu psát. Wikipedie na počítačovém rozlišení obrazovky 2) Špatný kontrast a další technické parametry Novinky jsou nejen vysázené Georgií, patkovým písmem s vynikající čitelností pro delší texty, ale také velmi kontrastní barvou. Na českém webu jsou i výrazně horší weby než Zdroják, ale uvádím ho jako hůře čitelnou variantu díky kombinaci několika faktorů. Zdroják.cz má bezpatkové písmo s horším kontrastem a délkou řádků kolem 120 znaků Více o kontrastu barev píšu na Vzhůru dolů. vrdl.cz/p/kontrast 3) Nesprávné znaky Každé rozumné písmo má speciální symboly pro uvozovky , pomlčky nebo výpustku . Aktuálně.cz používá nesprávné znaky Není to žádná buzerace typografických snobů – prostě se to lépe čte. Typografický tahák od Beneš a Michl vám může velmi pomoci. vrdl.in/am9wu Ideální šířka a výška řádku Teď zpozorněte, protože zmíním jeden ze základních designérských principů dnešního webdesignu. Na příkladu Wikipedie jsem ukazoval, jak se může dlouhý řádek negativně projevit do celkové čitelnosti textu a webu. A není to jen problém Wikipedie. Platí totiž následující: 66 je ideální počet znaků na jedné řádce, 45–75 je pak vyhovující rozmezí. U webů, jako je právě Wikipedie, se čtenářům stává, že snadno ztrácejí aktuálně čtenou řádku. Rychlost čtení se tím snižuje. Jsou to pravidla, která zpopularizoval Robert Bringhurst ve své knize „The Elements of Typographic Style“ a která jsou průběžně potvrzována nejrůznějšími studiemi. Ale vyzkoušet si je můžete i sami na sobě. Na malých displejích však není možné optima dosáhnout. Doporučení pak říkají s ubývajícím počtem znaků na řádce snižovat i jeho výšku, protože oči častěji přecházejí z jedné řádky na druhou. Tady je jedno z možných řešení v CSS, které ukazoval Marko Dugonjić ve své přednášce „Responsive Web Typography“ na WebExpo 2014. vrdl.in/rwdtypo body p body p body p Toto nastavení předpokládá vysázení patkovým písmem a do jednoho sloupce. Drobně se samozřejmě může měnit podle parametrů písma. Jinak to bude pro nepatkové písmo, pro jiný kontrast, pro specifický charakter písma nebo počet sloupců. Nejlépe nám správnou volbu potvrdí poctivé uživatelské testování, ale pro začátek stačí nastavení písem testovat na různých zařízeních a různých lidech ve vašem okolí. Příliš malý řádkový proklad spojuje sousedící znaky, zhoršuje čitelnost slov a ve výsledku zpomaluje čtení. Příliš velký zase vypadá jako seznam samostatných položek a nutí uživatele přemýšlet, zda se jedná o souvislý text nebo o nějakou formu odrážek. Nicméně délka a výška řádku je první designérské pravidlo, na které bychom při návrhu rozhraní měli myslet. Postup návrhu pak ideálně vypadá tak, že zvolíme písmo, získáme obsah a až na těchto dvou nerozlučných přátelích postavíme systém pro layout stránky. Další zdroje o typografii Jasně, vnímáte mě dobře. Typografii mám za jeden ze zásadních stavebních kamenů přípravy vizuálu skoro každého webu. A myslím, že ze všech pěti prostředků grafického designu, které jsem zmiňoval, by právě typografii měli nejvíce rozumět i kodéři a vývojáři. Protože oni jsou často ti „sazeči“, kteří mohou mnohé ovlivnit. Kniha „On Web Typography“ Skvělá učebnice typografie od Jasona Santa Maria. vrdl.in/76nb2 Přednáška „Praktická typografie pro webové kodéry“ Dan Srb se hezky rozpovídal na jedné z akcí Frontendisti.cz. youtu.be/bJLGEMQ3rnM Online kniha „The Elements of Typographic Style Applied to the Web“ Bible od Roberta Bringhursta a spoluautorů. webtypography.net Lukáš Augusta Na DesignUI.cz má Lukáš pěkné články o typografii a také nástroj pro tvorbu typografické stupnice. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
16.04.2024 03:00 Ve druhé části předvánoční diskuze v Productboardu, a padesátém díle našeho podcastu , jsme si vzali na mušku dvě oblasti, ve kterých se nyní mění paradigmata. Převládá ve sestavování aplikací stále Webpack, nebo se situace začíná měnit?“ Je SSR jasná cesta, kam bude vývoj webových aplikací směřovat a není to jen opsání kruhu do bodu, kde už jsme byli? V části o buildování JS jsme se shodli zhruba na následujícím: Webpack je produkt doby čistě klientských aplikací a potřeby dělat jeden velký build. Technologie se posunuly, máme např. HTTP/2, které umožňuje posílat více menších souborů naráz a také frameworky umožňují posílat menší buildy, které se načítají postupně. Nyní jsme ve stavu, kdy se hledá nové řešení, proto je nástrojů pro buildování opět hodně, ale převažuje Webpack a Vite. V zásadě ale nakonec vybíráme buildovací nástroj podle toho, co nám naservíruje meta-framework. V druhé polovině, tématicky o server-side renderingu , jsme se myslím na ničem úplně neshodli, ale povídali si o Edge Computingu, streamování HTML, Local First, Partial Prerenderingu, React Server Components, HTMX a dalších buzwordech i báječných technologiích. Bohužel jsme se opět ani jednou nepohádali. Podcast Celá epizoda na videu Hosté Riki Fridrich Riki píše JavaScript ve firmě Outreach. Učí ostatní, jak psát Javascript. Přednáší na konferencích a setkáních. Většinou o Javascriptu. Riki je z Ládví. Web – Twitter – Github – LinkedIn Libor Vaněk Libor je 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 Petr Glaser Petr v rámci projektu Nauč mě IT pomáhá lidem získat dovednosti a znalosti vhodné pro práci v IT. Říká o sobě, že je vývojář zapálený pro technologie a vzdělávání. Zaměřuje se na performance, kterou vnímá jako součást UX a přístupnosti. I díky tomu si oblíbil framework Qwik, o kterém je řeč v podcastu. LinkedIn – Twitter O čem si povídáme? Buildování JS: Webpack jako produkt doby SPA Žezlo přebírá Vite, ve kterém jedou všechny frameworky mimo Reactu/Nextu Další hráči , potřeba univerzálnosti, jsme v mezidobí Next na Webpacku a chystaný posun k Turbopacku Další buildovací nástroje už nebudou v JavaScriptu Jde se bez buildu obejít? Viz No Build od 37signals Jak si stojí Rollup? Viz RollDown. Druhé téma: Server Side Rendering Rikiho „teorie sinusoidy“ a progressive enhancement Kde je dělící linka mezi SSR a klientským renderováním? Záleží vždy na zdroji dat a rychlosti odezvy, změna díky edge computingu Odvážná Rikiho vize: streamování HTML Jak do toho vstupuje Local First Jedna z dalších cest může být Partial Prerendering Možná změna definice frontendu a backendu, ještě v případě React Server Components vs. návrat k Rails, Django, Nette… HTMX- „niche záležitost“ a interaktivita bez HTML Stimulus.js a náš nenázor Děkujeme za spolupráci Jiří Nečas, Productboard – Vladimír Příhoda, Productboard – Honza Michálek – Johana Kratochvílová, Signatura . Odebírejte podcast ze Vzhůru dolů Spotify – Apple Podcasts – 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. Přejeme vám příjemný poslech!
03.04.2024 07:15 Nedávno jsem řešil údajné porušení autorských práv u jednoho obrázku, který jsem používal na Vzhůru dolů. Přišlo mi to ve varování jako automatický e-mail. Ten jsem považoval za další podvod, scam, takže nazdar bazar. Scam to nebyl. No nazdar! Slyšte tedy můj příběh, který mě stál sedm tisícovek. Nebuďte jako já a neignorujte automatizované e-maily od PicRights. Můj příběh s „půjčeným“ obrázkem V květnu 2023 mi přišel e-mail s předmětem „Žádost o prokázání vlastnictví licence k obrázku společnosti Reuters News & Media Inc“ z adresy ResolveGL@picrights.com. V obsahu se mimojiné píše: společnost PicRights Europe GmbH zjistila, že na Vaší webové stránce, sociální média nebo média dostupná z vaší internetové stránky, byl použit obrázek/obrázky společnosti Reuters News & Media Inc. Našemu klientovi společnosti Reuters News & Media Inc se nepodařilo najít žádnou platnou licenci pro používání tohoto obrázku / těchto obrázků Vaší společností. V důsledku toho požadujeme jménem společnosti Reuters News & Media Inc přiměřené odškodnění za toto nepovolené používání. A dole je uvedený tenhle důkaz: Pozdrav od robota, který má rád peníze. Společnost PicRights po mě chtěla zaplatit 10 tisíc korun za využití obrázku pro koláž v článku, který jsem napsal v roce 2006, tedy před sedmnácti lety. S těmito typy e-mailů se obvykle nemažu. Víceméně je mažu, však Inbox Zero, že… Udělal jsem rychlé googlení, narazil na články s titulky jako „copyright trolling“ a zařadil si PicRights do mentálního šuplíku po bok internetových podvodníků, kteří se snaží vydělat na lidské neznalosti. Druhý e-mail přišel v červnu 2023. Třetí dorazil v červenci 2023. Obsahově byly stejné, i částka seděla. Nic jsem nedělal, na nic nereagoval, nic neplatil, obrázek dále visel na webu. S podvodníky se nebavím. Nazdar bazar. Zkraje ledna 2024 ovšem přišla předžalobní výzva od kanceláře PRK Partners s předmětem „Porušení autorských práv“. Mám prý udělat tři věci zároveň: Odstranit fotku. Kontaktovat PicRights a vyřešit ten případ. Zaplatit asi 14 tis. Kč. Tohle už zase tak snadno ignorovat nešlo, Inbox Zero nepomáhal. Takže jsem to začal řešit s advokátkou Petrou Dolejšovou. Tušil jsem, že jsem to trošku podělal, takže Petra mě v zásadě nepřekvapila. Prý to není podvod, mám se s nimi zkusit spojit a domluvit se alespoň na snížení té částky. To mi doporučila udělat po vlastní ose, aby netekly zbytečné peníze ještě na právní zastoupení, které by ve výsledku mohlo být vyšší než samotná částka Vzal jsem telefon a po chvíli se mi povedlo mluvit s člověkem z PRK Partners, který o tom něco věděl. Vysvětlil jsem mu situaci a po chvíli vyjednávání jsme se dohodli, že zaplatím polovinu a oni ten případ uzavřou. Ponaučení: obrázky nepůjčovat, nepůjčovat, nepůjčovat V mém případě to bylo jasné – fotku jsem opravdu kdysi stáhl ze sport.cz. Obvykle to nemám ve zvyku, ale kdysi jsem občas dělal výjimky. Ono v té době, kdo to měl jinak… Docela dobře si pamatuju, že v takových případech jsem doufal, že pokud tam uvedu zdroj, původní fotku upravím a fotku vystavím na nevýdělečný web, jsem v suchu. Nejsem v suchu. Tyhle společnosti využívají roboty, kteří skenují web a získané informace párují s databázi fotek od agentur jako AP nebo Reuters. mimochodem v Česku nejspíš spolupracují i s ČTK. Mimochodem, v mém případě byla trošku smůla, že jsem použil fotku od Reuters, což je agentura v tomto směru údajně docela drahá a důsledná. Na rozdíl od některých jiných nejsou výzvy PicRights jen plané. O ceně a spravedlnosti si můžeme myslet cokoliv, ale ženě, algoritmům a právníkům se neodmlouvá. Co si z toho vzít? Autorské právo ctím, ale jak jsem psal, velmi vzácně se historicky stalo, že jsem pro potřeby ilustrace použil „fotku z internetu“. Nejsem expert na právo, ale mám pár webů a tomuto se chci v budoucnu vyhnout, takže vám alespoň řeknu, co jsem po této minikauze udělal: 1) Fotky stáhnout a neřešit Pokud na obrázky nemáte práva nebo si tím nejste jistí, prostě je hned po prvním upozornění smažte. A je to. Podle mě s PicRights dále nijak komunikovat nemusíte a podle ohlasů na internetech se domnívám, že vám pak dají pokoj. 2) Udělejte si audit fotek na webu Je možné, že vám zatím žádné upozornění nepřišlo, ale to neznamená, že vás nemají v merku. Pokud si nejste jistí původem svých fotek, raději si udělejte alespoň základní audit. Já prošel fotky v CMS a pak obrázky z Google Images. Ještě, že si ilustrace většinou dělám sám. Ale výjimky se najdou a mohou být drahé. Beru to tak, že Google je velmi schopný robot, takže obrázky, které nezná on, snad nebudou znát ani roboti vydřiduchů jako jsou PicRights. 3) Zakažte robotům přístup do archivů Na tom mém „ukradeném obrázku“ mě nejvíc štve, že jej roboti nalezli v archívu webu, který mám hlavně pro své soukromé účely. Některé moje starší články jsou bezesporu hodné čtení, ale obávám se, že ty z roku 2006 už fakt nikdo nečte. Nejjednodušší je prostě zakázat robotům přístup pomocí předpisu v robots.txt: User-agent: * Disallow: /data/ Pamatujte ale na to, že pro roboty jde jen o doporučení, nemusí to reálně prostě fungovat. Na robots.txt se asi u soudu odvolávat moci nebudete. Ohlasy a „co třeba nezaplatit?” Tento článek píšu i proto, že na českém internetu o problému PicRights nebylo možné cokoliv relevantního vygooglit. Považoval jsem to tedy za okrajové téma, takže mě překvapilo, kolik lidí se mi po zveřejnění ozvalo, zejména na Twitteru a Facebooku. Zejména diskuze na druhém jmenovaném je zajímavá. Nevím, jestli vám to k něčemu bude, ale většina se zachovala jako já – fotky odstranila a zaplatila. Byli zde i tací, kteří PicRights považují za scam a nezaplatili jim ani korunu, např. s odkazem na vložení obrázku přispěvovatelem. Ale já nejsem žádný právník, zeptejte se těch svých. Bonus: právo kolem obrázků z fotobank Když už jsem s Petrou řešil tuhle kauzičku, poslala mi jeden svůj pěkný článek o právu kolem obrázků z fotobank na internetu. Tedy pěkný… mně se to vůbec nelíbí, co si budeme povídat. Dávám to sem proto, že i v téhle oblasti působí vydřidušské algoritmy napojené na právníky. Pokud používáte obrázky z fotobank, raději se ujistěte: Dvakrát měřte, takže čtěte licenční podmínky, jestli se opravdu vztahují na váš způsob použití. Ujistěte se, že na fotkách nejsou známé motivy , platí tam totiž licence i k původní fotce. Dejte si bacha na využití obrázků, kde jsou lidé nebo loga. Dotčené osoby nebo firmy se mohou bránit. Tož tak. Obávám se, že PicRights a spol. vydělávají nemalé prašule, takže těchto případů bude jen přibývat. Nepodceňujte to. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
