Discourse search requests
-
Okay, I tried to find where this was already talked about. I really did. But the current search utility in Discourse is a pile of
. Here's a few of the issues I have with it:- It overrides the brower's search capabilitiy. And it doesn't even do it correctly. There's no opportunity to go to the next, or the previous match. It tries to highlight the match, but doesn't always do so successfully. For example, try searching for "sacrificed". Click on the match for "I'm A Grumpy Cat: An open letter to Alex". Do you see the match? Not unless you have a behemoth of a monitor, because the match is so far down the post that it's off the screen. Now we know that the match is in the DOM, but we can't use Ctrl+F to bring up the browser's search function to find it, because Discourse hijacked the shortcut. And Discourse assumes that taking us to the top of the post with the match is enough, so we have to scroll. Now, before you get your panties in a bunch, I know why you hijacked Ctrl+F, but you certainly did a bad job of it.
- It now requires me to indicate that I want to search within the current topic. If you are going to hijack my browser, at least start by assuming that I want to search where I am now. If I want to search everywhere else, I'll let you know.
- Searching is not reliable. Back in my first complaint, I asked you to search for "sacrificed", and told you you would find a result in the topic "I'm A Grumpy Cat: An open letter to Alex". Now try searching for sacrifice. According to every other search/find tool out there, "I'm A Grumpy Cat: An open letter to Alex" should still be in the result set, but it isn't. Now try searching for "sacrific". Suddenly, "I'm A Grumpy Cat: An open letter to Alex" is back in the list. What the hell? Does Discourse not know how to handle search criteria ending in vowels?
So here are my requests:
- Unless Discourse can implement a feature exactly as it is done in the user's browser, don't hijack the keyboard shortcut. Better yet, don't hijack any keyboard shortcuts from the browser.
- Start by assuming that the user wants to search in their current topic (this somewhat goes back to #1). If they aren't in a topic, then of course, search everywhere.
- Get the search to work right. If "sacrificed" brings up a result, "sacrifice" should bring up the same result. We shouldn't have to fight the search utility to figure out exactly what to search for.
Edit: paging @sam, @codinghorror
-
Now try searching for "sacrific". Suddenly, "I'm A Grumpy Cat: An open letter to Alex" is back in the list. What the hell? Does Discourse not know how to handle search criteria ending in vowels?
Triggering search in onchange event on textbox but not the checkbox I guess?
-
I agree that search is a little weird OR I just don't know what I am doing. It never feels like I am getting what I want. I actually bookmark topics or <3 things as a result because it is easy to troll my profile history and pick out the things I am looking for.
Filed under: 60 percent of the time, it works every time.
-
Triggering search in onchange event on textbox but not the checkbox I guess?
If that were the case, "sacrifice" should display the result as well, but it doesn't. And, based on my testing, the checkbox does appear to have an onchange (or, more likely, onclick) event tied to it.
-
Issue 1 is considered 'by design'. The others... probably not too far from 'by design'.
-
the current search utility in Discourse is a pile of
.This has been complained about since day 1, but I'm too lazy to go searching for it (even if search were reliable). @codinghorror and friends have fucked around with it since then, but whether they have (partially) unfucked it or fucked it up more is debatable. IIRC, hijacking CtrlF is a "fix."
-
Issue 1 is considered 'by design'.
I note that in the OP. I also note that it's a dumb idea.
-
The problem is, things that are 'by design' have a curious habit of staying as they are.
Filed under: see also infiniscroll.
-
I propose the following web design rule: If you are considering hijacking the browser in any way (e.g., Ctrl+F) STOP!! If you feel that you must hijack the browser, odds are very high that You're Doing Something Wrongâ„¢.
-
e.g., Ctrl+F STOP!!
I don't mind giving you a user setting to disable it, but .... the bigger issue is that lots of the posts (even stuff in the scrollbar) are not loaded.
-
I am thinking of a few things here.
- Stop using fulltext within topic (cause of stemming and other stuff) and instead just use a standard ILIKE search.
- Agree about selecting "search within topic" if you click ctrl f
Let's see where that takes us.
-
Does Discourse not know how to handle search criteria ending in vowels?
My guess is no stemming is done within search...
Stop using fulltext within topic (cause of stemming and other stuff) and instead just use a standard ILIKE search.
As if by magic...
Would http://tt-rss.org/redmine/projects/tt-rss/wiki/SphinxSearch be of any value in a future feature request?
-
Sam...I think you should bother with this later...Not a good time to change things ATM.
But think about this: On the search query window where it says to search more, break us out of the dropdown select textfield and take us to a 'search page' with some 'basic' and 'advanced' search mechanics so we can do more. You don't need to get ajaxy, just post back search results...
Unless someone you or others are opposed to this sort of thing. Not sure what the sentiment is on search tools.
-
Sphinx is interesting. ElasticSearch seems more apt though.
-
the bigger issue is that lots of the posts (even stuff in the scrollbar) are not loaded.
Here's an idea: why not put all the posts into one big text file. That should be subject to standard browser search...
Filed under: just add a noodle and JAM IT!
-
The FSM approves this post.
-
SpectateSwampDiscourseSearch
-
Here's an idea: why not put all the posts into one big text file.
Could maybe publish the relevant table(s) from the backup and people could use SSDS...
-
Sphinx is interesting. ElasticSearch seems more apt though.
Agree, but there is a bunch of history here. We picked pg originally cause it helped us reduce dependencies. Since then we are more lax about dependencies cause we now expect everyone to be on Docker.
My plan is to have a pluggable search backend so you can use multiple providers. (pg when memory is tight and elastic search when you have ample) ... pg does a horrible job in Japanese and Chinese so we leave a bunch of people with bad search.
-
Oh sure, I wasn't suggesting that you should drop native functionality from PGSQL for it. Going pluggable is an interesting experiment (see SMF on how NOT to do it, XenForo on an example of how it might be done sanely).
For Sphinx vs ES... that really depends on metadata more than anything else. If you're not juggling too much metadata around (i.e. user id, primary category id, topic/post ids, subject, body, or even two indexes, one for subjects and one for bodies) and you're not looking to store content other than posts, Sphinx will do just great. But if you're starting to juggle plenty of metadata (e.g. whether a topic is a poll or not without explicitly searching for ^Poll, or you want to plug attachments or something else in, e.g. via plugins), ES is probably a better fit anyway even if the memory requirements by comparison are steeper.
-
My main beef with sphinx is that it does not support live indexing (or at least did not 2 years ago), but ... on the other hand it is super light weight compared to a Java behemoth.
-
You can simply press ctrl+f twice if you want to override.
-
Eh? Live updates were added years ago. Real time additions were added in a limited form to Sphinx in 2010 and improved in subsequent releases.
-
If you feel that you must hijack the browser, odds are very high that You're Doing Something Wrongâ„¢.
I guess google docs is doing it wrong then. Can you email them to let them know? ;)
-
Real time additions
Yeah that was what I meant, sorry. I remember having to juggle a delta index, was a headache.
-
Google gets lots of stuff wrong. Gmail is the only email provider out of all the big ones where I can't figure out how to do basic things and actually have to ask someone for help.
-
I don't mind giving you a setting via a plugin, but the in page search is a bit crummy to say the least on Topics.
-
Also, did you, by chance, think about making the search scope implemented like tabs or a switch? Something like Bootstrap's radio buttons (scroll down to radio, though I believe you personally would be familiar with those)?
I think they would fit better in the visual style, and with good color choices I think they would make the intent more clear.
-
My guess is no stemming is done within search...
Stop using fulltext within topic (cause of stemming and other stuff) and instead just use a standard ILIKE search.
As if by magic...
Would http://tt-rss.org/redmine/projects/tt-rss/wiki/SphinxSearch be of any value in a future feature request?
Then this takes us back to my complaint that they hijacked the browser functionality. If I use the browser Find on Page to look for sacrifice, I find it whether it occurs as part of another word or not. The fact that they hijack a browser tool and then implement it in a completely different way is user hostile.
-
The fact that they hijack a browser tool and then implement it in a completely different way is user hostile.
I agree with you there and will fix it.
-
You can simply press <kbd>ctrl</kbd>+<kbd>f</kbd> twice if you want to override.
But you're still hijacking the browser and expecting the user to do something new to get at what they want. That's wrong!
If you write a desktop program, you try to use the keyboard shortcuts that are standard for your target OS as the users expect them to be. In Windows, that means Ctrl+C for copy, Ctrl+V for paste, Ctrl+X for cut, and so on. Beyond those OS standards, shortcuts are fair game. Likewise, when you are writing a web page, don't touch the standard browser shortcuts, because when you change them, you're screwing up learned behavior of your users, and also making them second guess things on sites that are Doing It Rightâ„¢.
From a user perspective, a web site doesn't exist in a vacuum. It exists in a browser, and you must play nice in that environment. Hijacking the browser's shortcuts is not playing nice. It's user hostile, and should be avoided at all costs!
-
I guess google docs is doing it wrong then. Can you email them to let them know? ;)
To every standard there are exceptions. Do I agree with the exceptions in Google Docs? I don't know as I don't use Google Docs. But to be honest, I would expect the shortcuts there to behave more like Word or Excel than IE or Chrome anyway, so that would probably be an exception. Discourse is not an exception.
Also, you keep pointing to big companies like Google when someone tells you you're doing something stupid, and saying "but they're doing it too!" Did you ever try that argument with your parents? Remember them saying "If your friends jumped off a cliff, would you do it, too?" In short, just because Google, or Adobe, or Microsoft does, doesn't mean it's right.
-
I agree with you there and will fix it.
I will wait to see the end result before issuing my thanks. Consider this my pre-thanks.
-
Also, you keep pointing to big companies like Google when someone tells you you're doing something stupid, and saying "but they're doing it too!" Did you ever try that argument with your parents? Remember them saying "If your friends jumped off a cliff, would you do it, too?"
Been on both ends of that conversation.
In short, just because Google, or Adobe, or Microsoft does, doesn't mean it's right.
Examples of Doing It Wrong can be found in all of those, and even if something one of them does is right for a particular situation, it doesn't necessarily meant it's right for a different situation. Google Docs is not a discussion forum, so using it as an example of how forum software should behave is odd.
-
But that doesn't stop people using it as justification anyway.
-
So I noticed.
-
People are dumb. I reckon people in general are the TRRWTF.
-
12.8. Testing and Debugging Text Search
12.8. Testing and Debugging Text Search # 12.8.1. Configuration Testing 12.8.2. Parser Testing 12.8.3. Dictionary Testing The behavior of a custom …
The behavior of
a customtext searchconfigurationcan easily become confusing.There ... I fixed it.
-
I haven't seen a text search engine that was any good and wasn't a total PITA to configure. (And I've done both Sphinx and ElasticSearch deployments. Sphinx used to be absolutely terrible. I still giggle at the number of people who want to run Sphinx on shared hosting though.)
-
I smell a great task for your two new interns...
Why don't you and Jeff give this project to them with a set of search touch points, sit back and watch the magic.
If I can create a set of search tools for mhsdoctors.com using stored procs and text file derived search criteria plus caching AND geolocation then I know your guys can do it too...
-
or Adobe
Adobe doing it would be even a counter argument. Like: Look, Adobe does it like this so that is obviously the wrong way of doing it.
-
I agree with you there and will fix it.
Please fix this, as well:Using OS-default bindings<a href"#fn_1">1, start searching. Now use the OS-default "find next".
You'll notice that not only do I get the Discourse pseudo-search box with my search term in it, but also the browser-provided, OS-integrated search box with my last search term.
Expected behaviour would be for the OS-default "find next" / "find previous" bindings would move the highlight to the next and previous incidences of the search term that's been given to Discourse.
In addition, I would also expect the "currently selected" instance of found text to have a different highlight to the rest, in order to show where you are on the page. I'd probably lose the dropdown / pop-over / whatever you're going to call it when searching within a topic.
I'd also expect to see how many results were found.
1 - I'm not going to expect you to make search work properly on my machine with my normal workflow, as I have the keyboard bindings remapped. However, you might want to consider that, should the user be able to remap functionality outside of the app you're running inside, you probbly don't want to touch that.
-
You can simply press ctrl+f twice if you want to override.
Is that documented anywhere?
-
-
Google Docs is not a discussion forum, so using it as an example of how forum software should behave is odd.
But he wasn't talking about forum software. @abarker made a categorical statement about browsers. Both google docs and discourse work in browsers.
I think the real lesson is that since we don't have real nested quoting, you missed some important context about the post.
-
Yup.
Like most of the other documentation then? Spread all over the place. When it does exist that is...
-
Hey some of us have to CYA the best we can.
Filed under: Don't judge me just because I scatter beam documentation across the interwebs.
-
But he wasn't talking about forum software. @abarker made a categorical statement about browsers. Both google docs and discourse work in browsers.
I think the real lesson is that since we don't have real nested quoting, you missed some important context about the post.
Yes, the context was missing, but I think you missed an important detail in what I said (@codinghorror, please re-read this, since you appear to have missed it the first time):
If you feel that you must hijack the browser, odds are very high that You're Doing Something Wrongâ„¢.
Notice how I didn't say that you are always wrong to hijack the browser, I said that "odds are very high" that you are. Translation: Most of the time, probably about 99.99% of the time, you should not hijack the browser. If you are tempted to hijack browser functionality, stop and think about why you want to hijack the browser, and determine if there is a better way. Your situation probably isn't in the 0.01% of cases where hijacking the browser is ok.
Edit: Grammar correction to fend off late-coming grammar-nazis.
-
but I think you missed an important detail in what I said
As a pedantic dickweed, I'll decide what the important details are.
Notice how I didn't say that you are always wrong to hijack the browser, I said that "odds are very high" that you are.
Who could possibly know this without nested freakin' quotes‽
Seriously, though, I think with the way discourse doesn't load everything, they probably need to hijack CTRL+F. But they need to make it work better than it does.
-
Seriously, though, I think with the way discourse doesn't load everything, they probably need to hijack CTRL+F. But they need to make it work better than it does.
I'm not going to disagree with the latter, as what they are doing at the moment is seriously broken.That said, please bear in mind that not all operating systems / applications use <key>CTRL</key>+<key>F</key> for search, and that the combination chosen might well be overridden by the user (it is, in my case), with the mapping undiscoverable for
a javascript application running in the browserjust another fuckin' website.Most of Disourse's actual problems, the bits that are really upsetting people, (as opposed to bugs, which are allowed) are due to overriding browser builtins. I'll leave it to you to work out why Jeff and his team of crack coders / crack smokers / pole smokers are overriding browser builtins.
