I'm having trouble designing a search box with two mandatory filters/categories before the user hit the "go" button.
So far, the best solution I could come up with was this one:
I've presented the following solution to my client, but they insist it's not ideal once the user would have to open up the split button and change the axis of their cursor and all of that, but I don't really see how this can be a heavy impact on the navigation. If it was all up to me, I would go along with this one, but they insist it's not the format they want, so forget about it.
Well... any ideas?
I imagine the default selection at the top is what they believe to be the most common, which makes sense to search in the current repo by default. An advantage I note in this is that it let's you switch without hassle. If I wanted to search "rails" in "All GitHub" (which makes more sense), all I need to do is press ↓ before hitting Enter. This means that switching the filter is just a single additional keypress.
Comparing this with other solutions:
You can try a scoped search dropdown before the search input field. This way the search button is Active from the beginning.
Lead with what your metrics show that the majority of users will want to search by, and don't make them pause to choose a filter.
If you have some metrics that make the case for the most likely search, users who don't see the filter, and just search will be rewarded.
Those who would search 'Fragments' (let's say it's the lesser of the searches), might not see the dropdown, and search immediately.
Probably not an ideal design decision — I mean I certainly wouldn’t do this, but since the client seems to be a bit of a stickler, I’m just throwing it out there as an idea.
Two search bars, one for each category, when the user focuses on one, disable the other.
Like I said, not a good idea, but I don’t see anything wrong with the other solutions you’ve already presented to the client, so it seems to me like the client doesn’t really want some that makes sense. Instead, they just want what they want, and they want you to just figure out what that is.
Maybe they want something stupid like this...?!
One good alternative: Search for both every time (if performance considerations allow), and present the results in two tabs "documentos" and "fragmentos". Foreground the tab that is known to be about the more frequent search (can be globally set, or a per-user setting). If performance is a problem here, execute the search filling the background tab only if it is actually clicked.
You could ask yourself how mandatory choosing really is and just search in both categories by default. You can then offer filters on the result page to refine the search.
If, as you say, the search terms are long anyway, the results might already be unique enough to yield what the users are searching for.
If you still want to give all options from the beginning, hide the filters under an advanced search drawer or something similar.