Moving towards native app experience

Happy holidays! I myself celebrate Christmas in January, so this week I had plenty of time to work on Lotus. There's plenty of stuff to go through, so I'm going to keep it short and sweet.

Colorful navigation

This is one of those things that I didn't know I needed, but ended up quite cool. I asked what did people think about adding color to navigation on Twitter and turns out literally everyone who responded thought it was a good idea!

Colorful icons actually serve a purpose here. When you're viewing a notification, action buttons will have the same icon and a color as the related page in the navigation. For example, "Reply Later" button will have the same orange icon as "Reply Later" in the navigation. The idea is that it will hint where your notification will be put and where you can find it after performing that action. I don't have any scientific facts to back up that assumption, but at the very least it just looks nice.

All icon colors also become gray when window is not focused, which adds a nice "native app" detail to Lotus. Thanks @gokul_i for suggestion!

Undo/redo

Lotus now offers you a way to <kbd>Cmd</kbd>+<kbd>Z</kbd> out of any trouble. Accidentally marked notification as read and now it's gone? Don't worry, you can undo it. In fact, you can undo (or redo again) every action related to notifications (e.g. mark as read, reply later, bookmark). Next week I plan to expand the support to Screener and Do Not Disturb settings.

Keyboard shortcuts

Continuing the theme of features you're used to see in native apps, next up - keyboard shortcuts. It was interesting to implement, because "Undo" and "Redo" actions can be taken in Lotus or in the embedded GitHub webview. Turns out when webview is rendered on the screen, it takes the focus away from the Electron app itself. To take care of that I got involved in some really dark hacks around Electron's limitations to detect where I should send the shortcut. I'm not proud of the implementation, but it was worth it!

Inbox filters

You can now filter your inbox by notification type (e.g. issue, pull request, etc). You can also filter by repository, if you want to focus on notifications from a specific repository and not be distracted by others.

Repositories are conveniently grouped into "My repositories" and "Other repositories", because I assume you might be more interested in notifications from your projects first.

Invitations

GitHub treats invitations to repositories the same way as all other types of notifications. I decided to handle them differently, because users don't receive invitations often and they can end up buried in the inbox. It's also a simple "Yes" or "No" action to respond to an invitation, so it's not as hard to deal with it as with replying to a pull request, for example.

Invitations are fetched as soon as you focus the window, so you won't need to wait 30 minutes for data to refresh, like in the case of notifications.

Syncing with GitHub

If you tried Lotus and didn't like it some time, you would expect your notifications on github.com be in the same state as you left them in Lotus, wouldn't you?

To make that happen, Lotus essentially needs to repeat (or "sync") the same action you take in the app to GitHub. I mentioned it was working already before, but turns out it didn't quite.

For example, when I viewed some notifications on GitHub directly, Lotus still had those as unread in my inbox. It was happening, because Lotus only pulled new notifications since the last time you viewed them.

To fix this, fetching data is a 2-step process now:

Fetch new notifications since the last attempt.
Refresh existing notifications and update their unread and open/closed state. It also updates title, in case issue got renamed, for example.

One thing I'm worried about is refreshing existing notifications, because it can potentially take a long time if you have a lot of them. Moreover, it could significantly reduce your rate limiting quota in GitHub's API. If the quota is reached, all API requests will fail until the next hour, so that's not ideal.

I think there are several solutions to this.

Refresh only notifications that are immediately visible to the user and refresh others asynchronously, without blocking the loading of the app. Maybe even delay refreshing others unless user scrolls down in the inbox to see them.
Implement a rate limiting mechanism that delays all API requests until there's a new quota available.

This sounds like a good challenge and both of these workarounds are interesting, but I'm not going to spend time on these just yet. My main goal for now is to have something that works the way I want it to and put it in the hands of early testers. By the way, if you want to become one, let me know!

I want to say "thank you" to all people who responded to my last week's "Marketing was an afterthought for me" email! The marketing roadmap is clearer to me now and all of your ideas helped a lot. I will report back after some time to let you know what worked and what didn't.

I also want to thank everyone who's reading this newsletter, I appreciate your support! I have never written a newsletter before and so far I'm really enjoying this experience.

Some weeks are very productive (like this one), some aren't. However, I now realize that the key is to show up. Even if I don't have a lot of juicy screenshots to send your way, I can share my progress and let you know how it's going. After all, my goal was to show what's happening behind the curtains, and sometimes it's just not perfect and doesn't go as planned.

I actually think sending you this newsletter every Sunday is one of the most exciting things I did in 2020. Pressing "Send" brings me a ton of joy, knowing that someone is waiting for it and curious how Lotus has been doing in the past week.

I'm more excited than ever to continue sharing this story and see what's going to happen in the next year.

See you in 2021!

– Vadim.