将搜索恢复为旧的实时搜索模式

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.
source

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.

3 个赞

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.

10 个赞

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.

Suggestions:
(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.

7 个赞

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.

6 个赞

This topic was automatically opened after 14 days.

我一直在努力适应这个新的搜索功能,我不得不同意 OP 的观点——这并不是一个进步。它更难使用,而且用户界面令人困惑。

3 个赞

我也有同感,不过我也想明确一点,我理解团队关于其原因的观点,并且我认识到这次更改还有其他显著的好处。所以似乎只是一个如何做得更好的问题,希望能在新的设计上进一步完善。遗憾的是,我现在没有具体的改进想法,否则我会开一个主题来讨论……

话虽如此,我也有同样的看法:

虽然团队不一定有义务回答,但我还是希望他们会回答。:grin: 不过这似乎不值得开一个单独的主题。

2 个赞