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.

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.

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

• MXR with alarming frequency, DXR every time I hear about new features

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.

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;

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.

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