Um was es geht:
Dieser Artikel beschreibt die Möglichkeiten, die Recruiting Software zvoove nahtlos – mit und ohne iframes – in die eigene Firmen-Homepage einzubinden. Er geht detailliert auf die Vor- und Nachteile der Lösungen ein, Ihre Liste an Jobs und Vakanzen über ein ifame, die API oder das zvoove plugin für WordPress bzw. die TYPO3 Extension einzubinden. Er gibt Ihnen einen Überblick, mit welche Kosten Sie für die unterschiedlichen Arten der Einbindung durch Ihre Agentur rechnen müssen. Für Entwickler gibt es am Ende des Artikels eine erste „Starthilfe“ mit Beispielen für das Abfragen der Stellenanzeigen über die zvoove API.
TL;DR
Flexibilität, Kontrolle, Datenschutz, Usability – alles spricht für die Einbindung Ihrer Jobliste über die API statt iframes. Durch den Einsatz des „zvoove plugin WordPress“ oder der „zvoove TYPO3“ Extension können Entwicklungs-Kosten auf ein Minimum reduziert werden. Abhängig von den Anpassungswünschen liegt der Aufwand dann nur bei wenigen Stunden.
Gerne übernehmen wir (www.99grad.de) die Integration von zvoove in Ihre Homepage oder beraten Sie unverbindlich zu den Möglichkeiten. Sprechen Sie uns einfach an: Tel. 0611-4080919 oder per E-Mail an zvoove@99grad.de
Das Problem
Lassen Sie mich raten: Sie haben eine Recruiting-Firma und eine Webseite in WordPress oder TYPO3. Sie haben einen Vertrag mit der Recruiting-Platform zvoove abgeschlossen und fleissig Jobs eingepflegt. Alles funktioniert wunderbar – auf der Subdomain (unter https://ihrefirma.europersonal.com) sieht man Ihre Vakanzen. Die Anzeigen erscheinen auf den gewünschten Jobportalen (stepstone etc.), das Bewerbungsformular funktioniert und die Bewerbung mit den Unterlagen landen in Ihrer In-Box.
Alles rund? Ja… beinahe. Zwei kleine Dinge stören Sie vielleicht: Zum einen würden Sie die Jobs gerne auch auf Ihrer eigenen Homepage zeigen, direkt innerhalb von WordPress. Aber im WordPress-Plugin-Verzeichnis findet man bei der Suche nach „zvoove plugin wordpress“ oder „zvoove wordpress“ leider nur gähnende Leere.
Die zvoove-Webseite an das eigene Corporate Design anpassen
Und dann wäre da noch die Sache mit der Firmenwebseite, die zvoove für Sie eingerichtet hat und die unter https://ihrefirma.europersonal.com läuft. Diese Seite erfüllt zwar alle Funktionen, sieht aber relativ schlicht bis bescheiden aus. Der Admin-Bereich von zvoove bietet (fast) keine Möglichkeiten, das Design mit Farben, Logo, eigenen Icons und Ihrer Hausschrift anzupassen. Dadurch bleibt die Seite optisch weit entfernt von Ihrem eigenen Corporate Design… und sie ist auch von den Webseiten Ihrer Mitbewerber kaum zu unterscheiden.
In den Unterlagen und Flyern von zvoove klang alles noch ganz einfach: „Klar können Sie Ihre Vakanzen ganz einfach in Ihre eigene Homepage einbinden“. Zwei alternative Möglichkeiten wurden Ihnen mit den Vor- und Nachteilen erklärt. Sie können einen iframe nutzen – oder unsere API. In einem kurzen Erklärvideo werden die beiden Lösungen sehr anschaulich miteinander verglichen:
Dieses Video verweist Sie auf den Service eines Drittanbieters, um Videoinhalte abzuspielen. Dieser Service kann Daten zu Ihren Aktivitäten sammeln. Mit einem Klick auf „Play" werden Sie zu der Webseite des Drittanbieters weitergeleitet, um das Video anschauen können.
Wenn Sie sich mit Webseiten-Programmierung wenig auskennen, haben Sie diese Informationen vielleicht einfach an Ihrer Programmierer oder Ihre Webagentur weitergeleitet und gesagt: „Kümmert Euch darum“. Eine Agentur mit wenig Erfahrung (oder Zeit) wird dann direkt auf die iframe-Lösung gesprungen sein. Eine Agentur mit etwas mehr Weitblick wird Ihnen relativ schnell von der iframe-Lösung abgeraten haben – Sie aber dann mit einen Kostenvoranschlag konfrontiert haben, bei dem Sie sich erst mal setzen mussten.
Was also tun? Welche Entscheidung ist die Richtige? Lassen Sie uns die Vor- und Nachteile der beiden Lösungen noch mal genauer verstehen:
zvoove in die eigene Webseite integrieren: Per iframe
Die einfachste Lösung, die Liste mit Jobs in die eigene WordPress-Webseite einzubauen ist es, ein <iframe>
zu nutzen. Einfach erklärt ist ein iframe ein kleines Stück HTML-Code, das wie ein „Guckloch“ oder Fenster zu einer anderen Homepage dient. Wenn sie den iframe-Code in Ihre Homepage einbauen, geben Sie eine Höhe und Breite für das „Fensterchen“ an – und in diesem Fenster sieht ihr Besucher dann den Inhalt einer anderen Webseite.
Vielleicht kennen Sie bereits iframes von anderen Anwendungen. Die bekannteste ist vermutlich das iframe von YouTube: Wenn Sie ein Video von YouTube auf Ihrer Homepage einbinden, dann wird auch hier nicht das Video selbst auf Ihre Homepage kopiert – sondern Ihr Besucher schaut durch ein kleines Fenster auf die Homepage von YouTube und dort auf das Video.
Bei zvoove sieht der Code für das iframe wie folgt aus, wobei die Angabe unter src
natürlich an Ihrer Adresse bei zvoove angepasst werden muss:
<iframe width="560" height="315" src="https://ihrewebseite.europersonal.com/karriere/ihrewebseite" frameborder="0"></iframe>
Vorteile der Einbindung per iframe:
Die Einbindung der Jobliste von zvoove über die iframe-Lösung hat einige Vorteile:
- Die Umsetzung ist in wenigen Minuten gemacht, geringe Kosten für die Einbindung
- iframe kopieren, in WordPress einfügen – fertig
- sehr geringe bis keine Programmierkentnisse erforderlich
- CMS-unabhängige Einbindung möglich. Es spielt keine Rolle, ob Sie eine Joomla, Drupal, WordPress oder TYPO3 Seite haben: Das iframe ist mit allen Content-Management-Systemen „kompatibel“ und sie sind nicht auf ein Plugin oder eine Extension für ihr individuelles CM-System angewiesen.
Nachteile der iframe-Lösung:
Das Video von zvoove nennt bereits einige der Nachteile dieser Lösung, fokussiert allerdings auf das Thema Suchmaschinen und Ranking:
- Durch die Einbindung über ein iframe wird ihre Seite nicht besser „gerankt“, d.h. sie erscheint nicht besser in den Suchergebnissen von Google
- Die Links bei Google führen zu zvoove, aber nicht zu Ihrer Homepage
- Dadurch bekommen Sie keine Statistiken über Zugriffszahlen, Aufrufe, Conversionraten u.ä.
Unerwähnt bleiben im Video eine Reihe weiterer Usability-Probleme:
- Das Design der Jobliste ist nicht an ihr persönliches Design anpassbar, sie bleiben auf die Konfigurationsmöglichkeiten von zvoove beschränkt.
- Das iframe ist eine Fenster-im-Fenster-Lösung: Da sie nicht wissen, wie lang die Liste der Jobs in zvoove ist, müssen sie die Höhe des iframes über die
height
-Angabe evtl. immer wieder anpassen. Ohne die Anpassung sehen sie entweder unschönen Abstand / Freiraum unterhalb der Jobliste oder sie haben Scrollbalken innerhalb des iframes. - Gerade die Scrollbalken am iframe stellen in Zeiten der mobilen Darstellung auf Smartphones und Tablets ein großes Usability-Problem dar: Man kann nicht ohne Probleme am „Rahmen im Rahmen“ vorbeiscrollen! Man swiped sich bis zur Jobliste, dann bleibt der Finger erst mal am Rahmen „hängen“ und scrollt nur innerhalb der Jobliste. Erst am Ende der Liste angekommen kann er sich weiter auf ihrer Homepage nach unten bewegen.
- Links in der Jobliste, um die Details zu einer Anzeige zu sehen, öffnen sich immer innerhalb des iframes, d.h. die Detailansicht des Jobs ist evtl. sehr bescheiden – oder der User verlässt bei Klick Ihre Homepage. Beides mündet in eine eher negative User-Experience.
- Die Vor/Zurück-Navigation des Browsers ist durch die iframe-Lösung behindert und funktioniert evtl. nicht wie erwartet. Auch das ist ein unschönes Usability-Problem.
Auch aus technischer Sicht hat die iframe-Lösung viele Einschränkungen:
- Sie bleiben bei den Such/Filterfunktionen Ihrer Jobs immer auf das beschränkt, was zvoove bietet. Eigene Ideen, die Jobs nach bestimmten Kritierien zu filtern, clustern oder sortieren lassen sich mit der iframe-Lösung nicht umsetzen.
- Sie können keine Deep-Links zu den Jobs machen. Möchten Sie z.B. von der Startseite oder aus einer News einen Link auf ein bestimmtes Job-Angebot machen – oder auf eine gefilterte Vorauswahl der Jobs, dann ist das technisch nur mit höherem Aufwand möglich. Beispiel: Sie können zwar von der Startseite auf die Gesamtliste der Jobs verlinken, aber nicht auf eine gefilterte Ansicht, z.B. nur die 450-Euro-Jobs oder die Jobs in der Nähe von Frankfurt.
- Sie können keine neue Darstellung („Views“) der Jobs implementieren. Viele Kunden möchten auf Ihrer Homepage z.B. die neuesten 5 Vakanzen in einem Slider auf der Startseite darstellen. Diese Darstellung können sie weder umsetzen noch automatisieren. Die Liste der Jobs wird nicht automatisiert mit zvoove synchronisiert. Jedes Mal, wenn Sie einen neuen Job bei zvoove einpflegen, müssen sie den Slider händisch in WordPress ebenfalls aktualisieren. Sie haben also doppelten Aufwand bei der Pflege.
- Die Performance und Erreichbarkeit der Job-Liste und Suchfunktion ist immer abhängig von der Erreichbarkeit des zvoove-Servers. Leider hatten wir bei der Entwicklung unseres „zvoove plugins für WordPress und TYPO3“ einen Ausfall des Servers von ca. knapp 2 Tagen. Auch ein Server-Monitor, der den Status des zvoove-Server überprüft melden hin- und wieder Ausfälle. In dieser Zeit erscheinen dann auf der Homepage keine Jobs mehr – und auch eine Bewerbung über das Bewerbungsformular ist nicht möglich.
- Die Ladezeiten von iframes ist häufig nicht gut. Skripte und Designs müssen für zwei Webseiten parallel geladen werden: Einmal für die Darstellung Ihrer Homepage und einmal für die zvoove-Webseite, die in dem „Guckloch“ erscheint. Google straft lange Ladezeiten inzwischen ab, d.h. die Einbindung eines iframes könnte sich nicht nur neutral, sondern sogar negativ auf Ihr Ranking auswirken!
Probleme mit iframes aus Sicht der DSGVO:
Ebenfalls nicht erwähnt wird eine Reihe von Problemen aus Sicht der DSGVO – Datenschutz-Grundverordnung. Ihr Datenschutzbeauftragter wird bei der Einbettung von zvoove per iframe sehr genau „hinschauen“ und evtl. sogar komplett davon abraten:
- Ohne es zu wissen, öffnet der User ja „im Hintergrund“ (im „Guckloch“) die Webseite von zvoove. Da beim Öffnen der Webseite zwangsläufig Daten des Users an zvoove übertragen werden, muss der User darüber vorher informiert werden und seine ausdrückliche Einwilligung erteilen.
- Im Worst-Case erlebt ihr User ein Cookie-Banner-Desaster: Er kommt über Google auf die Ihre Webseite (weil er Ihren Firmennamen eingeben hat) und landet auf der Seite, die das iframe von zvoove eingebunden hat. Dort muss er sich durch zwei Cookie-Banner klicken: Einmal möchte Ihre Homepage die Einwilligung, Cookies zu setzen und/oder zu tracken. Und dahinter muss er dann noch einmal den Cookie-Banner im zvoove-iframe wegklicken, die ebenfalls Cookies setzen müssen.
- Alternativ könnten Sie eine 2-Klick-Lösung integrieren: Der User sieht dann die Jobliste auf Ihrer Webseite zunächst nicht, sondern muss erst seine ausdrückliche Einwilligung erteilen, z.B. über eine Checkbox. Sie kennen das evtl. von Webseiten, die Twitter oder YouTube über eine 2-Klick-Lösung eingebunden haben.
- In jedem Fall müssen Sie in Ihrer Datenschutzerklärung einen Hinweis über zvoove integrieren und aufklären, wann und welche Daten an den externen Dienstleister übertragen werden, wer diese Daten einsehen und verarbeiten kann – und wie lange sie dort gespeichert werden.
- Grundsätzlich sollten Sie immer darauf achten, dass Sie den Vertrag zur Auftragsdatenverarbeitung (ADV) mit zvoove abgeschlossen haben.
Auf die Risiken einer Abmahnung durch Mißachtung dieses Themas wird von zvoove leider weder im Erklärvideo noch auf der Homepage hingewiesen – aus unserer Sicht ein echtes Problem. Falls Sie sich näher mit diesem Thema beschäftigen möchten, könnten Ihnen folgende Links helfen:
iframe – Haftung bei Einbindung externen Inhalte
iframes – wo ist das Problem?
Was kostet es, zvoove per iframe in die Homepage einbinden zu lassen?
Die Kosten für die Einbindung durch Ihre Agentur oder Ihren Entwickler wird bei maximal 1,5 – 2 Stunden liegen (ca. € 100,– bis 180,–). Das klingt zunächst relativ viel, wenn doch eigentlich nur „ein Stück Code“ in die Seite eingefügt wird. Wir gehen aber davon aus, dass die Agentur bemüht ist, auch mit den sehr beschränkten Möglichkeiten der iframe-Lösung das maximale Ergebnis zu liefern. Dadurch ergeben sich eine Reihe von Arbeitsschritten:
Kosten für die Einarbeitung, Lesen der Doku bzw. Suchen des iframe-Codes | ca. 15 Minuten |
Falls gewünscht: Minimalste Anpassung des Designs, im Rahmen der Möglichkeiten im Admin-Bereich von zvoove | ca. 30 Minuten |
Einbetten des Codes in die Homepage, optimieren der iframe-Größe für Desktop und die Ansicht auf mobilen Endgeräten wie Smartphones, Tablets | ca. 10 Minuten |
Testing und Optimierung auf verschiedenen Endgeräten | ca. 15 Minuten |
Projektmanagement und Koordination | ca. 15 Minuten |
Sprechen Sie uns (www.99grad.de) gerne an, falls wir die Integration in Ihre Webseite übernehmen sollen: zvoove@99grad.de
Fazit der iframe Lösung:
Für die Einbindung der Jobliste aus zvoove über die iframe-Lösung sprechen nur die geringe Kosten. Es ist aber als eine Notlösung zu sehen. Auf lange Sicht wird die Webseite davon eher Nachteile haben und möglicherweise sogar an Sichtbarkeit bei Google verlieren. Für den User ergeben sich deutliche Usability-Nachteile und damit ein eher negatives „Erlebnis“ beim Besuch Ihrer Webseite.
zvoove per API einbinden: Viel Arbeit – aber volle Flexibilität
Was meint zvoove überhaupt mit „API“?
Die drei großen Buchstaben: API. Was soll das sein? Damit ist eine „Schnittstelle“ gemeint, an die sich eine fremde Webseite oder Applikation anbinden kann.
In Bildern gesprochen: zvoove stellt eine Art virtuelle „Steckerleiste“ bereit. Die Form und Anschlüsse der Steckerbuchse ist genormt und es gibt eine Anleitung, wie man dort sein eigenes Kabel anschließen kann. Am anderen Ende des „Kabels“ hängt, was immer Sie wollen: Ihre WordPress-Webseite, Ihre TYPO3-Installation, eine App aus dem App-Store – sogar ein Smarthome-Gerät könnte man so programmieren, dass es die Zahl Ihrer Vakanzen an Ihre Badezimmer-Wand beamt.
An eine API lässt sich ALLES anbinden!
Jede gute konzipierte Software hat erkannt: Wir müssen aufhören, in Insellösungen zu denken und uns „nach außen öffnen“. Lasst uns in Steckerleisten denken (APIs), damit die Leute da draußen ihre eigenen kreativen Ideen umzusetzen können, die sie an unser System unkompliziert andocken können. Wenn wir (99°) für einen Kunden eine Software entscheiden dürfen, ist unserer erste Frage: Haben die eine API? Keine API – kein Chance.
Die Arbeit von zvoove endet folglich an der Steckerleiste (API). Aber das, was physich aus der Dose kommt sind zunächst „Hieroglyphen“ (ein JSON, um genau zu sein). Ihr Programmierer muss jetzt den Code schreiben, um die „Rohdaten“ in etwas Sichtbares, Lesbares und „Schönes“ zu verwandeln.
Warum ist die Anbindung an eine API so aufwändig?
Darin steckt eine Menge Arbeit: Ihr Entwickler muss sich zunächst einmal die „Betriebsanleitung“ durchlesen und die Besonderheiten der API verstehen. Jede API ist anders, jede spricht einen anderen „Dialekt“ und hat individuelle Besonderheiten.
Dann muss er das eigentliche Programm entwickeln, dass die API anzapft und die Rohdaten ausliest. Es muss sich Gedanken machen über Caching (also das Zwischenspeichern der Daten, wenn zvoove mal nicht erreichbar sein sollte), die Performance der Suche (jede Mal eine Anfrage an zvoove schicken – oder schneller und effizienter die Daten lokal filtern?) – und über die Synchronisation / den Datenabgleich zwischen Ihrer Webseite und dem Datenbestand bei zvoove (Bei jedem Aufruf der Seite? Jede Stunde? Einmal in der Nacht?).
Erst ganz am Ende kommt der „schöne“ Teil, bei dem der ganze Aufwand dann auch sichtbar wird: Die Rohdaten in ein ästhetisches und bedienbares Interface (Bedien-Oberfläche) auf Ihrer Webseite zu gießen. Sieht man nur diesen Teil denkt man als Kunde: So viel Arbeit kann das doch nicht gewesen sein! 😉
Nachteile der Anbindung an die API: Hohe Kosten.
Damit sind dann aber auch schon (fast) alle Nachteile erwähnt, wenn man zvoove in die eigene WordPress oder TYPO3 Webseite integrieren möchte:
- Hoher Aufwand und Kosten. Das gilt natürlich nur, falls man nicht ein vorhandes PlugIn nutzen kann.
- Mögliche Folgekosten, falls sich an der API etwas ändert: Ihr Entwickler muss neue Versionen der API im Auge behalten und ggf. Anpassungen an seinem Code machen, falls sich seitens zvoove etwas ändert.
Vorsicht vor Folgekosten: Das PlugIn ist an Ihr CMS in der aktuellen Version gebunden!
Der Fairness halber sollte gerade beim Punkt „Folgekosten“ noch ein Punkt erwähnt werden: Falls Ihre Agentur nicht auf ein vorhandenes Plugin setzt, sondern auf eine komplette Eigenentwicklung, dann ist dieses Plugin an ihr individuelles CMS (WordPress, Joomla, Drupal, TYPO3) und an die akuelle Version dieses System gebunden. Sie müssen sich also klar sein:
- Wenn Sie in der Zukunft auf ein neues CMS wechseln, z.B. von TYPO3 oder Joomla zu WordPress, dann wird die zvoove Erweiterung in dem neuen System nicht funktionieren. Sie müssen es dann neu entwickeln lassen – auch wenn Code-Teile bzw. Logiken sicher übernommen werden können.
- Auch wenn Sie beim gleichen Content-Management-System bleiben, kann das Update von z.B. WordPress auf eine höhere Version dazu führen, dass das zvoove-Plugin nicht mehr funktioniert. Hier entstehen ebenfalls Folgekosten, die aber in der Regel nicht sehr hoch liegen und sich im Bereich von wenigen Stunden bewegen.
Klare Vorteile der API-Lösung: Volle Kontrolle, alle Möglichkeiten.
Integriert man zvoove über ein entsprechend programmiertes Plugin / Extension für sein Content-Management-System ein, dann sind nicht nur alle Optionen offen und alle Probleme gelöst – aus aus Sicht des Datenschutzes gibt es weniger Probleme:
- Alle Einschränkung in Bezug auf das Design, die Views (Ansichten) und die Darstellungsmöglichkeiten entfallen: Sie können das Design vollständig an Ihr Corporate-Design anpassen und auch Slider, Teaserboxen, Infobereiche etc. einfügen, die automatisch mit zvoove synchronisiert werden.
- Sie können z.B. die neuesten Jobs auf der Startseite in einem Slider / Carousel darstellen
- Sie können eigene Landingpages in die Homepage integrieren, die auf eine bestimmte Zielgruppe fokussiert oder eine bestimmte Branche bewirbt. Sie könnten z.B. nur die Jobs aus dem Bereich „Lagerarbeiter“ zeigen, einen allgemeinen (Suchmaschinen-optimierten) Text als Einleitung schreiben und darunter eine Liste von zvoove einbauen, die speziell nach diesen Jobs gefiltert wird. Mit den entsprechenden Suchmaschinen-Maßnahmen bekommen Sie diese Seite relativ leicht unter bestimmten Suchbegriffen auf die vorderen Plätze bei Google.
Wenn Sie das Thema „SEO / Suchmaschinenoptimierung für zvoove“ für Sie spannend ist oder Sie Probleme mit Ihrem aktuellen Ranking bei Google haben, sprechen Sie uns gerne an. Wir machen für Sie eine kostenfreie Kurzanalyse Ihre Webseite und beraten Sie über die Möglichkeiten und Chancen, Ihre Vakanzen, Jobs und Homepage bei Google besser sichtbar zu bekommen. Sprechen Sie uns einfach an: zvoove@99grad.de
Performance und Unabhängigkeit:
Auch aus dieser Sicht macht eine Implementierung über die Schnittstelle statt eines iframes Sinn:
- Bei einem gut programmierten PlugIn für zvoove werden die Jobs / Ergebnisse in der lokalen Datenbank Ihrer WordPress-Webseite „zwischengespeichert“ (Caching-Konzept). Statt jedesmal eine Anfrage an den externen API-Server zu senden, können Filterung, Sortierungen etc. direkt innerhalb Ihres Systems passieren. Das ist in der Regel deutlich performanter.
- Sie sind damit unabhängig von der Erreichbarkeit des externen Servers. Auch wenn es zu Ausfällen seitens zvoove kommen sollte, bleiben die Jobs auf Ihrer eigenen Webseite sichtbar.
- Sie können die Inhalte und Stellenbeschreibungen mit zusätzlichen Informationen, Bildern, Videos und Texten anreichern. Sollten Sie also die Möglichkeit vermissen, mehrere Bilder oder ein Video in die Stellenbeschreibung und Detailansicht bei zvoove zu integrieren, dann kann das innerhalb Ihrer eigenen Webseite ergänzt werden.
- Sie können eigene Filterungen und Umkreissuchen implementieren und dadurch besser und genauer auf die Wünsche und Bedürfnisse Ihrer Zielgruppe eingehen.
- Die Detailseiten (Stellenbeschreibungen) lassen sich komplett frei und unabhängig gestalten. Sie könnten sogar verschiedene Templates anlegen und je nach Zielgruppe das Design anpassen.
- Sie können Deep-Linking auf Stellenbeschreibungen machen. Das ist besonders wichtig, wenn Sie die Vakanzen parallel auf Social-Media-Kanälen bespielen möchten. Ohne die Implementierung über die API können sie z.B. von facebook oder Instagram immer nur zu zvoove-Webseite verlinken – oder zur allgemeinen Jobliste auf Ihrer eigenen Hompage. Mit einer „sauberen“ Integration über ein WordPress-Plugin oder eine TYPO3-Extension können sie direkt zur Detailansicht verlinken. Das wirkt sich deutlich auf Ihre Conversion-Rate aus, da der User, der sich für einen bestimmten Job interessiert nicht „orientierungslos“ vor eine Liste von allen Jobs geworfen wird.
- Sie können zusätzliche Funktionen einbauen, die es noch nicht seitens zvoove gibt. Unser Kunde wollte gerne eine Merkliste haben: Besucher können sich eine Liste der Jobs erstellen, die für sie spannend klingen und auf die sie sich bewerben möchten. Eine absolut spannende und wichtige Funktion, die es auf der Seite von zvoove (noch) nicht gibt.
- Alle oben beschriebenen Probleme mit der Usability entfallen. Sie können Ihren Besuchern eine optimale User-Experience bieten – ohne Kompromisse und unschöne „Hacks“
- Aus Sicht der DSGVO bleibt ihr User auf einer einzigen Seite. Für Sie entsteht weniger Erklärungsbedarf auf der Seite mit dem Hinweise zum Datenschutz. Die Irritaton über doppelte Cookie-Banner entfällt.
Was kostet die Anbindung an die zvoove API durch einen Programmierer?
Was kostet ein Auto? Das hängt natürlich immer von der Ausstattung und den individuellen Anpassungswünschen ab. In Sachen „zvoove“ gesprochen steht die Agentur / ihr Entwickler als erstes vor der großen Entscheidung: Komplett selbst entwickeln – oder auf vorhandenes aufbauen?
Auf vorhandene Plugins aufbauen
Das geht natürlich nur, wenn es auch ein Plugin oder eine Code-Basis für Ihr System gibt. Für TYPO3 haben wir eine Extension veröffentlicht, die kostenfrei im TYPO3 Repository (TER) heruntergeladen werden kann. Unser zvoove WordPress Plugin wird in Kürze veröffentlicht – Informationen dazu finden Sie auf dieser Seite.
Setzt ihr Entwickler oder Ihre Agentur auf eines der Plugins und sind die üblichen technischen Unwägbarkeiten behoben, dann geht es bei einem Minimal-Aufwand eigentlich fast nur noch um das „Styling“ der Listenansicht, Filterung und Detailansicht Ihrer Stellenanzeigen.
Exemplarische Kosten, falls eine vorhandene Erweiterung verwendet wird:
Einarbeitung in die Doku der Extension | ca. 2 h |
Technische Vorbereitung, Planung der Integration, Erstellung der erforderlichen API-Keys bei zvoove und Google | ca. 1,5 h |
Basis-Implementierung der Views für Suche, Liste, Detailansicht und Bewerbungsformular | ca. 1,5 h |
Anpassen der Templates an Ihr individuelles Corporate Design, z.B. Fonts, Farben, Icons, Auszeichnungen | ca. 3 h |
Testing, Polishing | ca. 2 h |
Projektmanagement und Koordination | ca. 2 h |
geschätzter Gesamtaufwand | ca. 0,5 – 1,5 Tage € 500,– bis € 1.500,– |
Eine realistische Implemtierung dauert also – je nach gewünschten Anpassungen zwischen 0,5 Tagen und 1,5 Tagen. Bei dem normalen Tagessatz einer Agentur kommen also zwischen € 500,– und € 1.500,– auf Sie zu.
Gerne machen wir Ihnen dazu ein Angebot – schreiben Sie uns einfach eine kurze Mail (info@99grad.de) oder rufen Sie uns an (0611-40 80 919).
Kosten bei einer kompletten Neuentwicklung:
Setzt Ihre Agentur nicht auf eine vorhandene Extension – oder gibt es schlichtweg keine für Ihr System, dann kommen zusätzlich zu den o.g. Kosten noch weitere Aufwände ins Spiel:
Einarbeitung in die API von zvoove, Testing | ca. 2 h |
Entwicklung der Module und Kernfunktionen zur Anbindung an die API | ca. 1 – 2 Tage |
Konzeption und Umsetzung von Caching-Funktionen, Filter- und Suchfunktionen, automatisierte Synchronisation | ca. 1 – 2 Tage |
Umsetzung des PlugIns und der unterschiedlichen „Views“ für die Liste, Detailansicht, Bewerbungsformular | ca. 1 – 2 Tage |
Falls erforderlich: Weitere Ansichten (Slider, Teaser etc.) | ca. 1,5 Tage |
Projektmanagement | ca. 1 Tag |
Sonstige (nicht abschätzbare) Kosten | ca. 1,5 Tage |
Geschätzer Gesamtaufwand: | 7 – 12 Tage € 6.000,– bis € 9.000,– |
Bei einer kompletten Eigenentwicklung sprechen wir also von 1 – 1,5 Wochen Aufwand. Die Implemtierung kann schnell zwischen € 6.000,– und € 9.000,– liegen. Dieses Geld in die Hand zu nehmen kann aber durchaus Sinn machen – gerade wenn Sie auf eine sehr individuelle und in Zukunft gut erweiterbare Lösung setzen möchten.
Fazit der API Lösung:
Im Vergleich zur iframe-Lösung punktet die Einbindung Ihrer Jobliste aus zvoove per API durch eine deutlich bessere User-Experience und auch das Design lässt sich problemlos an Ihre Wünsche anpassen. Ein wichtiges Argument ist aber auch das Thema Datenschutz! Durch den Einsatz des „zvoove plugin WordPress“ oder der „zvoove TYPO3“ Extension können Entwicklungs-Kosten deutlich reduziert werden. Bei geringen Anpassungswünschen liegt der Aufwand für Installation und Konfiguration des zvoove Plugins bei wenigen Stunden.
Sie haben Fragen – oder Rückmeldungen?
Wir freuen uns auf Ihre Gedanken oder Fragen! Schreiben Sie uns einen Kommentar – oder erreichen Sie uns über zvoove@99grad.de, per Telefon unter 0611 – 40 80 919 oder unsere Homepage www.99grad.de.
Entwickler-Ecke: So geht die Einbindung über die API im Detail
Dieser Abschnitt ist eher für Entwickler gedacht, die sich einen Überblick über die API von zvoove verschaffen möchten – oder um die Abgabe eines Angebot gebeten wurden und wissen möchten, was sie erwartet. Daher die Warnung: Es geht ins Eingemachte und es wird sehr technisch!
Von zvoove erhält man als Entwickler drei Dinge:
- Ein JSON im swagger-Format mit einer Beschreibung der REST Api Endpoints von zvoove. Die Datei lässt sich auf der Seite https://editor.swagger.io/ öffnen oder alternativ in einem Tool wie Postman. Vorteil an Postman: Man kann Queries an die RESTful Api direkt testen.
- Eine Kurzanleitung, wie man die swagger-Datei anschauen kann
- Einen API-Key – weitere API-Keys kann man selbst im Admin-Bereich von zvoove erstellen
Ab dort ist man relativ auf sich alleine gestellt. Support-Anfragen gehen leider fast ausschließlich über ein allgemeines Kontaktformular. Antworten dauern in der Regel 2 – 3 Tage, manchmal auch länger.
Hotline, Support bei der Entwicklung und Erreichbarkeit bei Ausfällen
Wirklich lustig ist es, wenn man eine Störung melden muss – beispielsweise, weil der Server „down“ ist und man dadurch nicht weiter entwickeln kann. Auf der Webseite gibt es einen großen, roten Button mit der Aufschrift „Störung melden“. Dieser führt dann zu diesem PDF (!), in dem gebeten wird, zunächst zu prüfen, ob vielleicht seine eigene Internetverbindung oder das lokale Netzwerk nicht funktioniert. Empfehlung: Bevor man zvoove fragt, erst mal probieren, ob man etwas auf seinem Drucker ausdrucken kann. Die Service-Zeiten der Hotline sind mit Arbeitszeiten von Beamten synchronisiert. Am Wochende (dem Tag, an dem relativ viele Jobsuchende sich nach neuen Arbeitgebern umschauen) scheint keiner Notfälle lösen zu können – auch wenn der Server komplett down ist.
Weshalb wir das schreiben? Weil wir diese Verzögerungen und Stolpersteine bei unserer eigenen Kalkulation nicht berücksichtigt hatten. Das Thema hat uns leider von der Projektplanung sehr aus dem Konzept gebracht.
Entwicklungsumgebung? Leider nein.
Kein Entwickler arbeitet gerne im Live-System. Bei zvoove geht das nicht anders – es gibt leider kein Development oder Staging-System gegen das man arbeiten kann. Gerade im Bereich des Rekruitings ist das doppelt blöd: Möchte man z.B. testen, wie die API reagiert, wenn man viele (100+) Jobs anfragt, dann muss man dies auf dem Live-System tun.
Hat der Kunde aber zur Zeit nur wenige (oder wie bei uns noch keine) Jobs veröffentlicht, dann testet man gegen ein leeres System – weit weg von der Realität. Wir waren also gezwungen, Jobs für die gesamte Öffentlichkeit sichtbar zu veröffentlichen – nur um die Anbindung an die API umsetzen zu können. Fehler und Probleme im Live-Betrieb und bei vielen Datensätzen sind so eigentlich prädestiniert.
Empfehlung auch hier: Bereits bei der Angebotserstellung berücksichtigen, dass es Bugs geben wird wenn der Laden brummt und viele Vakanzen im System sind. Der Kunde wird das nicht verstehen – als Entwickler unbedingt Sicherheiten einplanen.
Die RESTful API von zvoove im Detail
Was auf den ersten Blick nach einer ordentlichen Doku aussieht und einen bei der Angebotserstellung überschwänglich dazu verleitet, dem Kunden preislich entgegenzukommen, entpuppt sich in der Realität leider als eine Odysee mit einigen Überraschungen.
Unzureichende Fehlermeldung
Was uns während der Entwicklung die meiste Zeit gekostet hat, war es, uns die fehlenden Teile der Doku durch „Trial & Error“ in forensischer Kleinstarbeit selbst zu erarbeiten.
Das größte Problem dabei sind die sehr vagen Fehlermeldung bei der Übergabe falscher oder unzureichend strukturierter Daten an die API von zvoove. Meistens liest man etwas wie „Fehlerhafte Anfrage, unzureichende oder falsche Parameter übergeben
“ – nur leider ohne genauere Angabe, was jetzt genau nicht passt. Man muss dann Zeile für Zeile prüfen, bei welchem Parameter / welcher Property es „knallt“.
Vergiss die Doku, geh auf „Lauschangriff“.
Erst relativ spät im Prozess und nach vielen Stunden der Verzweifelung kamen wir auf die Idee, einfach mit einem Netzwerk-Tool die Requests auf der zvoove-eigenen Webseite aufzuzeichnen und zu analysieren.
Glücklicherweise ist das Reverse-Engineering auf der zvoove-Webseite leicht zu bewerkstelligen – die Webseite ist eine Webapp und basiert auf Angular. Man kann JavaScript problemlos dabei lauschen, welche GET- und POST-Requests es fleissig mit welchen Parametern an die API feuert.
Eine gewachsene Software – oder Wildwuchs?
An vielen Stellen spürt man die Ursprünge der Software: Die Grundsteine der API wurden vermutlich von einem kleinen, deutschsprachigen Team gelegt – vielleicht nie mit der Absicht, damit im größeren Rahmen „nach draußen“ zu gehen. Halb verwundert, halb lächelnd stößt man auf allerlei „Denglish“ bei den Endpoints, die dann z.B. so klingen:
/api /public /v1 /Bewerber /GetProfileAsPdf
/api /public /v1 /Bewerbung /GetNeuanlageModel
/api /public /v1 /MandantOeffentlicheDatei /GetAsStreamContent
/api /public /v1 /Katalog /GetByRelationName
PublicBewerberListeReadOnlyDto
Die Doku selbst ist in Deutsch geschrieben – ob es eine Englische Variante dazu gibt, wissen wir nicht. Das Denglish hat uns in der Entwicklung leider immer wieder irritiert und teilweise haben sich dadurch auch Fehler eingeschlichen.
Objekte (Models)
Relativ inkonsistent geht zvoove mit Relationen um: Je nach zurückgegebenen Model kommt (auch innerhalb eines Models) entweder ein Array mit Relationen und ObjectUuids
zurück (wunderbar!) – oder eine kommaseparierte Liste der Relations-Labels als String, wie bei den „Abteilungen“ (grauenhaft und fehleranfällig). Dann gibt es auch Variablen mit numerischem Suffix statt einem Array.
Hier ein Beispiel bei der Rückgabe der Stellen-Details, die für die Detailansicht der Stellenausschreibung benötigt wird:
Der GET
Request an /api
liefert ein denglishes Misch-Masch aus Strings, Arrays und Relationen:
{
...
// Abteilung sind eigentlich mehrere AbteilungEN und Relationen.
// Sie werden aber als kommaseparierte Liste zurückgegeben!!
"Abteilung": "string",
"Arbeitgeberleistung": "string",
"ArbeitgeberleistungHeader": "string",
"Arbeitgebervorstellung": "string",
"ArbeitgebervorstellungHeader": "string",
"Aufgaben": "string",
"AufgabenHeader": "string",
...
// Für das Bild kommt nur die Uuid – die Datei selbst streamt man
// über eine anderen Endpoint
"Image1Uuid": "3fa85f64-1234-4562-b3fc-2c963f66afa6",
"ImageKontaktUuid": "3fa85f64-1234-4562-b3fc-2c963f66afa6",
// Hier wurde offensichtlich mal über mehrere Logos / Bilder nachgedacht
// Warum wird hier nicht von Anfang an einfach ein Array zurückzugeben –
// sondern lieber eine Variable mit numerischem Suffix?
"Logo1Uuid": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"Mandant": {
...
// Hier kommt eine Mischung aus Relation und Datenfeldern
"AdresseOrt": "string",
"AdressePlz": "string",
"ObjectUuid": "3fa85f64-1234-4567-b3fc-2c963f66afa6"
},
"Vakanzarten": [
{
// Schönes Denglish...
"Bezeichnung": "string",
"ObjectUuid": "3fa85f64-1234-4567-b3fc-2c963f66afa6"
}
],
...
}
An dem Beispiel wird klar: Hier haben entweder viele sehr unterschiedliche Entwickler in unterschiedlichen Wachstumsphasen des Projektes am Core gesessen – oder es fehlte während der Entwicklung ein einheitliches Konzept.
Für die Implementierung ist das (bis auf das den kommaseparierten String-Irrsinn) kein großes Problem. Schauen wir uns jetzt im Detail und Step-by-Step die erforderlichen Abfragen an die zvoove-API an, die zur Darstellung der Listen- und Detailansicht erforderlich sind:
Liste aller aktiven Jobs aus zvoove als JSON laden:
Die erste Aufgabe ist es meistens, eine Gesamtliste der Jobs aus zvoove zu ziehen und auf der eigenen Webseite anzuzeigen.
Es gibt zwei Endpoints, die für das Abfragen aller Jobs genutzt werden können:
// Doku: "Holt alle aktuell veröffentlichten Stellen"
GET /api/public/v1/Stelle/GetStellen
und:
// Doku: "Holt alle aktuell veröffentlichten Stellen, die den Filtern entsprechen."
GET /api/public/v1/Stelle/GetStellenFiltered
Der Endpoint /GetStellen
ist in der Doku als „deprecated“ markiert und sollte damit vermutlich nicht weiter genutzt werden.
Da dieser Endpoint ohne Authentifizierung bei allen Kunden von zvoove öffentlich zugänglich ist, können Sie sich unkompliziert die Liste aller Ihrer eigenen Vakanzen ziehen (und nebenbei natürlich auch die Vakanzen aller ihrer Mitbewerber auf diese Weise anschauen… hmm…). Da es sich um einen GET
Request handelt, können Sie einfach die gewünschten Parameter an die URL hängen und den Endpoint direkt im Browser aufrufen:
Mit Klick auf diesen Link lassen wir uns die aktuellen Jobs anzeigen, die die Recruiting Firma BHM anbietet:
https://bhm.europersonal.com/api/public/v1/Stelle/GetStellenFiltered?keywords=&pageNo=1&pageSize=3&lat=&lon=&radius=
Der Response ist ein JSON
mit 3 Modellen (aufgrund des Parameters pageSize=3
). Im Beispiel haben wir das JSON gekürzt, es kommen eigentlich noch weitere Felder zurück:
{
"LastUpdateTime":"2022-03-12T15:56:29.1724346Z",
"TotalItems":934,
"Items":[
{
"Abteilung":"Lagerhelfer",
"BeginnAbSofort":true,
"Bezeichnung":"Mitarbeiter Logistik & Transport (m/w/d)",
"CultureName":"de-DE",
"DatumAb":"2022-03-12T00:00:00.0000000Z",
"EinsatzortGeoLocation":{
"Lat":50.6132229,
"Lon":8.435002400000002
},
"EinsatzortOrt":"Aßlar",
"EinsatzortPlz":"35614",
"LastUpdateTime":"2022-03-12T15:56:29.1724346Z",
"LinkSlug":"mitarbeiter-logistik-transport-m-w-d-35614-asslar",
"MandantUuid":"b4fa0902-9890-4563-9d52-2bb1204b0d06",
"StellenID":"1641",
"StelleUuid":"c8d36432-e60e-4aca-b11e-2ab1aed4a6d9",
"Vakanzarten":"Neubesetzung",
"Vertragsarten":"Vollzeit"
...
},
{
"Abteilung":"Produktionshelfer",
"Beginn":null,
"BeginnAbSofort":true,
"Bezeichnung":"Maschinen- und Anlagenführer (m/w/d) Lebensmittelbereich",
...
},
{
"Abteilung":"",
"Beginn":null,
"BeginnAbSofort":true,
"Bezeichnung":"Lagerhelfer/Fachlagerist (m/w/d)",
"DatumAb":"2022-03-12T00:00:00.0000000Z",
"EinsatzortGeoLocation":{
"Lat":51.1615558,
"Lon":6.774528999999999
},
...
}
]
}
Die swagger-Doku und das tatsächliche Ergebnis weichen ein wenig voneinander ab, vermutlich ist die Doku auch hier nicht auf dem aktuellen Stand. Entscheidend für die Synchronisation der Jobs ist die zum Glück vorhandene und leider undokumentierte Property „LastUpdateTime
„, die man verzweifelt in der Doku gesucht hat. Sie gibt an, wann der Job das letzte Mal geändert / bearbeitet wurde. Dieser Zeitstempel kann verwendet werden, um zu entscheiden, ob der lokale Datensatz aktualisiert werden muss.
Warum überhaupt die Daten lokal speichern? Weil die API von zvoove bei der Abfrage vieler Datensätze relativ langsam werden kann. Das würde sich unmittelbar auf die Ladezeiten der eigenen Homepage auswirken – und von dieser Abhängigkeit möchte man sich evtl. gerne befreien.
Details zu einem Job laden
Für das Laden der Details zu einem Job gibt es zwei Endpoints:
GET /api/public/v1/Stelle/GetStelleById
POST /api/public/v1/Stelle/GetStellenByIds
Einen einzelnen Job anhand der stellenUuid laden
Der erste Endpoint dient dazu, eine einzelne Stelle anhand der stelleUuid
zu laden. Da es sich um einen GET Request handelt, genügt es wieder die Variable im QueryString mitzuschicken. Auch hier ist kein API-Key erforderlich, man kann sich das JSON mit den Details zu einem Job durch einen einfachen Aufruf im Browser anschauen (von jedem beliebigen Kunden von zvoove).
Hier ein Beispiel (Link im Browser öffnen). Es kann natürlich sein, dass die Stelle im angegebenen Beispiel nicht mehr existiert – aber das Prinzip sollte klar sein:
https://bhm.europersonal.com/api/public/v1/Stelle/GetStelleById?stelleUuid=dda62c7e-dca3-421b-951e-ea743c20f647
Viele Jobs anhand einer Liste von stellenUuids laden
Beim Synchronisieren vieler Jobs kann der zweite Endpoint hilfreich sein: /api
erlaubt es, im POST-Request ein Array mit stellenUuids (als JSON) zu übergeben und so eine ganze Liste von Jobs mit allen erforderlichen Details und Properties zu erhalten.
Hier ein Beispiel für einen POST-Request in PHP, um von zvoove mehrere Jobs anhand der StellenUuids zu laden:
<?php
$url = "https://bhm.europersonal.com/api/public/v1/Stelle/GetStellenByIds";
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_POST, true);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
$headers = array(
"Accept: application/json",
"Content-Type: application/json",
);
curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
$json = json_encode([
'dda62c7e-dca3-421b-951e-ea743c20f647',
'6988c203-98f0-4bee-91ad-cb5e5c069025'
]);
curl_setopt($curl, CURLOPT_POSTFIELDS, $json);
$resp = curl_exec($curl);
curl_close($curl);
$data = json_decode($resp, true);
print_r($data);
Wichtige Erkenntnisse aus der Implementierung – unbedingt bei einer Kalkulation berücksichtigen:
- zvoove nutzt einen relativ schlechten RTE (Rich Text Editor) und bereinigt die Daten aus dem Texteditor nicht. Kopiert der Kunde Texte aus Word oder von seiner Webseite in den Editor, dann erhält man einen Irrsinn aus Inline-Styles, Formattierungen, Schriftangaben etc. Die Texte müssen vor Ausgabe auf der Webseite unbedingt bereinigt werden – eine gute Bibliothek dafür ist z.B. htmlpurifier.
- Das Feld
Abteilung
ist – wie oben erwähnt – eigentlich eine Relation, wird aber als komma-separierter String zurückgegeben. Möchte man die Daten lokal speichern, muss man den String am Komma trennen, die richtigen Relationen anhand der Labels finden und dann wieder in echte Relationen umwandeln – ein sehr unschönes und fehleranfälliges Thema.