Would an inline page search field (ctrl + F) be useful or not to users?

Question

In our world of information overflow users turn to a popular search engine to find the specific piece of data/information/knowledge they look for. And it works most of the time, but users often need to scroll or scan the bits and pieces they are really after, when they access a page directed from the search result.

Technical experienced users (I consider myself as one of those) tend to use the inline page search tool CTRL + F to find whatever they need, faster. To the best of my knowledge, this isn't used by general business non-tech users who find themselves with sometimes endless of scrolling and scanning for whatever they're after.

Would it be a good (or bad) idea to add an extra UI element that does precisely what ctrl+F does, but not hidden for non-tech users?

To Clarify

The problem with search engines is that they give you the page and not the place in the page where the information users need are mentioned. That the real issue here – how can users quickly find the place in the page.

Microsoft train users to use hidden browser functionality

At least when downloading proofing tool of MS Office 2016

Answer 1

The Real Issue

But the Find function is already perfectly visible to users. It’s right there with other critical functions like Copy and Paste under… say, where did…?

You’re only scratching the surface of a bigger problem. For reasons not explainable by science, certain browser designers elected to hide the menu bar by default. They apparently felt it would be a lot easier for users to memorize secret keys combinations than to trouble the users with something as standardized and discoverable as the File Edit View menus. That design decision is embedded in a still larger UI trend to reduce discoverability, manifested by favoring icons over words, gestures over visible controls, and arbitrarily coding links.

Replicate Browser Functionality?

As for dealing with your small piece of the issue by adding a Find control to your web page, how would it be implemented? A blank at the top of the page could scroll out of view, which would make it awkward to find the _n_th instance of a string; I think Find-as-you-type would be infeasible. So, now you’re talking about an AJAXy light box or pane that doesn’t scroll, but that would have its own idiosyncratic interactions. Can that be done without confusing users, keeping in mind these are “non-tech” users? Will it throw off tech-experienced users who are expecting something just like Find, but end up with something somewhat different? Will your UI be consistent with my UI if I choose to do the same for my web apps?

This is the problem with replicating browser functionality in the web app: it's difficult to get something that works as well as the browser, and even then, it won't be fully consistent with either the browser or other apps.

Alternative

I think you might have better results educating users on the browser’s Find functionality, and whatever other functionality users should be using. This has the advantage that once users learn about the functionality from you, they can use it for any app/site, not just yours. If your site/app is used by a specific organization, maybe you can persuade IT to set browsers to display the menu bar by default, and/or show the Find icon in the toolbar (I’d be interested to know if that actually encourages more Finding).

If you’re making a web site where Find is especially useful, maybe try displaying the text “Find on this page = Ctrl-F” at the top of each page, perhaps right under the Search box. Or maybe have a space at the top for “tip of the day” (do those work?), which could also be used to educate users on other hidden browser features like Copy and Bookmarks/Favorites.

Answer 2

I don't believe Ctrl+F is that unused. It's a very basic shortcut available in a wide array of applications: browsers, text editors (from Notepad to the full Office suite), File Explorer, etc.

You also have to consider that it can confuse users. Currently, a search box on a webpage usually means "search this site."

Answer 3

You should ask yourself why. For five times.

You need a search box. Why? Because users don't know how to use Browser search feature. Why? Because it's hidden and you can't help. Why they need it? Because search engines won't link to specific page content but always to its beginning. Page is full of content and they have to scroll down to find what they need (this is true also for intra-site navigation).

That's enough...

Why it is difficult to find content on my pages?

You should first, before worrying for search box, work on this issue.

• Categorize data to allow quick scanning.
• Split data across multiple pages (it's more Search Engine + user friendly).
• Highlight more relevant/common topics at page top and provide link to scroll down (for an example pick any ScrollSpy plugin).
• Provide details on request. Keep unnecessary information hidden until user explicitly asks (click) for them.

If you're doing all your best to present information in an accessible way (both for your users and for Search Engines) but you need advanced search features then you may consider to use a custom search box.

Drawbacks and Benefits

Search feature within current view is widely available, almost every application with enough content will provide a search function.

Drawbacks

• You replicate an existing feature which (IMO, I don't have any test to refer to) is well-known by many users. Not everyone knows it but it's true for almost every feature. I'v been asked to add Print button many times but no one ever asked for a Search box (even in pages with long/complex content).
• Sometimes (but this is just my very personal experience) users know there is a feature but it's not part of their workflow to use it (it doesn't matter where you put it). That's why nowadays where search is available is also pervasive.
• Users will expect a full-site search. However they'll learn fast (especially if you add a placeholder text such as Search in this page). For example Facebook search box explicitly says where you will search.

Benefits

• You will make clear this feature exists also for the small (IMO) number of non-tech users that didn't already know it.
• You can add your own advanced search features (more on this later).

How

My answer is yes if (and only if) your page is really long and full of content. For short pages it will just waste space and make interface less clear. If you do it you should at least:

• Make it small enough to do not disturb normal workflow, it may expand when user clicks on it.
• Add a placeholder text to make clear where search will be performed.
• Use type="search" for search input. This will enable, where supported, specific features (and/or keyboard layouts).
• Do not forget to add navigation through matches (at least previous/next).
• Add your own advanced search features (1): Browser is limited to text content but your JavaScript may use HTML microdata and/or specific data- attributes to perform better searches.
• Add your own advanced search features (2): you may perform not exact matching. Think, for example, a long data page (let's say your photo editor user manual). User searches for colorisation, browser won't find a match for colorization but you will because you will detect at least common spelling errors (a simple string function like Levenshtein distance may be enough).

If you feel you do not need to include all those features then I think you should simply do not provide your search box. If you add something to your interface then it has to add enough value to justify its drawbacks.

Answer 4

I think that's will be a lot usefull for tech users, for example in a tech products ecommerce. A really good idea.

But I think the user that ask doesn't wants to duplicate SearchInPage browser function, the user may propose activate the ecommerce product searh box to launch a query to the engine.

Difficult to do because yo need to override CTRL+F browser behaviour.