Hello! Lotus is slowly shaping into a ready-to-use app and this week I'm glad to share another batch of updates with you.
From removing tech debt to redesigning the UI, I feel like it's definitely going into the right direction and each week there's less unknowns than there were before.
But most importantly, winter is here! Every year at Segment I modify our web app to reflect that, because I just can't resist the opportunity. Last year I replaced our logo with a snow globe and Mariah Carey - All I Want For Christmas was playing in the background after page was loaded (sadly, the song was only on staging).
So why not have a little fun in Lotus too? I present to you... Lotus Winter Edition.
Actually, I just realized it looks like MS-DOS now, oh no! Let's quickly Cmd + Z that and move on.
New email-like UI
This week I changed the UI from displaying notifications grouped by repository to a simple list. I know it might look unusual to all of you GitHubbers out there, but hear me out.
I've read a lot of comments on HN and various blog posts about the way people are dealing with GitHub notifications and one topic stood out across every single one of them. People prefer to receive notifications via email, not github.com, because they have more control over what happens in their inbox.
This got me thinking, why not treat Lotus' inbox as email inbox? Grouped notifications are indeed easier to go through, but GitHub doesn't give you the same tools that Lotus does. With features like screener, reply later, bookmarks and snooze - you're in control. It's not "read now or leave it there" anymore, you decide when and how to deal with each notification.
Moreover, grouped UI just wasn't a good fit for more reasons:
- Infinite scroll or other kind of pagination just isn't possible when items are grouped.
- Because of the above, Lotus showed notifications in batches, ten at a time. If you wanted to see older notifications, you'd have no other choice but to go through the first ten, then get to the next ten. I'm sure this will get annoying, fast.
- Notifications are sorted by their "arrival" date, so groups can get automatically re-ordered when data is refreshed. This results in a UI that changes significantly without user interaction, which can get confusing.
Alright, so here it is.
It's simple and looks just like an inbox, very much on purpose. As you scroll down, older notifications are loaded instantly with no additional interaction. I enjoy it much more this way, but if you have concerns, feel free to reply to this email or write me directly at vadimdemedes@hey.com and let me know what you think.
Archive
There's a new Archive tab that shows notifications you recently marked as read. I think this will be useful as an activity log of some sort or when you need to dig up something you were reading a few days ago. It looks and works just like the other tabs. Note that notifications are sorted in the order of when you marked them as read, not when they landed in your inbox.
I noticed it starts to get a little crowded in the sidebar, so I'm thinking of moving Archive and Preferences elsewhere. Perhaps your username in the bottom could open a dropdown with links to these two. One downside of having a dropdown in an Electron app is that it can't be displayed outside application window, so it would have to open above username, not below as you would normally expect. I'll experiment with it next week.
Under the hood
Lotus needs to be in sync with GitHub to ensure the state of notifications stays the same between the two. To do that, Lotus sends API requests to GitHub to mark notifications as read or unread.
Previously, I triggered those API requests immediately after you clicked a "mark as read" button (for example). However, requests can fail, take longer than expected or be triggered in parallel with other conflicting requests (e.g. mark as unread). Also, all in-flight requests can be canceled and lost if user quits the app.
To solve that, I implemented a persistent queue in Lotus. As soon as you mark notification as read, a new job is added to a queue. Then queue executes pending jobs one by one. While that is happening, queue's state is updated in the database to make sure no jobs are lost. If queue is currently processing a job and user quits the app, that same job will be restarted after app is launched again.
Here are the modules I've used to build it:
- yocto-queue - Queue data structure.
- p-timeout - Handles job timeouts.
- p-retry - Retries failed jobs.
This feature was a much needed improvement and now I can sleep well at night, knowing that notifications are safely synced between Lotus and GitHub.
Thank you for checking out this week's newsletter! I hope I didn't eat your monthly internet quota by including a few gigabytes of GIFs here.
Stay safe and wash your hands. See you next week!
Vadim.
I'm building Lotus in the open and I'm sending out progress updates just like this one every Sunday.
I won't send spam and you can unsubscribe anytime.