RFR: 8236935: Improve UX of the search control

Hannes Wallnoefer HANNES.WALLNOEFER at ORACLE.COM
Thu Jun 11 09:21:44 UTC 2020


Thanks Jon.

> Am 11.06.2020 um 03:14 schrieb Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> 
> Hannes,
> 
> Code looks good and seems to work OK.
> 
> It would be nice to see a version without the 5 second delay, but I guess we will see soon enough.  The 5 second delay makes clear that the index files are loaded for every page. I hope that once the files have been cached, we don't get any flashing from a message popping up to say that files are being loaded.
> 

I uploaded a version without the delay (i.e. with just the webrev applied):

http://cr.openjdk.java.net/~hannesw/8236935/api.nodelay.00/

I can’t seem to produce the „loading“ message or any kind of flashing once the index files have been cached, even when typing immediately after (re)loading the page. 

Tried in Firefox, Chrome and Safari.


> I agree with deferring the discussion on using a single index file. The original intent was to make it faster to load types, for which the perception was that these are probably the most common search items.
> 

Which makes sense. A possible idea would be to group the indices which are usually smaller (modules, packages, search tags) into a single file and leave the type and members indices as standalone files.

But that is subject to future discussion anyway.

> -- Jon
> 
> Separate/bonus discussion: triggered by thinking of the 5 second delay ... would it work to have a "debug mode" such that the generated docs may contain an extra page which can be used to set cookies for the API presentation, which can be used to "configure" search?

No sure how useful that would be in the case of the index loading delay. I guess I’d have to see other use cases to be convinced. :)

Hannes


More information about the javadoc-dev mailing list