I like and agree with proposed changes.

Quick comment - for the screen listing existing groups - always take into account that there can be plenty of them (this also may apply to sites). Users will expect to browse bigger number of entries easier and be able to sort/filter them.

in current UI there is the concept of "root" users which has more privileges than other administrators and is able to modify the navigation/page of a group. This seems to be not taken in accout in this proposal.

I wonder where concept of "root" users should be configured/exposed in the UI. Not sure if fits into Sites Management. I don't think it is exposed in current UI at all actually (correct me if I'm wrong) - only XML - so good moment to include it in requirments.

it's defined by a specific user name which is "root" by default but can be changed in XML configuration (so it's not cannot be changed at runtime).

I agree that spaces are quite confusing to users and I like the approach of simplifying the concept for users. I do, however, have 2 concerns with the proposed solution:

1. It sidesteps the issue of dealing with what currently exists. Choosing to remove existing spaces is not a UI-domain decision, it's a product-level decision. While I agree that we certainly could trim down the list, it's not part of the UI design. The UI should deal with the existing with its existing constraints, not try to remove these constraints to make the design easier. Same thing goes with the rest of the UI admin proposal actually: it should deal with the existing, not lose features but make them more understandable and approachable. Many of the proposals actually assume that we can just remove what exists to make the design simpler. However, we need to deal with the migration case where people *will* have sites and spaces and we need the UI to properly deal with them, not change what exists because it makes things easier for us. Migrating from one version of EPP to another should be as seamless as possible. I don't believe that we can't come up with a good design without changing the existing and I don't believe that changing the existing for the sake of easier design at the expense of migration issues is a good solution for our users.
2. I believe that it would be better to separate Sites and Spaces if we want to de-emphasize the later. Instead of showing a single list combining both Sites and Spaces, we should separate them in two lists. This would have two advantages in my mind. First, we could collapse the Spaces list by default or maybe even not show them at all. It could be part of a Admin-UI level setting to show/hide Spaces. Maybe, we could combine that with a super-Admin mode: i.e. a switch that when activated (off by default) would show everything instead of hiding some stuff. Assuming most users won't use spaces, this simplifies the UI to let users focus on Sites. However, having the switch also allows "power users" to perform the same tasks that they are currently able to perform. Second, it would be easier for users to know what they deal with as in the current proposal the only thing that distinguishes a space from a site in the list is an icon. Moreover, they are mixed which is confusing as it puts them on the same level when we really want to emphasize one (sites) over the other (spaces). The directing idea here would be to hide the complexity until needed (which we hope will be never), not remove it completely.

What do you think?

Also, if we implemented a super admin mode, we could record stats as to how many times the switch was activated. Actually, we could implement user action tracing to record statistics as to which functions are actually used and which are not so that we can decide later what to add and/or remove in later versions.

For the first point, my concern is that some of the ideas (while good if we had the leisure of starting from a clean slate) are a little bit outside of the UI design realm and might cause issues with existing installs that should be upgraded as seamlessly as possible. Plus, they also tend to forget the fact that existing users might have used and still rely on the features we want to de-emphasize so, while the new design might try to steer new users away from these features (which might get deprecated/killed after a while), we still need to correctly support. That's the UI challenge we have: clean what we have without changing what already exists underneath while creating a path for a brighter tomorrow! :)

For the second point, I think if we really want to move people away from spaces, they should be hidden by default. Let people who still need them find them using the docs as they would know to look for them.

I like the new proposal. Updating content with scroll instead of pagination should be ok for performance IMO (if there are no other technical issues).

Many sites / spaces is something that can happen for sure - in case of both legacy data from migration or less usual portal structure. So this needs to be taken into account. I agree that it would be good idea to split sites and spaces into separate lists.