project database as separate page

[friep]

placeholder issue: @jstet and me discussed this that we could / should have a separate page where we provide a project database that provides information on as much projects as possible, not only the ones where we have detailed reports (ie. the ones who are currently on /daten_nutzen/projekte). This list of "described projects" would then be removed from projects subpage, instead linking to this new page.

Format ideas: cards but filterable/searchable?

text search on:

• title
• summary
• description

filters (decreasing prioritiy):

• LCs
• sector of organization
• type of project (type tag)
• data of project (data tag)
• language of project (language tag)

on card:

• title
• organization
• tags (data, type, language..) , e.g. type:dataviz or data:open_data

all projects get a subpage:

• short summary for all projects (minimum 2 sentences - what and how)
• outputs if available
• organization block (tbd: what to do when anonymized)
• description if available

[jstet]

An alternative would be to implement the projects db on the page where the projects are now. After having closed #148 we and maybe #209, this wouldn't take up too much space.

[friep]

summary of call:

for now:

• mehr lesen /read more instead of "Projektbericht"
• Git Repository as main output (but keep in mind only public ones are of interest!) --> is_public flag of the project outputs collection

for later:

display all public outputs

• reason: some projects might not have a full report but have quite a few other outputs
• i first thought of something like this: https://stevenstromick.com/css/css-card-overlay/ (on click on "outputs" not on hover though)
• alternatively: https://flowbite.com/docs/components/card/#card-with-nav-tabs or https://flowbite.com/docs/components/popover/ (latter again on click on "outputs")
• display title of podcast episode and blog post then as well next to the icon

[jstet]

• [x] Do the above

[friep]

• [ ] private repos are currently also linked --> use field is_public in projects outputs to filter.

[friep]

@jstet one question that links to #457 : how do the API requests work? are they processed during build or dynamically? are they authenticated or via the public role?

Background: What i'd like to see on the "project database" are (almost) all projects. most of them would only have a title and maybe a 2 sentence text in an anonymized way and only information re. the sector and maybe legal form of the organization (see #457 ) . Hence, it'd be really good if the data was not only processed/filtered in frontend to avoid people just going to the network tab and pulling the data from there.

[jstet]

They are using the public role and for the production static build, they are processed during build.

[jstet]

in any case, the api requests should happen in the backend ( we are using server.js files)

[jstet]

re: going to the network tab and pulling the data from there: people can always scrape the projects from the website; i think we cant avoid that. I am not 100% sure how the data is served with the static website, because if u look at the resulting build, there are files that contain all the data and people might be able to access these files.

[jstet]

But there are no api requests in the static build apart from images etc.

[friep]

that'd be good to know how the data is served and what data is available. i'd really like to do this correctly :)

scraping of content that is on the website is not a problem -> that's open anyway. i'm more concerned about the data discussed in #457

[friep]

i updated the issue description to include the results of our discussion today.

[friep]

re :

all projects get a subpage: short summary for all projects (minimum 2 sentences - what and how)

i think it'd be easier to relax this constraint - otherwise it'll take ages to get through all projects initially