Every Sunday I share my progress and tell you all about new ideas, plans, features and hopefully it sparks the excitement around Lotus! Sometimes it does and readers email me saying how much they liked this or that idea, which makes me really happy.
Well, today I'm going to break that streak of interesting new announcements and list the things I don't like about Lotus.
I'm also going to use this as an opportunity to understand how can I solve or at least reduce the impact of these problems.
This should be fun, let's go.
If you have more than a few hundred unread notifications, Lotus is quite slow to switch from a loading screen to your Inbox.
It takes time to refresh all your unread notifications and fetch new ones. That's why the more notifications you have, the longer it takes Lotus to start. I've described this process with greater detail in "Moving towards native app experience".
I built it this way to ensure Inbox is always up-to-date when you see it. If notifications were synced in the background, UI would change without user interaction, which could be confusing. For example, if notification was marked as read on GitHub, Lotus would remove that notification from Inbox without user pressing anything.
I understand that it's probably a tradeoff I will have to make to show a fully initialized UI faster. Refreshing existing notifications asynchronously would significantly speed up the loading process.
Lotus would still show a loading screen while it fetches new notifications, but this change should already be a good improvement.
When you view a notification in Lotus, it embeds an actual github.com page for the linked issue or a pull request, instead of fetching comments from the API and rendering it manually.
This was a concern from the first days of Lotus, but long story short is it's too complicated to recreate the UI for issues and pull requests.
Not only Lotus would know how to display the entire conversation, it would also need to:
Maintaining up-to-date support for GitHub features is not something I can do sustainably alone. So I went for embedding GitHub's pages inside a
<webview> (or browser view).
Because of this, loading the content of notifications isn't fast. There's also no way to cache it for notifications you've opened before, which could at least speed up viewing pages that were already loaded in the past.
At this point, not much. Electron doesn't support caching webviews and I haven't come up with other ideas to make it quicker yet.
I could spend time building a minimal UI for rendering threads, but I feel like that would be a half-baked solution. Users would need to open GitHub if they needed some feature that Lotus doesn't support yet in its minimal UI.
Usually when you're offered to log in with GitHub, Twitter or Facebook (for example), you're redirected to these websites. Then you complete the authentication and website redirects you back to the app.
Lotus works exactly the same, only not in user's browser, but inside an app window. It's actually another webview underneath. As a result, users can't see the URL of the page where they're entering GitHub credentials and apps like 1Password don't work here either. You'd need to manually copy a password from 1Password and paste it in the login form.
One of the early adopters pointed this out to me, saying they don't trust a 3rd-party app and they're concerned about entering email and password in an unknown window.
I started looking into it, but unfortunately I realized I have to use webviews for authentication. Authenticating in a webview persists your session across all webviews in Lotus, which allows viewing notifications from private repositories and post new comments, just as if you were on GitHub directly.
If I were to remove that, you would see notifications from private repositories in the Inbox, but there would be no way to view the thread inside Lotus. You'd have to open GitHub for that.
I understand that I can't solve the root cause of this problem just yet, but here's what I've done:
The moment I stop using
<webview> to embed GitHub in notification pages, I will start opening a user's browser to perform authentication there instead.
If you have other ideas how to increase users' confidence in the authentication process, I'd really appreciate it.
One of the first few features I planned was automatically skipping notifications for replies like "+1", "any update?" or "bump". These are a waste of time and they shouldn't take place in developer's Inbox.
However, I didn't build this feature yet, because GitHub's API only returns the title of the notification, not the content of the latest comment. To fetch that, I'd need to make another API request for each notification, which will slow down the app.
I should explore the possibilities and performance of using GraphQL API instead of REST API. With GraphQL API I can fetch multiple data fields in one request, which should be faster than sending multiple requests to the REST API for the same data.
I built Lotus on REST API, but if GraphQL API isn't slower and offers more flexibility, I think it's worth trying to migrate it.
If you use Lotus on two machines, your preferences, muted notifications and some other things aren't synced between the two computers.
Lotus is local-first and it doesn't store your data on any server, so there's no single place to sync to/from.
To clarify, whenever you mark notification as read or unread, Lotus syncs these changes to GitHub. Then, because GitHub is the source of truth for unread notifications, both computers would show up-to-date list of notifications in the Inbox. But, for example, if you bookmark a notification on your Macbook Air, that same notification won't be automatically bookmarked on your Macbook Pro.
The difference between marking notification as read and bookmarking it, is that bookmarks aren't synced to GitHub, since there's no API for them. So the following things are stored only locally and aren't synced:
Lotus uses SQLite for storing data, which doesn't support replication (syncing between multiple computers). Thankfully, there's Litestream by Ben Johnson, which syncs SQLite database file to/from S3-compatible storage. There's no sensitive information in the database, so this sounds like a safe and interesting option to explore.
I could either store these SQLite files in my S3 account or users could set up their own. Obviously, the latter option has way more friction to it, which could be a big deterrent.
When a new version is out, Lotus automatically updates in the background and asks to restart the app to apply changes.
But after you restart it and start using the new version, there's no way to know what was added, changed or removed. Users have to figure that out themselves, which is not ideal.
Add the changelog!
It should be available on the website and perhaps app could link to it, instead of displaying the same changelog in-app too.
I already maintain a changelog using GitHub releases, so I can use GitHub's API to pull the content from there.
This was indeed fun! Now I have a list of biggest pain points I feel today and I can gradually work my way through them.
If you have tried a beta of Lotus, what did you not like? Let me know by replying to this email! Feel free to be as harsh as possible and call out the smallest details.
If you haven't tried Lotus yet, let me know and I'll send you a copy.
Thank you and see you next time!
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.