Jak stworzyć czytelny dashboard wyników w Pythonie: wykresy, filtry i wnioski dla promotora

Kontekst: czego promotor naprawdę oczekuje od dashboardu

Rola dashboardu w pracy dyplomowej i projekcie badawczym

Dashboard wyników w Pythonie ma dla promotora przede wszystkim funkcję narzędzia do rozmowy, a nie fajerwerku technologicznego. Chodzi o to, aby w jednym miejscu zebrać najważniejsze wskaźniki, wykresy i filtry, które pozwolą szybko odpowiedzieć na kluczowe pytania badawcze. Dobrze przygotowany dashboard ułatwia promotorowi ocenę jakości analizy, a Tobie – obronę decyzji metodycznych.

W praktyce oznacza to, że interaktywny dashboard powinien:

• pokazywać główne wyniki badań w formie zrozumiałej bez zaglądania w kod,
• pozwalać na proste filtrowanie (np. grupy badawcze, zakres dat, wariant metody),
• umożliwiać szybką zmianę perspektywy: od ogólnych trendów do szczegółów danych,
• klarownie prezentować konsekwencje zastosowanych metod, a nie tylko same obliczenia.

Techniczna doskonałość (idealne CSS, rozbudowane animacje) ma tu drugorzędne znaczenie. Liczy się to, czy promotor po 30 sekundach rozumie, o co chodzi, i jest w stanie zadać sensowne pytania pogłębiające w oparciu o dashboard, a nie o surowy kod.

Czego typowo szuka promotor: wnioski, porządek, pytania

Promotor patrzy na dashboard wyników w Pythonie przez pryzmat logiki badawczej, a nie technologii. Najczęściej oczekuje trzech rzeczy:

• Jasnych wniosków – czy z układu wykresów i metryk od razu widać, co jest najważniejsze? Czy pierwsza sekcja dashboardu mówi „co wyszło”, a nie „jak liczyliśmy”?
• Porządku – czy metryki i wykresy są ułożone od ogółu do szczegółu, czy można intuicyjnie przejść od głównego wyniku do jego rozbicia na podgrupy?
• Możliwości zadawania pytań – czy można szybko sprawdzić: „a co jeśli ograniczymy się do tej konkretnej grupy?”, „jak wygląda rozkład, a nie tylko średnia?”, „co się dzieje w innym okresie czasu?”.

Promotor bardzo rzadko pyta, czy dashboard ma piękny gradient tła. Zdecydowanie częściej: „czy mogę zobaczyć tylko grupę X?”, „a jak wygląda porównanie przed/po?”, „czy możemy odfiltrować odpowiedzi skrajne?”. Dlatego panel filtrów w Dash lub prosty zestaw interakcji w Plotly ma większą wartość niż najbardziej dopieszczony layout graficzny.

Różnica między ładnym wykresem a narzędziem do rozmowy

Pojedynczy, ładny wykres to ilustracja. Dashboard wyników w Pythonie to narzędzie decyzyjne. Różnica polega na tym, że:

• wykres odpowiada na jedno konkretne pytanie („jak zmienia się średnia w czasie?”),
• dashboard pozwala zadawać kolejne pytania („jak zmienia się średnia w czasie, jeśli bierzemy tylko grupę A, a jak w grupie B, a jak po wycięciu skrajnych obserwacji?”).

Tworząc dashboard dla promotora, dobrze jest przyjąć perspektywę: „jakie trzy–pięć pytań badawczych promotor na pewno zada?”. Pod te pytania projektuje się wykresy, filtry i układ. Ładna paleta kolorów jest dodatkiem, który może pomóc, ale nie nadrobi braku sensownej logiki pytań.

Ograniczenia: czas, zasoby sprzętowe, brak front-endu

Większość osób przygotowujących pracę dyplomową nie ma czasu ani budżetu na rozbudowane środowiska produkcyjne. Zazwyczaj jest:

• jeden laptop średniej klasy,
• kilka tygodni do oddania pracy,
• brak doświadczenia w HTML/CSS/JavaScript,
• promotor, który chce coś zobaczyć na ekranie, ale nie żąda komercyjnej jakości aplikacji.

Z tego powodu warto postawić na minimalny stos technologiczny: Python + Pandas + biblioteka do wykresów (np. Plotly Express) + lekkie narzędzie do dashboardów (Dash lub Streamlit). Taki zestaw pozwala uzyskać efekt „wow, to jest interaktywne i zrozumiałe” przy niewielkim nakładzie pracy, bez nauki front-endu od zera.

Wybór narzędzi: minimalny stos technologiczny pod czytelny dashboard

Porównanie: Jupyter + widgets, Plotly + Dash, Streamlit, Voila

Dla większości prac dyplomowych i projektów badawczych wystarczy kilka prostych bibliotek. Poniżej skrótowe porównanie podejść używanych najczęściej.

Jeśli celem jest pokazanie czegoś na spotkaniu z promotorem na własnym laptopie, najczęściej wystarczy:

• Jupyter Notebook + Plotly Express (interaktywne wykresy w notatniku),
• lub Streamlit – gdy chcesz w kilka linijek mieć menu boczne i filtry.

Gdy zależy Ci na bardziej „produkcyjnym” wyglądzie i większej kontroli nad layoutem, rozsądnym kompromisem jest Pandas + Plotly Express + Dash. Tę kombinację łatwo odpalić lokalnie, a jednocześnie daje bardzo dużo swobody przy projektowaniu panelu filtrów i struktury sekcji.

Kryteria wyboru: czas, deployment, wymagania promotora

Zanim wybierzesz stos technologiczny, przelicz koszt w czasie i nerwach. Dobrze sprawdza się krótka checklista:

• Ile mam czasu? Jeżeli mierzysz czas do oddania pracy w tygodniach, lepiej wybrać Streamlit lub Dash z małą liczbą widoków niż ambitną aplikację wielostronicową.
• Jak będę prezentować dashboard? Jeśli tylko lokalnie – wystarczy uruchomienie serwera na laptopie. Jeżeli promotor chce dostać plik, lepszy będzie eksport do statycznego HTML z wykresami Plotly.
• Czy promotor potrzebuje „live demo” online? Jeżeli tak, trzeba doliczyć czas na prosty hosting (np. darmowe plany w chmurze lub serwer uczelniany). Gdy nie ma takiej potrzeby, nie ma sensu planować produkcyjnego deploymentu.
• Czy potrafię HTML/CSS? Jeśli nie, wybierz narzędzie, które daje sensowny UI z pudełka (Streamlit, domyślne layouty Dash), zamiast budować zera front-end w React.

Najczęściej promotorowi wystarczy: „Uruchamiamy plik Python, otwiera się okno przeglądarki, klikamy filtry, rozmawiamy o wynikach.” Jeżeli tak ustalisz oczekiwania, nie musisz inwestować dziesiątek godzin w dopieszczanie rzeczy, których i tak nikt nie wykorzysta.

Budżetowe podejście: dashboard w jednym notatniku Jupyter

Najtańsza czasowo opcja to stworzenie pół-dashboardu w jednym notatniku Jupyter:

• sekcja ładowania i czyszczenia danych,
• sekcja z obliczeniem kluczowych metryk w Pandas,
• kilka komórek z wykresami Plotly Express,
• ewentualnie kilka prostych widgetów (slidery, dropdowny).

Plotly pozwala zapisać każdy wykres jako .html, więc można wyeksportować najważniejsze widoki do osobnych plików i dołączyć je do pracy lub wysłać promotorowi. Ten wariant jest idealny, gdy masz bardzo mało czasu, a i tak chcesz mieć interaktywne wykresy i minimum logiki filtrów (np. klikanie w legendę, zaznaczanie fragmentów wykresu).

Racjonalny kompromis: Pandas + Plotly Express + Dash

Jeśli możesz poświęcić trochę więcej czasu i chcesz mieć prawdziwy dashboard z panelem filtrów i kilkoma sekcjami, dobrym wyborem jest zestaw:

• Pandas – przygotowanie i agregacja danych,
• Plotly Express – szybkie tworzenie interaktywnych wykresów,
• Dash – prosty framework do składania aplikacji webowej w Pythonie.

Taki stos:

• jest w całości w Pythonie (bez konieczności pisania JS),
• ma sporo przykładów i gotowych snippetów,
• pozwala wygodnie zbudować panel filtrów (dropdowny, checkboxy, slidery),
• wygląda profesjonalnie nawet w wersji „na szybko”.

Dla wielu dyplomów i projektów naukowych to optymalna ścieżka: notatnik Jupyter do eksperymentów i analiz, a docelowy dashboard z wykorzystaniem tego samego kodu Pandas i Plotly w ramach aplikacji Dash.

Przygotowanie danych: tabela, która nie zabije żadnego wykresu

Struktura danych „long” vs „wide” a dashboard

Najczęstszą przyczyną bólu przy budowaniu dashboardu nie są biblioteki, tylko źle ułożona tabela. Żeby interaktywne wykresy i filtry w Pythonie działały gładko, dane powinny być możliwie bliskie formatu tall/long:

• każdy wiersz to jedna obserwacja (np. odpowiedź ankietowa, pojedynczy pomiar),
• kolumny opisują cechy tej obserwacji (np. grupa, data, wartość pomiaru, wariant metody).

Format wide (szeroki), z kolumnami wartosc_grupa_A, wartosc_grupa_B, wartosc_grupa_C łatwo wchodzi na początku, ale potem utrudnia filtrowanie i rysowanie wykresów według kategorii. Większość bibliotek (Plotly Express, Seaborn) zakłada, że masz jedną kolumnę z wartością i osobną kolumnę z kategorią (np. grupa, wariant).

Jeżeli dane są w formacie wide, w Pandas można je przekształcić na long np. przez pd.melt(). Zrób to raz na początku projektu, zamiast walczyć później z każdą nową metryką i wykresem.

Czyszczenie: brakujące wartości, duplikaty, niespójne kategorie

Dashboard nie wybacza bałaganu w danych: drobne problemy zamieniają się w dziwne wykresy, błędne legendy i rozjechane liczby. Minimalny „budżetowy” zestaw sprzątania w Pandas powinien zawierać:

• Obsługę braków – df.isna().sum() i decyzja: wyrzucamy, imputujemy (np. medianą), czy oznaczamy specjalną kategorią typu „Brak danych”.
• Usuwanie duplikatów – df.drop_duplicates() przed agregacjami, szczególnie gdy łączysz kilka plików źródłowych.
• Ujednolicenie kategorii – sprowadzenie wartości typu „grupa A”, „Grupa A”, „A” do jednej postaci, np. przez str.lower() i mapowanie słownikami.

Warto też wyczyścić kolumny dat tak, by były faktycznymi datetime, a nie tekstem. To ułatwi filtrowanie po okresach, grupowanie po miesiącach czy tygodniach i późniejsze użycie sliderów dat w Dash.

Kolumny pomocnicze pod filtry i agregacje

Dobrze zaprojektowany dashboard wyników w Pythonie opiera się na kilku logicznych filtrach, które promotor może zrozumieć i wykorzystać. Z tego powodu warto dodać do tabeli kolumny pomocnicze, które uproszczą filtrowanie:

• Rok, miesiąc, dzień – wyciągnięte z daty (df['rok'] = df['data'].dt.year),
• Grupa badawcza – jawnie oznaczone etykietą zamiast kodu liczbowego,

Agregacje pod wykresy i KPI

Surowe dane rzadko nadają się bezpośrednio na wykres. Zamiast liczyć wszystko „w locie” w callbackach, opłaca się przygotować kilka gotowych agregatów w Pandas. Dzięki temu dashboard:

• ładuje się szybciej,
• mniej obciąża procesor przy każdej zmianie filtra,
• ma mniejszą szansę na błędy w logice.

Typowe agregacje pod dashboard wyników to:

• średnie / mediany po grupach (np. metoda, grupa badawcza, okres),
• liczności (np. liczba odpowiedzi w ankiecie w każdej kategorii),
• procenty (udział danej odpowiedzi / wariantu w całości).

Przykładowo, jeżeli analizujesz skuteczność dwóch algorytmów w różnych zbiorach danych, zamiast trzymać surowe pomiary w dashboardzie, przygotuj ramkę:

kpi_df = (
    df.groupby(["algorytm", "zbior_danych"])
      .agg(
          sredni_blad=("blad", "mean"),
          mediana_bledu=("blad", "median"),
          liczba_prob=("id_pomiaru", "nunique")
      )
      .reset_index()
)

Potem wykresy odwołują się już do kpi_df, a nie do wielkiej tabeli z każdym pojedynczym pomiarem. To bardzo upraszcza też debugowanie – jeżeli liczby na dashboardzie nie zgadzają się z tym, co masz w pracy, sprawdzasz jedno miejsce, a nie dziesiątki linijek kodu w callbackach.

Stabilne identyfikatory i klucze

W bardziej złożonych projektach przydają się stabilne identyfikatory, które jednoznacznie oznaczają obiekt (np. respondenta, jednostkę badawczą, eksperyment). Dzięki nim łatwiej:

• łączać dane z kilku źródeł,
• wracać do pojedynczych przypadków (np. kliknięcie w punkt na wykresie pokazuje szczegóły),
• weryfikować, czy agregacje nie dublują rekordów.

Jeżeli nie masz takich kluczy w danych wejściowych, można je dodać na etapie przygotowania:

df = df.reset_index(drop=True)
df["id_obs"] = df.index.astype(int)

Taki prosty, rosnący identyfikator bywa wystarczający, szczególnie gdy dashboard służy głównie do rozmowy z promotorem, a nie jako produkt dla szerszego grona odbiorców.

Definiowanie metryk i KPI: co naprawdę pokazać na ekranie

Metryki dla promotora, nie dla autora

Naturalny odruch: pokazać wszystkie wskaźniki, które policzyłeś. Mniej kuszące, ale znacznie skuteczniejsze podejście: zacząć od dwóch–trzech pytań, na które promotor chce dostać odpowiedź. Pod nie dobrać metryki.

Przykładowe pytania, które często wracają na spotkaniach:

• „Która metoda działa lepiej i w jakich warunkach?”
• „Jak stabilne są wyniki – czy dużo się wahają między próbami / grupami?”
• „Czy efekt jest na tyle duży, żeby miał sens praktyczny?”

Pod takie pytania metryki dobierasz inaczej niż pod rozbudowaną analizę w publikacji. Czasem wystarczy:

• 1–2 główne KPI (np. średni błąd, dokładność, czas działania),
• 1 wskaźnik stabilności (np. odchylenie standardowe, IQR),
• 1 prosty wskaźnik efektu (np. różnica między metodami, % poprawy).

KPI pierwszego ekranu: liczby, które widać od razu

Na starcie dashboardu opłaca się mieć 3–6 dużych kafelków z najważniejszymi liczbami. To są wartości, które promotor powinien zobaczyć, zanim w ogóle ruszy jakikolwiek filtr:

• „Średnia dokładność najlepszej metody”
• „Liczba próbek / respondentów w analizie”
• „Średnia poprawa względem baseline”
• „Czas obliczeń na jedną próbę”

Technicznie, w Dash czy Streamlit to zwykle proste komponenty typu metric card lub własnoręcznie wystylizowane div z liczbą i krótkim opisem. Różnica w efekcie jest jednak duża: promotor od razu rozumie skalę projektu, nie musi zgadywać, co jest tu najważniejsze.

Metryki „pod maską”: wsparcie dla trudniejszych pytań

Oprócz KPI „na froncie” dobrze mieć w zapasie 2–3 metryki wspierające: niekoniecznie na pierwszym ekranie, ale w niższej sekcji lub w zakładce „szczegóły”. Mogą to być:

• dokładność w podgrupach (np. osobno dla mniejszych i większych zbiorów danych),
• miary błędu rozbite na zakresy (np. ile przypadków z błędem poniżej progu),
• liczby pokazujące robustność (np. wynik po odrzuceniu skrajnych 5% obserwacji).

Takie metryki są przydatne przy dopytywaniu: „A co, jeśli usuniemy te najbardziej odstające punkty?”. Zamiast ponownie liczyć wszystko w notatniku, możesz zmienić filtr w dashboardzie i pokazać różnicę na żywo.

Spójność metryk między dashboardem a pracą

Jedno z częstszych potknięć: inna definicja metryk w kodzie do rozdziału wyników, a inna w kodzie dashboardu. Potem wartości „prawie się zgadzają”, co na spotkaniu nie brzmi najlepiej.

Bezpieczniejsza praktyka:

• mieć jedno źródło prawdy – moduł lub notatnik z funkcjami do liczenia metryk,
• wykorzystać te same funkcje zarówno do generowania tabel w pracy, jak i do zasilania dashboardu,
• przed prezentacją przelecieć kilka losowych przypadków i porównać liczby: praca vs dashboard.

Ta inwestycja to zwykle jedna–dwie godziny porządkowania kodu, w zamian za spokojną głowę na obronie.

Projekt układu dashboardu: logika od ogółu do szczegółu

Jedna historia na jedną stronę

Najprostszy sposób na przeładowanie dashboardu: upchnąć wszystko na jednym ekranie w trzech kolumnach. Dużo wydmuszkowego „wow”, mało realnej czytelności. Zamiast tego lepiej przyjąć zasadę „jedna historia na jedną stronę” lub sekcję.

Dla pracy dyplomowej czy projektu badawczego sensowny układ to:

• sekcja 1 – Podsumowanie: główne KPI i 1–2 kluczowe wykresy porównawcze,
• sekcja 2 – Szczegóły metod: rozbicie wyników na metody, warianty, warunki,
• sekcja 3 – Struktura danych: liczebności, rozkłady, ewentualnie mapa braków,
• sekcja 4 – Analizy dodatkowe: eksperymenty, warianty, testy wrażliwości.

Nie trzeba od razu implementować przełączanych zakładek – czasem wystarczy przewijalna strona z wyraźnie oddzielonymi blokami. Dla promotora liczy się to, żeby widział, gdzie się zaczyna nowy wątek.

„F” zamiast „choinki”: kolejność elementów

Ekran czyta się w kształcie litery „F”: z lewej do prawej, potem w dół. Tę starą zasadę z projektowania stron można bezpośrednio zastosować w dashboardzie:

• główne KPI – u góry, na całej szerokości lub w dwóch kolumnach,
• główny wykres porównawczy – pod nimi, centralnie, szeroki, czytelny,
• szczegóły, tablice, histogramy – niżej lub po bokach.

Jeżeli używasz panelu bocznego (np. w Streamlit), filtry naturalnie lądują po lewej. Dzięki temu promotor nie musi ich szukać; od razu widać, że „najpierw wybieramy, potem oglądamy wykresy”.

Panel filtrów: zgrubnie na górze, precyzyjnie niżej

Filtry można poukładać warstwami – jak w rozmowie. Najpierw wybierasz „duże” kryteria, potem doprecyzowujesz:

• na górze: wysokopoziomowe – rodzaj metody, główna grupa badawcza, zakres dat,
• niżej: szczegóły – konkretne warianty, parametry, progi.

W praktyce dobrze działa prosty układ:

• sekcja „Zakres analizy” – daty, zbiór danych, populacja,
• sekcja „Metody” – wybór algorytmów / wariantów,
• sekcja „Widok” – wybór metryki na osi Y, ewentualnie przełącznik typu wykresu.

Taki podział ułatwia też tłumaczenie promotorowi logiki dashboardu: „Na górze wybieramy, na czym pracujemy, niżej – jak to oglądamy”.

Stałe elementy a sekcje dynamiczne

Kilka elementów powinno być „zakotwiczonych” – widocznych niezależnie od innych części:

• tytuł dashboardu i krótki opis (1–2 zdania),
• zawsze dostępne główne filtry,
• oznaczenie aktualnego podzbioru danych (np. „Dane: 2019–2021, grupa: studenci”).

Reszta może się zmieniać w zależności od wybranego widoku. Nie trzeba tworzyć złożonego systemu stron – czasem wystarczy przyciski przełączające sekcje (np. „Podsumowanie / Szczegóły / Dane surowe”) i prosty warunek w kodzie, który pokazuje odpowiedni zestaw wykresów.

Wybór i implementacja wykresów w Pythonie: od prostych do sprytnych

Minimalny repertuar: 3–4 typy wykresów

Większość pytań promotora da się sensownie obsłużyć wąskim zestawem wykresów. Zamiast eksperymentować z wodospadami, sankeyami i radarami, lepiej dopracować kilka solidnych klasyków:

• liniowy – przebieg w czasie lub wzdłuż rosnącej zmiennej,
• słupkowy (zwykły lub grupowany) – porównanie metod, grup, wariantów,
• pudełkowy / violin – rozkład wyników i stabilność metod,
• rozrzutu – zależności między dwiema zmiennymi (np. dokładność vs czas).

Plotly Express pozwala wszystkie z nich narysować kilkoma linijkami. Przykładowy kod dla wykresu słupkowego porównującego metody:

import plotly.express as px

fig = px.bar(
    kpi_df,
    x="algorytm",
    y="sredni_blad",
    color="zbior_danych",
    barmode="group",
    title="Średni błąd algorytmów według zbioru danych"
)

Kolory i legendy: mniej znaczy czytelniej

Biblioteki dbają o estetykę domyślnie, ale ich celem jest „ładnie”, niekoniecznie „czytelnie dla promotora”. Kilka prostych zasad robi dużą różnicę:

• ogranicz liczbę kolorów na jednym wykresie – 3–5 kategorii to często maksimum,
• użyj spójnych kolorów dla tej samej metody na wszystkich wykresach,
• popraw etykiety w legendzie – "alg1_best" zamień na „Algorytm 1 (ulepszony)”.

W Plotly można zdefiniować własną mapę kolorów jako słownik:

kolory_metod = {
    "baseline": "#636EFA",
    "metoda_A": "#EF553B",
    "metoda_B": "#00CC96",
}

fig = px.bar(
    kpi_df,
    x="algorytm",
    y="sredni_blad",
    color="algorytm",
    color_discrete_map=kolory_metod
)

Dzięki temu przy każdym kolejnym wykresie nie zastanawiasz się, czy „zielony to nadal metoda B”.

Dodawanie niezbędnych adnotacji zamiast ozdobników

Zamiast dolepiać kolejne wykresy, często wystarczy lepiej opisać te istniejące. Kilka adnotacji, linia referencyjna czy podpisy wartości robią więcej niż drugi, prawie identyczny wykres.

Przykłady użytecznych dodatków:

• linia benchmarku (np. wynik metody bazowej) na wykresie słupkowym,
• etykiety wartości nad słupkami, gdy liczba kategorii jest mała,
• pasek błędu (min–max lub kwartyle) dla porównania stabilności.

W Plotly służą do tego np. parametry error_y, add_hline albo dodatkowe ślady z linią.

Porównania względne zamiast ściany liczb

Przy pracach badawczych promotor zwykle zadaje pytania w stylu: „O ile lepsza jest metoda A od B?” zamiast „Jaka jest dokładność metody A?”. Łatwiej więc operować na różnicach niż na gołych poziomach metryk.

Zamiast kilku osobnych wykresów dla każdej metody, często wystarczy jeden widok pokazujący:

• różnicę względem metody bazowej (np. baseline = 0, reszta powyżej/poniżej),
• procentową poprawę względem punktu odniesienia (np. „+12% vs baseline”),
• ranking metod na jednej osi, posortowany malejąco po jakości.

Przykład szybkiego wykresu różnic względem metody bazowej:

import plotly.express as px

baseline = kpi_df[kpi_df["algorytm"] == "baseline"]["sredni_blad"].iloc[0]
kpi_df["roznica_vs_baseline"] = kpi_df["sredni_blad"] - baseline

fig = px.bar(
    kpi_df,
    x="algorytm",
    y="roznica_vs_baseline",
    title="Różnica błędu względem metody bazowej"
)

Tego typu wykres od razu ustawia rozmowę: widać, które metody realnie „odklejają się” od bazowej, a które są w granicach szumu.

Łączenie wykresów: siatka zamiast nowych stron

Gdy liczba wariantów rośnie, łatwo utonąć w zakładkach. Prostszym rozwiązaniem jest siatka małych wykresów (tzw. facet grid): jeden typ wykresu, powielony dla różnych grup lub metryk. Promotor patrzy na jeden ekran i widzi całość.

Plotly Express ma do tego facet_row i facet_col:

fig = px.box(
    wyniki_df,
    x="algorytm",
    y="blad",
    color="algorytm",
    facet_col="zbior_danych",
    facet_col_wrap=2,
    color_discrete_map=kolory_metod,
    title="Rozkład błędów algorytmów w zależności od zbioru danych"
)

Zamiast trzech osobnych stron „Zbiór 1 / Zbiór 2 / Zbiór 3” masz jedną czytelną macierz wykresów. Mniej klikania, więcej porównań „na oko”.

Wykres tabelaryczny: kiedy zwykła tabela wygrywa

Nie każdy wynik trzeba na siłę wrzucać w słupki. Dla kilku metryk na krzyż zwykła, dobrze posortowana tabela (z możliwością filtrowania) bywa szybsza w interpretacji.

Przydadzą się:

• sortowanie po wybranej metryce (np. od najlepszego do najgorszego algorytmu),
• podświetlenie wiersza z metodą bazową,
• kolorowe tło komórek dla ekstremów (np. gradient od czerwonego do zielonego).

W Streamlit minimalna tabela to jeden wiersz:

import streamlit as st

st.dataframe(
    kpi_df.sort_values("sredni_blad"),
    use_container_width=True
)

Na początek to w zupełności wystarczy. Często można odłożyć bardziej zaawansowane komponenty tabelaryczne (jak AG Grid) na później – na etapie pracy dyplomowej nie musisz ich nawet wdrażać.

Wykresy „komentarzowe”: podkreślenie kluczowych punktów

W części wykresów zależy nie tyle na ogólnym kształcie, co na kilku konkretnych punktach. Zamiast gęstego scattera, który przytłacza, możesz wyróżnić wybrane obserwacje:

• punkt odpowiadający najlepszej konfiguracji,
• punkt z podejrzanie niskim wynikiem (do dyskusji),
• konfiguracje, które wylądują w tabelach w pracy.

W Plotly realizuje się to przez dodanie dodatkowego śladu lub adnotacji:

fig = px.scatter(
    wyniki_df,
    x="czas_uczenia",
    y="dokladnosc",
    color="algorytm",
    color_discrete_map=kolory_metod
)

najlepszy = wyniki_df.sort_values("dokladnosc").iloc[-1]

fig.add_scatter(
    x=[najlepszy["czas_uczenia"]],
    y=[najlepszy["dokladnosc"]],
    mode="markers+text",
    marker=dict(size=14, color="black", symbol="star"),
    text=["Najlepsza konfiguracja"],
    textposition="top center",
    showlegend=False
)

To drobiazg, a od razu wiadomo, o którym punkcie mówić na spotkaniu.

Filtry i interaktywność: jak nie przesadzić z opcjami

Limit filtrów: 3–5 kluczowych przełączników

Interaktywność kusi: można dodać selektor metody, danych, dat, progu, metryki, wariantu metryki, trybu logarytmicznego… Po piątym przełączniku użytkownik przestaje pamiętać, co właściwie ma włączone.

Dla prostego, promotorowego dashboardu dobry punkt startowy to:

• 1–2 filtry dotyczące danych (zakres, zbiór, grupa),
• 1 filtr wyboru metryk (co jest na osi Y lub w KPI),
• 1 filtr dotyczący metody/algorytmu (wybór pojedynczego lub kilku wariantów).

Pozostałe „fanaberie” można schować pod przełącznik „Ustawienia zaawansowane” albo w ogóle obliczyć offline i podać jako osobny wykres.

Domyślne wartości: scenariusz „otwieram i widzę sensowny widok”

Promotor rzadko będzie miał czas, żeby najpierw klikać. Po otwarciu dashboardu pierwszy widok powinien odpowiadać na bazowe pytanie: „Która metoda jest ogólnie najlepsza i jak bardzo?”.

Domyślny stan formularza można łatwo ustawić w kodzie, np. w Streamlit:

import streamlit as st

domyslne_metody = ["baseline", "metoda_A"]

wybrane_metody = st.multiselect(
    "Wybierz metody",
    options=sorted(wyniki_df["algorytm"].unique()),
    default=domyslne_metody
)

Ważne, żeby domyślne wybory odpowiadały przypadkom opisanym w pracy. Wtedy to, co promotor widzi na ekranie, pokrywa się z tabelami w rozdziale wyników.

Filtry zależne: prosta logika, mniej błędnych kombinacji

Jeżeli masz kilka zbiorów danych i nie wszystkie metody były na nich testowane, można nieco odciążyć użytkownika: lista metod powinna zależeć od wybranego zbioru. Unikasz wtedy pustych wykresów i pytań „czemu tu nic nie ma?”.

Przykładowe podejście w Streamlit:

zbior = st.selectbox("Zbiór danych", sorted(wyniki_df["zbior_danych"].unique()))

dostepne_metody = sorted(
    wyniki_df[wyniki_df["zbior_danych"] == zbior]["algorytm"].unique()
)

metoda = st.selectbox("Algorytm", dostepne_metody)

Nie jest to wyszukana logika biznesowa, a realnie podnosi komfort pracy – i Twój, i promotora.

Minimalna liczba akcji: jedna zmiana = jedna reakcja

Jeżeli do zobaczenia wyników trzeba wyklikać trzy pola, interaktywność zaczyna męczyć. Lepiej, gdy pojedyncza zmiana (np. metody) automatycznie odświeża wykres. Bez przycisku „Przelicz”, o ile tylko dane nie są ogromne.

Streamlit i Plotly aktualizują wykresy przy każdej zmianie formularza. To wygodne, ale przy cięższych modelach może spowalniać. Wtedy da się przełączyć się na prosty mechanizm:

• u góry filtrów – checkbox „Tryb wolniejszy, ale stabilniejszy”,
• jeżeli zaznaczony – pokazujesz przycisk „Odśwież wykresy” i blokujesz automatyczne przeliczanie.

Taka „awaryjna opcja” przydaje się na słabszym laptopie albo przy bardzo dużych tabelach.

Interaktywność wewnątrz wykresu: zoom, wybór legendy, podgląd

Zanim dodasz 10 filtrów po stronie formularza, sprawdź, co da się osiągnąć samymi funkcjami wykresu. Plotly ma kilka użytecznych mechanizmów bez żadnej dodatkowej logiki:

• kliknięcie w legendę – ukrywanie/wyświetlanie serii (np. wyłączasz metody, które Cię nie interesują),
• przeciągnięcie myszką – zoom na wybrany obszar wykresu,
• podpowiedzi (hover) – szczegóły punktu bez zagracania osi etykietami.

Często wystarczy dopracować informacje w podpowiedzi (parametr hover_data) zamiast budować osobny panel szczegółów.

fig = px.scatter(
    wyniki_df,
    x="czas_uczenia",
    y="dokladnosc",
    color="algorytm",
    hover_data=["parametr_C", "parametr_gamma", "fold"]
)

Od notatnika do prostego dashboardu: praktyczny schemat krok po kroku

Krok 1: Uporządkowany notatnik z jedną tabelą wyników

Zanim zaczniesz bawić się w interfejs, dobrze mieć stabilną podstawę: jedną, sensownie nazwany DataFrame z wynikami. Najczęściej wystarcza struktura:

• algorytm – nazwa metody lub wariantu,
• zbior_danych – nazwa zbioru lub podgrupy,
• metryka – nazwa metryki (np. accuracy, MAE),
• wartosc – wynik metryki,
• opcjonalnie: fold, numer eksperymentu, parametry modelu.

Jeżeli już na etapie notebooka zbierzesz wszystko do takiej tabeli i zapiszesz np. do .parquet lub .csv, przejście do dashboardu to kilka importów, a nie przepisywanie logiki.

# przykładowa agregacja do jednej tabeli
wszystkie_wyniki = []

for alg in algorytmy:
    for zbior in zbiory:
        # ... liczysz metryki ...
        wszystkie_wyniki.append({
            "algorytm": alg,
            "zbior_danych": zbior,
            "metryka": "accuracy",
            "wartosc": dokladnosc
        })

wyniki_df = pd.DataFrame(wszystkie_wyniki)
wyniki_df.to_parquet("wyniki.parquet")

Krok 2: Minimalny szkielet aplikacji (np. Streamlit)

Zamiast od razu dopieszczać layout, dobrze zacząć od pliku w stylu app.py z trzema blokami:

1. ładowanie danych,
2. proste filtry (nawet pojedyncze selectbox),
3. jeden wykres i jedna tabela.

Taki „goły” szkielet można postawić w ciągu godziny. Potem ewoluuje się go w kierunku docelowego dashboardu, zamiast projektować wszystko w głowie.

# app.py
import streamlit as st
import pandas as pd
import plotly.express as px

@st.cache_data
def load_data():
    return pd.read_parquet("wyniki.parquet")

wyniki_df = load_data()

st.title("Wyniki modeli – podsumowanie")

zbior = st.selectbox("Zbiór danych", sorted(wyniki_df["zbior_danych"].unique()))
metryka = st.selectbox("Metryka", sorted(wyniki_df["metryka"].unique()))

filt = (wyniki_df["zbior_danych"] == zbior) & (wyniki_df["metryka"] == metryka)
df_view = wyniki_df[filt]

fig = px.bar(df_view, x="algorytm", y="wartosc", title=f"{metryka} dla {zbior}")
st.plotly_chart(fig, use_container_width=True)

st.dataframe(df_view, use_container_width=True)

Krok 3: Wyciągnięcie logiki do funkcji

Kiedy szkielet działa, kod najczęściej zaczyna się powtarzać: te same filtry, podobne wykresy. Kilka prostych funkcji porządkuje całość i zmniejsza ryzyko błędów:

• filtruj_wyniki(df, zbior, metryka, algorytmy) – zwraca przefiltrowany DataFrame,
• rysuj_wykres_slupkowy(df) – buduje standardowy wykres słupkowy,
• przygotuj_kolory_metod(df) – tworzy mapę kolorów według listy algorytmów.

Tak samo jak wcześniej przy metrykach: jedno miejsce prawdy to mniej niespodzianek na obronie.

Krok 4: Podział na sekcje stroną „if/else”

Zamiast od razu wchodzić w rozbudowane frameworki wielostronicowe, można zrobić prosty przełącznik widoku na jednej stronie:

widok = st.sidebar.radio(
    "Widok",
    ["Podsumowanie", "Szczegóły metod", "Struktura danych"]
)

if widok == "Podsumowanie":
    pokaz_podsumowanie(wyniki_df)
elif widok == "Szczegóły metod":
    pokaz_szczegoly(wyniki_df)
else:
    pokaz_strukture_danych(dane_surowe_df)

Każda funkcja może mieć swój zestaw filtrów i wykresów. Logiczny podział sekcji z poprzednich fragmentów artykułu przekładasz bezpośrednio na takie funkcje.

Krok 5: Zapisanie konfiguracji widoku (opcjonalnie)

Najczęściej zadawane pytania (FAQ)

Jakie narzędzia w Pythonie są najprostsze do zrobienia dashboardu na pracę dyplomową?

Przy ograniczonym czasie i jednym laptopie najszybciej zacząć od: Jupyter Notebook + Pandas + Plotly Express albo Streamlit. W pierwszym wariancie masz wszystko w jednym notatniku, interaktywne wykresy i minimum konfiguracji. Streamlit dorzuca z automatu boczny panel, filtry i czystszy podział na sekcje bez znajomości HTML/CSS.

Jeśli promotorowi wystarczy pokazanie wyników u Ciebie na laptopie, ten „budżetowy” stos technologiczny jest zwykle w zupełności wystarczający. Bardziej rozbudowane rozwiązania (np. Dash) opłacają się dopiero, gdy potrzebujesz większej kontroli nad układem i filtrami.

Czy lepiej wybrać Streamlit czy Dash do dashboardu wyników dla promotora?

Jeżeli masz mało czasu i nie chcesz walczyć z layoutem, praktyczniejszy będzie Streamlit. Kod jest prostszy, interfejs powstaje „sam z siebie”, a do prostych filtrów wystarczy kilka linii: selektor grupy, zakres dat, checkbox na usuwanie skrajnych wartości.

Dash ma sens, gdy:

• chcesz mieć dokładną kontrolę nad układem sekcji i panelu filtrów,
• potrzebujesz bardziej „produkcyjnego” wyglądu (np. kilka kart, różne widoki),
• planujesz ten dashboard rozwinąć po obronie.

W większości klasycznych prac dyplomowych Streamlit wygrywa stosunkiem „efekt vs wysiłek”.

Jakie elementy dashboardu są najważniejsze z perspektywy promotora?

Promotor szuka przede wszystkim odpowiedzi na pytania badawcze, a nie fajerwerków wizualnych. Kluczowe są:

• sekcja z głównymi metrykami i wnioskami (co wyszło),
• wizualizacje od ogółu do szczegółu (trend → rozbicie na grupy → rozkłady),
• proste filtry pozwalające szybko „przeklikać” różne warianty danych.

Gradienty, animacje i dopieszczone CSS mają marginalne znaczenie, jeśli promotor po 30 sekundach wciąż nie wie, na co patrzy.

Jak zaprojektować filtry w dashboardzie, żeby promotor faktycznie z nich korzystał?

Najpierw spisz 3–5 pytań, które promotor niemal na pewno zada, np.: „a jak wygląda tylko grupa X?”, „co z okresem po zmianie metody?”, „jak zmienia się wynik po wycięciu skrajnych obserwacji?”. Pod te pytania zaprojektuj minimalny zestaw filtrów: wybór grupy, zakres dat, wariant metody, przełącznik „usunąć skrajne wartości – tak/nie”.

Nie dodawaj dziesięciu suwaków „na wszelki wypadek”. Każdy filtr to dodatkowa rzecz do ogarnięcia w kodzie i dla użytkownika. Lepiej mieć 3 trafione kontrolki niż rozproszony panel, z którego nikt realnie nie korzysta.

Czy muszę znać HTML/CSS, żeby zrobić sensowny dashboard wyników w Pythonie?

Nie. Przy narzędziach takich jak Streamlit czy domyślne layouty Dash, sensowny interfejs dostajesz praktycznie „z pudełka”. Skupiasz się na logice danych, wykresach i filtrach, a nie na ręcznym ustawianiu pikseli. To znacznie obniża koszt czasowy całego projektu.

HTML/CSS zaczynają być potrzebne dopiero wtedy, gdy chcesz mocno personalizować wygląd (własne szablony, nietypowe układy). W kontekście pracy dyplomowej to zwykle przerost formy nad treścią – promotor dużo bardziej doceni dobrze przemyślane wnioski niż idealnie wyrównane marginesy.

Jak pokazać dashboard promotorowi, jeśli nie mam hostingu ani serwera?

Najprostszy wariant to uruchomienie wszystkiego lokalnie: odpalasz skrypt Pythona, otwiera się przeglądarka z dashboardem i wspólnie przeklikujecie filtry na spotkaniu. Zero kosztów infrastruktury, tylko Twój laptop.

Jeżeli promotor chce coś „na maila”, możesz:

• wyeksportować wykresy Plotly jako statyczne pliki HTML,
• albo wysłać notatnik Jupyter z już wykonanymi komórkami.

To tanie czasowo rozwiązania, które nie wymagają od Ciebie konfiguracji żadnego zewnętrznego serwera.

Czy wystarczy „pół-dashboard” w Jupyter Notebook zamiast pełnej aplikacji?

W wielu przypadkach tak. Jeden notatnik z:

• sekcją ładowania i czyszczenia danych,
• kilkoma kluczowymi metrykami w Pandas,
• interaktywnymi wykresami Plotly Express

pozwala przejść z promotorem przez całą logikę analizy bez budowania pełnej aplikacji.

Taki „pół-dashboard” to sensowny kompromis, gdy deadline goni, a chcesz pokazać coś więcej niż statyczne rysunki. Masz interakcję (zoom, filtrowanie po legendzie), zachowujesz przejrzystość, a czas implementacji liczysz w godzinach, nie w tygodniach.

Najważniejsze wnioski

• Dashboard dla promotora ma być przede wszystkim narzędziem do rozmowy o wynikach, a nie pokazem umiejętności front‑endowych – kluczowe są wnioski, logika i możliwość zadawania pytań.
• Najważniejsze elementy to: jasne pokazanie głównych wyników bez zaglądania w kod, proste filtry (grupy, daty, warianty metody) oraz możliwość przejścia od ogólnych trendów do szczegółów.
• Układ treści musi odzwierciedlać tok myślenia badawczego promotora: od „co wyszło” w pierwszej sekcji, przez rozbicie na podgrupy, aż po sprawdzenie alternatywnych scenariuszy („a co jeśli zawężymy próbę?”).
• Ładny pojedynczy wykres to tylko ilustracja; dopiero zestaw wykresów z filtrami staje się narzędziem decyzyjnym, które pozwala dynamicznie sprawdzać różne warianty danych (np. grupy A/B, przed/po, z wycięciem skrajnych obserwacji).
• Przy ograniczonym czasie i sprzęcie lepiej wybrać minimalny stos: Python + Pandas + prosta biblioteka wykresów (Plotly Express) + lekkie narzędzie do dashboardów (Dash lub Streamlit), zamiast inwestować w rozbudowany front‑end.
• Do spotkań na własnym laptopie najczęściej wystarczy Jupyter Notebook z interaktywnymi wykresami Plotly lub prosty Streamlit z menu bocznym i filtrami – daje dobry efekt przy niewielkim nakładzie pracy.
• Wybór narzędzi powinien wynikać z trzech czynników: dostępnego czasu, sposobu prezentacji (lokalnie vs „produkcyjny” wygląd w przeglądarce) oraz realnych oczekiwań promotora, a nie z chęci użycia najbardziej zaawansowanej technologii.