Webtools/DXR User Research
Contents
- 1 Questions Asked
- 1.1 Which of the following two interfaces do you currently prefer and why? http://dxr.mozilla.org/ or http://dxr.allizom.org/
- 1.2 When using either of the services what is your main end goal?
- 1.3 Do you ever use MXR or do you exclusively use DXR?
- 1.4 Which aspects of the service do you currently love and why?
- 1.5 Which aspects of the service do you currently dislike and why?
- 1.6 Is there anything in MXR that you miss in the DXR service?
- 1.7 Any additional comments?
- 2 High Level Feedback
- 3 Performance Analysis
- 4 Front Page Mock
- 5 Search Page Mock
- 6 Bugs
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)
- 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.