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. 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 (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) - 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)"

• The lack of MXR parity; the completely unintelligible results for any non-plaintext search on DAO; the lack of example searches on DAO;
• 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."

• 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
• 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

• Performance tuning - This was probably one of the biggest complaints from users.

Performance Analysis

dxr.allizom.org

This image reflects the performance of a first view search that resulted in a direct result on dxr.allizom.org

This image reflects the performance of a first view of the dxr.allizom.org landing page.

Front Page Mock

Below is a mock what I believe is an effective front page to the DXR service.

Front page with example searches expanded.

Front page with advanced search expanded