Das Management-Applet baut auf dem CardLayout auf, welches das AWT zur Verfügung stellt. CardLayout erlaubt, die graphische Oberfläche der Anwendung in mehrere Bildschirmseiten (panels) zu unterteilen, die unabhängig voneinander im Web-Browser dargestellt werden können. Bildlich kann man sich dies als Stapel von Karten vorstellen, von der jeweils nur eine sichtbar ist. Somit können die GUI-Elemente wie Ein-/Ausgabefelder, Listen und Buttons zur Darstellung und Manipulation der Managementinformation für einzelne oder eng zusammengehörige Klassen des Objektmodells auf einem Panel angeordnet werden. Im Idealfall hat der Anwender dann alle Informationen, die der Agent zu einer Ressource bereitstellt, auf einer Bildschirmseite parat. Das Haupt-Panel erscheint beim Start des Applet und fordert die Auswahl des zu überwachenden Systems. Nach erfolgreicher Bindung des Applet an die Objekte und Factories des Agenten, kann über entsprechende Buttons auf Unter-Panels, z.B. für allgemeine Systeminformationen, Benutzer, Dateisysteme, Überwachung von Servern, Ereignismeldungen, etc. gewechselt werden. Das CardLayout hat den großen Vorteil, daß die Anwendung leicht erweitert bzw. modifiziert werden kann. Es ist problemlos möglich, neue Panels in das Applet zu integrieren, wenn das Objektmodell um neue Klassen ergänzt wird. Änderungen an der von einem Agentenobjekt bereitgestellten Information oder Funktionalität ziehen wiederum meist nur Änderungen an einem Unter-Panel des Management-Applet nach sich. Die leichte Erweiterbarkeit des Prototypen sowohl auf Agenten- als auch auf Managerseite ist eine wichtige Anforderung, da dieser erst einen Teil der Klassen des Objektmodells aus Kapitel 4 realisiert. Auch die Verfeinerung von Objektklassen auf Agentenseite wird von dem Design der Anwendung gut unterstützt. Da die Panels eigene Java-Klassen sind, können Panels für spezialisierte Objekte die GUI-Elemente und deren Implementierung von Panels für allgemeinere Oberklassen erben.
Innerhalb eines Panels wird das äußerst mächtige, aber auch sehr komplexe GridBagLayout zur Anordnung der GUI-Elemente verwendet. Dieses erlaubt es, die einzelnen Elemente auf einem rechteckigen Gitter frei zu positionieren. Jedem einzelnen Gitterfeld werden dabei eigene Darstellungsattribute (GridBagConstraints) wie Schriftart, Ausrichtung, Farbe, Größe, etc. zugeordnet. Theoretisch ist es aufgrund des Rasters möglich, das Aussehen eines Panels vor der Implementierung genau zu planen. In der Praxis funktioniert dies aber wegen der unzähligen Attribute zu jedem Feld kaum. Dies impliziert ein sehr zeitaufwendiges ,, Trial-and-Error``-Verfahren durch Iterieren folgender Schritte: Modifikation von Attributen im Quelltext, erneute Übersetzung und Kontrolle der Bildschirmdarstellung. Die einfacheren Layout-Stile des AWT haben sich im Test jedoch als zu wenig mächtig erwiesen. Die Komplexität des GridBagLayout erfordert aber eigentlich den Einsatz eines Entwicklungswerkzeugs (Java GUI-Builder). Dieses stand während der Implementierung des Prototypen leider nicht zur Verfügung. Die Abbildungen 6.19 und 6.20 zeigen zwei Panels des Management-Applet für die Administration von Benutzerkennungen und zur Überwachung eines NFS-Servers.
Die Implementierung der Ereignisbehandlung zu den GUI-Elementen, z.B. die Reaktion auf einen gedrückten Button, kann leider nicht innerhalb der Panel-Klasse gekapselt werden. Das schwache Ereignismodell des JDK 1.0.x erfordert eine globale Behandlungsroutine in Form einer großen, unübersichtlichen CASE-Anweisung. Sobald die Browser mehrheitlich das JDK 1.1.x unterstützen, sollte zur besseren Wartung des Applet-Codes das neue Ereignismodell implementiert werden.