A Widget System for Agricultural Monitoring
The problem
The old plot summary was a fixed stack. We piled sections in an order we controlled, based on whatever sensors and integrations the users added. At first, it was fine we didn't have that many. But as the app grew, so did the complaints.
Some users had to scroll through, a lot, to reach what mattered. Let's say you wanted to reach the accumulation section you had to scroll through every other sections, paying for load times and screen real estate to display data they'd never check. And it would get even worse, with new features landing in the middle. They wanted control back on what was displayed and how, fair enough!
The constraints
Most Weenat users are on mobile, so we had to think mobile first, letting mobile constraints set the rules while still taking advantage of what desktop offers. We had around ten sections to work with, which we broke into roughly twenty widgets.
We also knew from feedback and experience that users don't want to configure. Or if they must, once and they never want to hear about it ever again. We also had to account for different usage patterns around the same data, some users care about real-time and short-term forecasts, others use the same space for historical analysis.
The wrong path
Our first instinct was to change as little as possible. We explored adding flexibility to the existing stacked sections, let users reorder, delete sections, and call it a day!
But something was missing: comparison. In a vertical stack, you can't easily compare data across sections. The problem wasn't just about order, It was also about layout, at least on the web. That's how we ended up considering building grid, and then building widgets.
The approach
Automation over configuration
If configuration is an issue, let's try to need it as little as we can, and if it's needed let's keep it simple. To solve this, we tied adding widgets to actions users were already taking. For example, linking a sensor to a plot would automatically add its widget. Same goes for DSS integrations, adding one magically add the corresponding widget. Doing so, you only have one action, not two and your dashboard builds itself!
Defaults that earn trust
Still on the “less configuration” train, we analyzed usage data from the old stack. Which sections got clicks through to details? What did users praise at fairs? We used that data to shape default configurations that felt right without being pushy. Most users never touch settings, so defaults have to earn their spot.
That said, widgets also made customization easier. So when users did want to configure, it finally felt approachable.
Platform-specific editing
Talking about customization, let's get into it. On browser we implemented a WYSIWYG drag-and-drop on a 3-column grid, you can see your dashboard as you build or change it. To expand, or add widget a big button takes you towards everything you haven't added yet, also offering discoverability of what you can do on the application. Here's what's possible, add it and explore.
On mobile its a different game. WYSIWYG is harder to execute, and it's more about order than spatial arrangement. So we built a simple, separate config page with a list of all the widget you currently have, and an accessible at the bottom of the dashboard scroll. Didn't find what you wanted? Add it now. This avoids the classic drag-in-scroll hell and the nightmare of dragging a large widget across a small screen.
Sizing logic
Remember the mobile first constraints, that's were it really make sense. Each of our widget has one fixed size, no variants. To create a widget, we always start thinking about 1x1, can we make this work small? If not, we escalate to 1x2 or 2x2, but only if the content demands it and the importance justifies the space. Every pixel has to defend itself.
Consistency across widgets
What makes widget click is predictability and consistency. So every widget shares the same bones: a three-dot menu, a consistent footer, predictable states for loading, empty, and error. Learn one, and understand most, yes most, why not all ? That's a conversation for another time. When you've got five or more widgets on screen, this consistency compounds, moving, removing, adding, finding actions all feel familiar.
Outcome
It worked. Users told us they liked the system, it feels easy, that they feel in control again, that they like seeing only what matters. One thing we didn't anticipate though seasonal reconfiguration. Priorities shift through the year, and now dashboards can shift with them.
What's next
I'd love to explore the widget-to-widget synergies, and the synergy with the rest of the application. How can one connect to another? And what about connections beyond the dashboard, to alerts, exports, other features?
I designed this system; implementation was handled by colleagues on the engineering team.