In unserem letzten Beitrag haben wir die Vorteile und Herausforderungen von Portalmanagementsystemen erörtert. Dieser Beitrag war jedoch rein theoretisch, und wir dachten, es wäre eine gute Idee, Ihnen eines in Aktion zu zeigen.
Das Portal, über das wir sprechen werden, haben wir für Yourfirm.de entwickelt.
Yourfirm betreibt ein Jobportal, auf dem Arbeitssuchende Jobs in Deutschland und Österreich finden und sich auf diese bewerben können. Das ursprüngliche Jobportal Yourfirm.de lief für seine Größe und Geschäftsausrichtung ziemlich gut und man entschied sich dafür das Geschäftsfeld zu erweitern. Das Ziel war es, mehr Kunden in anderen Ländern zu erreichen und spezialisierte Dienstleistungen für ausgewählte Berufe anzubieten.
Auf der Grundlage von Kundenfeedback und aus SEO-Überlegungen heraus wurde beschlossen, mehrere spezialisierte Seiten für verschiedene Arten von Arbeitssuchenden zu erstellen.
Yourfirm.de, die Webseite, blieb als allgemeines Jobportal bestehen, aber es wurde Regio-Jobanzeiger (RJA) für regionale Jobs und Fachportale (FPO) für spezialisierte Jobs eingeführt.
Jede Webseite benötigte eine andere Markenbildung und eine individuelle Anpassung, während sie gleichzeitig zentral verwaltet werden sollte.. Wie haben wir dieses Kunststück vollbracht und ein spezialisiertes Jobportal geschaffen?
Wir hatten mehrere Dimensionen zu berücksichtigen, und die potenzielle Anzahl der Portalinstanzen konnte von zehn bis zu Hunderten reichen. Unsere Dimensionen waren drei verschiedene Marken, verteilt auf drei Länder, verschiedene Städte sowie Regionen und noch mehr Berufe. So könnten wir zum Beispiel ein Portal für Jobs in München, Deutschland, und ein anderes für IT-Jobs in Österreich haben.
Vor diesem Hintergrund entschieden wir uns, von Anfang an eine richtige Portalverwaltung zu haben.
Erstens brauchten wir eine Möglichkeit, instanzspezifische Daten im System zu verwalten. Das heißt, wir brauchten einige zusätzliche Tabellen in unserer Datenbank für portalspezifische Inhalte wie die Standard-Suchkonfiguration und funktionale Daten. Wir mussten die oben genannten Dimensionen modellieren und entscheiden, welche Kombinationen zulässig waren. Zum Beispiel wollten wir in jedem Land regionale Portalinstanzen und berufsspezifische Instanzen haben, aber die regionalen berufsspezifischen Portalinstanzen würden nicht genug Inhalt haben, um für die Benutzer von Interesse zu sein.
Die nächste Herausforderung bestand darin, eine Art Vorbereitungslogik (in unserem speziellen Fall als Middleware) zu haben, um die genaue Instanz auf der Grundlage der Informationen aus den Benutzeranfragen zu erkennen und zuzuweisen, z. B. die Domäne, über die sie auf das Portal zugreifen. Diese Erkennungslogik musste sehr optimiert sein, da sie für jede einzelne Anfrage an eine Portalinstanz ausgeführt werden musste.
Nach der Erkennung mussten die Informationen über den Portaltyp und den Inhalt dem Rest der Anwendung zugänglich gemacht werden, einschließlich der Frontend- und Backend-Logik, die diese Informationen zur Implementierung der erforderlichen Sonderfunktionen verwendete.
Das Frontend musste die verschiedenen Stile für jede Benutzeroberfläche auf der Grundlage des Portaltyps handhaben. Anstatt die Anzeigelogik an das Frontend zu koppeln, entschieden wir uns, mehrere Bundles für jede Instanz zu generieren und nur das passende Bundle für jede Marke zu verwenden. Dadurch konnte der Frontend-Code relativ einfach gehalten werden, während jede Marke ihr eigenes Erscheinungsbild erhielt.
Für die Suche wendeten wir für die regionalen Instanzen geografische Filter auf die Suchergebnisse an und für die berufsspezifischen Instanzen eine berufsbezogene Filterung.
Eine weitere Überlegung ist, wie das Backend Informationen an das Frontend weitergibt. Wir haben bereits erwähnt, dass das Frontend separate Bundles für jede Instanz verwendet, aber es benötigt auch einige explizite Informationen über die Instanz und wir haben diese Informationen in einem Konfigurationsobjekt übergeben.
Nachdem wir die Logik für die verschiedenen Arten von Instanzen implementiert und die portalspezifischen Daten in der Datenverwaltungsoberfläche des Portals erfasst hatten, konnte das Hinzufügen neuer Instanzen mit minimalem Aufwand und praktisch ohne Beteiligung der Entwickler erfolgen.
Der Kunde konnte auch Instanzen entfernen und ersetzen, wenn er sich beispielsweise entschloss, die Regionen oder Berufsgruppen, die er verwenden wollte, neu zu definieren.
Sobald das Portalverwaltungssystem eingerichtet war, bot es eine große Flexibilität bei der Verwaltung der Portalinstanzen. Es musste nur erweitert werden, wenn neue Funktionen hinzugefügt wurden, neue Daten instanzspezifisch gemacht werden sollten oder eine neue Art von Asüekt eingeführt wurde, um einen anderen Portaltyp zu unterscheiden, der vorher nicht unterstützt wurde.
Die verschiedenen Marken hatten ihr eigenes Aussehen, das vom Portalsystem verwaltet wurde. Jedes Portal verfügte über unterschiedliche Farbschemata und Styling-Anpassungen, zum Beispiel hatte RJA abgerundete Ecken, während FPO eher eckig war.
Die Anpassungsmöglichkeiten waren damit noch nicht erschöpft, denn jedes Portal hatte seine eigenen speziellen Funktionen, die nur ihm zur Verfügung standen, z. B. hatten die FPO-Portale ein Video auf ihrer Homepage, was bei RJA nicht der Fall war.
Dies ermöglichte es dem Kunden auch bei jedem Portal obligatorische Suchparameter festzulegen, so dass zum Beispiel bei berliner-jobanzeiger.de Berlin und bei muenchner-jobanzeiger.de München vorausgewählt wurde.
All dies geschah, ohne dass die Portale auf gemeinsame Daten, wie z. B. die Stellenangebote, verzichten mussten, und mit einer einheitlichen Suche, die den Suchvorgang für alle Portale durchführte.
Unser Kunde verwaltet derzeit zwischen 100 und 200 Portaloberflächen für drei verschiedene Marken in mehreren Ländern und verzeichnet dank einer besseren Zielgruppenansprache steigende Besucherzahlen - eine Erfolgsgeschichte, auf die wir stolz sind.
Reizt Sie der Gedanke, Ihr Unternehmen mit einem Portalmanagementsystem auf die nächste Evolutionsstufe zu bringen? Zögern Sie nicht, uns zu kontaktieren. Unser Expertenteam entwickelt Portallösungen, die auf Ihre Bedürfnisse zugeschnitten sind. Wir werden gemeinsam herausfinden, ob ein Portalmanagementsystem das Richtige für Sie ist, und wenn ja, werden wir es gerne gemeinsam mit Ihnen entwickeln.