Feedback on javadoc UI changes

Maurizio Cimadamore maurizio.cimadamore at
Wed Oct 9 20:27:01 UTC 2019

#3 is the one I prefer; it is subtle (compared to #2), offer some 
benefits (as Alex said) in terms of screen estate, and, indirectly put 
the search bar front and center, as it should be.

I wonder if there should be an 'up' button to hide the top bar even when 
you are looking at the top part of the page; but the autoscroll does 
what I'd like already, so that probably asking for troubles.

One nit (on #3) - it seems like if you start typing on the search box 
and some suggestions show up, the top bar doesn't show up, even if you 
reach the top of the page. Probably that's deliberate, mostly asking.

(tested on Ubuntu 18.04/Firefox)


On 09/10/2019 19:33, Alex Buckley wrote:
> On 10/9/2019 10:29 AM, Hannes Wallnöfer wrote:
>> The feedback we are looking for:
>> - What do you prefer for scrolling up and down a page? Do you find 
>> the moving parts useful or distracting?
> I find the motion of the top blue bar and search box distracting at 
> the first scroll, but only in the most minor way.
> I find the universal visibility of the search box to be very helpful 
> and useful in #1 and #3.
> I appreciate the extra screen real estate I get with #3 when the top 
> blue bar is gone. (What about in #2? See below.)
> People should remember that the search bar often contains overview 
> information of its own -- not on the top-level javadoc page, but on 
> module and class pages. Having that always visible is very useful on 
> module and class pages. It would be even more useful if the "SUMMARY:" 
> part on a class page had a "DESCRIPTION" link to get you back to the 
> top, like the "SUMMARY:" part on a module page has.
>> - Which version is best for navigating to an anchor within a page 
>> (e.g. member search or internal links)?
> I think #2 has a serious problem. If you scroll, and then hit any key,
> then the search box grabs focus -- this is useful on the many 
> occasions when you want to search, but it means that keyboard 
> shortcuts such as Ctrl-C are pre-empted. Specifically, if I select 
> text anywhere on the javadoc page with the mouse, then press Ctrl-C, I 
> see focus jump to the search box; if I then switch to another program 
> to paste in the copied text (to quote it in an email, say), then I 
> find the clipboard is empty, nothing was copied, Ctrl-C was 
> pre-empted. For this reason, I disregard #2.
>> - Do you experience any technical problems with your particular browser?
> No, everything worked as you described. Firefox 60 on Windows 10.
> Alex

More information about the jdk-dev mailing list