Let's continue the discussion in English as this is a more general thing. More people will be able to follow without needing to rely on the outcomes of a translator.
Ubiquiti is doing the same...
Well, there are two main differences here: 1. Ubiquiti has a large(r) number of employees and, for sure, a design team. While our userbase is really great (and this is a lot of value!) Pi-hole's codebase is mostly maintained by maybe two to three people actively writing code. And even this strongly depends on their availability as we are not earning our money through Pi-hole.
Especially as the design team is missing, we try to come up with good solutions, however, again, none of the main code contributors is employed in the IT/network management sector so we don't know the tools many users are talking about. I, for instance, have never seen a Ubiquiti device in real life and, likewise, I have no idea how the interface may look like from your description.
I can very well understand your enthusiasm for a "all-in-one" network management solution Pi-hole could offer, however, things are on the very edge of really escalating here.
Firstly, Pi-hole is not (and should not become) a network management tool. Something like this needs a lot more manpower PLUS should run on a router. The more we offer network tools, the more support we will be providing on network management, host names, MAC IDs, IPv6, etc. Almost all of this is unrelated to the core function of adblocking. What started as a simple tool to show users a quick overview of their network so they can identify clients not using Pi-hole is escalating in your request to become a "one-for-all" thing to also manage DHCP static leases.
As I said above, I can see the network overview becoming a replacement of the currently existing groups-clients management page as it makes it easier for users as they are thinking more in terms of devices rather than single addresses. I can see this and we're trying to find the best approach in the background.
However, we're certainly at a point where the core team is severely loaded with support requests already know and you see what this leads to: More and more feature requests, we try to address most of this, at least we always take our time to reply with more than simple "No, will not happen." and, in the end, there is no time left to do actual coding in the hour we can take away from our family time after work. This is no meant as a complaint, more to put things into perspective.
Users with only a few devices may not care too much, however, places using change control need to care about "dead" devices as well.
This is about deploying Pi-hole on a large scale with potentially hundreds of clients, maybe even separated in VLANs. We try to make Pi-hole as good as possible for every possible environment, however, and especially because we are not getting paid for our "product" (which would allow to hire people for coding stuff), I have the feeling that we're coming to a point where we have to say: So far and no further.
We know from reports that Pi-hole has been used on large-scales in businesses with hundreds of clients and everything works really well. However, please keep in mind that Pi-hole was never intended to work on these scales. The main idea was is and will be to have a system running for small-scale networks on low-end hardware in typical at-home kind of networks. The fact that we realize Pi-hole in such a way that it uses minimal resources allows you to go to large scales given you use suitable hardware. That's possible but - by no means - an intended feature.
We simply cannot process the incoming support workload. If more people with good networking knowledge were to participate, okay, however, the current team of people contributing on a daily basis for a sufficiently long time to say that they'll stay for longer is less then ten people. This is not enough.
Blocklists can be removed altogether, if the network table is redesigned, DHCP lease management isn't needed, either.
Blocklists is already gone:
Lease Management is simple and proven to work. My explanation why I don't want to see it in the network table is partially above, already above. As said, Pi-hole is still intended for the home network. It is furthermore intended as a starting project. Many (most?) users new to Pi-hole use it as their first Raspberry Pi project. Many even as their first Linux and networking project. The interface has to be as clear and easy as possible. I know that there's some room for improvement on the current interface, however, I wanted to add the per-client feature as it was requests for such a long time. And I think we're on a good way to get there.
The DHCP server was never meant to be used on any large networks. I implemented it some years ago for those routers where you cannot change the DNS server announced to the routers (I had the Deutsche Telekom Speedport at home at this time). That's the reason for its existence. Even adding static leases is something we probably shouldn't have done: why would you care for IP addresses to stay constant? You should really use host names to contact devices also to ensure more simple migration if ever needed. But this was requested by a lot of users and, in the end, we implemented it for them because it was not much work.
The navigation menu can be trimmed down, like removing Whitelist and Blacklist.
When comparing these with the Groups-domain management page, you'll see a subtle difference: The groups-domain page can change domains between white- and blacklist types and add to both types of list + mange the groups. This is a more difficult thing for users and the decision was to keep two more simpler pages so users can use the Pi-hole as before when they do not want to wrap their heads around per-client blocking. I, for instance, don't care myself. All my devices block the same stuff, I see no need for per-client differences, but tastes differ and that's okay.
TL;DR
Pi-hole is dangerously close to a "one-for-all" network management tool. We have to stop this or we will completely swamped by support questions by users doing networking for the first time and asking us how to realize complex setups with guest networks, split-horizon, IPv6 tunneling and whatnot. This will bring its development to a halt.
The network overview page already got very complex now. If you are working in IT or if this is your hobby, you may see this differently. I don't find it complex, too, but I wrote the code for it.
We will likely (<- not promised!) replace the current groups-client interface by the network overview + group assignment selection. Everything beyond this will be too much.