DXR UI Refresh

History

Once upon a time, Schalk Neethling surveyed the userbase and heuristically analyzed the UI, resulting in some nifty mockups.

Later, Erik Rose came along and did another round of wireframes adding these simplifications:

• Removing the front page, which not a soul remembers the reason for and which complicates the implementation and visually destabilizes the UI when it goes "poof". (I think the UI was inspired by Google. But, unlike them, we don't have other properties to advertise, so we don't need a place to park a navbar.)
• Teaching the query syntax via live feedback from the advanced search form rather than through written instructions. It's a little more JS, but users won't have to pogo-stick back and forth to a help page.
• Making a few improvements to the multi-tree story

Then Erik mailed dev-platform and got tons of feedback about what they need from DXR and what their usage patterns are, and he realized that the textual query interface cannot be discarded; it is just too handy for custom keyword searches and search-box plugins. Erik, Schalk, Jonas, and rhelmer got together at the Santa Clara Mozilla Summit, chewed through all the dev-platform feedback and that from the DXR Innovation Fair booth, and came to the conclusions under #Plans_And_Priorities. The raw feedback is categorized and sorted under #Feedback.

Plans And Priorities

• We'll write a search query parser that supports Python-style quoting for regexes and everything else. Use double quotes or single quotes. Each can contain the other. If you really need to go crazy, you can backslash-escape the kind of quote you're using.
• Regex search will support barewords. If you need to use a pattern that contains a space or quotes, put it in single or double quotes (see above). There's no reason to require quotes all the time, since we don't need to hang a "replace" pattern off the end a la vi.
• Advanced search on a separate page OR modally mutually exclusive with textual search (so we don't immediately need a JS query parser, though we could add one later and remove the modality). We'll have examples of what each advanced field takes in dimmed text in the field, demonstrating a few of the interesting features: for instance, '"main(const int, ...)"'. Upon submitting an advanced search, you'll get a search results page with the equivalent textual search, a la Google. That'll teach you the textual syntax so you can go faster next time. (It also saves display space, which our users are rabid about.)
• Improve our filter names so they're shorter and more memorable ("subclass" vs. "derived").
• Take the "l" out of line-number URL fragments. It looks like a 1. You can just start them with numbers.

Our next step is to comb through #Feedback and design product changes around them for Q4. We're looking for quickly deliverable improvements that will advance us toward retiring MXR.

Feedback

Here we've collected user feedback, largely from the dev-platform thread. We use the following numbers (and letter) to rank items with regard to MXR retireability. These express nothing about difficulty. Order of attack will of course take this and other factors into account.

1. Must have. Everybody will be mad otherwise. Not having would be silly. MXR retirement blocker.
2. Must have for >= 10% of the audience. Likely MXR blocker.
3. Can wait but should get to to feel proud of the project. Might be able to turn off MXR without it.
4. A useful thing for later
5. A rare edge case, out of scope, or there's probably a better solution

B: Behind the scenes. A non-user-visible change that will enable other changes.

More Trees, More Often

• (1) Index multiple trees (starting with comm-central and mozilla-aurora, the most commonly used ones on MXR. The UX branch has been requested, too.) (some impact from IT, possibly) - this is a blocker for turning off MXR
• (3) "Right now I think mxr updates from mozilla-central faster than daily. I've used that on a number of occasions to figure out what has broken my build/patch."

Search

• (1) Move to a line-based search, as proposed in https://github.com/mozilla/dxr/pull/161#issuecomment-25201532.
  • This should solve jruderman's need to sometimes load all the search results onto the page and then cmd-F through them.
• (2) A way to semantically include double quotes in the search string: the parser shouldn't always eat them.
• (3) Just typing a filename (or path segment?) without a path: specifier should find files by name or path.
  • [Should be solved by ^^] Trying to find files is hard. (Still haven't figured out how to get easily from the main page to Navigator.cpp on dom/base)
  • [Should be solved by ^^] A basic "file:" keyword hint with simple wildcard globing could do most of it well enough, I think... "file:*.css", "file:nsILogin*", "file:/test*". (We already search for "path" matches as unanchored substrings. We just need to add the globbing. Why this isn't super slow I don't know.)
  • [Should be solved by ^^] As a jump point when I know a filename (eg, "nsILogin", click search, click the particular IDL I wanted).
• (3) Better ranking: if you type an exact identifier name, put the definition at the top. (If we implement "id:", this is easy.)
• (3) Stop differentiating between macros, functions, consts, etc.: just find me an *anything* called "fred". People coming up to the booth were confused that they had to know the kind of target.
• (4) Search just within strings, for error messages and such.
• (4) Let us structurally query stuff that gets #ifdef'd out on x86, like ARM stuff.

Indexing

• (3) Better support for JS, Python, etc.
  • Remove the C++ assumptions from the core so we can support structured queries on other languages. Python keeps coming up. Java and Scala did once as well. People mentioned JS a long time ago.
• (4) Merge multiple build configuration databases somehow.
  • The code base is compiled for multiple platforms. Currently I cannot find the functions which are defined on ARM unless we use a search as we used to do on MXR.
• (4) Include Doxygen/Javadocs-like documentation. For C, C++, IDL, Java, JS, etc.
• (5) Support for generated files in indexing

Blame/VCS integration

• (4) Diff between trees
• (4 - Does MXR offer this now? yes -MattN) Be able to refer to specific revisions of code somehow, so links don't rot.
• (4) Be able to refer to certain ranges of code.
• (5 - Shouldn't we delegate to hgweb or github for this?) Blame integrated into main file view
  • Be able to navigate blame history better, stepping back and back in time until we find the change we were looking for.

Other

• (4) Support for image browsing would be super helpful for front-end stuff.
• Compare http://dxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/icons with http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/icons/
• (5) DXR gives a nice contextual navigation, but the size of the code base is overwhelming to have a clear understanding of what is going on. One of the thing that I am looking at in general is to understand the conditionals which are giving a particular result, or the consequences of a statement. Such overview is hard to get when you have ~30 DXR tabs opened. I would love to have a graph overview of these relations, as well as seeing the conditionals/guards as part of the graph.
• (huh?) "cycleCollection" on the right side may or may not do something useful. In most cases it just ignores all the stuff, so it might be better to not have it at all.

UI/UX

• (1) Docs (mostly user-facing) about how the query language is spelled and what it means
• (1) Don't require delimiters around a regex when entered into the Advanced Search Regex field
• (1) In the new UI, keep a text-only representation or some other way to be usable from custom search plugins or URL-bar keywords.
• (1) Optional case sensitivity
• (1) The Navigation pane, also something which shows up apparently at random, should be more predictable and should have whatever kind of disclosure control we decide upon for the Advanced Search form.
• (2) Mook (and Dave Townsend) switches trees a lot while looking at a single file in MXR. He'd like to be able to do that without losing his scroll position, as it typically lands him at a similar-enough place in the code that he can reorient himself. We'll add a tree switcher to the navigation panel, which appears when a file is being viewed. The nav panel will be pinned.
• (2) When navigating down the directory/file tree, it keeps autofocusing the search field, which is super-annoying if you're using keyboard-only navigation (with quickfind and enter) to do the traversal.
• (3) Enable integration with IDEs. I'm scoping to not include writing any plugins, but we should at least expose a well-documented public API. Then we can see what develops. We've had interest from a couple directions on this.
• (3) Change line-number fragment from #l5 to just #5. Lowercase Ls look like ones. (easy)
• (3) More obviously indicate when the search results are out of date. Dim them?
• (4) Count of search results, so we can use DXR to gather continuous metrics
• (4) Direct results: some love them, some hate them (because they just want to see the file pathname (don't we show that with the file? Is it bothersome because it's slow to load?))
• (4) Show context around results (with a clickable control? by saying "context:3[lines]" in the query? show the entire statement?)

Just Bugs

• (1) Clicking on macros seem to lead to some results, but definitely not the one I'd expect - the definition of the macro.
• (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?

As a result of the above, search UI in the following wireframes is out of date at the moment.

Basic Search

• The basic search panel gets an always-present case-sensitivity checkbox, with an accesskey so it can be toggled quickly and without leaving the keyboard.
• A pop-up menu exposes most of the 24 filter types. Users no longer have to check a manual (which never existed) or the source code to see what's available. Also, the presence of a single menu encourages the use of only one filter per query, which is all that makes sense with most filters. (Filters that do make sense in combination with others are available in the advanced search panel.)

Initial Page

DXR's current front page goes away, replaced with a code-browsing view. If we'd like to add a tree description page, a la MXR, we could do it at the root of the browsing hierarchy. Breadcrumbs make clear where you are in the tree and are separated from the search panel to make clearer that browsing location has no effect on search scope.

Advanced Search

Currently, nobody understands when the advanced search panel shows up. It seems rather random. Now, it'll always be accessible via a disclosure control on the basic search panel.

Open Questions

• Should we add a textual signifier to the main search field when something other than text is chosen—function:foo rather than foo, 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 ((function:foo OR function:bar) regexp:sme+p), 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?
• 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 Results

File View

Drill-Down Advanced Search: A Dead End?

This style lets you start a search quickly, without a lot of up-front thinking about constraints or DXR syntax. Like a web search engine, it returns a mixture of matches, across various filter types, and invites you to drill down further if you don't see what you want.

Problems

• If we divide the results by filter type, we can't also divide them by extension or path, unless we hierarchalize, organizing extension subdivisions under filter-type ones. But what if we combine the interactive approach with an explicit couple of disclosable fields for truly extradimensional filters? If somebody loves that, I'll sketch it.
• Any symbolic-filter result is also going to show up in the plain-text result section. Should we de-dupe or something?

Notes

• As now, Caller or Bases or Members results would show once the query matched a full function or class name.

In the end, this style has some nice things going for it, but I think it takes too much clicking around for the tastes of our audience. Plus, it would likely be lower-performance than the current system, at least without redesigning the data storage. Finally, we're not a web search engine: our users have a pretty good idea what kind of entity they're searching for up front, and making them sort through a bunch of noise to specify that constraint (along with tolerating the mental switching inherent in dialogue) strikes me as impolite.

Gallery of Unwanted Advanced-Search Widgets

Just for fun, here's a slagheap of discarded advanced-search disclosers. :-)