how to make searching/filtering from homepage richer?

[brainwane]

William Ray Wing writes:

I do see the list of filters, but I only get it AFTER I’ve entered my first search term. I may be an outlier here, but I find that an unfortunate bit of UI design. I suppose it is deliberate in that the filters can then be used to narrow search results, but if I know going in that I’m only interested in a particular set of results, I’d like to be able to apply that filter to my first search.

Thanks,
Bill

I'm asking for more info here and checking whether this is connected to #3454.

[brainwane]

Clarifications in this followup: the home page includes an invitation to "search" or "browse" but there's no filter list on the front page, which means Wing cannot simply apply the filter to his first search.

I wonder if #727 would help here -- as soon as the user starts typing, one of the lookahead menus we provide could be for structured/faceted filtering by classifier.

[emmatyping]

I'm not sure if this deserves a separate issue, but one thing that I would love to be able to do is hit a key and have the cursor focused on the search box (https://crates.io uses s which seems logical, but other keys would likely work). Thank you so much for making pypi so awesome!

[miketheman]

one thing that I would love to be able to do is hit a key and have the cursor focused on the search box

This functionality was added in #10395 with the / key (similar to GitHub)

[treyhunner]

one thing that I would love to be able to do is hit a key and have the cursor focused on the search box

This functionality was added in #10395 with the / key (similar to GitHub)

I'm using a Dvorak keyboard layout and the implementation of this feature doesn't work on my machine (Ubuntu Linux in both Chrome and Firefox).

To clarify: hitting the z key works to start search, as the physical / key on my keyboard is mapped to z in Dvorak. It looks like the implementation of this is using a physical keyboard layout so non-QWERTY layout mappings act unpredictably.

[miketheman]

It looks like the implementation of this is using a physical keyboard layout so non-QWERTY layout mappings act unpredictably.

The implementation is using JavaScript KeyboardEvent.code, see here:

warehouse/warehouse/static/js/warehouse/controllers/search_focus_controller.js

Line 23 in c195b21

if (event.code === "Slash" && event.target.tagName !== "INPUT") {

This maps to a physical key, not logical.

Would it be preferable to continue to use Dvorak z due to placement, or is it common to press / ?

[treyhunner]

Every website I've use / on used the non-physical mapping when I'm in Dvorak (GitHub, Gmail, etc), so I think that would be preferable. 👍

…

On Tue, Mar 7, 2023, 11:40 Mike Fiedler ***@***.***> wrote: It looks like the implementation of this is using a physical keyboard layout so non-QWERTY layout mappings act unpredictably. The implementation is using JavaScript KeyboardEvent.code <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code>, see here: https://github.com/pypi/warehouse/blob/c195b213d8e2fda6ef0d88d60ce006f8831ec681/warehouse/static/js/warehouse/controllers/search_focus_controller.js#L23 This maps to a physical key, not logical. Would it be preferable to continue to use Dvorak z due to placement, or is it common to press / ? — Reply to this email directly, view it on GitHub <#3462 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACFVKBWP3GWYLQ2P35M7MLW26FMLANCNFSM4EYA7SGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[miketheman]

@treyhunner fix should be live

[treyhunner]

That was quick. Thanks @miketheman!