berlin / haushaltsdaten Goto Github PK

On mobile the filters are taking a considerable portion of the screen, thus leaving less space for the visualisation itself. We might want to find another solution here, such as having a button with a filter icon that, when clicked, opens a menu with selects and switches.

Inspired by the Moneten Kieker: https://www.schleswig-holstein.de/DE/fachinhalte/S/steuern/monetenkieker.html

We want all Einzeltitel belonging to a certain group (Hauptfunktion, Oberfunktion, Funktion) to be displayed in the list. For the MVP this can limited to the first 100 items.

Ideally, the table also holds information about the different group levels.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Error updating PR

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• fix(deps): update dependency @headlessui/react to v2
• fix(deps): update dependency @mdx-js/loader to v3
• fix(deps): update dependency maplibre-gl to v4
• fix(deps): update dependency react-type-animation to v3
• fix(deps): update dependency swr to v2
• fix(deps): update dependency use-debounce to v10
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency postcss to v8.4.31 [security]
• chore(deps): update devdependencies-non-major (@storybook/addon-actions, @storybook/addon-essentials, @storybook/addon-links, @storybook/react, @tailwindcss/typography, @testing-library/jest-dom, @testing-library/user-event, @types/d3, @types/node, @types/react, @types/react-dom, @types/react-type-animation, autoprefixer, commitizen, eslint-config-next, eslint-config-prettier, eslint-plugin-import, eslint-plugin-jsx-a11y, eslint-plugin-react, eslint-plugin-react-hooks, prettier, tailwindcss, typescript)
• chore(deps): update dependency node to v20.17.0
• deps(deps): update dependencies-non-major (@headlessui/react, @mdx-js/loader, @next/mdx, @supabase/supabase-js, classnames, d3, just-snake-case, maplibre-gl, use-debounce)
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update devdependencies-major (major) (@storybook/addon-actions, @storybook/addon-essentials, @storybook/addon-links, @storybook/react, @testing-library/jest-dom, @testing-library/react, @types/jest, @types/react, @types/react-dom, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, babel-jest, babel-loader, eslint, eslint-config-next, eslint-config-prettier, eslint-import-resolver-typescript, eslint-plugin-prettier, husky, jest, jest-watch-typeahead, lint-staged, prettier, storybook-addon-next-router, tsconfig-paths-webpack-plugin, typescript)
• fix(deps): update dependency @next/mdx to v14
• fix(deps): update dependency @supabase/supabase-js to v2
• fix(deps): update dependency react-cool-dimensions to v3
• fix(deps): update react monorepo to v18 (major) (react, react-dom)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Make sure the searched term is easily visually identifiable.

In Chrome auf Android in sehr kleine Devices.

What do we want?

We want a stable link for each filter/treemap combination, so that it can be shared with others. At the moment, we can already share the expense type and district combination. But we also want to be able to share a view that is already zoomed into the treemap. We already have URL params for this (mainTopic, midTopic, deepTopic), but these need to be put to use.

Idea for how this could work:

If a prop such as path (e.g. ['allgemeine_dienste', 'rechtsschutz']) is provided, we jump to the appropriate depth again by simulating clicks like we did initially.

However, this only ever happens on the first render of the treemap.

We avoid running server-side code again by passing shallow: true when we update the URL params for the path (on click within the Treemap component's D3 code).

But when we share the current link, there is a path present in the URL params, so that the treemap jumps to the correct depth on first render.

When changing district or showExpenses, we remove the path-related URL params, so that we always start in the highest depth for a new filter.

So much for the theory, hope this works out.

Currently we only display the data for 2022 (and excluding any IST data as opposed to the SOLL data).

Ideally we include 2023 as well as previous years, so that each year can be viewed. This may require us to think about the way we store the data. Currently we use a PostgreSQL view haushaltsdaten_2022. Can we just create new views for each year or is there a better way? What is the most friction-less way? What can be automated?

For README:

• add where the data comes from (Supabase and possible alternatives)
• rework the "Getting started" guide
• basic information where to find the important components
• which pages exist
• (how to change texts)

Also check if the code needs refactoring to make it a bit clearer for future work.

For issues:

• add more context to currently existing issues
• add issues for future feature ideas
• more testing as an issue?

In Chrome auf Android small devices

Based on... group?

This only happens navigating up from depth 1 to depth 0. This is probably because the mapTopicDepthToColumn util doesn't handle a depth of 0.

More content should be added to the Info Page. The FAQ page contains only a few entries so far. Here a brainstorming and an elaboration of further questions and texts should be done.

JSON is easy
CSV is relatively easy
At first limited to the max rows visible on the page

The treemap could be extended by a function, so that one can select whether the monetary values are to be indicated as total values or as calculated per capita. In the district display, the values would then be calculated on the district population.

The placement of the spinner on the full text search could get some love

In Chrome auf Android on small devices

At least some basic info which API we are using, sorting/relevance of results, etc.

It's open source, let's show it!

A small bar (or something similar) should display the currently selected view and its amount of € and contextualize it with the highest level value of €.

Some parts were done really quick and dirty. Let's try refactoring these a bit so that the code remains understandable in the future and for others.

If there are no results we could run a fuzzy search with the same search term and show these results

Currently, the CI runs all fail because we do not provide the necessary env variables to the GitHub Action.

When a category is clicked on a list element, the relevant filter should be activated.

Add routes and menu. Also merge Lisa's PR with example content.

Should we make our "cleaned" data available as an API endpoint? Is there a value to this?

Duplicate our the Qtrees NextJS setup and prepare it for the project

At the moment we have quite long loading times. As a first step we could add a loading bar like in Stadtpuls.

But ideally we should improve the loading times.

• Make a table per year
• Load data into supabase
• Add filter in UI
• Load the relevant data
• In search, add a Year UI filter

We (some people from Code for Germany) had a discussion about your project and wonder if you could lobby for better input data. Berlin seems to still provide that data as a XLSX file without documentation. So no advancement in direction to more structured, semantic (even linked) OpenData at the moment.

Have you also consider to use a different workflow in the UI? At the moment it's same workflow designed in OffenerHaushalt at 2012?

Had you had a look at things like https://specs.frictionlessdata.io/fiscal-data-package/#introduction and consider this as an interopable format for the data (e.g. as reexport from the app)?

We've got a couple of tests already and we might not need that many since it's a rather simple data visualization. But we might wanna add more tests, especially for gaining confidence when making changes or just updating dependencies.

Key features that we might wanna test:

• the treemap controls: does changing the filters dispatch the correct events at all times?
• the list view: is it always in sync with the current treemap level?

Perhaps we should consider integration testing over unit testing for these things?

I wonder if we should test anything treemap-itself-related. Or can we rely on D3 testing all our used functionalities?i

At the moment we have title, main group, district, and amount. This leads to (seemingly) duplicates sometimes:

If we would add the columns oberfunktions_bezeichnung and funktions_bezeichnung the differences would become clear. However then we have to deal with space issues because we tend to have long values in these columns.

This ticket is for extending the list view so that it can display more than the initial 100 items.

On mobile, the breadcrumbs path is often cropped so that we can not see the last level we're in and usually only the first depth (see screenshot).

It would be ideal if we could only show the last level in this breadcrumb. Maybe the display for small and large screens could even be different.

A feature could be added to the treemap to allow a dropdown to select whether the levels shown should be based on the function, on the groups, or on the individual plans.

Some levels are not self-explanatory. We've got some textual information for these that could be displayed next to the treemap.

Example: Maybe the group Allgemeine Dienste is not self-explanatory. In this case we could show 2 - 3 sentences next to the treemap or below it to explain and contextualize the current view.

We want to have a full-text search so that people can search for a field of interest and immediately find the expenses/earnings related with that field.

No exact design idea yet. May require some more thought.