Closed Bug 895143 Opened 7 years ago Closed 6 years ago
Sources view groups should show the domain
We are forcing data that is organized in a directory structure (a tree*) into a 2 dimensional grouping in the sources. People know and are familiar with their web server's directory structure, but they are not familiar with the way we force this tree into sections with sources listed in each section. This leads to confusion. We should just display the sources as a tree and stop fighting against people's existing expectations by trying to represent a tree as a grouped list thingy. * Well, actually a set of trees: one tree for each host.
The initial argument for not choosing a tree was that "trees suck", however, I'm very much inclined to agree that, although they suck, they're unfortunately the "expected thing". If we do this, then please let's take this opportunity to create a base Tree view structure, because it bit us many times in the past where it was needed but wasn't available. At least the variables view and the sources view should use it. I can take on this endeavor if no one else desperately wants to.
(In reply to Victor Porof [:vp] from comment #1) > The initial argument for not choosing a tree was that "trees suck"[citation > needed], however, I'm very much inclined to agree that, although they suck, > they're unfortunately the "expected thing". Agree that they (or at least implementations of them) tend to suck, but strongly agree it is expected. I think one thing that often makes them sucky is that they tend to be implemented as collapsed-by-default, and I think that it would be a lot less sucky if you could actually see your files without having to expand a bunch of directories in a tree view before you get to them. > If we do this, then please let's take this opportunity to create a base Tree > view structure, because it bit us many times in the past where it was needed > but wasn't available. At least the variables view and the sources view > should use it. +1
While I agree trees are a better choice for showing sources, I would say they're not much nicer in some cases. Here's the same list of sources shown in Chrome's debugger. Compared to https://bugzilla.mozilla.org/attachment.cgi?id=760201 it looks all over the place, and it took me a while to expand all of those nodes. If we switch to trees, we need to somehow better address these cases.
I think usability could be improved in the current scheme if we displayed the directory/group URL as a tooltip on the group's label and added some UI affordances to expand and collapse groups (without going as far as adding recursive toggling, like a tree). I'm not saying that this is a replacement for a tree view, but I believe both approaches have their respective sweet spots: a regular web site (like the bugzilla example above) is better in a grouped list, but a very big number of sources is easier to navigate through using a tree. Stepping back for a bit, I think the problem with a tree is the lack of a quick overview (and the awkwardness and wasted vertical space when auto-expansion is used), whereas the problem with the grouped list is the lack of expansd/collapse toggles to customize the display when a big number of sources is present (like in chrome debugging). Such an improvement seems less work, as it is essentially an iteration on our current scheme, so maybe we should give this approach a shot?
(In reply to Panos Astithas [:past] from comment #5) Iterating on our current scheme certainly involves much less work. This shouldn't be the only argument for choosing what the final approach will be, but I tend to agree with you. There are downsides and advantages to both ways of displaying sources. Trees are very familiar, but quite cumbersome in most scenarios. Flat lists blur the underlying folder structure, but if you're not dealing with huge projects and carefully crafted directories, it doesn't matter that much. I think web developers care (or don't care) about the following things in their projects: * hand written js * generated js (almost a synonim to hand written js now that we have sourcemaps) * minified js (blackboxing helped a lot here) * markup * styling (granted, I'm talking about the finished flavor of a project, be it written by hand or generated) Let's put this into the "Project Maps" perspective. We don't have mapping techniques right now for generated markup (users probably don't care about that anyway, since they deal with what's generated directly, via the Inspector etc.). We do have source maps for stuff that compiles to js. We can do a better job with minified js and blackboxing. In case the Style Editor and Debugger are merged, a clear project "texture" emerges, and our sources widget should probably reflect that. Even if the potentially upcoming GLSL editor is merged, shaders fit well into this structuring algorithm. This is exactly what one of shorlander's mockups depict (minus the "img" group): https://people.mozilla.org/~shorlander/files/devtools/creation/DevTools-BuildTab-03-%28WebApp%29.png Long story short, if we're smarter about what groups are and what we put into them, style them accordingly and make them collapsible, I think users will be happy.
Maybe in the meantime we could switch from: http://i.imgur.com/EZC21Nf.png To: http://i.imgur.com/Jnh8YJI.png ? IE group by domain, show items with minimum number of directories required to make the item unique in its group.
Can you post a screenshot of how that makes the browser debugger look like? It seem OK for a small web site, but I wonder how it fares with more complex cases.
resource://gre/ and file:/// have a ton of items in them, but I still think this is better than what we currently have. Note that I only have a partial implementation, of what I have described + screencapped, and the last screenshot involved me using DOM inspector to change a value. http://i.imgur.com/PHiufRm.png
I like it. Users might lose some information in the case of smaller websites or prototype projects, but in that case structuring the items doesn't add that much benefit anyway, since there are not many files to look at in the first place.
Nick's suggestion in comment 7 seems much better to me. The current version does not map to my mental understanding of files at all, so I mostly ignore the left panel and use file name search. It would be even better if the file names in each group were sorted... but maybe that is a separate bug.
(In reply to Nick Fitzgerald [:fitzgen] from comment #7) Are you still planning to do this, Nick?
(In reply to Victor Porof [:vp] from comment #13) > (In reply to Nick Fitzgerald [:fitzgen] from comment #7) > > Are you still planning to do this, Nick? Nope, I only ever hacked up a prototype (and even then, I had to use DOM Inspector to make it how I wanted). I started looking into the source utils code and it seemed like too much work to do quickly. The problem is that we need to update existing source names as we get new ones. For example if you have only the following script: http://example.com/models/foo.js The debugger should show: # http://example.com foo.js But if we were to get a new script: http://example.com/controllers/foo.js Now the debugger should show: # http://example.com models/foo.js controllers/foo.js And I didn't spend enough time to figure out a clean way to do that renaming of "foo.js" to "models/foo.js".
Although I think we could use a trie like structure where host/each directory/filename/etc were stored in the trie instead of every single character, and then store them in reverse so the first lookup is filename, then last dir, then second to last dir, ..., then host. For the above example: foo.js models http://example.com/ controllers http://example.com  http://en.wikipedia.org/wiki/Trie
I was thinking we could just use the domain as a group, not go through all the splitting to construct the lowest common path.
(In reply to Victor Porof [:vp] from comment #16) > I was thinking we could just use the domain as a group, not go through all > the splitting to construct the lowest common path. I'm down as long as we do the splitting in a follow up. Otherwise, we will end up with this in the debugger: # http://example.com foo.js controllers/foo.js Which is really horrible. Especially when you add "views/foo.js" and "routes/foo.js" etc. What is the "foo.js" without a prefix?? You have to look at every single other "<dir>/foo.js" and figure out which one is missing. Really gross.
(In reply to Nick Fitzgerald [:fitzgen] from comment #17) > Which is really horrible. Especially when you add "views/foo.js" and > "routes/foo.js" etc. What is the "foo.js" without a prefix?? You have to > look at every single other "<dir>/foo.js" and figure out which one is > missing. Really gross. Oh the humanity! :) In this case it's easier to modify the label, since we have direct access to items, versus groups. As sources are being added, if another "foo.js" appears, the first one will be modified as well. In any case, this seems a bit easier than mucking about with the groups.
(In reply to Nick Fitzgerald [:fitzgen] from comment #17) > (In reply to Victor Porof [:vp] from comment #16) > > I was thinking we could just use the domain as a group, not go through all > > the splitting to construct the lowest common path. Mind if hack on this a bit, Nick?
[FWIW, the storage inspector will also most probably need a tree kind of thing with 3 levels of hierarchy (instead of usual 2 provided by sidemenuwidget)]
(In reply to Girish Sharma [:Optimizer] from comment #20) My quick thought about this is that one could do something easy like this: - storage type 1 -> side menu widget --> stuff - storage type 2 -> side menu widget --> stuff ... There's no good reason to keep adding functionality inside the widget. It can be elegantly wrapped.
Feel free to hack on this. dcamp also has a really nice tree widget in itchpad that would be perfect for this.
Flags: needinfo?(nfitzgerald) → needinfo?(dcamp)
Separate bugs for tree views are warranted.
OS: Mac OS X → All
Hardware: x86 → All
Summary: Sources view should be a tree → Sources view groups should show the domain
Assignee: nobody → vporof
Status: NEW → ASSIGNED
Attachment #8343110 - Flags: review?(past)
Comment on attachment 8343110 [details] [diff] [review] dbg-domain.patch Review of attachment 8343110 [details] [diff] [review]: ----------------------------------------------------------------- This is definitely an improvement! I couldn't find any issues with the patch in all of my testing.
Attachment #8343110 - Flags: review?(past) → review+
(In reply to Panos Astithas [:past] from comment #25) > > This is definitely an improvement! Thank you Panos :)
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
You need to log in before you can comment on or make changes to this bug.