cesko-digital / blog Goto Github PK

View Code? Open in Web Editor NEW

6.0 6.0 14.0 12.8 MB

Kód a obsah blogu Česko.Digital

Home Page: https://blog.cesko.digital

License: MIT License

JavaScript 0.51% CSS 25.87% HTML 0.82% TypeScript 72.80%

blog's People

Contributors

Stargazers

Watchers

Forkers

janpetr erbenos vpekarek pavelsuraba fidelman mzadrazi snorbik petrhrudka91 teryii l-korous jindrich-oukropec martinahabova pavelsnabl wergilka

blog's Issues

Chybné řazení aktualit

Přidal jsem novou aktualitu s aktuálním datem, ale je zařazená jinam než na první místo. Chvilku jsem se v tom šťoural, ale nenapadá mě, co je špatně. Mrkneš prosím na to, Matěji? Commity případně klidně rovnou do nachystané větve.

Přidat Open Graph metadata

Viz https://ogp.me, hlavně asi jde o náhled pro Facebook. Možno ladit přes Open Graph Debugger a pokud dobře koukám, tak minimálně do první verze můžeme velkou část obšlehnout z hlavního webu Č.D. (Akorát u rozkliknutých článků je nutné vyplnit metadata článku, nikoliv blogu.)

Zprovoznit doménu

Budeme potřebovat zapojit vlastní doménu, k čemuž ale nejdřív potřebujeme vyřešit definitivně hosting, abysme věděli, kam vlastně v DNS odkazovat.

Generované ilustrace pro titulní fotky

Bavili jsme se na Slacku o tom, jestli budou titulní fotky článků povinné. Já jsem spíš pro, jelikož to podle mě pomáhá například při sdílení na FB. Zároveň je teda ale otázka, co tam dávat za fotky, protože u textů à la Problémy v digitalizaci státu nám ilustrační fotky síťových kabelů brzy polezou krkem :)

Napadlo mě tedy, jestli bysme nemohli obrázky generovat, podobně jako mají třeba kluci ve Swift Talks. Jedna možnost je čistě dynamické generování na požádání, klidně za nějakým API, druhá možnost je něco interaktivního, co by se dalo ručně tweakovat nebo opakovat, dokud z toho nevypadne něco zajímavého.

Pokud se to podaří napsat nějak obecněji, určitě bysme to pak uměli využít i jinde na webu nebo v propagačních materiálech. Blbé je, že zatím nemáme stabilní vizuální identitu, o kterou by se to dalo opřít – web i blog aktuálně jedou na provizoriu, výhledově skončíme u nějaké dopracovanější verze tohoto návrhu. S trochou štěstí by tohle provizorium nemuselo být problém, třeba bychom později akorát vyměnili barvy?

Technicky je vcelku jedno, jak to bude udělané. Určitě by bylo dobré, kdyby generátor šel pustit online, ideální by bylo, kdyby mohl běžet i někde za API nebo to byl JavaScriptový modul. Vizuálně si představuju něco trochu nerdy, ale zároveň sympatického, progresivního, dobře identifikovatelného. Stylem mě napadly třeba balící papíry Bastl Instruments od Anymade. Nenašel jsem už nikde doma vhodnou ukázku, ale zhruba ten černý papír vpravo:

A ještě jedna věc, která mě napadla a už je asi příliš nerdy, je Conwayova Hra života, z té by taky mohlo jít vydojit něco vizuálně zajímavého. A ještě ASCII art nebo obecně využití znaků mně přijde nosné, podobně jako ty „pásy“ z většítek v návrhu webu (odkaz výše). Každopádně to jsou jen nápady a impulzy, ne zadání ke kopii.

@mkj-is se hlásil, že by se do toho pustil 👍 Termín ideálně do 14 dní, ale samozřejmě podle možností, na první veřejnou verzi bychom asi ještě nějak zvládli improvizovat.

Nastylovat podle designu

Viz variantní návrh webu. Je potřeba dořešit práci s logem a navigaci hlavní web ↔︎ blog.

Přidání Facebook Pixel Analytics

Přidat vedle Google Tag Manager ještě Facebook Pixel Analytics. Ideální minimální cesta je úprava konfigurace v gatsby-config.js. Lze přidat samostatný plugin nebo přidat takový, který podporuje oba nástroje.

Hover stavy odkazů a oprava border-radius u tlačítka

Albert Zikmud přidal do Figmy hover stavy všech odkazů. Bylo by fajn je zapracovat.

Také je potřeba opravit border-radius u tlačítka.

Vylepšit design karty s krátkými aktualitami

Přidat indikaci možnosti scrollování a zapracovat feedback od @zoul:

Ještě by podle mě stálo za úvahu je nějak lehce přestylovat, teď to vypadá trochu neohrabaně (hodně podtrhávaného textu). Zvážil bych, jestli neodstranit podtržení a neudělat klikací celý ten blok od jedné dělicí čáry po druhou. To samozřejmě vůbec nehoří, v případě zájmu si můžem poznačit jízdenku bokem a vyřešit později.

Importovat poznámky z Trella

Shodli jsme se, že tyhle technické věci máme radši v GitHub issues, takže bychom mohli importovat hodnotné poznámky z Trella, zbývají-li ještě jaké, a následně to v Trellu promazat.

API pro propojení s hlavním webem

@woodarius:

Ve zkratce bychom chtěli obsah blogu používat v režimu čtečky např. na webu ČD, například pro každý běžící projekt přidat odkaz nebo lépe obsah posledního zápisu pro projekt na blogu, využít ho v sekci novinek, umožnit témata streamovat na FB, Twitter atd…

Podle mě by bylo praktické oddělit ty dva weby přes API, ačkoliv jsou si tak blízko. Abychom nebyli na sobě závislí a mohli libovolně měnit věci, když dodržíme API. Velmi snadno bychom vám například měli být schopni vystavit nějaký JSON feed, ve kterém by byla anotace posledního článku pro každý tag. Něco jako:

{
    "CityVizor": {
        "title": "Srpnové novinky v projektu CityVizor",
        "perex": "Udělali jsme něco krásného a teď vám o tom povíme.",
        "url": "https://blog.cesko.digital/…"
    },
    …
}

Nakolik by tohle splňovalo vaši představu, @woodarius?

V editoru CMS se nezobrazují nově vložené články

@lukasnavesnik povídá, že se mu nezobrazují nově vložené články v seznamu v Netlify CMS – ale najít pomocí vystavěného vyhledávače je může.

Multiple Authors

https://dev.to/wgao19/building-a-multi-author-blog-with-gatsby-3607

Chybný řádkový proklad v odrážkových seznamech

Viz například tenhle náhled, v sekci Jak projekt změní Česko k lepšímu je řádkování výrazně těsnější než ve zbytku textu. @HormCodes, mrkneš na to, prosím?

Strukturovaný obsah ve zdrojových souborech

Markdown nám dává nástroje pro označení základní struktury dokumentu – nadpisy, číslované seznamy, etc. My ale chceme do dokumentů vkládat i další obsah, v současné době například video (a do budoucna třeba medailonky dobrovolníků). Můžeme sáhnout k HTML, což teď taky děláme – na tom je ale blbý to, že takový zdroják přestává být značkovaný sémanticky (významově) a sklouzává k čistě prezentačnímu značkování. To nám potenciálně svazuje ruce do budoucna – kdybychom například chtěli nějak změnit způsob prezentace videa u všech článků, tak pokud je máme vložené přímo přes HTML, tak to budem muset ručně projít a měnit. Což je pruda.

Ideální je podle mě zakázat používání HTML ve zdrojáku a zavést nějaké vlastní značky pro obsah nad rámec běžného Markdownu, viz například tenhle blog post o řešení v Elmu. Pak ten zdroják vypadá třeba takhle:

## Markdown Within HTML (Within Markdown)

You can now:

- Render HTML within your Markdown
- Render Markdown within that HTML!

<bio
name="Dillon Kearns"
photo="https://avatars2.githubusercontent.com/u/1384166"
twitter="dillontkearns"
github="dillonkearns"

>

Dillon really likes building things with Elm!

Here are some links:

- [Articles](https://incrementalelm.com/articles)

</bio>

A pro tu vlastní značku bio parser zavolá nějakou funkci, která se stará o její zpracování. Tímhle vlastně vznikne čistý, logicky značkovaný dokument, který není nijak vázaný na HTML a je dokonale future-proof.

@HormCodes, co si o tom myslíš? Je to srozumitelný? Jde něco takovýho udělat v JavaScriptu? Respektive určitě jde, ale víme o nějakém hotovém řešení, například rozšiřitelném parseru Markdownu? (Nebo by to šlo udělat jako postproces průchod po základním naparsování Markdownu?)

Post Categories

Podpora zvolení článku jako "featured"

Přidat do frontmatter podporu pro vlastnost fatured. Článek s featured: true pak bude na hlavní stránce zobrazen jako první.

Přidat favikonu

Je potřeba s někým dohodnout, co vlastně v té favikoně má být. Jestli dobře koukám, na cesko.digital nemáme nic. (Takže bysme pak rovnou mohli poslat i PR do repa hlavního webu?)

Podpora Markdownu v perexu

Momentálně nepodporujeme Markdown v poli description (ani HTML, tagy se escapují). Je to škoda, v perexu často popisujeme nějaký kontext a rádi bychom odkazovali jinam. Ideální mně přijde, kdyby byl perex na titulku vytažený bez značkování (čistý text) a uvnitř článku by pak normálně fungovalo značkování.

Optimalizace obrázků

Souvisí s hostingem obrázků, #7. Momentálně cpeme do článků rovnou velké fotky, což není dobré, zbytečně posíláme mraky dat, které klient stejně nevyužije. Chtělo by to obrázky nějak optimalizovat – buď staticky do několika kategorií (malá, střední, velká fotka), anebo dynamicky na míru danému klientovi (například Thumbor).

Přidání ESLint kontroly (využívající Prettier) jako GitHub action

Cílem je zabránit aplikování změn a jejich nasazení na produkci, které nejsou správně naformátované.

Lze se inspirovat ve web repozitáři, kde byl obdobný PR

Čitelnost fontu

Feedback od uživatele: font, který používáte na blogu se mi strašně špatně čte. Prakticky jsem to nedokázal dočíst - musel jsem si to dát do textového editoru a přečíst u sebe lokálně.

Zkusil jsem udělat screenshot a nakreslit linky - ono je to fakt jen 1-2px rozdíl. Ale u mě to vypadá, jako by některá písmenka byla větší, některá menší, a písmenko "r" mi nepochopitelně skáče nahoru dolu (při porovnání s písmenkem a).

Oba screeny v příloze.

Zdroj: Issue od @suchoss, viz link na Twitter: https://twitter.com/suchoss/status/1460172696764006400?s=20c

Zanést úvodní obsah

Rozhovor s Jakubem (viz #20)
Doplnit zpětně aktuality (viz #24)
Letní newslettery (viz #25)

V RSS chybí první odstavec

Viz například rozhovor s Jakubem:

<item>
    <title><![CDATA[„Naším hlavním produktem je největší dobrovolnická digitální komunita v ČR a její koordinace“]]></title>
    <description><![CDATA[Česko.Digital má za sebou řekněme půlrok existence. Podle agilního vývoje softwaru existuje jediné skutečné měřítko pokroku, a tím je hotová…]]></description>
    <link>https://blog.cesko.digital/2019/09/rozhovor-nesetril</link>
    <guid isPermaLink="false">https://blog.cesko.digital/2019/09/rozhovor-nesetril</guid>
    <pubDate>Fri, 20 Sep 2019 12:00:00 GMT</pubDate>
    …

V tagu description je první otázka, ale měl by tam být obsah pole description z frontmatteru článku.

Doplnit informace o vkládání obrázků do README

Koho kontaktovat, kde je uloženo, jaká je struktura.

Možná pro sekci "How To Insert Article" začít používat nadpisy druhé úrovně.

Odstranit tiskové zprávy z RSS

Přidat category eq "blog" filter do query pro RSS.

Dořešit hosting obrázků

Prozatím můžeme jet na punk přes imgur.com nebo cpaním obrázků do repa, výhledově budeme chtít něco příčetnějšího (AWS S3 + CloudFront nebo Netlify Large Media, kde by ovšem bylo potřeba dořešit podmínky na neplaceném účtu).

Medailonky dobrovolníků v blog postech

Chtěli bysme víc zviditelnit dobrovolníky, kteří dělali na konkrétních projektech – například v blog postu o dokončeném projektu tedy nějak vizuálně „prodat“ všechny, kteří se za Č.D na projektu podíleli. Vizuální představa je prostě profilová fotka s kruhovým ořezem, jménem a případně rolí na projektu („UX Design“, „Tech Lead“, etc).

Jak tohle nejlíp do blog postu dostat? Postupné varianty od dřevní po ideální:

Stylované HTML. Výhody: stačilo by nachystat styly a nic jiného. Nevýhody: všechno ostatní, je to pracné a svazuje nám to ruce do budoucnosti (viz též #68).

MDX komponenta s ručně vyplněnými daty, například:

<VolunteerProfile
    img="https://data.cesko.digital/img/…"
    name="Tomáš Znamenáček"
    role="Cat Trainer"
/>

Výhody: Výborný poměr cena/výkon, relativně future-proof řešení.

MDX komponenta napojená na nějakou databázi, například:
```
<VolunteerProfile id="123" role="Cat Trainer"/>
```
…a k tomu databázi (lokální JSON/YAML nebo časem AirTable?) s profilovkami a jmény. Výhody: totéž co předchozí, plus bysme omezili duplikaci dat a umožnili proklik z profilovky do nějaké větší databáze dobrovolníků, která bude časem na hlavním webu. Nevýhody: není to už overkill?

A pak je tu ještě otázka, jestli profilovky vkládat do článku takhle „ručně“, anebo jestli seznam zapojených lidí nevložit přímo do metadat článku a nevysypat je pak na nějaké standardizované místo, třeba do sidebaru, záhlaví, zápatí nebo na místo určené nějakým ručním kontejnerem (<InsertVolunteersHere/>).

Tohle je furt spíš brainstorming než specifikace, takže uvítám připomínky a návrhy, Matěji.

Statistika návštěvnosti

Mrkněme, co používá hlavní web
Google Analytics by vyžadovaly nějaký cookie consent? To je pruda.
Netlify umí nějaké vlastní statistiky bez cookies, ale je to placené, relativně draho.

Endpoint pro upload fotek na data.cesko.digital

Fotky pro blog hostujeme na data.cesko.digital, což je S3 kyblíček za CloudFront. Pro upload je potřeba IAM uživatel v AWS, což není úplně praktické. @martinwenisch navrhuje HTTP frontend, představuju si to následovně:

Upload bude pomocí HTTP POST na nějaké URL (ještě nevím, kam bysme to nasadili). Něco jako curl -F "[email protected]" https://dev.cesko.digital/api/upload-img.
Autorizace by mohla být nějakým tajným tokenem v hlavičkách.
Skript by převzal soubor a uložil do S3 pod názvem odvozeným z jeho SHA256 (shasum -a 256 foo.jpeg | cut -c 1-8).
V odpovědi by bylo „venkovní“ URL nahraného obrázku.
Autentizační údaje pro S3 by byly uložené v repu.
Nejlíp v TypeScriptu, nasadit jako serverless funkci ve Vercelu.

CC @HormCodes.

Pole “twitter” a “bio” u autorů by neměla být povinná

Momentálně s nimi nikde nepracujeme, ale pokud aspoň u jednoho autora nejsou vyplněná, tak to rozbije build. To by bylo dobré spravit.

CSS styly pro mobilní zařízení

Stalo by za to opravit CSS styly pro menší obrazovky tak, aby se blog dal lépe číst a nedocházelo k overflow-ům jako na přiloženém obrázku.

Device: iPhone X
OS: iOS 13.3.1, iOS 13.4.1
Browser: Safari

Omezit vkládání tiskových zpráv do složky pro blog a naopak

Toto bylo bráno v úvahu už při merge #91, ale rozhodli jsme se to vyřešit dodatečně.

Vložením souboru do content/posts nebo do content/press s nesprávnou kategorií stejně vytvoří daný příspěvěk/tiskovou zprávu. Bylo by dobré vytvořit filtr pro generování stránek, který bere příspěvky/tiskové zprávy pouze jen ze správné složky.

Přepsat do Next.js

Chceme kód překlopit do Next.js, podobně jako https://github.com/cesko-digital/web/, jednak abychom sjednotili stack, jednak protože se nám v tom lépe dělá.

Odstranit/předělat atribut `isPermalink=false` z RSS

U odkazu na článek se nachází isPermalink=false. Nejsem si jistý, co říká specifikace RSS, ale je nutné atribut odstranit nebo změnit jeho hodnotu.

Optimalizace workflow přípravy newsletteru

V současné době je proces publikování newsletteru Česko.Digital neefektivní a zahrnuje velké množství manuálních činností. Diskutovali jsme situaci se @zoul, a navrhujeme následující změny ve workflow:

Vzhledem k tomu, že obsah pro newsletter je identický s obsahem, který se publikuje v příslušném příspěvku na blogu (newsletter, blog), navrhujeme úplně zrušit repositář cesko-digital/newsletter, a jako výchozí obsah pro newsletter použít repositář cesko-digital/blog.
Tím odstraníme nutnost obsah připravovat dvakrát — jednou ve formátu mjml pro newsletter, jednou v Markdownu pro blog. Jediným zdrojem bude Markdown. Z hlediska formátování přijdeme pouze o dvousloupcový layout v sekci „To nejlepší z našich projektů“, což nám přijde přiměřená cena za tak radikální snížení objemu manuální práce.
Finální výstupy z Markdown obsahu jsou dva: a) HTML pro blog, b) HTML pro newsletter. V případě blogu se technicky nic měnit nebude. V případě newsletteru implementujeme post-processing, který z Markdown nejdřív vyrobí mjml, z něhož pak vyrobí (komplikované a ulítlé) HTML pro newsletter.
Post-processing implementujeme pomocí Github Actions pro a) pull requesty, b) push/merge do hlavní větve. Pull requesty pak budou sloužit k náhledu blogu i newsletteru před publikací.
Pro získání finálního HTML pro newsletter (copy & paste do Ecomail) chceme implementovat ovládací panel, ve výchozím zobrazení skrytý, který umožní vložení finálního HTML přímo do stránky.

Finální workflow pak bude vypadat takto:

Obsah pro newsletter je připravován v Markdown, v repositáři cesko-digital/blog (příklad), pomocí Netlify CMS (nebo v editoru).
Pro každou úpravu se se vytvoří pull request (příklad). Vercel automaticky nasadí preview (příklad), které umožní zkontrolovat obsah vizuálně.
Na preview stránce je k dispozici ovládací panel s tlačítkem Kopírovat HTML pro newsletter, které do schránky vloží specifické HTML, připravené k přímému použití v rozhraní Ecomail, a tedy k rozesílání. Je tudíž možné získat HTML pro newsletter ještě před následnou publikací newsletteru na blog.cesko.digital, k němuž dojde zamergováním pull requestu.

Odstraňujeme tak časově náročnou práci spojenou s konverzí textu newsletteru do mjml formátu.

Technické poznámky:

Workflow pro publikaci HTML na webu blog.cesko.digital se nijak nemění.
Pro získání HTML pro newsletter potřebujeme z Markdownu vygenerovat mjml XML, a z něho následně HTML (viz stávající skript).
Výsledné HTML pro newsletter uložíme jako .html v sestaveném webu (pro zkopírování do stránky nebo přímé načtení v prohlížeči)
Zrušíme repositář zoul/cist.digital, který není používán.
Zavedeme automatické přesměrování na aktuální vydání na titulní stránce blog.cesko.digital. Nadále tedy nebude potřeba provádět manuální úpravy v souboru now.json (příklad).

Zprovoznit RSS feed

Do feedu chceme asi celý obsah textů?
Prozatím bychom tam dávali pouze naše vlastní články.
Později bychom mohli dát na výběr: pouze články z webu, nebo články + aktuality odjinud.

Přidání Facebook Pixel Analytics

V případě přístupů a správného nastavení kooperovat s @radkoa a Šnorbim (na Slacku).

Stream novinek

Odkazy na dřívější rozhovory s Jakubem a Michalem Bláhou, Brain & Breakfast s Radkem Háblem, zajímavé zahraniční zdroje, a tak dále. Datum, URL, stručný komentář, ještě něco? Nice-to-have pro první veřejné vydání, v krajním případě ale můžeme obětovat. Přišlo by mně dobré ty novinky držet v nějakém strukturovaném formátu, YAML? Ať s nimi v případě potřeby můžeme nějak kreativněji zacházet.

Větší odsazení nadpisů druhé úrovně

V souhrnu novinek vždycky řešíme, že jsou nadpisy druhé úrovně málo oddělené od předchozího obsahu. Zatím to řešíme ručním vkládáním dělicí čáry nebo prázdného řádku, což je prasečí™. (Viz například novinky za prosinec a leden.)

Matěji, mohl bys prosím zkusit zvětšit odsazení odstavců druhé úrovně? Nevím, kam to v Gatsbym má přijít. A jakmile tu změnu zaneseme, budeme muset ještě projít články a zároveň vyhodit ty ruční hacky (br, hr), ať to pak mergnem najednou.

Doplnit jasnou licenci pro obsah

Měli bysme k textům psát, pod jakou licencí s nimi jde pracovat. Ideálně všechno publikovat jako Creative Commons Attribution. Nevím, jestli do toho míchat ještě další omezení – ShareAlike? NoDerivs? NonCommercial?

U fotek je to ještě složitější, protože na ně asi ne vždycky budeme mít práva, respektive ne vždy budeme jejich autory – ale možná bychom si mohli předem říct, že chceme pouze fotky kompatibilní s licencí na text, a tím pádem bychom měli licencování celého blogu úplně jasné.

Bordel v RSS feedu na Feedly

Narazili jsme na to v rámci #32, viz tenhle odkaz na Feedly. Jsou v něm i starší testovací články, ačkoliv v našem feedu (/rss.xml) už dávno nejsou. Matěj našel nějaké obecné rady od Feedly, ještě jsem nečetl.

Podpora dvojjazyčných článků

V souvislosti s rozhovorem s Olivií nás napadlo, že by bylo pěkné mít některé texty dvojmo, česky i anglicky. Co by to znamenalo technicky:

Zavést „výchozí jazyk blogu“, cs.
U každého článku v metadatech zavést parametr lang s doménou {cs, en}. Pokud chybí, nastavit na výchozí jazyk blogu.
V HTML správně nastavit jazyk článku podle tohoto parametru.
Dvojjazyčný článek by ve skutečnosti byly dva samostatné soubory s vlastními URL, například /2019/09/rozhovor-vereha a /2019/09/vereha-interview.
Oba soubory je potřeba nějak navzájem provázat, například parametrem lang-version:
```
lang-version:
    en: <identifikátor>
```
Na výsledné stránce by se pak zobrazil přepínač ve smyslu This article is also available in English, který by vedl na /2019/09/vereha-interview.

Nevím, co by měl být ten <identifikátor>. Relativní cesta k souboru? URL výsledného článku?
Různé jazykové verze textu je potřeba ve streamu článků zobrazovat jako jeden článek.
Co v RSS? Můžeme buď nechat odkaz na alternativní verzi, anebo do RSS pustit obě vedle sebe. Mírně preferuju první variantu, nečekám, že by nás přes RSS odebíralo mnoho zahraničních čtenářů. Anebo variantu RSS jen s anglickým obsahem.
Co pak s odkazem English vpravo nahoře? Už teď má dost komplikovanou sémantiku, protože vlastně znamená Anglická verze hlavního webu, což je na blogu matoucí.

Zapomněl jsem na něco?

Automatické značkování kanálů ze Slacku

Na novou verzi blogu, až budeme mít čas na sympatické drobnosti, bysme mohli udělat automatickou konverzi názvů kanálů ze Slacku na klikací odkazy. Stáhnout přes Slack API všechny kanály, udělat seznam názvů plus ID, a pak detekovat regulárním výrazem názvy v textu.

Popis "How To Contribute" v README

Bylo by fajn do README přidat popis, jak je možné přispívat do repozitáře. Pamatuji si, že o tomto byla vedena na Slacku diskuze. Pokusit se dohledat a přidat.

Archiv tiskových zpráv

Potřebujeme archiv tiskových zpráv (něco à la Apple Newsroom, samozřejmě jednodušší). Ideální by bylo, kdybysme se k tomu dostali ještě na starém blogu – mohli bysme tím nahradit sekci Krátké aktuality, kterou nakonec nepoužíváme.

Technická představa:

Jde o samostatný „stream“ článků, které mají prakticky stejné náležitosti jako články na blogu. (U tiskovek nebudem uvádět autora. Ale pokud je například u článků na blog povinný, můžem to pole klidně zachovat a jen ho nezobrazovat.)
Potřebujeme jednoduchý seznam posledních pár tiskových zpráv, stačí titulky s datem a proklik dál. (Pokud nebudou dostupné starší tiskovky, není to problém.)
Po kliknutí se tiskovka otevře ve velké podobě, úplně stejně jako článek na blogu.
Nevím, na jakém URL ten detail tiskovky otevřít. Články blogu otvíráme na /YYYY/MM/slug (například /2020/05/novinky), nevím, jestli chcem nějaký samostatný namespace pro tiskovky. Myslím, že není nutný (vždycky to v případě kolize můžem vyřešit přejmenováním slugu).
Na disku by tiskovky asi mohly být v samostatném adresáři, například v podadresářích podle let.

Případné podrobnosti u mě, @zoul na Slacku Česko.Digital.

Formát URL článku

Články bych strukturoval podle roků (složky 2019, 2020,...), kde název složky obsahující článek bude mít prefix YYYY-MM-DD- a pak název článku v "kebab case".

Přemýšlím, ale jak by měla vypadat výsledná URL článku. Přidat stejný prefix/subdirectory s datem/inkrementaci při shodě?

@zoul, co si o tom myslíš?

Náhled článku

Cover článku
Titulek
Perex
Datum a autor