diff --git a/content/blog/cookie-consent-banner.mdx b/content/blog/cookie-consent-banner.mdx index 4d46e45..c1a0ca8 100644 --- a/content/blog/cookie-consent-banner.mdx +++ b/content/blog/cookie-consent-banner.mdx @@ -24,20 +24,19 @@ readTime: 5min
**Patrick (System Architect My Porsche):** I'm a huge fan of a great user experience. Not only for the end users of a product, but also for the software - engineers creating those. An awesome developer experience leads to an awesome + engineers creating these. An awesome developer experience leads to an awesome (end-) user experience. That's why I enjoy spending time into defining a meaningful and scalable interface definition. The Cookie Consent Banner is such an example. It's a component that you have to build for legal reasons and - probably don't touch quite often after the initial implementation. It shouldn't - be complicated if you need to adapt it again after some time. The Cookie Consent - Banner is very flexible, but still convenient to integrate. - + probably doesn't change quite often after the initial implementation. It shouldn't + be complicated when you need to adapt it again after some time. The Cookie Consent + Banner is very flexible, yet still convenient to integrate. + title="You are currently maintaining Porsche's open-source project Cookie Consent Banner on GitHub. How would you explain your project in a nutshell? What problem does your project solve for Porsche?"> - **Patrick:** I'm sure everybody remembers the time when cookie banners hit the + **Patrick:** I'm sure everybody remembers the time when cookie banners first appeared on the internet. It's not only cumbersome for the visitors of a website but also for the maintainers to implement such a solution. So we created a component that is not only informative to the visitors of a website, but also easy to integrate for @@ -63,9 +62,9 @@ readTime: 5min balance between sensible defaults and a potentially overwhelming set of options to customize. Given the success of the component, I would say we found a good balance. I really like the feedback the community provides via - GitHub Issues and Pull Requests. For example, did we face an issue where - someone mentioned how the component affects their Google Lighthouse Score. - Together, we found a solution, making the component better performing for + GitHub Issues and Pull Requests. For example, one of the issues we had + was someone mentioning how the component was affecting their Google Lighthouse score. + Together, we found a solution, making the component performing better for everybody. And while feature requests are always welcome, I'm hopeful to see more direct contributions through Pull Requests in the future. It's this kind of active collaboration that brings out the best in open-source