Is it worth it to re-implement the browser's find feature?

Question

I'm working on a web application in which users will occasionally have to search for various information in a log file. So users would go to this app, kick off a batch script, and wait for it to finish. If there are any issues, they might search through the log for some piece of information to help troubleshoot.

Here's my question - since the entire log will be displayed on the page, is it worthwhile to implement a custom search at the top of the page, or should users just rely on the browser's built in Cmd/Ctrl-F feature? A custom search feature would certainly be more visible, but might not offer any different/better functionality from what the browser already will.

(For the sake of this question, please assume that the user actually needs to search the log file. I realize there are far superior solutions that would move relevant error messages out of a giant text file, but for the moment we're stuck with this interface.)

Answer 1

Besides the obvious UI affordance of a visible search box, offering a custom Find solution gives you one big advantage over the browser-based find: control over the presentation of matches.

If most of your users are going to be looking for specific text in chronological order, a custom solution may not be necessary. However, implementing your own Find experience allows you to:

• Present more contextually relevant matches
• Autocomplete matches in the search box as the user types
• Offer advanced filtering and grouping of results

If 99% of your users are just going to be finding the most recent match, Ctrl+F may be sufficient. However, for more complex queries, strongly consider a custom solution.

Answer 2

Don't expect users to know shortcuts. If searching within the log file will be something users will be doing often, an unobtrusive search bar that accomplished this is the best answer. Though it sounds like your users are likely to be more tech savvy than the average person, here's an article that states that only about 1 in 10 internet users even know about Ctrl/Cmd+F: via The Atlantic.

Answer 3

In any case let your users know how they can search the log file. As stated before only 1 in 10 internet users know about the CTRL+F shortcut, so don't just assume everybody knows.

A visible "custom" search bar is better from a UX perspective (if it performs well), however it might not make sense for you to implement it, so instead you can make it obvious to the users how they can use the browsers built in search.

Answer 4

Some advice in addition to the points already mentioned: if you do implement your own, don't think of it as a re-implementation. Think of it as an addition. That means:

• Make sure the Ctrl+F version still works, and make sure it works well (so keep the text as basic HTML). Don't steal the ctrl+f shortcut.
• Choose a fundamentally different form for the search. Do not use modal popups like the old IE, or a search bar like modern browsers. You could try a sidebar search, perhaps with a list of results, rather than highlights that jump around the page.
• Find the features that you can add above and beyond the classical search. Tailor the search specifcally to your domain. There are many things you can benefit from. You know the exact for the text will take. For instance, if your log files contain Java code, you can do Eclipse-style code ocmpletion while the user types the query. You know the user much better than a browser maker, and you have a much better idea of specific use cases. They might be looking for a specific time, or a module, or an IP address.

So yes, there is a case to be made for implementing your own search, but make sure that the browser search stays available, and only do it if you're sure you can get it right.

Answer 5

The CTRL+F search in current versions of browsers perform search which treats the entered phrase as case insensitive and finds only exact matches, treating the text on the site as a one big object. Also it makes user "go to results" not "results go to user". I've implemented search on my page because:

• words user entered could appear in a single record in any order possibly separated by other words, but such records should still be considered as match. Mentally my users think about the content of the page as many separate records, and think that a record matches the query if it contains all the words.
• I wanted to hide all non-matched records, and show all matching records together, so user can compare them

You could easily see other cases where your search might need to work differently that browsers defaults. For example support for regular expressions (people who maintain logs might know what regex is) or custom fields/tags like in gmail (in:inbox has:attachment is:starred from:Hugo) or fuzzy search (as in Sublime Text).