Re: [w3ctag/design-reviews] Find-in-page API(s) (#236)

Here's some early thoughts after reading through the spec (these may not be consensus positions):

I totally understand the use case from the individual site developer's experience--when the site wants to customize the Find-on-page experience to tailor it to the site's specific use-case, it is useful to be able to universally recognize the user's intent to start a "find" action, and try to take ownership of this.

Another perspective to be considered is the end-user, who appreciates a consistent experience coming from their browser UI. When an action is taken in the UI, but the browser doesn't respond as expected, this erodes the user's confidence in the browsing experience. This happens not only with Ctrl+F, but also with other similar browser actions for which web sites provide an alternate experience (e.g., Printing, Context Menus, Save As). Other sites take the approach that a Browser's native experience is "broken" and try to suppress it; or view some Browser UI features as too revealing (e.g., suppressing context menus due to Developer Tool's View Source or Inspect options). In all of these cases, (via the keyboard) the website has the option to block the user experience. Sadly, sites can not be expected to always provide some equivalent functionality, which leads to user frustration (e.g., `e.preventDefault()` in your example, but no other code to enable a site-specific find + focus--or worse, the code is there, but doesn't work properly).

I like the concept of the event as a way to centralize all the entry-points by which a user can invoke the find-on-page UI, and because it allows a site to setup and expose a more rich 'find' service to the user in a consistent way. However, I disagree with the premise that the site should be able to hijack the browser's UI. When there is visible text on the screen, and the user activates find-on-page, they expect to use the Browser's find service to locate that visible text.

Furthermore, the use of an event, while the appropriate metaphor, is also a synchronous construct--I imagine while the event handler code is running, the expectation is that the browser would delay showing it's UI. This is intensely problematic as this enables a user-experience hang if the web page takes too long to respond (e.g., the code in the event handler is too slow/complicated). A non-blocking or asynchronous solution would be needed (but is also tricky assuming you want a "before"-style event).

Another potential problem with the design is figuring out what the timing of the event should be. Naively, it seems that the event would fire when the user invokes the find-on-page UI and that UI is not previously showing. However, often the UI is persistent and the key combinations for find-on-page (Ctrl+f) is used to re-focus the browser's "find" input box for follow-on searches. Should the event fire in these cases? What happens when the persistent UI is enabled, and the user switches tabs? Does the event fire immediately after tab-switch in the new tab? Is another event needed when the UI is disabled/cancelled, in order to keep the experience consistent with the browser's UI?

I prefer a model where the Browser's find-on-page and the web page's find service can work together without having to compete. While a complicated form of that scenario is out-of-scope (as noted in the explainer) a much simpler design could still be in-scope. For example, the web application could use the `openfind` event both as a trigger to enable page-specific find services, and also as a mechanism for the Browser UI to discover that the web page *has a find service* and, at a minimum, advertise this fact in it's UI. This, coupled with the inability to block the browser's UI, will ensure a consistency of user experience from the browser POV, and enable a service-discovery entry-point for the page's find service. Would love to see more exploration of something along these lines...


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/236#issuecomment-379126114