Bugzilla

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
> Hah, I wish! :) I'm not a big fan of accordions in general but it's probably a reasonable thing here given the use-cases won't usually involve switching between navigation and info often.

I think this is a general UX need we're going to have going forward, so it certain wouldn't hurt to try and do better.  Specifically, the problem is "I have this extra information that could be useful, but where can I put it so it doesn't hide information the user actively needs/wants, doesn't infuriate them, but they can also discover the information is available?"

Options I've tried so far:
- My initial approach pre-dating the fancy branch was the "mega menu" approach where each menu option in the traditional searchfox popup menu provides contextual information in an pane that's attached to the menu and appears to be part of the menu.
- [A pop-up menu with horizontal tabs](https://clicky.visophyte.org/files/screenshots/20180730-231245.png) (on the fancy branch) but where the mouse placement advantage was not yet implemented/optimized.  [github does something similar now but more optimized for the mouse](https://docs.github.com/en/free-pro-team@latest/github/managing-files-in-a-repository/navigating-code-on-github#jumping-to-the-definition-of-a-function-or-method).  The general feedback on this was that it occluded way too much of the source code people were looking at, so it would be better at the top/bottom or sides.
- [As shown in the attachment](https://clicky.visophyte.org/files/screenshots/20201026-113631.png) Showing info in multiple optional panes that at the top.  The panes are optionally present if they have data.  My goal here was to make it so that as you scrub over the searchfox default menu we'll restrict the visible pane to the one you're hovering over.  Extra panes that don't correspond to a searchfox menu item with a textual link would get an icon in a gutter at the top of the menu above the current options (and so all muscle memory is maintained).  I also figured there could be a way to persistently disable/collapse panes the user isn't interested in.  (The gray vertical bars are intended to allow for such toggling.)

Example for that:
```
[ class diagram icon ] [ local calls diagram ] [IPC interaction diagram]
[ "Go to definition of Foo" / shows definition peek text on hover ]
[ "Go to declaration of Foo" / shows declaration peek text on hover ]
```

One of the things that's been clear about the current fancy branch approach is that the header at the top is not working either.  I've been trying in vain to try and make it work because I currently use 2 4k monitors with 2 side-by-side Firefox windows on each monitor, each using Tree Style Tab in the sidebar and with a `layout.css.devPixelsPerPx` of 1.25.  This nets me a `document.body.offsetWidth` of about 1291 and a `document.body.offsetHeight` of 1599 which doesn't leave much room on the sides, only on the top.  I think I'll have to bite the bullet and resize the active Firefox searchfox window to be more like 2/3rds of the screen at an offsetWidth of 1830 or full screen of 2827.  Then the panes can live in the super-duper navigation panel.

If we went down the road of scrubbing over the searchfox menu as a means of selecting info pane visibility, one can imagine then adding a "show other inclusions of this header" menu option which would correspond to showing all the dirty details about the header and its many inclusions.  I imagine the first menu option would still want to be "Go to this header".  In terms of showing the information about the header's inclusions when it's the file we're already displaying, perhaps we could make a menu show up when you click on the filename's breadcrumb, or perhaps to the right of the filename we put a little bubble labeled "(meta)" or we put one bubble per useful info panes we have for the file.  I know I've discussed with Simon how we might put things like "(coding guidelines)" up there for our DOM Workers & Storage components which have their own [more specific guidelines](https://firefox-source-docs.mozilla.org/dom/workersAndStorage/CodeStyle.html).

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
> Hah, I wish! :) I'm not a big fan of accordions in general but it's probably a reasonable thing here given the use-cases won't usually involve switching between navigation and info often.

I think this is a general UX need we're going to have going forward, so it certain wouldn't hurt to try and do better.  Specifically, the problem is "I have this extra information that could be useful, but where can I put it so it doesn't hide information the user actively needs/wants, doesn't infuriate them, but they can also discover the information is available?"

Options I've tried so far:
- My initial approach pre-dating the fancy branch was the "mega menu" approach where each menu option in the traditional searchfox popup menu provides contextual information in an pane that's attached to the menu and appears to be part of the menu.
- [A pop-up menu with horizontal tabs](https://clicky.visophyte.org/files/screenshots/20180730-231245.png) (on the fancy branch) but where the mouse placement advantage was not yet implemented/optimized.  [github does something similar now but more optimized for the mouse](https://docs.github.com/en/free-pro-team@latest/github/managing-files-in-a-repository/navigating-code-on-github#jumping-to-the-definition-of-a-function-or-method).  The general feedback on this was that it occluded way too much of the source code people were looking at, so it would be better at the top/bottom or sides.
- [As shown in the attachment](https://clicky.visophyte.org/files/screenshots/20201026-113631.png) Showing info in multiple optional panes that at the top.  The panes are optionally present if they have data.  My goal here was to make it so that as you scrub over the searchfox default menu we'll restrict the visible pane to the one you're hovering over.  Extra panes that don't correspond to a searchfox menu item with a textual link would get an icon in a gutter at the top of the menu above the current options (and so all muscle memory is maintained).  I also figured there could be a way to persistently disable/collapse panes the user isn't interested in.  (The gray vertical bars are intended to allow for such toggling.)

Example for that:
```
[ class diagram icon ] [ local calls diagram ] [IPC interaction diagram]
[ "Go to definition of Foo" / shows definition peek text on hover ]
[ "Go to declaration of Foo" / shows declaration peek text on hover ]
```

One of the things that's been clear about the current fancy branch approach is that the header at the top is not working either.  I've been trying in vain to try and make it work because I currently use 2 4k monitors with 2 side-by-side Firefox windows on each monitor, each using Tree Style Tab in the sidebar and with a `layout.css.devPixelsPerPx` of 1.25.  This nets me a `document.body.offsetWidth` of about 1291 and a `document.body.offsetHeight` of 1599 which doesn't leave much room on the sides, only on the top.  I think I'll have to bite the bullet and resize the active Firefox searchfox window to be more like 2/3rds of the screen at an offsetWidth of 1830 or full screen of 2827.  Then the panes can live in the super-duper navigation panel.

If we went down the road of scrubbing over the searchfox menu as a means of selecting info pane visibility, one can imagine then adding a "show other inclusions of this header" menu option when clicking on `#include`s which would correspond to showing all the dirty details about the header and its many inclusions.  I imagine the first menu option would still want to be "Go to this header".  In terms of showing the information about the header's inclusions when it's the file we're already displaying, perhaps we could make a menu show up when you click on the filename's breadcrumb, or perhaps to the right of the filename we put a little bubble labeled "(meta)" or we put one bubble per useful info panes we have for the file.  I know I've discussed with Simon how we might put things like "(coding guidelines)" up there for our DOM Workers & Storage components which have their own [more specific guidelines](https://firefox-source-docs.mozilla.org/dom/workersAndStorage/CodeStyle.html).