I use narrow windows in my desktop workflow a lot and appreciate the responsive design. I get that this is still primarily a mobile flow but it would be great if you can continue to keep things working well for narrow desktop windows in any rework. Right now on the desktop a narrow UX mostly works but there are some gotchas. Most annoying is the search bar that only appears on click but not when pressing /.

I'd want to move these out of crumbs and into ApplicationMenu by default, that is any action link added to a page, also gets built into the mobile menu. Further since some pages have multiple sections of action links, we'd need maybe some label or dividers automatically built as well.

Alternatively could have a little menu on PHUIObjectBoxView appear on each section, though I can't imagine how to make that happen automatically.

Specifically, you want things like "Edit Task" in the application menu?

In the current design of Releeph, you can have 100 of them on a page. I don't have any test data and it's a huge pain to generate it, but roughly it looks like this:

+-----------------------------+
| Pull Request: More Pink     |
+-----------------------------+
| Author: epriestley | Accept |
| Revision: D123     | Reject |
|                    | Edit   |
|                    | Hotfix |
|                    +--------+
|                             |
+-----------------------------+
| This makes everything more  |
| pink, it is urgent and I    |
| promise it is very safe.    |
+-----------------------------+

+-----------------------------+
| Pull Request: More Violet   |
+-----------------------------+
| Author: epriestley | Accept |
| Revision: D123     | Reject |
|                    | Edit   |
|                    | Hotfix |
|                    +--------+
|                             |
+-----------------------------+
| This makes everything more  |
| violet, it is urgent and I  |
| promise it is very safe.    |
+-----------------------------+

+-----------------------------+
| Pull Request: More Indigo   |
+-----------------------------+
| Author: epriestley | Accept |
| Revision: D123     | Reject |
|                    | Edit   |
|                    | Hotfix |
|                    +--------+
|                             |
+-----------------------------+
| This makes everything more  |
| indigo, it is urgent and I  |
| promise it is very safe.    |
+-----------------------------+

<... 97 more of these ...>
`

Moving those actions into the application menu, even with dividers, doesn't seem great, since you'd see:

Accept
Reject
Edit
Hotfix
-----
Accept
Reject
Edit
Hotfix
-----
<... etc, 98 more times ...>

The use case for this interface (essentially, an actionable list view) is that release engineers at Facebook go through this whole queue before every push.

We don't need to keep the UI like that, but if we don't then we need to do something else with it before we can automatically move actions into the application menu.

Another less extreme case is the Diffusion edit interface:

In this case, the options are uniquely named and just shoving them into the application menu wouldn't be unusable, but we'd lose the relationship between options and editing them (instead of clicking the adjacent button, you have to go read through all the options). There are also still a fairly large number of options.

My proposed fix is to convert this menu to a button on mobile:

               New Button --+
                            |
                            V
+-----------------------------+
| Pull Request: More Pink  [=]|
+-----------------------------+
| Author                      |
|   epriestley                |
| Revision                    |
|   D123                      |
+-----------------------------+
| This makes everything more  |
| pink, it is urgent and I    |
| promise it is very safe.    |
+-----------------------------+

When clicked, it would disclose the options:

                   Click! --+
                            |
                            V
+-----------------------------+
| Pull Request: More Pink  [-]|
+-----------------------------+
| Accept                      |
| Reject                      |
| Edit                        |
| Hotfix                      |
+-----------------------------+
| Author                      |
|   epriestley                |
| Revision                    |
|   D123                      |
+-----------------------------+
| This makes everything more  |
| pink, it is urgent and I    |
| promise it is very safe.    |
+-----------------------------+

I like this approach because:

• It's technically easiest, and I'm confident I can execute it without duplicating DOM nodes.
• It handles the existing unusual cases gracefully.
• Keeping actions closely associated with their contextual objects/panels feels good to me.

That said, I'm not especially committed to it. Do you have ideas on the Diffusion and Releeph UIs if we move away from this plan of attack?

Diffusion would probably be OK without changes.

We could maybe just make Releeph work normally (require clicks into it to make changes) and then give it a fast-review workflow in Nuance eventually, although that feels reallllly iffy to me.

Alternatively could have a little menu on PHUIObjectBoxView appear on each section, though I can't imagine how to make that happen automatically.

I'm happy to implement this if you're OK with trying it (this is basically my second "mock", right?), I think it's way easier to execute cleanly from a technical perspective than the other version. If it's garbage we can drop it, but it feels worth trying to me?

Yeah I think #2 is better.

Is this just a hidden button on ActionListView that gets some display: block and negative margin when on mobile? I could probably build that.

Yeah, I think it's just:

• Button, which is hidden on .device-desktop.
• Menu is hidden on .device (or just .device-mobile, we might have enough space on tablets).
• When clicked, button toggles a class on the menu which shows it on .device.

Still not sure how to do this, initial plan was to just push the button up into the header, but I forgot that headers already have their own buttons (not often, but somethings like on the current project homepage). It's still likely the best place for it, just not sure how to make this auto-magical.

Oh silly, I see we're passing PropertyList into ObjectBoxView anyways. Alright, should be able to figure this out after kiddo bath time.

There are broadly two issues here:

1. The left navigation menu doesn't do something reasonable by default on mobile.
2. Property lists in ObjectViews don't do something reasonable by default on mobile.

(1) is my primary focus first.

I think (2) is pretty straightforward, but I'll deal with that after (1).

Actually I guess (2) already got pretty much fixed in D11340.

Happy to help with conversions if that's how this gets solved.