Yeah, that initial processing lag with 50 items is surprising. I was thinking about trying it for something similar with market research reports, but that's a bit off-putting.
You mentioned comparing it to Notion or Asana feeling snappy. I wonder if it's because those tools are dealing with simpler, structured data, while this is trying to map out conceptual links on the fly? Maybe that's why it feels different.
Have you tried with a smaller set, like 10 items, just to see if the interactivity improves? Or is it laggy even then?
The comparison to Notion's "simpler data" is missing the point. A proper trend engine should pre-process those conceptual links into a simple structure for the view. That's its job.
>Have you tried with a smaller set, like 10 items
If you need to drop to 10 items for basic interactivity, the module is broken for any real analysis. It confirms they're sending the full, unprocessed graph. A smaller set just hides the data model problem until you hit the next scaling wall.
That's a great example of payload bloat. I've run into the same thing where someone thinks "more data is better for the client" and attaches full documents to each node, when all you need for the layout is an ID and maybe a short label. The parsing overhead alone can lock up the UI thread for a noticeable second or two.
A move to a WebGL library would definitely help with rendering many elements, but you're right that it won't fix a bloated data model. It might just let you crash your browser with 5000 nodes instead of 500, ha.
Keep it civil, keep it real.
That's a really solid suggestion to test with a smaller subset to check for linear scaling. I've done exactly that in vendor demos with data-heavy tools.
You often find the initial load is slow because the system is trying to do all the work at once, but once it's loaded, interactions are fine. Or you find it's equally laggy at 15 items as at 50, which tells you it's a fundamental rendering or payload problem, not a scaling issue. That distinction is crucial for the bug report.
>Detailed feedback on specific interactions being "frustrating" is exactly what helps
Absolutely. I always tell teams to record a quick Loom video showing the cursor and a timestamp. "Click here at 0:42, wait 1.8 seconds for the tooltip" is impossible for a product manager to ignore.
buyer beware, but buy smart
Exactly. Spotting a `force-directed` graph library is a giveaway for client-side lag. Those libraries are famous for it when node counts creep up, especially with complex event bindings.
You can actually test the theory. If you open your browser's dev tools network tab during a zoom or drag, you shouldn't see any new calls back to the server. The lag is all local compute. That's the clearest sign it's a front-end bottleneck, and why a graph library version bump in the patch notes is the only fix that matters here.
Agreed on watching for library bumps in patch notes, but that fix can be incomplete. I've seen teams upgrade a force-directed library only to find the core lag pattern remained because the bottleneck shifted to their own custom event handlers or state management.
The cleanest test for a front-end bottleneck, as you alluded to, is the network tab. If there's no activity on interaction, the problem is client-side compute. But you should also check the performance profiler for long-running functions that aren't part of the core library, often from wrapper code that processes the entire graph data on every mouse move.
Latency is a liability
50 abstracts taking "way longer than I expected" is the real data point. That's server-side compute time, not just frontend lag. If their cloud bill spikes from unoptimized NLP jobs, the "Trend Detection" module won't be a module for long - it'll be a cost center they deprioritize.
Comparing it to Notion isn't fair. Compare it to the processing time of a comparable AWS Comprehend job on the same dataset. I'd bet theirs is 10x slower, which means 10x the cost. They're probably burning VC money on oversized inference instances.
show the math
Yeah, that sluggishness would really throw off my workflow too. I use Gantt charts all day and even a half-second lag when dragging a task makes me crazy, so I totally get your frustration with the graph not responding.
>I really want to like it because the concept is super cool
Same! For project planning, spotting those research gaps early could be a huge time saver. But if the tool itself slows you down, it defeats the purpose.
Have you sent them a screen recording? I've found that's the fastest way to get a vendor's attention on a UX issue like this.
That's a good idea about the screen recording. It's way more convincing than just saying "it's slow."
But it does feel like a weird catch-22. You're supposed to use this tool to be more efficient, but to report the bug properly you have to spend time making a video? Kind of ironic 😅
Do you think they actually watch those, or just forward them to engineering?
Oh, that network tab test is a great idea. So if there's no new call on a zoom, it's definitely a frontend issue. I'm still learning this stuff - would a library upgrade usually come in a normal patch, or would it need a bigger version change?