Jak si vedla ve volbách do PS 2025 strana Volt?
Jedna stránka = jedno téma. Každá page má svůj jasný komunikační cíl, který nechci rozmělňovat.
Slider na rok chci vlastně všude. Minimálně pro mě jako pro člověka, co s PBI nikdy nepracoval je neintuitivní, že filtr nemusí fungovat vždy napříč celým projektem. Vždy je na stejném místě, konzistence a tak..
Nadpisy komunikují konkrétní sdělení grafu, ne jen popis dat. Čtenář má vědět, co si z grafu odnést.
Popisky grafů nechávám v pozadí – malé písmo, šedá barva. Jsou tam pro kontext a kredibilitu, ale nemají krást pozornost.
Barvičky s “good vibes” patří neúspěšným útokům – ty jsou vlastně dobré zprávy. Úspěšné útoky jsou černé, zachmuřené. Mixovat zelenou/červenou s negací by působilo zmatečně.
Druhý graf zvýrazňuje trend rostoucího poměru neúspěšných útoků, což ze samotného celkového grafu není patrné.
Zvažovala jsem stacked area chart, ale pak jsem ho jsem zavrhla – a působí příliš kontinuálně pro diskrétní roční data a při kliknutí se choval divně.
Line stacked chart umožňuje snadné filtrování podle let, což odpovídá mému záměru se sliderem.
Ideální by bylo přidat čáru s trendem (lineární regrese?), ale s tím se mi upřímně nechtělo patlat.
Mapku jsem dělala s pomocí Claude – nechtěla jsem vymýšlet metriku od nuly, ale chtěla jsem si podobný typ vizualizace vyzkoušet.
Automatické přepočítávání osy Y u line graphu je potenciálně problematické – nepozorný čtenář si nemusí všimnout rozdílů v celkových počtech. Ale když ji zafixuju, data z menších států jsou nečitelná. Nejsem si jistá, co by zde bylo ideální řešení
Barvy z mapky neodpovídají barvám z treemap. Opravit by trvalo příliš dlouho. (A ta mapa mi teď stejně nefunguje, protože příliš často ukazuje bomby… Nejsem si jistá co cs tim)
Quick fix by byla heatmapa/matice – typy útoků × oblast/stát. Ale to je takové škaredé, nešla jsem do toho.
Cílem stránky je ukázat bizarně velký počet útoků v Middle East – proto koláčový graf, který tohle sdělí na první pohled.
Bubbles na mapě mají nejmenší možnou velikost, aby přes ně šla mapa vůbec vidět.
Mapka se může zdát redundantní, ale kopíruje konfliktní oblasti. Ideálně by k ní patřily popisky typu “Konflikt XY” – ale to je beyond the scope.
Opět jsem zvažovala heatmap, ale zjistila jsem, že vypadá jak z malování a zdaleka nekomunikuje převahu ME tak moc, jak bych doufala.
Původně tu byl i graf s průběhem v čase, ale byl nadbytečný a nekomunikoval žádnou novou informaci.
Treemap ukazuje bizarní převahu Iráku. Nastackovala jsem ho jako jednu linku – podle Cole Nussbaumer Knaflic se snáz vnímá rozdíl délek než ploch.
Odebraná desetinná místa u procent – méně clutteru, čistší vizuál.
Ideálně by na pozadí treemap byla vlajka dané země. Ale to Power BI neumí….
Asi by se s tím dalo ještě mnohem více vyhrát, ale už jsem nad tím strávila nekřesťanské množství času. Snad to takto stačí.
Přiznám se, že se mi report horkotěžko tvořil, protože jsem neměla moc představu, k čemu je, kdo je moje publikum a co mu vlastně chci sdělovat…
link to spreadsheet -> 🔗🔗🔗
první problém - funkce IMPORTXML nezvládla scrapovat heureku, ani alzu, bazoš ano -> hence asi potřeba lepší scraping tool, který heureka nezablokuje -> obešla jsem to extenzí IMPORTFROMWEB. jinak syntaxe vypadá v podstatě stejně
druhý problém - filtr dle TOPu. if statements vypadaly jako peklo, takže jsem to nakonec obešla pomocí ancestor::div[#️⃣]
třetí problém - chybějící hodnocení se prostě nenaimportovala a chybějící data tak posunují celou tabulku. u případných chybějících cen (nebo akčního formátování) by to byl úplně stejný problém. nenapadlo mě elegantní řešení a domnívám se, že je beyond the scope of this domácí úkol (?)
zkusila jsem si zběžně Geneeu, nevím vlastně ale k čemu bych ji kde využila.
jako jednu entitu jsem se nakonec rozhodla mít jeden blok času, resp. jednu událost v kalendáři
date,timestart,timestop,code,location
2025-09-16,10:00,12:00,ISKM95,teams
2025-09-17,16:00,18:00,ISKM55,G02
2025-09-23,10:00,12:00,ISKM95,teams
2025-09-23,16:00,18:00,ENTRE01,zoom
2025-09-24,16:00,18:00,ISKM55,G02
2025-09-26,12:00,16:00,ISKM11,D22
2025-09-30,10:00,12:00,ISKM95,teams
2025-09-30,16:00,18:00,ENTRE01,zoom
2025-10-01,16:00,18:00,ISKM55,G02
2025-10-07,10:00,12:00,ISKM95,teams
2025-10-07,16:00,18:00,ENTRE01,zoom
2025-10-08,16:00,18:00,ISKM55,G02
2025-10-10,12:00,16:00,ISKM11,D22
# so and so on
prvně jsem doufala, že jedna entita by byl jeden předmět. to by ale nepodchytilo různé frekvence předmětů, blokové předměty a jiné. četnost tedy dává smysl podchytit spíše řádky, jinak je to imo extrémně sloppy. tahle varianta by asi fungovala třeba na rozvrh pro prvňáčky, kde zas takové výkyvy nebývají.
na řešení se mi moc nelíbí, že jsou mnohé informace duplicitní - časy hodin, nebo kdyby se např. měla přidávat informace o vyučujícím. na druhou stranu to dovoluje flexibilitu při změnách ve výuce. 🤷
celý soubor na githubu
<?xml version="1.0" encoding="utf-8"?>
<gpx version="1.1"
creator="viktorie"
xmlns="http://www.topografix.com/GPX/1/1">
<rte>
<name>brno heart</name>
<rtept lat="49.194373" lon="16.608736">
<ele>215.000000</ele>
</rtept>
<rtept lat="49.195442" lon="16.608852">
<ele>215.000000</ele>
</rtept>
<rtept lat="49.196704" lon="16.609122">
<ele>215.000000</ele>
</rtept>
<!-- so and so on -->
<rtept lat="49.194373" lon="16.608736">
<ele>215.000000</ele>
</rtept>
</rte>
</gpx>
web si každých pár sekund vyžádá json, kde každá entry (?) v array vehicles je jedno konkrétní vozidlo… každé vozidlo pak má přirazené údaje - číslo linky, destinaci, poslední zastávku atd.
(stačí takto? víc mi přijde jako okecávání)
