While developing Beacon I had to face this data cleanup challenge:
When an issue/MR is closed/merged, Beacon should not show it to the dev anymore since Beacon shows ongoing work, but removing would surprise the user and gives a bad experience.
First, how is managed new data?
You got assigned to an issue, and you pushed the sync button. As soon as the sync is over, the UI is refreshed and shows your new issue with a blue left border to highlight it:
Second, how is managed data update?
Now this issue got some new comments, labels and assignee have changed and you synchronized in Beacon.
Here we need a different way to highlight that issue, a more discrete one that just tell to the user there are updates, but potentially not urgent to check now.
I did this by adding a dot on the left of issue/MR title styled like a little blueish LED light which is "ON" when there are updates, or "OFF":
And now, closed/merged issues/MRs
Beacon shows them dimmed for 7 days, at the bottom of the panel with the reason for being here (unassigned, merged, closed and so on).
But now let's say you have plenty of issues or MRs, how to get notified that you have those items at the bottom of the list?
I opted for a clickable discrete banner at the bottom of the list that scrolls to the beginning of the to-be-deleted-items section:
What do you think?
I'm satisfied the way it works, but I need feedback from you!
If you see a better way to handle data update/removal on local-first app I would be more than happy to hear from you.
Top comments (3)
This is a really thoughtful pattern. The part I like most is that you’re not treating “closed” as “instantly gone.” That preserves orientation and avoids the feeling that the app is rewriting reality behind the user’s back.
What you’ve really done here is separate three different states cleanly: new data that needs strong visibility, updated data that needs lighter visibility, and inactive data that still needs a reversible off-ramp.
That feels like a strong local-first instinct to me. In systems like this, disappearance needs to be legible, not just technically correct.
The only thing I’d watch over time is whether the 7-day dimmed state should eventually become user-tunable, since different people have very different tolerance for how long resolved work should linger.
But the core model feels right. It respects continuity instead of surprising the user.
Thank you so much for your feedback.
I'm trying to keep Beacon as a Dashboard, it doesn't have a Settings page so far, and the rare options are where you need it, like for example the clickable stack trace line to open in your IDE, there's the IDE selection dropdown:
But in future releases, if the need is to high for settings I'll keep your suggestion in mind.
Again, thank you!
Totally fair, and I think that restraint is probably a feature, not a limitation.
My main reaction wasn’t really “add settings,” it was more that the behavior already reflects a good systems instinct: don’t make resolved work vanish in a way that breaks user orientation.
If that continues to hold, then whether the 7-day window ever becomes configurable is just a later optimization, not a design hole.
Honestly, I like that Beacon seems to be choosing clarity in-context over a bloated preferences page. That usually ages better.