So just to recap our discussion from here - I wrote:
it's very slow, and the noisy notifications made that very obvious.
it's okay with the notifications muted, I guess.
To which @FanaticPythoner replied:
By all rational metrics and evaluated metrics, on all aspects, BTT is orders of magnitude faster, and more memory efficient, while never compromising the main thread and such. The notification you're talking about has been changed based on requests, also.
More was said, but this is the essence.
So, I haven't benchmarked anything, and clearly you have numbers to prove this is objectively faster.
My feedback, then, is on the user experience vs the original extension.
The original extension felt fast - likely because I never knew it was doing anything at all. Just humming along in the background, it was always instantly ready whenever I would open it.
Your extension instead announced what it was doing - which clearly took a long time. I am working in a fairly large codebase - and I'm sure this took much longer in the original extension, but I never even knew it was happening.
So that would be my first bit of feedback: don't announce what you're doing.
It's fine to have that as an option, if someone wants that, but I don't think most people need to know what it's doing. The todo-list isn't typically the first thing I open, but it was always ready when I did, even with the old, slower extension. I never noticed any delay.
What I would suggest as better UX would be a progress bar (ideally, if possible) or even just a spinner in the todo-list panel itself - so that, if you do open it before it's ready, you would understand that the list is incomplete and still being gathered. I don't need the details of what it's doing, just that it's not ready for what I'm asking for.
One other possible UX improvement: I believe that extension starts scanning immediately, at launch, in the background, whether you open the todo-list or not, correct?
This is a good thing, but also comes at the cost of adding to IDE startup time overall - you are competing with other extensions for storage bandwidth (and other resources) while they perform other kinds of static analysis on the same files at startup. Your extension being faster likely means it's "running on more cylinders", making better use of constrained resources - but likely also means it's putting more pressure or competing harder for those resources.
Taking a quick look at the document scan cache, I believe there are two things you can do to improve this experience:
-
Persist the cache between sessions: the startup overhead (after opening a project for the first time) in most cases will be reduced to a simple directory listing and modification time check - compared to a full scan, this adds almost nothing to overall IDE startup time.
-
Make the persisted cache stale during revalidation: experienced startup time will be literally zero. You will open your project and the todo-list will be immediately available. If the initial cache revalidation is still running, you can indicate this with the mentioned progress bar or spinner - but for most normal use-cases, you will immediately see what you saw the last time you had the project open.
I hope this is useful. I've been UX brained these past couple of years, after taking a UX design course, so I am hyper aware and easily annoyed by these things.
I hope I don't come off as crass. 😅 I promise, I am just trying to help!
Thanks for the work you put in to keep this extension alive! It is appreciated. 😊
So just to recap our discussion from here - I wrote:
To which @FanaticPythoner replied:
More was said, but this is the essence.
So, I haven't benchmarked anything, and clearly you have numbers to prove this is objectively faster.
My feedback, then, is on the user experience vs the original extension.
The original extension felt fast - likely because I never knew it was doing anything at all. Just humming along in the background, it was always instantly ready whenever I would open it.
Your extension instead announced what it was doing - which clearly took a long time. I am working in a fairly large codebase - and I'm sure this took much longer in the original extension, but I never even knew it was happening.
So that would be my first bit of feedback: don't announce what you're doing.
It's fine to have that as an option, if someone wants that, but I don't think most people need to know what it's doing. The todo-list isn't typically the first thing I open, but it was always ready when I did, even with the old, slower extension. I never noticed any delay.
What I would suggest as better UX would be a progress bar (ideally, if possible) or even just a spinner in the todo-list panel itself - so that, if you do open it before it's ready, you would understand that the list is incomplete and still being gathered. I don't need the details of what it's doing, just that it's not ready for what I'm asking for.
One other possible UX improvement: I believe that extension starts scanning immediately, at launch, in the background, whether you open the todo-list or not, correct?
This is a good thing, but also comes at the cost of adding to IDE startup time overall - you are competing with other extensions for storage bandwidth (and other resources) while they perform other kinds of static analysis on the same files at startup. Your extension being faster likely means it's "running on more cylinders", making better use of constrained resources - but likely also means it's putting more pressure or competing harder for those resources.
Taking a quick look at the document scan cache, I believe there are two things you can do to improve this experience:
Persist the cache between sessions: the startup overhead (after opening a project for the first time) in most cases will be reduced to a simple directory listing and modification time check - compared to a full scan, this adds almost nothing to overall IDE startup time.
Make the persisted cache stale during revalidation: experienced startup time will be literally zero. You will open your project and the todo-list will be immediately available. If the initial cache revalidation is still running, you can indicate this with the mentioned progress bar or spinner - but for most normal use-cases, you will immediately see what you saw the last time you had the project open.
I hope this is useful. I've been UX brained these past couple of years, after taking a UX design course, so I am hyper aware and easily annoyed by these things.
I hope I don't come off as crass. 😅 I promise, I am just trying to help!
Thanks for the work you put in to keep this extension alive! It is appreciated. 😊