Webtools/DXR User Research: Difference between revisions
Espressive (talk | contribs) |
Espressive (talk | contribs) |
||
Line 16: | Line 16: | ||
* 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. | * 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. | * 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.) | |||
=== Do you ever use MXR or do you exclusively use DXR? === | === Do you ever use MXR or do you exclusively use DXR? === |
Revision as of 19:56, 13 November 2012
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.
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.)
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.