Webtools/DXR User Research

Questions Asked

Which of the following two interfaces do you currently prefer and why? http://dxr.mozilla.org/ or http://dxr.allizom.org/

"A mix...

allizom is better in that there's no jarring shift-to-the-right as the menu goes in. It has the various boxes so I don't have to remember syntax (but see above on merging identifiers). It loads _slightly_ faster (I tried ""Jump to definition"" for NS_DECL_ISUPPORTS from both, via the definition of nsRunnable.) mozilla is better in that it can show macro expansions without going to a new page. This is mitigated though if I can quickly middle-click the link. Also, it does get points for actually letting me middle click... allizom just gets confused, because it wants me to left-click to bring up the menu, then middle-click the link instead. (Letting left-click cancel the link navigation and pop the menu would be better)."

Neither is a clear winner; DMO has clearer styling for the results and a menu that follows the view, DAO has find-as-you-type and nicer clickable identifiers.
My understanding is half the reason for DXR is to have intelligent searching for uses of a method, and I can only do that *without needing to know how to write out the query* with the latter. Plus if I don't write it out correctly, the failure mode might be that it gives me no results, but I can't always *know* when I get 0 results that it's just user error.
"dxr.allizom.org; the fixed search bar makes it _seem_ more useful ;) (Also, it doesn't break mouse wheel scroll if I accidentally set RequestPolicy to block loads from googleapis.com) Of course, the slow script dialog just popped up on the allizom instance here, left on a search.... sigh."

When using either of the services what is your main end goal?

Most of the time, find what's available on an interface (yes, that means *.idl, not *.h/*.cpp/*.mm/whatever, since I deal a lot with scripting languages). Typically I know what interface I'm looking for (e.g. "nsIWindowMediator") and just need to look up the method names and such.
Exploring code that I don't know well; finding all uses of code that I am modifying.
Mostly finding callers of some method, sometimes finding its implementation. Sometimes just browsing around, if I know the file I want to view. (I could open it in an editor, but then I have to deal with any changes I might have made to it, and sometimes I'm trying to see what the original code looks like.)
"Typically, either one of

  1) Find the IDL file for an interface to figure out what methods/properties are available;
  2) Look up the implementation of a method to figure out what the heck is going wrong in my code (or, frequently, somebody else's code)"

Do you ever use MXR or do you exclusively use DXR?

MXR with alarming frequency, DXR every time I hear about new features
Mostly MXR (basically force of habit with mxr.mozilla.org ingrained), occasionally DXR for more intelligent querying

Which aspects of the service do you currently love and why?

I used to love the ability to perform searches like derived:nsILoadContext, but that appears to be broken in both DAO and DMO (Derived searches no longer work on DXR). I love the incremental searches for DAO, the ability to limit searches based on the current results, and the speed with which results and source files appear.
Being able to find callers intelligently, without getting same-name results in unrelated code.
"The potential to be actually strongly supported by people, instead of seeming like just some random old cruft on life support. :)

It also seems to be styled a lot prettier than mxr. Being able to click on something and just have it search is also nice :D Unfortunately it sometimes doesn't tokenize correctly... no, I don't want to search ""CGAffineTransform);"" complete with the close-parent-and-semicolon..."

Which aspects of the service do you currently dislike and why?

It's slower than MXR; enough so to be frustrating in a papercut sort of way. This seems to be partially a client-end thing - i.e. it's not necessarily the network, just that it's doing too much on my end.
The RegExp field is broken on allizom (Regular expression text search) (it keeps inserting # all over the place, and... is that running client-side? because it just went slow-script-dialog on me, not to mention hanging Firefox...)
It doesn't understand XPIDL, JS, Python, Perl, ...
In fact, Python just errors out (it's probably trying to run it as CGI) (Random python crash)
Clicking the ""search"" button near the textboxes can often complain about no tree (i.e. it doesn't pick up the tree= query string in the URL)" (Search button on advanced search does not work DXR.a.o)
The lack of MXR parity (Bugs marked with mxr-parity); the completely unintelligible results for any non-plaintext search on DAO; the lack of example searches on DAO; (DXR Provide user guidance information on all pages)
dxr.allizom seemingly displays files in last-touched order, not alphabetical. The query box on allizom seems to only accept search queries; entering a path will show search results for the string but not open the file. Browsing and searching seem to be distinctly separate in the UI; I can't switch between the two easily. (Admittedly I can't with MXR either, but I have years of search-URL address bar muscle memory, so it's no longer a hindrance there.)
"Too much JS magic; that ends up more likely to be broken. Feels slower than mxr. (I have crappy machines, so more work on the client ends up doing that) I can't search anything but possibly-somewhat-outdated mozilla-central. (In my case, I'd like to search ESR, and sometimes CVS)"

Is there anything in MXR that you miss in the DXR service?

"- Tree-switching (though with the current pace there's too many trees people might be interested it, sigh)

- Speed. MXR is a heck of lot faster to load (due to simpler UI). It also does well at streaming results in. - On identifier searches, it lists definitions (things in *.h) first. I probably care about uses a lot less than what's available. (It would be nice to suppress forward declarations to later, though) - It understands (somewhat) XPIDL files (*.idl) better; it actually seems to parse it somewhat. - It has a single field for identifiers, so I don't have to think about whether I'm looking for a function, a type, or a macro. (If something is all three, it's probably too complicated) - MXR does regexp for path: searches."(Bug: Searching for a file giving its path pattern)

JS/IDL/JSM/etc. integration (linked identifiers, searches for GetFoo returning JS entries for foo, and more), case-insensitive results.

Any additional comments?

"I think I'd actually want to get this hooked into the address bar so I can have search suggestions as I go... That would be nice, but probably outside your immediate scope ;) (So I can start typing ""dxr nsIDOMWin"" and have it display ""dxr nsIDOMWindowUtils"" as one of the suggestions, even if I've never looked at it before) Oh, did I mention speed? ;)"
The lack of JS integration severely hinders my ability to use DXR on more than a trial basis.
"Yay! People care! :D Sorry if I sound negative - I like it, a lot! But I end up criticizing stuff I care about more than I do things I couldn't care less about."

High Level Feedback

Provide a consistent, uncluttered UI that is task focused.
Provide user guidance information on all pages but, the visibility of this information should be entirely user driven.
Advanced search options should be provided from the landing page.
Provide advanced short code search support for advanced users. Such as being able to search for derived:nsILoadContext
Ensure that DXR meets feature parity with MXR
When viewing individual files, provide filtering of functions and macros in side bar.
Bookmarkable URLS
Don't break the back button
Provide breadcrumbs (Bug: Having the path displayed when browsing a specific file)
Paginate results to improve performace
Decouple the front end from the back end and move the front end to Django/Playdoh
Provide consistent syntax coloring and clearer highlighting of search terms in results (Source code highlighting)