895143 - Sources view groups should show the domain

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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.

Comment 1

[Victor Porof [:vporof][:vp]]

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"[citation needed].

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.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(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"[citation needed].

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

Comment 4

[Victor Porof [:vporof][:vp]]

Attachment: Screen Shot 2013-09-14 at 9.13.44 AM.png

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.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

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?

Comment 6

[Victor Porof [:vporof][:vp]]

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

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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.

Comment 8

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 9

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 10

[Victor Porof [:vporof][:vp]]

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.

Comment 11

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 12

[Victor Porof [:vporof][:vp]]

(In reply to J. Ryan Stinnett [:jryans] from comment #11)

Bug 883702.

Comment 13

[Victor Porof [:vporof][:vp]]

(In reply to Nick Fitzgerald [:fitzgen] from comment #7)

Are you still planning to do this, Nick?

Comment 14

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 15

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Although I think we could use a trie[0] 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

[0] http://en.wikipedia.org/wiki/Trie

Comment 16

[Victor Porof [:vporof][:vp]]

I was thinking we could just use the domain as a group, not go through all the splitting to construct the lowest common path.

Comment 17

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 18

[Victor Porof [:vporof][:vp]]

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

Comment 19

[Victor Porof [:vporof][:vp]]

(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?

Comment 20

[Girish Sharma [:Optimizer]]

[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)]

Comment 21

[Victor Porof [:vporof][:vp]]

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

Comment 22

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Feel free to hack on this. dcamp also has a really nice tree widget in itchpad that would be perfect for this.

Comment 23

[Victor Porof [:vporof][:vp]]

Separate bugs for tree views are warranted.

Comment 24

[Victor Porof [:vporof][:vp]]

Attachment: dbg-domain.patch

Comment 25

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 26

[Victor Porof [:vporof][:vp]]

(In reply to Panos Astithas [:past] from comment #25)
> 
> This is definitely an improvement!

Thank you Panos :)

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e7bcfaff073b