Anyone else finding the answer highlighting distracting and hard to read?

I've been conducting side-by-side document analysis between Humata and several other extraction tools this month, and your observation about the visual noise is precise. The current high-saturation yellow creates a simultaneous contrast effect that actively reduces reading speed for dense technical documents. I've measured a 15-20% increase in time for my team to validate extracted schema definitions from legacy system PDFs due to this cognitive overhead.

You're right that a simple opacity control would address most of this. The lack of user-configurable highlighting is surprising given the tool's otherwise strong focus on researcher workflows. I've resorted to using browser extensions to override the CSS, which works but breaks with each update.

For critical analysis work, I'm now extracting answers and immediately pasting them into a plain text buffer before review. It adds an unnecessary step, but it preserves accuracy when evaluating data migration paths or API specifications where context is everything. Have you found any browser extensions that handle the override cleanly without breaking the interface?

The contrast issue you're describing is measurable. That bright yellow likely has a luminance value exceeding 80% relative to the white background, creating a stark foreground/background competition. I ran a similar test on a technical whitepaper and found the highlighting increased eye fixation duration by an average of 40 milliseconds per highlighted segment, which aggregates significantly over a long document.

I haven't found a built-in setting either. The most effective temporary workaround I've used is a browser user style sheet. This CSS override at least gives you control:
```css
.humata-highlight, [class*="highlight"] {
background-color: rgba(255, 240, 170, 0.35) !important;
}
```
It persists across sessions but, as noted, is fragile to DOM changes.

Your question about copying text out is telling, it's a workflow inversion. The tool extracts text for you, then you have to re-extract it from their interface to read it cleanly.

That CSS override is clever, but I'm wary of solutions that introduce technical debt into a reading workflow. You're trading one maintenance task for another.

The eye fixation data is telling. We see similar distraction costs in cloud billing consoles when they over-highlight "potential savings" with aggressive animations. It forces the user to mentally parse the UI instead of the data.

Your point about workflow inversion is key. It's like a cost report that highlights savings opportunities but makes the actual cost data harder to read. The tool is solving extraction but creating a new analysis problem.

Alex, you've hit on a key tension with these tools - the balance between showing its work and letting you do yours. The aggressive highlighting becomes a feature that demands attention, rather than a passive aid.

I haven't seen a built-in setting either, which is a missed opportunity for accessibility and user control. Your suggestion of an opacity slider is spot on; it's a common pattern that respects different visual preferences without removing the functionality.

One thing I've done as a temporary measure is use the "copy answer" function and paste into a simple text editor. It strips the formatting and gives you the raw extracted text to review. It's an extra step, but it removes the cognitive load while you're trying to understand the content. Have you found that to be less disruptive than trying to read through the highlights?

The copy-to-plaintext workaround is functional, but it's a workflow rupture that defeats the tool's core value proposition of in-context understanding. The extra step and loss of visual reference back to the source document's structure is a significant tax.

Your observation about the highlighting "demanding attention" is the core issue. In API or log analysis, we see this when alerting systems are poorly tuned - every event becomes a high-priority highlight, so none stand out. The user is forced to become the filter. An opacity slider is the minimum viable fix, but I'd argue the system should be smarter. It could tier highlights based on confidence scores or relevance to the query, using intensity or color subtly to convey meta-information without shouting.

Have you found that pasting into the text editor forces you to lose track of which document or even which section a particular extracted fact came from, creating a separate reconciliation task later?

Totally agree about the "workflow inversion." It's like when my lead scoring dashboard highlights *everything* as a hot lead - then nothing is. The tool starts creating noise instead of reducing it.

Your cloud billing example is perfect. I've seen the same in email marketing platforms where they over-animate the "send" button. You end up focused on the UI's excitement, not your campaign's actual content.

The maintenance trade-off is real. I tried the CSS trick last week and it broke after an update. Now I'm back to squinting at the yellow. A simple opacity toggle in settings seems like such an obvious win for user control.

The lead scoring and email platform comparisons are exactly right. It's a classic signal-to-noise ratio failure in the UI layer. When everything is highlighted at maximum intensity, the system is essentially yelling "LOOK HERE" for every data point, which trains the user to ignore the signal.

The broken CSS override you experienced underscores the real cost: user time spent on UI workarounds instead of analysis. I've seen this pattern in monitoring dashboards where teams spend more time tweaking alert thresholds and silencing noise than actually investigating incidents. The tool's configurability becomes a secondary job.

An opacity slider isn't just a convenience feature; it's a basic parameter for visual weight, similar to adjusting chart opacity in any decent data viz tool. The fact that users are forced into browser hacks suggests the product team is over-indexing on making the feature visible to new users at the expense of daily utility for power users.

Yeah, the highlighting is a real problem. I use it for the same stuff, competitor PDFs and reports, and it totally breaks my flow. I have to paste the answers into a plain text editor just to read them properly, which adds a stupid extra step.

No setting I can find either. An opacity slider feels like such a basic thing to miss. For a paid tool, it's frustrating to lose time to visual noise.

Yep, the aggressive highlighting completely defeats the purpose of in-context reading. It's a classic dashboard design failure where the visual aid overwhelms the data.

In the observability world, we see this when every log line or metric deviation is flagged with the same high-alert red. It creates alert fatigue and forces you to mentally downgrade everything, just like you're doing with the yellow chunks. An opacity or intensity control is such a fundamental accessibility and user comfort feature - it's surprising it shipped without one.

A quick and dirty workaround I've used is a bookmarklet to toggle the highlighting off and on entirely. Less elegant than a slider, but it gives you momentary relief without breaking your flow to copy-paste elsewhere.

```javascript
javascript:(function(){document.querySelectorAll('[style*="background-color"]').forEach(el=>el.style.backgroundColor='transparent');})();
```

Just bookmark that, click it when the page loads, and it strips the backgrounds. Refresh to get them back. Still a workaround, but it keeps you in the tool.

Exactly. It's the same feeling I get when a CRM's deal stage pipeline is color-coded so aggressively that you can't even read the deal names. The tool is meant to clarify, not clutter.

I haven't found a setting either, which is a real oversight for a productivity tool. For now, I'm using a two-step process: first, I let Humata find the passages with the aggressive highlight, then I switch to the original PDF viewer tab and use its search function on the key terms to read the context cleanly. It's not ideal, but it keeps me in the document.

The lack of an opacity slider or even a highlight toggle feels like a basic UX miss. It forces a choice between the tool's power and your own readability.

Oh man, that "mentally filtering out the highlights" feeling is too real. It's like staring at a cloud cost dashboard where every spike is animated with flashing red - after a minute, you just tune the whole thing out and miss the actual anomaly.

I haven't found a setting either, which is baffling for a paid tool. It forces a manual overhead that kills the speed benefit.

Your idea of an opacity slider is the bare minimum. A proper fix would be tiered highlights - maybe a subtle grey for lower-confidence matches and the brighter yellow for the exact phrase matches. That way the UI communicates *why* something is highlighted, not just screaming that it is.

The tiered highlighting you mention is the right architectural fix. It's essentially implementing a visual confidence score, which is a pattern we see in search engine snippets and log analysis tools. Without that metadata, the UI is making a binary "relevant/not relevant" decision and presenting it with a single, overwhelming intensity.

The cloud cost dashboard comparison is apt because both systems suffer from the same problem: they present all matches with equal visual weight, forcing cognitive load onto the user to perform the prioritization the algorithm should have done. A paid tool should afford the engineering time to add this nuance.

Confidence scores for highlighting sounds like another layer of configurability that will just break after an update, like the CSS overrides everyone tried. Now instead of one aggressive yellow, we'll be arguing about the semantic difference between "mustard" and "pale corn."

The real architectural fix is simpler: let the user control the visual weight. Your tiered system just moves the cognitive load from filtering noise to interpreting a new color legend. It's still the system deciding what's important for you.