Revert search to old live search pattern

This advice made me change my mind from ‘hate the new search’ to ‘it’s ok and I applaud the lower performance impact’. It would be fantastic if this advice would be shown in the placeholder, which now just says ‘Search’.


I will probably adjust to this, but I do have one minor thing.

I search for a word


Click on all topics and posts


Click on the only result and then I want to search within that topic, but I don’t get the “search this topic” after clicking on it.

The hamburger menu takes me to the Advanced Search and the only way I can get a prompt to search this topic is by putting a space after the search word.

Maybe I’m remembering incorrectly, but it seems that after clicking on a topic, I would get the prompt to search in the topic without altering the search word.


The reason why you aren’t seeing it is because the search panel is showing you the cached results from the previous screen. If you type something new in the input field, you should see the “search this topic” option.


Hm I see where you came from with this update, but I’m on the fence here.
My estimated behaviour would be:

  • when I’m on the homepage, the default search realm is “all topics”
  • when I’m in a category/topic, that is the default search realm

In both cases, I would like to see the results of that realm instantly without a second click - just like before. Changing the realm via 1klick is ok though.

The hack “just hit enter”? Yes this could work, but it rivals “show, don’t tell” and “don’t make me think” in terms of UX design.
The old search just felt snappier, more respnsive, more intuitive to use. Now I have to think about my behaviour.


Ok, I understand, I have to do the extra step of putting in a space. Thanks for your response.


I think this hack used by almost every website. Google, Youtube, Facebook etc… They just add some suggestion to the search but the process is same like Discourse search. I know this is unusual in Discourse but it is just a habit. I’ve got pretty positive feedback from my community about the new search usage. I think this is add some good benefit us in performance. :slightly_smiling_face:


Thank you for the reply.

The annoying hints, tags, and user listings seem to appear for the sole purpose of distracting attention from the fact that search no longer works (until additional user actions applied).

Yes, an extra press on Enter is not difficult. But why did the special search items appear on the screen? Does any ordinary user usually use them? I don’t think so. Right now, the pop-up tags and names of unknown users dropped down in packs is like an intrusive McDonald’s kiosk. I don’t want fried potatoes, but they offer them to me at every click.

Honestly, I would have been sympathetic to a pinned topic stating in advance that Discorse have to turn off live search because of performance issues. Those who own hosting have the option to stay on the version with the current settings for now.

But now there is no chance to roll back to beta6 or beta5. Rebuild crashes.

What does ctrl+enter do? I clicked when it appeared for the third time. There was nothing in the search box yet, so I was redirected to a blank screen with an error message.

I already sent the bug report about the cross-reference link bug today. You are right, there is such a problem. I wrote about hotkeys, that they are not so effective now, because there were additional clicks and I have to distract the screen to make sure that the keyboard arrow is selected the right option. Previously, the user didn’t care, because the default search in the current topic was off and it wasn’t easy to reach and enable it.


Oh, okay. Were most servers already struggling with Discourse’s search functionality as is?

1 Like

We have observed that pointless search work was the bulk of search work our servers did. Our servers did mountains of search work, on some sites it was the 2nd or 3rd most expensive route when it comes to total cost.

Our servers are very very fast, we can eat a lot of this pain. Self hosters on the other hand were paying a price that was way too high.

This is not in our plans, sure we will tweak and improve the design, possibly make the hinting richer and so on. However we have no plans to sail this ship back to the harbor.

Cheese has moved, I strongly recommend living with this for 14 days, providing feedback about little tweaks we can make to further improve the situation.

Cheese will not be moving back.


Thank you for the clarification. The problem is not technical. As a SaaS owner, Discourse pay is too much for pointless searches during a live search. Each user’s move has a cost. Because Discourse is open source, I agree with the statement that the maintainer should have fewer costs. As a community member, I have to support the development team.

Anyway, the previous version of the search was configurable. Currently, some options (by tag, by a user, etc) became active while they used to be disabled by default.

I’m expressing the feelings of my users because they are not in this forum. I suppose most active users here are admins, developers, or designers from their self-hosted installations, so I hope my feedback is useful.


this was how i first saw the new search box. In my mental model everything below the box are results. So the search button looked like it was another type of result. I think design guidelines should prevent this kind of situation.
From my intuition the search button should be on the right next to the search box. Instead there is this search reset button. I only recognized it exits just now.

To my surprise google is also like this. It also has this weird search reset button that I never realized existed. The difference is, that google at least clearly distinguishes the search button from the results.

I think discourse did many things right from a UX perspective. But there are also some odd things. Sometimes changes are an improvement and sometimes they are just changes.

I think the root cause for this is, that changes are done in an ad hoc manner without a design system that is based on clearly defined guidelines. It grew from the intuitive knowledge its creators acquired over the years. The paradigms behind the UI decisions are not clearly verbalized and are made in a quasi dictatorial fashion.


A design system would be fully dictatorial, no? When it comes to this change specifically, what guidance could a design system have provided?

Are there examples of this? If this ever comes up feel free to ask about it on Meta, there’s some reasoning behind every change as far as I know… but it’s true that we don’t announce the reasons for every change beyond the commit message that made the change.

We’re quasi-dictatorial in that we’re the ones who will make the final call on what makes it into Discourse (someone has to), but there are a lot of factors that are considered. Performance was already mentioned, but input from our customers plays a major role because Discourse wouldn’t exist without them. We also operate Meta to specifically gather this type of feedback from the wider community of self-hosters, and we’ll lurk #site-feedback categories on large sites (especially large migrations from other platforms) to get an idea of how things are going for regular users.


right now this reasoning is based on paradigms that are not verbalized for the most part. It is the result of intuition and the discourse with customers. This strategy will avoid regressions and catastrophes like the loss of a customer for the most part. But it has its limits. There is no clear scale against which progress can be measured. So pragmatic KPIs like “How many users complained about / praised the change?” and “did it achieve secondary goals like improved performance etc?” will decide if a change was a success or not.
The issue is: potential users and potential customers cant complain.
A user interface is like a language. Our ability to understand this language is influenced by the culture we got socialized in. If we don’t verbalize the underlying paradigms we employ while creating these user interfaces we will embed our culture into these systems. This means that they are easy to use for people like us but not necessarily in general.
Benefits a design system might bring from an abstract perspective:

Consistent appearance and interaction, maintaining a familiarity to the user, can reduce the difficulty of learning, cognitive and operating costs, and improve work efficiency.

By having clearly defined categories of user interface components this confusion between “data display” components and a user action (for which a button might be used for example) would not have happened. If there was a page like this where all the different UI components and their purpose was listed a rational discussion could be had. It would also be good if these discussions would be held in public and weren’t just communicated through git commit messages.


I just added a similar hint, but not in the placeholder. Given all the languages Discourse is translated in, a long string in the placeholder risks being cut off. Plus, as soon as you type, the placeholder is gone. Instead I went with a right-aligned hint in the search all topics/posts row:

This is also fixed alongside a few more minor bugs.

I will be working on a better solution for this use case, it’s on my todo list.


My experience of the within-topic search experience on meta right now is that it seems weirdly broken.

When I want to search within a web page, I’n trained to press ctrl F, type, and press enter. I understand why Discourse needs to hijack /enhance that for long topics.

What happens now when I press ctrl F on meta and type ‘theme’ into the search box is:

  1. it shows me a bunch of users (WTF) or tags (helpful)
  2. if I press enter, it shows me a bunch of other topics (WTF, I’m trying to search within topic)
  3. If I press “more” I lose the topic context altogether

My conclusion: you’re completely violating users trained expectations of how within page search works on the web.

(1) if the user has triggered search with ctrl F, default to within-topic search; but keep all topics search as default when the search is triggered in the way that other global navigation is.
(2) don’t show users by default, as mostly people are searching for topics.

I’m honestly puzzled why you used a sledgehammer for this nut; I’d have thought the performance impact of per-character searching could be handled by a 500ms delay before triggering search.


I am sorry, I am closing this for 2 weeks per:

Please open a new topic for constructive feedback around new improvements for the new paradigm.

This discussion has gotten off the rails.


This topic was automatically opened after 14 days.

I’ve been trying to get used to this new search, and I have to agree with the OP — it’s not a step forward. It’s more difficult to use, and it’s a confusing UI.


I feel the same, though I also want to be clear that I understand the points made by the team around the reasoning for it, and I recognize the change has other significant benefits. So it seems it is just a matter of getting it right, hopefully with further refinement on the new design. Unfortunately I don’t have any specific ideas for improvements at the moment, or I’d open a topic for the…

That said, I had this same thought:

While the team doesn’t necessarily have an obligation to answer, I hope they will nonetheless. :grin: Doesn’t seem seem to necessitate its own topic though.

1 Like