Talk:DXR UI Refresh: Difference between revisions

Auto-checking case-sensitivity can be confusing, especially if that was a typo and the user later removes the upper case - not unchecking gives unexpected behaviour (adding and then removing isn't the same as nothing), but unchecking is also unexpected if the check was added manually. --[[User:Mook|Mook]] ([[User talk:Mook|talk]]) 22:35, 25 July 2013 (PDT)

:I agree. I'm inclined to omit all that automatic magic and simply provide an accesskey for the case-sensitivity control. Based on talking with users, the default should be case-insensitive, which is different from current behavior. How does that sound? --[[User:Erikrose|Erikrose]] ([[User talk:Erikrose|talk]]) 10:23, 26 July 2013 (PDT)

Maybe move the advanced disclosure toggle to the right of the bottom of the logo (and have the status text go to the right of that), for a taller click area?  I don't like to click targets less than about 20px tall... --[[User:Mook|Mook]] ([[User talk:Mook|talk]]) 22:35, 25 July 2013 (PDT)

:Perhaps. What you see there is about the 5th iteration of the disclosure control. I have another that's pretty decent, and it's easier to target—about 20x60 px—but I felt it was visually confusing. Hmm, what if we made the area of the bar immediately around the "advanced" caption higher, as if it had a tab? That would combine the best of each. I'll sketch it up and see how it plays. --[[User:Erikrose|Erikrose]] ([[User talk:Erikrose|talk]]) 10:23, 26 July 2013 (PDT)

If we really end up with >1000 results, do we still want to show all of them? (Contrast with what MXR does; this is mostly a "arghh my browser is too slow I should stop using Firefox" thing) --[[User:Mook|Mook]] ([[User talk:Mook|talk]]) 22:35, 25 July 2013 (PDT)

Would defaulting to searching in the current scope be useful? (The button can instead clear / reset the scope) --[[User:Mook|Mook]] ([[User talk:Mook|talk]]) 22:35, 25 July 2013 (PDT)

:Where that becomes confusing is in the file view: when you're looking at a single source file, what folder are searches scoped to? Here's another possibility. I suspect that a common search-within-folder workflow is to first browse to the folder, then do a search. We could stick some kind of "search inside here" control in the file-browsing area, and that would add path:whatever to the search field (and the advanced form, of course). --[[User:Erikrose|Erikrose]] ([[User talk:Erikrose|talk]]) 10:23, 26 July 2013 (PDT)

== File View ==

I find that the extra spacing between path components in the header makes it look nothing like a path; would it be possible to not have that excess padding, and rely only on text colour to make it look like the parts are clickable? The thing about copying is a good point though... but I'm personally more likely to copy from the address bar, on account of the keyboard hotkey to get there (I have no idea why I still use Alt+D) --[[User:Mook|Mook]] ([[User talk:Mook|talk]]) 22:35, 25 July 2013 (PDT)

:Some people copy from the viewport area; the spacing was a requested feature from them. Now that I've reduced the font size, does it appear less confusing to you? --[[User:Erikrose|Erikrose]] ([[User talk:Erikrose|talk]]) 10:23, 26 July 2013 (PDT)

The path pinning - heck, maybe even the search box pinning - should be using CSS media queries, and don't pin if the window height is too small? --[[User:Mook|Mook]] ([[User talk:Mook|talk]]) 22:35, 25 July 2013 (PDT)

:Actually, forget the pinning. Initially, I wanted to pin the search box, but I didn't write down my reasoning, and it seems like a bad idea now. There's nothing up there you'd constantly need to see while browsing results, and most other search engines don't pin. You can always get back to the top with a single Home press if you need to. --[[User:Erikrose|Erikrose]] ([[User talk:Erikrose|talk]]) 10:23, 26 July 2013 (PDT)