Featured Community Plugin - Buienradar

This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.

Buienradar

Community member Doeke (Discord: doekenorg) created the Buienradar plugin; here are their words on how it was created.

Why did you want this plugin to exist?

I've tried a few of the other weather plugins, but their accuracy for The Netherlands was not that great. Not that weather apps are often right... but I figured using a Dutch service, would have more accuracy overall.

Why were you the person to make it?

I'm a software developer, with some sense of proper design. Not that I'm a designer at all, but I know what looks and works well. So I keep at it, making it suck less, until it looks good.

Were you inspired by any other recipes or plugin creators?

Yes, since I've been using other plugins; I've been biased to their designs, of course. But also by other plugins that were way too crowded and cramped a lot of info in a small window.

How did you balance look vs functionality?

In this case, design was slightly more important. Functionality is of course: making the weather information available. But design drives how easy it is to absorb that information. Visual hierarchy is very important there. I also wanted to make the plugin feel native to the TRMNL platform, as well as to users familiar with Buienradar. So I reused their iconography.

What was your process for creating the plugin?

First I read the API and figured out what information would be good to use on the screens. Then I used a combination of Claude and my JetBrains IDE to design every step. I also used the TRMNL local dev server to test the plugin on various screens. Lastly, I created a proper git repo for the plugin, using the GitHub actions to quickly be able to release new features and updates.

What, if any, challenges did you face while creating it?

The data is limited to a 5-day forecast (today + 4 days). This meant that the design needed to include or exclude information based on the screen size. Sometimes that meant including something only on portrait mode, but not on portrait mode of another screen size. This meant testing and retesting every screen on OG and X a lot. I also missed some leading tools to increase the line-height of larger and longer texts. I mentioned this to the team, and they responded very positive on the idea.

Did you learn anything that you want to apply to future or past recipes?

I created an AGENTS.md file to let AI agents use the correct best practices, as well as the appropriate helper classes. This meant that changes would always use the framework, making the change automatically work on light/dark mode. And the shared template is a great way to set up re-usable template parts. Having a single place to change classes across pages has been a great timesaver.

Is there a tip you would give to a new plugin developer?

As always, first, RTFM. That is very extensive. It would be great to have those docs as markdown files for LLM's. Or even as an MCP server (Editor: We do!). For now I just pulled to my local memory. But definitely test your plugin on multiple screens using the local dev server.