Consider using page manager UI similar to Backdrop?

Screenshots... So I do like the simplified context and visibility selection. I don't like where menu settings ended up.

Adding a new page/panel/layout: its somewhat all combined.

Aside from "Add Layout" on this page, which I assume for page_manager is still, "Add Page" what would we improve upon or change about this?

I do agree with a lot of what is going on from Backdrop in reducing the number of steps to get to the "Content" page, etc.

Why would we want to have a wizard? The wizard part of Page manager/Panels is one of the more complicated bits, precisely because you're asked to think about stuff that you don't understand until later. (Unless you've already grokked it and now you know what's coming, which is not helpful for new users.) An interface that emphasized incremental reveal and "don't expose it until you need it" would be a better fit.

I've not used Backdrop so I can't say how well it fits that bill, but let's not get hung up on wizards. They're easy to turn into a terrible terrible thing. :-)

Expanding the discussion a bit, there's I think 2 ways to approach this problem.

1) The user should go through the process in the order that the code does. Ie, define a route first, then select what type of thing to put there, then configure that thing. In this case, we should be honest about what the user is doing. That is, Page_manager is really a UI for creating routes. So, use the word "route". Don't call it a page, call it a route, and then select the type of route: A Panel route, an HTTP route, a Node route (essentially duplicates /node/X), a JSON/REST route, etc. As we learned from trying to call taxonomy "Categories" in ancient versions of Drupal, trying to hide what's going on behind what we think a user's assumption is tends to backfire badly, as it robs the user of a learning experience.

2) Flip it around completely. First have the user create the thing (Panel, HTTP responder, Node, REST, whatever). Then, and only then, ask "OK, so where do you want to put it?" This is somewhat more how Views works (although Views conflates these two steps as well).

Both of those are very viable approaches, although have extremely different implications for how things like Context or variants get defined. I'm not sure which one is better, to be honest. However, I do believe that trying to complect "what this thing is" and "where it goes" is the source of a lot of confusion around Page_Manager/Panels. "What" and "Where" are legitimately different things. Don't try to paper that over to the user. (Having both just be different tabs in a long list does paper that over, which IMO is part of the problem.)

Yes, and with the add/edit conflation like you describe, it becomes a wizard and not necessarily a very clear one. :-) We know that the D7 UI model doesn't work, from experience. Perhaps we should try thinking in an entirely different model?

Per the last paragraph in #12, I'll make a radical statement and suggest that perhaps "page manager" is not even the right name for this module... :-)

+1 to these not really being "pages" and page_manager being a strange name for the module. Its true that those who know page_manager know how to use it... but very few of those people exist. I often have a lot of difficulty explaining page_manager to folks as they typically only understand the whole system as "Panels" and don't distinguish between the different sub-systems.

Sounds like we need some formal UX input on the "route then panel or panel then route" question. That's rather core to the UI interaction, and will impact everything else that gets done. We need to make sure to get that right. :-)

So, since I've been down this road quite a bit over the course of the last 4+ years, let me share some of my own feelings and insight on this problem space.

1.) Let's start with backdrop's screen shots and why they don't work.

It's a great idea, it really is, but am I the only person noticing a distinct lack of "update" vs "update & save" style approach. I know MANY people HATE this in page_manager, but it's kind of essential if you don't want to show the panel/page/variant/whatever while you're working on it to live traffic.

While separation of these UIs could probably be done, keep this particular wrinkle in your mind as you think about it because it's SUPER important and I think largely removes this UI approach from feasibility pretty quickly.

2.) Responding to #11

Page Manager absolutely does 11.1, and this is with great forethought and purpose, because 11.2 is REAAALLLLY ridiculously hard for something as robust as Page Manager & Panels. Imagine, if you will, willy nilly placing blocks in some layout with no regard for the required contexts of those blocks and then trying to wire together the required contexts into those blocks later. I'm not convinced this approach is workable in any sense since it functionally doubles the effort for all contextual blocks (bare minimum) meaning the very workflow you wanted to streamline is now more obtuse than before. This is why Page Manager's wizard allows users to opt into various sections of the wizard during creation allowing a knowledgable user to opt-in to the behaviors they know they want to leverage.

In short, I'd LOVE to have a long honest technical conversation with a UX person devoted to the job. This has happened a couple of times in the last 4+ years, but truthfully, the project is really really big, and it needs more than volunteer efforts and community funding. I would REALLY vote for a 1 to 1 straight port of Page Manager into D8. If we want to rename it "Route Manager" meh, I get it, but meh.

Eclipse

It's a great idea, it really is, but am I the only person noticing a distinct lack of "update" vs "update & save" style approach. I know MANY people HATE this in page_manager, but it's kind of essential if you don't want to show the panel/page/variant/whatever while you're working on it to live traffic.

Could it not be achieved with a similar workflow to that which views uses?
i.e. auto-update when changes are made, save to commit changes live, cancel to undo changes and revert to original live version

Given the multi-page nature of the system, I think we'd find that difficult. Views benefits from a UI that while complex, is still single page. This makes such behaviors easier to implement and communicate to the end user. Technically, this could be pretty doable, but I worry about communicating it to the end users. I tend to suspect they'll hit "save" a lot when they really mean "tempstore save".

Eclipse

Talking without thinking here: Is there a reason that PageManager couldn't use a Views-inspired single-page approach? Views is complex, but the UI at this point is pretty solid. It could communicate the "what, how, where" split more cleanly but it's still pretty good, and much more approachable than Page Manager. Its create wizard is also much much much simpler, which is fine.

I'm sure we CAN. But we need dedicated resources for working through that before we're going to have answers about whether or not we SHOULD. I'd love to do that long term, short term I'm more interested in a straight port.

Eclipse

Ok, then I'm closing this issue.

Eclipse