6 ms·

I see lots of replies suggesting scrolling for a long time and then using CTRL+F. However, this won't work if the page is using virtualised scrolling (common w

I see lots of replies suggesting scrolling for a long time and then using CTRL+F. However, this won't work if the page is using virtualised scrolling (common with React et al. SPA for performance reasons, to avoid huge DOM trees as the page expands). The majority of content that is outside of the visible window will simply be unmounted from the DOM. I'm not sure what the best-practice for a webapp designer is here? Perhaps intercepting Ctrl+F and displaying a custom search that will do the correct filtering on the back-end and update/retarget the view? Azure DevOps does this but it's still frustrating if your focused element is not within the capture point for the event.

lonelappde 7y ago
Google Docs implements custom search. Unless web frameworks start to expose some basic controls to the user, like pre-walled-garden Operating Systems, that's what we have to wait for
Hello71 7y ago
that's what discourse does. it's frustrating because it's significantly slower than the built-in browser search, probably in part due to excessive network accesses, but also probably due to poor caching and inefficient implementation.
- 1wd 7y ago
  The custom UI is also IMO terrible. It's completely different than the browser Ctrl-F UI. It does not simply highlight and move to the matches. Instead it shows a "preview", so you have to navigate to each match separately and back to the search UI. And it just navigates to the matching comment, but for very long comments I still have no idea where in the comment the match is. Thankfully you can press Ctrl-F twice to get the browser UI.
- ekzy 7y ago
  I hate discourse's CTRL+F. When things like this happen I open the devtools and search in the dom, and it's a horrible experience too. I just don't want to learn each website's custom controls. Don't hijack my CTRL+F or my scrolling or anything else please!
AlchemistCamp 7y ago
That's a horrible UX. A better practice would be to avoid infinite scroll and better yet to think carefully before using a full-blown SPA for a standard UI. If it's a web page as opposed to a web app, there are certain UX features that every browser supports out of the box and many, many users with keyboards will expect.
dangerface 7y ago
> I'm not sure what the best-practice for a webapp designer is here? Perhaps intercepting Ctrl+F Oh god no, the solution is simple stop reimplementing the browser in the browser.
- matthuggins 7y ago
  Google Drive does this within Google Chrome, fwiw. I don't disagree with the spirit of your comment though.
  - ottomatias 7y ago
    I'd say Google and Algolia are the only companies with the resources and know-how in search that can even think of this. And probably even they shouldn't.
- blablabla123 7y ago
  The result can give a much better UX if done properly. (If done poorly it's just frustrating of course...) Just think of SPAs vs normal backend templated apps. The SPA can be much faster with poor network connection or when the data needed is large but unpredictable. Then the SPA can really shine, if routing is (re-)implemented well enough.
  - malux85 7y ago
    What about MX (machine experience)?
- Kaze404 7y ago
  I would agree, if the opposite didn't make the page unusable. Infinite scrolling doesn't really work if you don't unload what's on the screen (at least it didn't the last time I tried it, in 2014).
ceejayoz 7y ago
> Perhaps intercepting Ctrl+F and displaying a custom search that will do the correct filtering on the back-end and update/retarget the view? Stripe does this in their docs and I find it absolutely infuriating.
- beatrobot 7y ago
  You can also use Ctrl+G
mschuetz 7y ago
> Perhaps intercepting Ctrl+F Please don't ever do that. I know one site that does this and I hate it.
- Fnoord 7y ago
  Discourse [1], popular forum software, does this as well. [1] https://www.discourse.org/ https://www.discourse.org/
  - mercer 7y ago
    Not a fan either, but at least it allows you to repeat the keystroke to do a native page search.
  - Kaze404 7y ago
    This is infuriating. Every time I CTRL+F on Discourse I get upset.
    - efreak 7y ago
      At one point I had a user script that prevented certain key combinations from being intercepted. Worse than discourse is a hosting platform I was encountering frequently for a while, where pressing esc to stop the page from loading instead caused the website to switch pages to a login prompt for the site owner. Other offenders that annoy me include intercepting alt+d (focus address bar), Ctrl+n (new window, outlook captures this), Ctrl+t (new tab), Ctrl+a (select all), and other common keyboard functions. Fix: Just add a dummy onkeyup function to the document root and body elements, and set @match rules for whatever sites annoy you. Occasionally you'll also need the more generic event handler function as well.
- ultrarunner 7y ago
  Google Docs does this, e.g. in a spreadsheet. I think it's reasonable in that context. For what it's worth, if you really need to search e.g. "View" to figure out where the View menu is, the OS-native menu option still works.
sobellian 7y ago
GitHub does this in workflow logs and it makes it impossible to copy/paste logs greater than the number of lines in your view. Then you download the raw logs and every line has a timestamp so you need to write a shell command just to parse out the actual text you wanted to copy.
- blacksmith_tb 7y ago
  They also bind to the "/" to focus on their searchbox, which breaks the native behavior in FF (which would be a single-keystroke for Find in Page, at least meta-f still works). Google likes to do this too, e.g. Google Tag Manager.
jakub_g 7y ago
1. Open devtools. Disable cache. Reload the page. Go to sources panel. CTRL-SHIFT-F. Enjoy the JSON response. 2. Alternative: same but with web debugging proxy like Fiddler or Charles. Yep. For JS-heavy pages with virtual scrolling (i.e. removing from DOM stuff that is out of viewport) there's no better solution.
huebomont 7y ago
The solution is to stop re-writing basic browser functions. Just let me scroll.

lonelappde 7y ago

Google Docs implements custom search. Unless web frameworks start to expose some basic controls to the user, like pre-walled-garden Operating Systems, that's what we have to wait for

Hello71 7y ago

that's what discourse does. it's frustrating because it's significantly slower than the built-in browser search, probably in part due to excessive network accesses, but also probably due to poor caching and inefficient implementation.

1wd 7y ago
The custom UI is also IMO terrible. It's completely different than the browser Ctrl-F UI. It does not simply highlight and move to the matches. Instead it shows a "preview", so you have to navigate to each match separately and back to the search UI. And it just navigates to the matching comment, but for very long comments I still have no idea where in the comment the match is. Thankfully you can press Ctrl-F twice to get the browser UI.
ekzy 7y ago
I hate discourse's CTRL+F. When things like this happen I open the devtools and search in the dom, and it's a horrible experience too. I just don't want to learn each website's custom controls. Don't hijack my CTRL+F or my scrolling or anything else please!

AlchemistCamp 7y ago

That's a horrible UX. A better practice would be to avoid infinite scroll and better yet to think carefully before using a full-blown SPA for a standard UI. If it's a web page as opposed to a web app, there are certain UX features that every browser supports out of the box and many, many users with keyboards will expect.

dangerface 7y ago

> I'm not sure what the best-practice for a webapp designer is here? Perhaps intercepting Ctrl+F Oh god no, the solution is simple stop reimplementing the browser in the browser.

matthuggins 7y ago
Google Drive does this within Google Chrome, fwiw. I don't disagree with the spirit of your comment though.
- ottomatias 7y ago
  I'd say Google and Algolia are the only companies with the resources and know-how in search that can even think of this. And probably even they shouldn't.
blablabla123 7y ago
The result can give a much better UX if done properly. (If done poorly it's just frustrating of course...) Just think of SPAs vs normal backend templated apps. The SPA can be much faster with poor network connection or when the data needed is large but unpredictable. Then the SPA can really shine, if routing is (re-)implemented well enough.
- malux85 7y ago
  What about MX (machine experience)?
Kaze404 7y ago
I would agree, if the opposite didn't make the page unusable. Infinite scrolling doesn't really work if you don't unload what's on the screen (at least it didn't the last time I tried it, in 2014).

ceejayoz 7y ago

> Perhaps intercepting Ctrl+F and displaying a custom search that will do the correct filtering on the back-end and update/retarget the view? Stripe does this in their docs and I find it absolutely infuriating.

beatrobot 7y ago
You can also use Ctrl+G

mschuetz 7y ago

> Perhaps intercepting Ctrl+F Please don't ever do that. I know one site that does this and I hate it.

Fnoord 7y ago
Discourse [1], popular forum software, does this as well. [1] https://www.discourse.org/ https://www.discourse.org/
- mercer 7y ago
  Not a fan either, but at least it allows you to repeat the keystroke to do a native page search.
- Kaze404 7y ago
  This is infuriating. Every time I CTRL+F on Discourse I get upset.
  - efreak 7y ago
    At one point I had a user script that prevented certain key combinations from being intercepted. Worse than discourse is a hosting platform I was encountering frequently for a while, where pressing esc to stop the page from loading instead caused the website to switch pages to a login prompt for the site owner. Other offenders that annoy me include intercepting alt+d (focus address bar), Ctrl+n (new window, outlook captures this), Ctrl+t (new tab), Ctrl+a (select all), and other common keyboard functions. Fix: Just add a dummy onkeyup function to the document root and body elements, and set @match rules for whatever sites annoy you. Occasionally you'll also need the more generic event handler function as well.
ultrarunner 7y ago
Google Docs does this, e.g. in a spreadsheet. I think it's reasonable in that context. For what it's worth, if you really need to search e.g. "View" to figure out where the View menu is, the OS-native menu option still works.

sobellian 7y ago

GitHub does this in workflow logs and it makes it impossible to copy/paste logs greater than the number of lines in your view. Then you download the raw logs and every line has a timestamp so you need to write a shell command just to parse out the actual text you wanted to copy.

blacksmith_tb 7y ago
They also bind to the "/" to focus on their searchbox, which breaks the native behavior in FF (which would be a single-keystroke for Find in Page, at least meta-f still works). Google likes to do this too, e.g. Google Tag Manager.

jakub_g 7y ago

1. Open devtools. Disable cache. Reload the page. Go to sources panel. CTRL-SHIFT-F. Enjoy the JSON response. 2. Alternative: same but with web debugging proxy like Fiddler or Charles. Yep. For JS-heavy pages with virtual scrolling (i.e. removing from DOM stuff that is out of viewport) there's no better solution.

huebomont 7y ago

The solution is to stop re-writing basic browser functions. Just let me scroll.