Hello,
I have a suggestion.
Logseq currently is very buggy and slow. I think that the focus right now should be on making Logseq stable and performant. I don’t think it’s a good idea to spend time on new features like flash cards or Zotero integration etc. Those features are nice, but they’re pointless if in the end Logseq is full of bugs, and some of them cause data corruption, which is very inconvenient.
I think the focus right now should be only on Stability and Performance until v1.0 comes out. After that, continue to work on new features.
Those were my 2 cents. Please let me know what you think.
I would also prefer it if more work were currently being done on stability and bug-fixing. I have reported 15 bugs in the last few weeks and still have a few to report.
If anything, I would rather focus on features that are closer to the core functionality (like search where there are some important requests).
So my for a few weeks with focus on stability and bug fixing. Performance has been worked on recently - also an important topic.
I would agree with your statement, more focus on bug fixing, with improvements on core features. There’s lots of small things that seem to break with each update too, such as templates are back to indenting the content under the 1st block on 0.3.1, and tags are now rendered as both a page tag and a block reference, and many other things.
I seem to recall it’s already the stated intention to shift focus back to bug fixing and performance once the current batch of features are out the door.
For me, spaced repetition and Zotero integration were minimum requirements for me to use Logseq. If they’re targetting academia in any way then all their competitors have these features available now.
The PDF highlighting will be amazing (and bring parity with RemNote but in a much easier to use format). So they’re getting Logseq to a minimum viable product for a lot of their users; this week I think they’ll reach that point so they can concentrate on the behind the scenes stuff. It’s always difficult for new products - early adopters tend to have more “in depth” needs than most potential users.
For what it’s worth, RemNote is a paid product and has been around quite a while, yet I found myself regularly fighting with bugs, performance issues and complexity. The Logseq UI is superb.
Currently there are bugs in the basic features like copy/paste. I have lost content many times. Sometimes the database doesn’t refresh properly until I close Logseq and open it again. Plus many other bugs that affect the absolute core components of the product.
Copy/paste definitely comes before spaced repetition or Zotero. There is no need to rush those features at the expense of the absolute basics.
I’m pleased with the stability and reliability, but my database is currently quite small, and I am probably not using the full range of built-in features. I think that flashcards and zotero integration are key features which were worth prioritising, and it was important to develop these for academic users. Having said this, performance/reliability does seem to be an issue for many people, so probably worth working on that in the short term?
I know when I led a development team, we often had some people working on bugs and some on features. Throwing more people at fixing bugs wouldn’t always work because they would have got into each other’s way if they were working on the same area of code and actually slowed down the process. I appreciate that there is some apparent regression here which the Logseq team do need to look at.
I agree 100%. It seems like it has great potential, but it’s unusable because it’s so slow. A feature freeze until response times are less than 100ms would be a wise choice.
My own current Logseq graph is about 650 pages. Response times while editing blocks in Logseq v0.3.2 is perfectly acceptable. For sure below 1s, not sure whether it’s less than 100ms though.
for a few weeks with focus on stability and bug fixing. Performance has been worked on recently - also an important topic.