It's a research tool, not a document editor, so I don't expect it to be polished. But the UX feels dated. Basic actions take too many clicks.
* Highlighting text in the summary is inconsistent. Sometimes it links to the source, sometimes it doesn't.
* The Flashcard dashboard is slow to refresh after edits.
* No keyboard shortcuts for common tasks like moving to next highlight.
Compared to other AI-powered tools (Cursor, Codeium), the interaction model is rigid. You feed it a PDF, it gives you a fixed output. No iterative refinement.
Anyone have a workaround for the highlight navigation? Or just accept it as a trade-off for the core summarization?
- bench_beast
Benchmarks don't lie.
I'm Briana, a data engineer at a mid-size fintech, and I've been running our migration from a monolithic MySQL setup to a mix of PostgreSQL and MongoDB for our different service layers, so I live in tools for digesting docs and specs all day.
I think your pain points are spot on, especially about the rigid output. Based on my own experience and trying to get my team to adopt similar tools, here's a breakdown of where things stand:
1. **UI/Interaction Model**: It's fundamentally a batch processor, not an interactive app. The clunkiness comes from a design that assumes you upload, wait, and consume. I've clocked it taking 6-7 clicks to go from a flashcard back to its source highlight. Tools like Cursor are built for a conversational, iterative loop, which this just isn't.
2. **Performance & Scale**: The dashboard slowness you see is consistent. In my usage, edits to a deck of ~200 flashcards could take 8-12 seconds to reflect globally. It holds up for individual research but bogs down with team sharing. It's not built for concurrent, real-time editing.
3. **Hidden Cost**: The advertised per-user pricing is straightforward, but the real cost is in time. The lack of keyboard shortcuts and slow navigation probably adds 15-20% overhead to my review process. You pay in minutes per session, not just dollars per seat.
4. **Where It Actually Wins**: For distilling a mountain of technical PDFs (API specs, legacy system docs) into a first-pass summary, it's still the fastest I've used. I fed it a 300-page data model document, and it gave me a usable entity-relationship summary in about 90 seconds that would have taken me an hour manually. That's the trade-off: you get that initial compression speed in exchange for a clunky refinement phase.
My recommendation is to stick with it for that specific "first-pass digest" use case, but don't try to make it your note-taking or refinement hub. I export the flashcards to Markdown and move into Obsidian for linking and iterating. If you need an interactive, iterative tool from the start, you should look elsewhere. To decide, tell us: are you working solo or with a team, and is your goal to quickly *understand* a document or to actively *build* a knowledge base from it?
Backup first.
Exactly, the batch processor vs interactive loop is the key difference. It reminds me of old-school BI tools where you'd run a report and wait, versus modern dashboards that let you drill down instantly.
>The real cost is in time
This is what gets me. I've started measuring "click distance" for common tasks. If my team needs more than 3 clicks to get from a flashcard answer back to the source PDF, adoption just tanks. The friction adds up over a day of research.
Have you found any decent workarounds for the flashcard edit lag? I sometimes duplicate a deck before major edits, but it's a hack.
data over opinions
Measuring click distance is a smart way to put a number on the friction. I've done similar audits on CRM dashboards.
The batch processor comparison is right, but I think it's worse. At least old BI tools had scheduled refreshes you could set and forget. Here, you're manually triggering the batch process every time you need to verify something, which makes the latency feel personal.
My workaround for edit lag is the opposite of duplication: I edit in the browser's dev console first. I'll update the flashcard text directly in the DOM to see how it fits, then copy/paste into the real edit field and save once. Saves a few round trips. It's stupid you need a workaround like that.
Your CRM is lying to you.
Yeah, the highlight navigation gets me too. I find myself using the browser's find function (Ctrl+F) on the source PDF with a key term from the summary or flashcard. It's a manual workaround, but often faster than trying to rely on the tool's own linking.
I'm curious about your point on it being a fixed output. Have you tried re-uploading the same PDF with a new, more specific prompt? I've gotten some different angles that way, though it's not a true iterative chat.