DXR UI Refresh: Difference between revisions

Jump to navigation Jump to search
1,279 bytes removed ,  22 November 2013
The wireframes are no longer out of date. Also resolved 2 Open Questions.
(→‎File View: Link to file tree menu.)
(The wireframes are no longer out of date. Also resolved 2 Open Questions.)
Line 124: Line 124:
* (3) Fix redundant "mozilla-central/search?tree=mozilla-central"
* (3) Fix redundant "mozilla-central/search?tree=mozilla-central"
* (4) I find the call graph information to be wrong some of the time, I have never been able to tell why. See this query for example: http://dxr.mozilla.org/mozilla-central/search?q=%2Bcallers%3A%22mozilla%3A%3AAudioNodeStream%3A%3ASetDoubleParameter%28uint32_t%2C+double%29%22. Do you have any idea what the source of these problems is, and if yes, is that on track to get fixed?
* (4) I find the call graph information to be wrong some of the time, I have never been able to tell why. See this query for example: http://dxr.mozilla.org/mozilla-central/search?q=%2Bcallers%3A%22mozilla%3A%3AAudioNodeStream%3A%3ASetDoubleParameter%28uint32_t%2C+double%29%22. Do you have any idea what the source of these problems is, and if yes, is that on track to get fixed?
'''As a result of the above, search UI in the following wireframes is out of date at the moment.'''


== Initial Page ==
== Initial Page ==
Line 146: Line 144:


=== Open Questions ===
=== Open Questions ===
* Should we add a textual signifier to the main search field when something other than ''text'' is chosen—<code>function:foo</code> rather than <code>foo</code>, for instance? There is little reason to support such syntax at all with the pop-up there, since you can select something from the pop-up at least as efficiently as typing out the signifier, assuming type-to-select in the user agent. If DXR grows to support arbitrary boolean expressions (<code>(function:foo OR function:bar) regexp:sme+p</code>), then syntax becomes more useful again. If we do decide to keep the syntax, we'll have to decide what to do with the menu if the user manually changes a signifier—change its selection, dim it, etc.
* Can we detect when a qualified name is entered and do a fully-qualified search only then? What of global symbols?
* Can we detect when a qualified name is entered and do a fully-qualified search only then? What of global symbols?
* I'm not thrilled with that one, big field doubling as a place for fancy, multi-term queries ''and'' the simplest of terms. It makes for a lot of complicated edge cases when the user frobs either the field or the other controls that feed into it. Google takes the easy way out, moving its advanced-search fields to a separate page, which doesn't do find-as-you-type. Also, it has only words to deal with; our terms are more complex, having a variety of filter types.


== Search Within ==
== Search Within ==
Confirmed users
574

edits

Navigation menu