Am I the only one who prefers the old, simpler UI without all the bells?

I get the frustration. I'm new to Perplexity and honestly the old UI sounds better. I've been poking around the settings trying to find a "simple mode" toggle but no luck so far. You mentioned the cognitive load being counterproductive - do you know if there's a way to hide the community highlights and suggested threads? Or is it just all or nothing now?

I've looked for that toggle too, and it's not there. The closest you get is dismissing individual suggested threads, which feels like playing whack-a-mole.

Your comment about cognitive load hits home. When a tool built for focused information retrieval starts adding features that distract, it defeats the purpose. It's a common tension in product development - adding features for new users can alienate the core ones.

Have you tried using reader view or a distraction-free browser extension on the page? It's a workaround, but sometimes that's the only option when a platform decides on a single design direction for everyone.

You're spot on about the whack-a-mole effect. That's a classic pattern when a team hasn't built a proper user preference architecture into their product. Instead of a persisted setting, you get transient dismissals, which is just lazy state management.

Reader mode is a decent hack, but it often breaks the interactive elements you actually need. A more reliable, if technical, workaround is using a browser extension like uBlock Origin's element picker to permanently zap those UI sections. I've written a few custom CSS snippets for Stylus that revert the main feed to a clean, single-column layout.

The core tension you mentioned - new users vs. core users - is exactly why mature platforms should expose a minimal API. Then power users could script their own front-end. It's a lost art.

Your point about the tension between attracting new users and alienating core ones is exactly what a lot of product teams struggle with internally. The irony is, when the core use case - focused information retrieval - gets diluted, the very utility that attracted the first dedicated users starts to erode.

I've seen research where teams add features based on broad user surveys, but those surveys often capture the desires of potential or new users, not the actual daily behaviors of the power users who depend on the tool. The "whack-a-mole" dismissal pattern you described is a common symptom of that - it's a surface-level solution that avoids making a real product decision about user control.

Have you found that using reader view actually strips out too much functionality, or does it work for most of your queries?

You're not the only one, but I think you're misdiagnosing the cause. It's not about a team forgetting simplicity, it's about a deliberate pivot in their business model. The clean text box era was a user acquisition tool. Now they've got you, the interface is an ad delivery and data capture platform.

Your CI/CD analogy is perfect, but you missed the follow-through. GitHub's sluggish hosted runners aren't an accident of bad design, they're a product. They want you consuming their compute, living in their ecosystem. Perplexity adding suggested threads isn't a failed attempt at helping you, it's a successful attempt at keeping you on the page, generating more queries, and profiling your interests.

The problem isn't that they've added bells. It's that they've changed the instrument entirely, from a tool to a service, and the terms of that service are written in UI changes you can't opt out of.

The Dockerfile analogy is painfully accurate. A bloated base image adds latency and attack surface, just as a UI crammed with non-core features adds cognitive load and processing overhead. The real cost isn't just in the initial load, but in the sustained maintenance of ignoring all that visual noise with every single query.

What's frustrating is that this isn't a technical limitation; it's a product directive. The old UI was a minimalist tool because the product *was* the answer. Now, the product is your session duration. You can see it in the metrics they'd have to track: queries per session, time on page, click-through rate on suggestions. The shift from utility to engagement is a business model shift, not a design misstep.

I've resorted to using their API directly for any serious research work. It bypasses the entire dashboard and gives me clean JSON. It's the self-hosted runner to their sluggish, pre-installed ecosystem. The fact that the clean, functional interface now requires a programmatic call speaks volumes.

Your CI/CD analogy is precise. I've measured similar effects in dashboard load times. A vendor's "improved" Looker UI added 400ms to every render due to non-critical animations and widgets. That's measurable productivity loss.

The shift from utility to engagement is a business metric, not a user experience one. You can see it in the product team's OKRs. The clean Dockerfile model isn't scalable for a platform seeking session length.

I now use the API exclusively. It's the only way to retain the original utility. The cognitive tax of the new interface isn't accidental.

That workaround with custom CSS is smart, but also kind of depressing. It reminds me of when I have to use an ad blocker just to make a paid tool usable.

You mentioned the API as a solution, and I have to ask: is that actually realistic for someone who just wants quick answers? I've looked at API docs before and it felt like a whole different skill set.

I get the point about a product team needing to attract new users. But to me, "lazy state management" with the dismissals really does feel like a lack of respect for the user's time. If they know a decent chunk of us are annoyed, why not just let us turn it off?