Dokumentation

SOCIAL E-PLATTFORM LOVEBUMBLE

– Vereinfachte Methodendokumentation, Features/Funktionen der Member-Dating-Plattform Lovebumble, zuhanden Kunde
– Entwickelt von: Gregor Lemmenmeier (Website www.greg.ch): Detailkonzeption, Programmierung, Datenbank-Entwicklung, Layouts, Designs, partiell Textentwicklung, Security, ePayment, Installation, Suchmaschinenoptimierung, Testing, Support
– Entwickelt nach den Kundenwünschen von: Pamment Projects GmbH, Zürich

1. Zusammenfassung
2. Generelle Site-Funktionen
3. Zugangsbereich "Visitors"
4. Geschützter Zugangsbereich "Members"
5. Geschützter Zugangsbereich "Coaches"
6. Geschützter Zugangsbereich "Admins"
7. Verschiedenes


1. Zusammenfassung

1.01. Komponenten der Website
Diese Website besteht aus:

Über 1'000 Funktionen (rund 270 Scripts), 154 Menupunkte in 8 verschiedenen und dynamisch ändernden Menus, 107 Einzelseiten, 34 Hilfstexte, 3 passwortgeschützte Zugangsbereiche, 5 Zahlungsmethoden, etc.

Der Zweck der Website ist, Menschen auf der Suche nach einer passenden Liebesbeziehung zu unterstützen. Die Kernaktivität in der Website ist das Bearbeiten von Datingvorschlägen im Matchingfenster und die Kommunikation mit vorgeschlagenen Members via Member Messaging System. Das Herzstück des Systems ist der "Matching-Generator", der als justierbares Analyseprogramm die Partneranalyse bzw. das Partner-Matching anhand der verschiedensten Kriterien und Kombinationsmöglichkeiten erledigt.

Das Meiste davon wurde zweisprachig in Deutsch und in Englisch entwickelt. Die über 1'000 Funktionen sowie Layouts, Designs, 2 Logos, Multimediamovies, und viele der Texte, Namings, Wordings, Profilfragen, kontextabhängigen Hilfstexte etc. mussten vom Entwickler speziell für diese Website konzipiert, entwickelt und getestet werden. Alle Daten, Menus, Statusdefinitionen, Logs, Spezialstatistiken etc. werden in einer Web-Datenbank gespeichert und auf der Systemebene verwaltet. Diese stellt die gewünschte Funktionalität bereit.

Die Programmierung ist luxuriös in dem Sinne, dass es für Users keine kryptischen Codes und Vorgänge gibt. Alles erscheint in Klartext, wird in Klartext protokolliert, und auch im Adminsystem gibt es keine der typischen, unverständlichen Computer-Ausdrücke. Alles wird vom System möglichst verständlich und kompakt kommuniziert. Gerade das CMS ist somit in keinster Weise mit den üblichen, schwer verständlichen und stark von Spezialausdrücken durchsetzten CMS zu vergleichen. Von der Software merkt man wenig. Die Admins haben eine Vielzahl von Kontrollmechanismen, vollautomatischen Auswertungen zur Performance der Website und viele Editing-Tools zur Verfügung. Nur so konnten die Website und die vielen verschiedenen User-Aktionen auch für Admins ausreichend transparent gemacht werden. Ferner musste das System besonders stark gegen mögliche Angriffe (z.B. durch nigerianische Love Scammers und eifersüchtige Lebenspartner von Clubmitgliedern) abgeschirmt werden.

Aus der obigen Logik ergibt sich die Arbeitsweise. Obwohl die Website visuell einfach wirkt (und wirken soll), konnte diesmal eigentlich gar nichts linear gemacht werden. Die Site ist voller Ausnahmen auf jeder Ebene. Dies war die Problemstellung, die zu bewältigen war.

Da die Website unter einer neuen, nicht Keyword-relevanten Domain im momentan am stärksten boomenden Webbusiness antritt (Online-Dating / Social Websites) und die Matching- und Weiterempfehlungs-Mechanik der Site erst ab einer gewissen Anzahl Members zu spielen beginnt, musste ein grosser Konzeptions- und Entwicklungsaufwand in den Bereich SEO (Suchmaschinenoptimierung) investiert werden.

- Hierin beschrieben sind lediglich die für ein tieferes Verständnis der Plattform relevanten Features - nicht aber simple HTML-Seiten oder Infoseiten. Wo ein Fachbegriff unbekannt ist, hilft Google.

1.02. Die vier Zugangsbereiche
A) Visitors
Der öffentliche Teil (public area), den man als anonymer Nutzer beim normalen Besuch sieht. Dieser Teil ist der am wenigsten komplexe, alle anderen Sektoren sind vielfach komplexer. Navigation: 3 Menus (Hauptmenu, Topmenu, Blogmenu) und eine zweisprachige, direkt aus der Datenbank generierte Sitemap.

B) Members
Passwortgeschütztes Login via kombinierte Loginbox, die auch von Coaches benutzt wird. Navigation: Separates Member-Menu mit 7 Menupunkten, viele Spezialfunktionen.

C) Coaches
Passwortgeschütztes Login via kombinierte Loginbox, die auch von Members benutzt wird. Navigation: Separates Coach-Menu mit 4 Menupunkten, viele Spezialfunktionen. Der Coaching-Teil d.h. alle vier dazugehörigen Bereiche für Visitors/Members/Coaches/Admins musste so entwickelt und bezüglich Datenbanken strukturiert werden, dass dieser Teil im Bedarfsfalle mit relativ wenig Aufwand als separat operative Website ausgelagert (entkoppelt) werden könnte.

D) Admins
Passwortgeschütztes Login via separate Administratoren-Loginseite. Navigation: Admin-Menu mit 48 Menupunkten, sehr viele Spezialfunktionen, Statistiken etc. Der Admin-Zugang ist via Rollenmodell und Zugangsbereich-Zuordnung geregelt. Admins haben individuell einstellbare Zugangsberechtigungen zu den einzelnen Bereichen sowie individuell einstellbare Benachrichtigungs-Präferenzen.

1.03. Web-Technologien
A) FRONTEND (User Interface) — der Entwickler arbeitete mit folgenden Technologien, die Links führen zu Lernseiten:
Valid HTML, CSS, Javascript, AJAX, WYSIWYG Editor, PHP, Google Maps API, ActionScript.

B) BACKEND (Systemebene) — der Entwickler arbeitete mit folgenden Technologien, die Links führen zu Lernseiten:
PHP Programmiersprache, MySQL Datenbank mit rund 40 Datenbanktabellen, SSL, Proxyserver, Cron Jobs, cURL, GDLib, XML, htaccess, PDF-Generator etc.

Spezielles zu SSL: Das SSL läuft so, dass je nach Access-Freigabestatus einer Webpage (abhängig von der für die Webpage individuell definierten Login-Anforderung, dem User-Typus und seinem aktuellen Login-Status) das SSL automatisch ein- oder ausgeschaltet wird. Falls eingeschaltet, wird SSL erzwungen, sogar falls die HTTPS URL manuell verändert wird. Im Adminsystem können Admins frei definieren, welche Webpage welches Login erfordert und ob die Webpage mit SSL laufen muss oder nicht. Diese hohe Flexibilität war notwendig (nicht zuletzt wegen der Problematik: Google Maps via SSL).

Spezielles zu .htaccess: Zwecks SEO und Verhinderung von Double Content Penalties muss verhindert werden, dass eine Domain mit http://domain.com und auch mit http://www.domain.com aufgerufen kann. Darum wurde ein entsprechender 301 Redirect installiert.

Spezielles zu Cron Jobs: Diese steuern das "Housekeeping Script", ein zeitgesteuertes Programm, das Aufräum-Aufgaben abarbeitet. Dazu gehört zum Beispiel: Accounts bearbeiten die abgelaufen sind, Account-Statusdefinitionen je nach Situation und Zeitfenster ändern, Coaching-Testfragen bearbeiten die abgelaufen sind, und das aktuelle Alter aller Members updaten (wäre als rein dynamische Berechnung zu ineffizient für den Matching-Generator sobald es viele Members hat). Jedes Mal, wenn das Housekeeping-Programm verändert wird, muss beim Webhost im Cron Job Panel ebenfalls neu gespeichert werden (!)

Bei einer Dating-Site sollten bestimmte Länder komplett geblockt d.h. vom Besuch der Website ausgeschlossen werden. Hierbei handelt es sich um Länder, die für betrügerische Love-Scams, 419 Scams, Hacking (Cracking/Defacement), Relay-Spam und Formular-Spam berüchtigt sind. Der aktuelle Hoster erlaubt kein simples Country Blocking auf TLD Level via ".htaccess" Datei. Deshalb musste zu diesem Zweck ein umfangreiches IP2Country Modul integriert werden, das eine Reihe von Ländern blockt. Das IP2Country Modul wird auf jeder Seite geladen, was zwar die Ladezeiten minim verschlechtert, aber aufgrund der Erfahrungen notwendig ist. Geblockt werden folgende Länder in Übereinstimmung mit den aktuellen und im Web publizierten Empfehlungen: Nigeria, China, Russia, Ukraine, Korea, Taiwan, Senegal, Cote d'Ivoire, Ghana, Argentina, Brazil, Singapore, Malaysia, Hong Kong. Zusätzlich zum Country Blocking blockt das System einzelne unerwünschte IP-Adressen (via IP Bans).

C) Externe Module
- Google Maps 2, Saferpay VT.

Spezielles zu Maps: Für die verschiedenen Map-Applikationen verwendete der Entwickler das API (Programmier-Schnittstelle) und programmierte spezielle Funktionen wie z.B. Plotting von Radien (Radiusberechnung und -Anzeige für 2 mögliche Dating-Partner wobei 2 Kreise auf die Map gezeichnet und 4 Distanzen, z.B. Member-Distanz, Kreis-Überschneidungen etc. gemäss Geometrie berechnet werden), Standort-Erkennung (nach Adresseingabe erscheint der Landkarten-Standort), etc. Die drei Google Maps API Keys (für .com .ch .ca) durften nicht statisch (hardcoded) sein, sondern werden passend zur jeweiligen Domain aus der Datenbank geladen und in die verschiedenen Requests integriert.

Spezielles zu Saferpay: Für das Saferpay Virtual Terminal programmierte der Entwickler ein spezielles Transaktions-Interface mit der "cURL Library". Nur so ist sichergestellt, dass diese Funktionen auch dann laufen, wenn die Site bei einem Hoster läuft der "fopen" deaktiviert hat. Auch designte der Entwickler das Saferpay VT so, dass es den Grundfarben der Website entspricht (Türkis und Orange), verbreiterte das Fenster für Firefox-User (wäre sonst zu schmal), und reduzierte die Auswahlsprachen auf Deutsch und Englisch. Das VT wird also automatisch mit derselben Sprache wie die aktuell gewählte Website-Version gestartet. Für den Aufruf des VT war noch eine Speziallösung notwendig, denn ein Script das normalerweise bei Saferpay läuft, musste direkt in die LB-Website integriert werden. Dies wird also nicht extern sondern intern aufgerufen.

D) Security
Dating-Sites sind sehr beliebte Angriffsziele. Einige der hier implementierten Sicherheitsmassnahmen sind: SSL (flexibel via Adminsystem ein- und ausschaltbar für jede Webpage), Klartext-Protokollierung sämtlicher User-Aktionen mitsamt IP-Adresse / Host-Adresse / WHOIS-Link, Country Blocking mittels IP2Country Modul, IP Banning, Cracktracker, Formspam-Schutz, Spambot Harvester Trap, MySQL Injection Prevention, "Sleep" Verzögerung nach Falscheingabe, automatische Email bei Failed Admin Login, Smutfilter etc. - selbstverständlich werden hier nicht alle implementierten Sicherheitsmassnahmen aufgeführt. Üblicherweise sind gehostete Websites gut durch den Webhost geschützt. Sobald für die Website ein eigener Server betrieben wird, braucht es weitere Sicherheitsmassnahmen.

1.04. Spezialmodule
Es gibt etliche zweisprachig entwickelte Spezialmodule, hier kurz zusammengefasst:

1.05. Zahlungsmethoden
Es gibt in dieser Website ausnahmsweise 5 verschiedene Zahlungsmöglichkeiten und die jeweils dazugehörigen Ablaufprozesse, Plausibilitätschecks, Admin-Tools etc. Alle Gebühren, Credits-Umrechnungen etc. können flexibel via Adminsystem definiert werden.

A) Kreditkarte
Es wird in den Zahlungsseiten direkt angezeigt, welche Kreditkarten momentan akzeptiert werden. Dies kann flexibel via Adminsystem definiert werden. Die KK-Zahlungen werden über das Saferpay System abgewickelt, wobei keinerlei Kreditkartendaten im eigenen System (in dieser Website) gespeichert werden können. Das Transaktions-Interface realisierte der Entwickler selber mittels der "cURL Library", um die volle Kompatibilität mit allen Hostern und ein detailliertes Payment-Logging zu ermöglichen.

B) Banküberweisung
Die Admins können je nach User-Nachfrageentwicklung im Adminsystem einstellen, ob auch Bezahlung per Überweisung/Rechnung angeboten wird. Für diese Fälle beinhaltet das Adminsystem eine Buchhaltung der noch offenen und bereits eingegangenen Banküberweisungen. Die Admins müssen bei Zahlungseingang ein Memberaccount manuell freischalten. Eine Rechnung im PDF-Format wird automatisch erzeugt. Die Zahlungsinstruktionen werden flexibel im Adminsystem definiert - Deutsch und Englisch getrennt da sich die jeweiligen Bankdetails unterscheiden.

C) Promocode
Falls ein anmeldendes Member einen Promotion Code als Teil einer Marketingaktion von LB gesehen oder direkt erhalten hat, kann dieser Code bei der Anmeldung eingetragen werden. Der entsprechende Rabatt wird abgezogen und der reduzierte Betrag kann via Kreditkarte (oder Banküberweisung falls aktuell möglich) bezahlt werden.

D) 100% Promocode
Als Ausnahme musste programmiert werden, dass auch Promocodes mit 100% Rabatt definierbar sind (demnach kostenlos und eigentlich kein Rabatt).

E) Gutschein
Geschenkgutscheine können entweder von Visitors oder von eingeloggten Members gekauft werden. Die Gebühren sind via Adminsystem flexibel definierbar. Visitors könnnen nur via Kreditkarte bezahlen, Members jedoch wahlweise auch mit Credits, falls der Credits-Saldo genügend hoch ist. Solche Infos werden vom System auf den jeweiligen Seiten in Klartext angezeigt.

Bei Coach-Anmeldungen ist der Ablaufprozess wiederum anders.

1.06. Benachrichtigungen
Das System versendet vollautomatisch generierte, verschieden vorgetextete Emails in Deutsch und in Englisch. Teils in Plaintext, teils in Richtext mitsamt Design und Logo und Member-Foto. Teils nur an eine Einzelperson, teils an mehrere Empfänger als "Serienbriefe" (Admin Notifications und Weiterempfehlungen). Zudem erzeugt das System verschiedene Arten von Rechnungen im PDF-Format mit aktuellen Daten aus der Datenbank.

A) Member als Empfänger:
B) Freunde von Members als Empfänger:
Es können gleichzeitig bis 7 Weiterempfehlungen gesendet werden, mit Namen des empfehlenden Members und mit speziell codiertem Referrer-Link. Selbstverständlich kann der Email-Text und der Betreff noch vor dem Absenden editiert werden - jedoch nicht der Referrer-Link, da dessen Mechanik sonst nicht gewährleistet werden könnte. Der Referrer-Link wird also erst beim Serienversand in die Emails integriert.

C) Coach(es) als Empfänger:
D) Admins als Empfänger:
E) Entwickler als Empfänger:
1.07. Das spezielle CMS
Das CMS (Content Management System) umfasst Layout-Steuerungen für alle 4 User-Sektoren sowie eine Vielzahl von Funktionen im Adminsystem.

Die Website ist durch die Betreiberfirma selbst verwaltbar. Hauptmenu, Topmenu, Hierarchie der Menus, SSL, Login, Seitentitel, Inhalte der Webpages, hochgeladene Bilder und Dokumente, neue Uploads, Links, Blogposts, Magazin-Ausgaben, Events etc. können je nach Bedarf editiert, hinzugefügt oder gelöscht werden.

Wie immer bei kompletten E-Plattformen der Webagentur GREG.CH ist das CMS eine komplette Massanfertigung (selbst konzipiert und programmiert) und besteht aus genau denjenigen sinnvollen Funktionen, die einerseits benötigt und andererseits vom Auftraggeber zusätzlich gewünscht wurden. Es gibt somit keine umständlichen Prozeduren oder kryptischen Bedienungsvorgänge - und keinerlei Ballast, wie dies bei marktüblichen CMS der Fall wäre. Davon abgesehen wären marktübliche CMS (wie z.B. Typo3) nicht einmal annähernd in der Lage, die vielen in dieser Website benötigten Spezialfunktionen und über mehrere Ebenen verknüpften Ablaufprozesse überhaupt auszuführen.

Die Ausnahme bei dieser Website ist, dass das CMS vielfach flexibler sein musste, als dies normalerweise bei einem massgeschneiderten CMS nötig ist. Die Steuerung des Layouts ist von Ausnahmen durchzogen: Es gibt ein Submenu das oben steht, es gibt Frames links und rechts, die je nach Seitenwahl, Sektorwahl und sogar Login-Status ändern, gar nicht angezeigt werden, aktualisiert oder nicht aktualisiert werden, etc. Je nach Login-Status wird rechts ein Hinweis "Anmeldung" angezeigt oder nicht. Es gibt einen Newsframe links in der Startseite, der editierbar sein musste, obwohl er keine Webpage ist. Es gibt Menupunkte, die situativ ändern und zusätzlich je nach Accountstatus und Loginstatus ausgeblendet werden müssen. Beispiel: Ist ein Konto deaktiviert, dann muss gleich an 3 Stellen eine Filterung, jedes Mal anders, erfolgen (im Member-Menu, im Hauptmenu und in der Sitemap). Auch andere Teile der Website beruhen auf Ausnahmen. Zum Beispiel das Membermenu, in dem je nach Member und Situation zusätzliche Sektoren wie "Coaching" und "Rankings" angezeigt werden. Zudem gibt es Seiten, die nach einer bestimmten Aktion den Benutzer auf eine ganz andere Seite weiterleiten müssen. Oder AdSense Ads, die weder auf SSL-Seiten noch in passwortgeschützten Bereichen erscheinen dürfen. Und so weiter.

Die Datenorganisation ist transparent und sauber strukturiert. An allen entscheidenden Punkten sitzen Log-Mechanismen, die sämtliche Aktionen von Besuchern/Members/Coaches/Admins in Klartext (mit verständlicher Beschreibung) protokollieren und mitsamt Direktlinks zu den jeweils betroffenen Modulen (z.B. Member-Account, Promo-Code Verwaltung, Events etc.) abrufbar halten.

Bilddateien werden über mehrere, verschieden programmierte Upload-Module hochgeladen. Dabei wird der Dateiname von Sonderzeichen und Leerschlägen befreit (zwecks Verhinderung von Problemen auf dem Linux-Server), der Dateityp geprüft, das Bild nötigenfalls verkleinert (es gibt hierfür gleich mehrere Grössendefinitionen je nach Einsatzzweck) und je nachdem ein Thumbnail automatisch angefertigt und auch in der Datenbank gespeichert.

Das Editieren und Erfassen von Webpages läuft voll zweisprachig mit einem Menu-Editiersystem und einem Webpage-Editor. Der Editor ist deutlich besser als die üblichen Webpage-Editoren, die man sonst in Content Management Systemen findet. Es können auch vordefinierte Bausteine (Objekte), CSS-Styles, interne Links (auch zu bestimmten Blogposts etc.), Bilder und Dateien (mitsamt Dateiverwaltung), vielfältig definierte Tabellen, Website-spezifische Farben und so weiter in Webpages integriert werden. Ausserdem ist der Webpage-Editor übersichtlicher und einfacher bedienbar als die üblichen Editoren. Zudem gibt es keine der sonst üblichen, aber unsinnigen Formatierungen wie "underline".

Eine derart flexible und auf extrem vielen Ausnahmen beruhende Website-Struktur ist mit marktüblichen CMS (z.B. Typo3 oder Drupal) unmöglich realisierbar. Doch kein Problem, das ganze CMS und die verschiedenen Frameworks wurden sowieso speziell für diese Website programmiert.

1.08. Statusdefinitionen
Wie bei solchen, stark prozessorientierten E-Plattformen üblich, basiert die ganze Systemlogik der Website auf dem jeweiligen Status (Zustandscode) eines Accounts, eines Vorganges oder einer Aktion. Für diese Website mussten gemäss Bedarfsanalyse sehr spezielle Statusdefinitionen eingeführt werden. Alle Statusdefinitionen wurden in Englisch definiert um im deutschsprachigen Adminsystem eine klare Trennung zu haben, umso mehr als das System wie üblich in Englisch entwickelt wurde.

A) Ein Member-Account hat 5 mögliche Statusdefinitionen und 2 mögliche MG-Definitionen.
Matchinggenerator-Status:
Das Website-System berücksichtigt für viele Funktionen eine Kombination des Accountstatus und des MG-Status. So lange das Reisegepäck (2. Profilteil) noch nicht ausgefüllt ist, wird das Member nach Login dorthin geleitet. Sobald das Member sein Reisegepäck ausfüllt, wechselt das System den MG-Status von "blocking" zu "receiving". Der Matchinggenerator läuft erst für das Member, wenn das Reisegepäck ausgefüllt und keine Zahlung offen ist.
Zudem wird der Activity Level ermittelt. Diesen gibt es nur für Members:
Pro Login 1 Punkt, pro Profil-Update 2 Punkte, pro Member-Message 5 Punkte, pro Kommentar im Blog oder Magazin 7 Punkte, pro Coach-Anfrage 7 Punkte, pro Event-Anmeldung 10 Punkte, pro erfolgreiche Weiterempfehlung 10 Punkte. Der Activity Level ist nicht etwa verknüpft mit dem Credits-Saldo, sondern dient lediglich den Admins zur Erkennung derjenigen Members, die besonders aktiv sind. Bei der Organisation von z.B. Events oder der Vergabe von Assistant Admin Positionen werden besonders aktive Members in die engere Wahl gezogen.

B) Ein Coach-Acocunt hat 3 mögliche Statusdefinitionen: Zudem gibt es hier eine Statusdefiniton für die (wählbare) Teilnahme am Testfragenpool.

C) Ein Admin-Account hat 2 mögliche Statusdefinitionen:
D) Ein Matching (Datingvorschlag) hat 8 mögliche Statusdefinitionen, die teils automatisch aufgrund einer aktuellen Situation oder User-Aktion, teils durch Administratoren und teils durch das via Cronjob zeitgesteuerte Housekeeping Script geändert werden können. Der Status besteht für jedes Matching 2 Mal, denn er muss für beide beteiligten Members separat definiert werden. Wichtig ist hier auch das Datum, an dem das eine oder andere Member den aktuellen Status setzte. Die Statusdefinitionen bei den Member-Ratings sind analog zu diesen definiert.
Sobald eine Mission beendet wird, erscheint der Datingvorschlag nicht mehr. Beim Beenden gibt es 4 spezielle Statusdefinitionen (als "Missionsresultat"): Diese 4 Statusdefinitionen werden vom System unterschiedlich behandelt. Bei Typ 2 bis 4 werden neue Datingvorschläge erzeugt. Negative Missionsresultate werden gesondert ausgewertet, so dass im Adminsystem ersichtlich ist, welche Members besonders oft ein negatives Resultat erzeugt haben.

E) Ein To-Do Item (im Member-Menu) hat 2 mögliche Statusdefinitionen:
F) Eine Member-Message hat 2 mögliche Statusdefinitionen:
G) Ein Member-Kommentar (im Blog oder Magazin) hat 2 mögliche Statusdefinitionen:
H) Eine Profilfrage hat folgende spezielle Statusdefinitonen:
Input-Format: Um den Input der Profilfragen voll editierbar zu machen, wurde hierfür ein spezielles Framework entwickelt. Via Adminsystem kann das Input-Formate für jede einzelne Profilfrage flexibel definiert werden. Jedes Input-Format wird dann bei der Speicherung vom System anders verarbeitet. Die möglichen Input-Formate sind: "text", "textarea", "textareaandfile", "textareaandtext", "select", "selectandtext", "checkboxes", "radioandtext", "upload", "uploadandtext".
Zudem werden hierbei Gewichtungs-Punkte pro Frage definiert, welche bei der Berechnung des Datingfaktors mit berücksichtigt werden.

I) Ein einzelner Gutschein (nicht Batch) hat 3 mögliche Statusdefinitionen: Zudem wird hier für den dazugehörigen Batch als Status ermittelt, wie viele der Gutscheine in einem Batch bereits eingelöst wurden, und wie lange die Gutscheine in einem Batch ab heute noch gültig sind.

J) Eine Magazin-Ausgabe hat 2 mögliche Statusdefinitionen:
K) Eine Zahlung im Payment Log hat 2 mögliche Statusdefinitionen:
L) Ein Matchinggenerator-Kriterium hat bezüglich Justierung 2 mögliche Statusdefinitionen:
M) Eine Webpage hat folgende Statusdefinitionen:
2. Generelle Site-Funktionen

2.01. Layout-Funktionen
Das CSS-File (Stylesheet) wird direkt mit PHP generiert. Das PHP-Script beinhaltet auch dynamische Komponenten wie Style-Anweisungen, die abhängig vom jeweiligen User-Browser sind. Ins Stylesheet werden auch die Website-spezifischen Farben aus der Datenbank integriert, sowie die fürs Print Layout nötigen Spezifikationen. Diese sehr spezielle Lösung ist maximal flexibel und kompakt. Sie erlaubt auf einfachste Weise die gezielte Definition von Styles pro Browser / Website-Sektor / Webpage / Loginstatus, und die beliebige Übertragung von Website-Grundfarben auf andere Objekte.

Auf das Template/Presentation Framework "Smarty" wurde verzichtet, da dieses nur zusätzlichen Overhead erzeugt und die Ladezeiten verschlechtert. Vor allem aber wäre Smarty bei diesem Ausnahmen-basierten Layout vollständig überfordert gewesen. Statt dessen wurde ein eigenes Templating-System entwickelt, das in der Lage ist, alle Ausnahmen (verschiedenste Seitenlayouts und dynamisch ändernde Menus) sowie die Zweisprachigkeit zu managen.

Das System verhindert, dass eingebettete Programme separat aufgerufen werden können. Selbst wenn ein Hacker den Dateinamen eines der vielen eingebetteten Programm-Scripts (z.B. memberfees.php) herausfinden sollte, ist es unmöglich, dieses getrennt von der Website aufzurufen. Das System schaltet in diesem Falle auf die Index-Seite.

Für die Pop-Ups musste ein spezielles System entwickelt werden. Grundsätzlich kann jede Webpage dieser Website auch als Pop-Up definiert werden, in welchem dann nur der zentrale Inhalt ohne die Sitemenus etc. erscheinen. Diese Teile werden also ausgefiltert. Nun war es aber so, dass der Auftraggeber in einigen Seiten, die auch als Pop-Up zur Verfügung stehen müssen (z.B. AGB, Coaching Leitsätze etc.) auch Links definiert hatte. Aber solche Links können nicht funktionieren wenn das Pop-Up geladen ist, vor allem nicht im Firefox-Browser, der je nach Settings einfach einen neuen Tab erzeugt der im selben Pop-Up erscheint. Um dies zu lösen, wurde ein Parser entwickelt, der alle aktiven Links in Plaintext umwandelt, falls die Webpage als Pop-Up geladen wird. Ausnahme sind natürlich die aufklappbaren Textblöcke ("toggle blocks").

Die Seitentitel werden dynamisch als Grafiken mit einer speziellen Designerschrift erzeugt, die punkto Schriftbild vermutlich die am meisten harmonische Schriftart überhaupt ist. Sobald im Adminsystem ein anderer Seitentitel definiert wird, erzeugt das System eine neue Grafik mit dem dafür entwickelten Generator. Damit die Schriftgrafiken nicht bei jedem Ladevorgang neu generiert werden müssen, wurde hierfür ein Caching Mechanismus entwickelt, der die Grafiken auf dem Server speichert und bei jedem Ladevorgang prüft, ob ein Seitentitel geändert wurde.

Einige Textareas (grosse Texteingabefelder) sind mit einer Zeichenanzahl-Begrenzung und laufender Anzeige der noch verbleibenden Zeichen programmiert.

Tabellen-Zeilen werden beim Darüberfahren visuell hervorgehoben, um so die Übersichtlichkeit zu steigern. Dies funktioniert auch im IE.

Texteingabefelder werden bei der Eingabe grün umrahmt, was die Usability erhöht.

Es gibt zwecks Usability drei verschieden designte Button-Typen: Submit, Store, Delete. Lösch-Buttons haben einen roten Balken und leuchten beim Darüberfahren rot auf. Bei kritischen Aktionen fragt das System zuerst mit einem detaillierten Hinweis auf die Konsequenzen nach, ob die Aktion wirklich ausgeführt werden soll.

Nach allen relevanten Aktionen in den geschützten Zugangsbereichen für Members/Coaches/Admins erfolgt eine On-Screen Bestätigung, die kurz erscheint und die Aktion in Klartext bestätigt. Gleichzeitig wird die Datenbank aktualisiert, die Aktion mit allen wichtigen Details im Actionlog protokolliert und in einigen Fällen dieselbe Seite neu geladen, in vielen Fällen aber gleich auf eine andere Seite geleitet. Beispiel: Im Member-Bereich erfolgt nach dem Editieren des eigenen "Passports" eine automatische Weiterleitung zur Seite "Datingvorschläge" (Matchingfenster), da dort das Resultat des Passport-Editings in Form von neuen Datingvorschlägen sichtbar sein könnte.

Kontextuelle Hilfstexte sind nicht als Pop-Ups definiert (da diese unbeliebt sind), sondern als "pure CSS Pop-Ups" die ohne Fenster und Javascript funktionieren. Solche CSS Pop-Ups mussten in 6 verschiedenen Versionen entwickelt werden. Je nach Einsatzzweck brauchte es verschiedene Grössen, Positionierungen und Farben.

Sobald ein nicht eingeloggtes Member die Startseite verlässt und nicht auf der Anmeldeseite ist, erscheint in den meisten Fällen rechts ein "Reminder" d.h. eine Aufforderung, sich anzumelden. So bleibt der Anmelde-Link stets in Griffweite für Visitors, die zuerst die Website erkunden möchten, bevor sie sich zur Member-Anmeldung entschliessen. Die Steuerung dieser Funktion ist spezifisch d.h. pro Webpage geregelt.

Es wurde ein "Favicon" designt (Bookmark-Icon), das in der Adresszeile des Browsers sowie in Bookmarks erscheint. Dies funktioniert immer im Firefox, während der IE damit öfters Probleme hat (Bug).

Es wurde ein herzförmiger Cursor integriert (Firefox), der aber auf bestimmten Seiten ausgeblendet wird (z.B. im Adminsystem, im Member-Messaging System etc.) um nicht beim Schreiben im Editor zu stören.

Als Special wurden auf Wunsch einige private Gemälde des Auftraggebers in die Frames rechts integriert, um so einen weiteren persönlichen Bezug herzustellen. Die Gemälde mussten dazu zuerst grafisch bearbeitet werden (weisse Hintergründe, Konturschärfung etc.)

Selbstverständlich wurde in dieser Website auf echte "HTML Frames" verzichtet, weil HTML Frames im modernen Webdesign vermieden werden sollen. Die Bezeichnung "Frames" bedeutet hierin also lediglich einen klar abgetrennten Abschnitt im Layout (z.B. der Newsframe links in der Startseite).

2.02. Sprachen-Management
Falls noch keine manuelle Sprach-Umschaltung vorgenommen wurde, erfolgt die Auslieferung der passenden Website-Version gemäss Browsersprache nach der Regel: Falls kein deutschsprachiger Browser, wird die englische Website-Version ausgeliefert.

Der Sprach-Umschalter funktioniert so, dass direkt von einer deutschen auf die entsprechende englische Webpage umgeschaltet werden kann (same level language switching). Ähnlich funktioniert auch die zweisprachige, automatisch und situationsabhängig (je nach aktuellem Loginstatus etc.) aus der Datenbank generierte Sitemap.

Die Localizations, wo sie z.B. Hilfstexte und On-Screen Meldungen betreffen, sind direkt zweisprachig in die jeweiligen Webpages implementiert bzw. hardcoded, was das Editieren der vielen enthaltenen Detailtexte sehr viel übersichtlicher macht, als wenn wie üblich die mehrsprachigen Detailtexte in der Datenbank ausgelagert werden. Zudem wäre die Auslagerungsmethode in dieser Website völlig unbrauchbar, denn sehr viele Detailtexte wie z.B. Fehlermeldungen in dieser Website beinhalten auch dynamische (aus der Datenbank aktuell abgerufene) Daten zwecks erhöhter Verständlichkeit für die Benutzer. Ein selbst entwickelter Parser konvertiert zur Laufzeit alle Umlaute, Sonderzeichen, Ampersands in Links (wichtig für die HTML Validation) etc. Dafür wird der gesamte sichtbare Output eines PHP-Scripts zunächst auf dem Server gebuffert, vor der Auslieferung geparst, und erst dann an den Browser ausgeliefert. Dies bringt die für diese Website nötige Flexibilität in der Output-Steuerung, es hat auf die Ladezeiten der Webpages keinen nennenswerten Einfluss.

Das Sprachen-Management erledigt ausserdem automatisch die Umwandlung in deutsche Mehrzahlformen je nach Situation (z.B. "ein Gutschein, sieben Gutschein-e-").

Wenn ein Member eingeloggt ist und sein Account in Englisch ist, kann das Member nach dem Login unmöglich zur deutschen Version wechseln. Und umgekehrt. Denn dies könnte bei nachfolgenden Dateneingaben eine Inkongruenz erzeugen, vor allem im Rahmen von Datingvorschlägen und Member Messages. Also verhindert das System ab dem Login zur Sicherheit einen Sprachenwechsel.

Per Statistik im Adminsystem wird erfasst, wie die Sprachwahl Deutsch/Englisch bisher aussieht. So kann je nach tatsächlicher Benutzung (User-Nachfrage) entschieden werden, welche Sprachversion "wichtiger" ist und noch optimiert werden soll. Falls überwiegend die englische Version benutzt wird, lohnen sich weitere Übersetzungsaufwände.

2.03. Das Hauptmenu
Die Website wird primär mit einem dreistufigen Hauptmenu und einem Topmenu (oben rechts) navigiert. Das Hauptmenu ist zwar in der Bedienung übersichtlich und einfach, technisch jedoch ausserordentlich komplex. Jeder Menupunkt wird bei jedem Ladevorgang neu nach folgenden Kriterien überprüft und entsprechend im Menu dargestellt:

- Access-Status:
Die aktuellen Zugangsberechtigungen zu den Seiten sind direkt ersichtlich und werden mit grünen Pfeilen (= Zugang zu dieser Webpage offen) oder Schlüsseln (= Zugang zu dieser Webpage momentan gesperrt) visualisiert. Wo zuerst ein Login notwendig ist, wird ein Schlüssel angezeigt und bei Darüberfahren erscheint der notwendige Logintypus (Member oder Coach Login). Sobald der User einloggt, werden die definierten Seiten freigeschaltet und die Schlüssel werden durch grüne Pfeile ersetzt. Für eingeloggte Members und Coaches erscheint zudem im unteren linken Bereich ein spezielles Submenu.

- Blogposts, Ezine Issues und Events:
Diese 3 Bereiche wurden zwecks Übersichtlichkeit direkt in das Hauptmenu integriert und werden sehr speziell gehandhabt. Bei jedem Ladevorgang wird überprüft, ob es neue Einträge hat. Bei Blogposts wird das gebloggte Datum angezeigt, bei Magazin-Ausgaben der Monat der Ausgabe, und bei Events das Startdatum der Veranstaltung. Zudem wird die Breite der Menupunkte für diese 3 Bereiche einzeln so adjustiert, dass genügend Platz besteht. Die Menupunkte werden sinnvollerweise so geordnet, dass die neuesten Einträge (Blog/Ezine/Events) zuoberst stehen. Damit bei vielen bestehenden Einträgen das Menu nicht endlos nach unten erweitert wird, und um das Hauptmenu kompakt zu halten, werden diese speziellen Menupunkte auf die maximal 10 neuesten Einträge begrenzt.

Ein übliches Problem (Internet Explorer Bug) bei Overlay-Menus ist, dass alle weiter unten vorhandenen Selectboxen oder Movies nicht vom Menu überdeckt werden, sondern umgekehrt. Dieser mühsame Bug wurde hier gelöst: Auch wenn im Aufklapp-Bereich des Menus irgendwelche Selectboxen (Dropdowns) oder Movies sind, überdecken diese im IE nicht das aufklappende Menu.

Für die Zwecke der SEO (Suchmaschinenoptimierung) ist das Hauptmenu optimal. Denn es ist absolut "semantisch" und suchmaschinenfreundlich d.h. Suchmaschinen wie Google haben keinerlei Probleme, die Links einzulesen. Oft ist dies bei anderen Flyout-Menus ein grosses Problem, hier aber nicht. Für das Hauptmenu gibt es ausserdem einen automatischen Fallback (pure CSS menu) ohne Javascript.

Ein Menu dieser Komplexität (mit unterschiedlichen Datenbankabfragen und Sortierungen, Loginstatus-Anpassungen, SSL-Umschaltungen, Datum-Konversionen, dreistufigen Menu-Layers und Icons) verursacht normalerweise Ladezeitprobleme. Je nach Inhalt einer geladenen Webpage ist es so, dass das Hauptmenu den überwiegenden Teil des Datenvolumens ausmacht. Diesem Problem wurde insofern entgegengewirkt, als der Entwickler einerseits das Hauptmenu komprimierte und andererseits einen Webhost (Novatrend) fand, der die Seiten im Vergleich zu anderen Schweizer Hostern gemäss Performance-Tests bis zu dreimal schneller ausliefert. Die Ladezeit des Menus wird gemäss Tests nicht durch die Datenbank-Abfragen verursacht sondern durch die Anzahl der Menus, was sich nicht ändern lässt. Zwar wurde hierfür auch ein Caching-Mechanismus entwickelt, jedoch sollte für die Spezialmodule (Blog/Ezine/Events) das Menu jedes Mal neu aus der aktuellen Datenbank geladen werden und das zeitgesteuerte Caching mit Überprüfung des letzten Speicherungszeitpunkts brachte keinen nennenswerten Speedvorteil. Somit ist dies so gut wie möglich gelöst.

Da auf der Startseite die per Javascript animierten Quotes (Liebesweisheiten oben im "Himmel") beim Window-OnLoad gestartet werden, würde dies normalerweise zu einem Programmkonflikt mit dem Hauptmenu führen, das gleichzeitig initialisiert wird. Dieses Problem wurde schliesslich gelöst, indem diese beiden Programme voneinander abhängig gestartet werden.

Aufgrund der speziellen Navigationsstruktur (sämtliche Menupunkte werden angezeigt mit Pfeilen oder Schlüsseln je nach Zugangsstatus zu einer Webpage) musste ein spezielles Google-Problem gelöst werden. Google indexiert alle Links in einem Menu - auch solche zu geschützten Webpages die ein Login erfordern und eine Fehlermeldung zeigen wenn man nicht eingeloggt ist. Es bringt aber nichts, wenn solche Seiten ebenfalls indexiert werden. Also wird im Hauptmenu das spezielle Link-Attribut "rel=nofollow" überall dort in den Link eingefügt, wo eine Webpage ein Login benötigt.

Bei anderen Websites besteht oft das Problem, dass beim Ausdrucken (Printout) einer Webpage auch die Menus ausgedruckt werden. Diese stören jedoch im Printout oder führen dazu, dass der Ausdruck abgeschnitten wird und dadurch komplett unbrauchbar ist. In dieser Website werden beim Ausdrucken sämtliche Menus vollautomatisch ausgefiltert, so dass man stets einen brauchbaren Printout erhält.

2.04. Das Actionlog
Um für die Admins eine möglichst hohe Transparenz bezüglich der Vorgänge in der Website zu ermöglichen, erfasst das Actionlog sämtliche relevanten Vorgänge und protokolliert diese. Nicht etwa mit kryptischen Computercodes oder Kürzeln, sondern für jede der vielen möglichen Aktionen mit individuell getexteten, informativen Log-Einträgen mitsamt Direktlinks zu den betreffenden Daten (z.B. zum betroffenen Memberprofil, zum soeben gekauften Gutschein-Batch, zum soeben gespeicherten Blogpost in Deutsch oder Englisch, zu der soeben eingereichten Coaching-Testfrage etc.)

Dabei werden zurück verfolgbare Identifikationsmerkmale wie IP-Adresse (mitsamt WHOIS-Link), Host, Browsertyp etc. gespeichert. Auch wird differenziert, welcher Usertypus (Visitor/Member/Coach/Admin) eine Aktion ausgeführt hat und wie hoch die Relevanz oder das Risiko jeder einzelnen User-Aktion ist (Dangerlevel: 0 / 1 / 2).

Im Adminsystem sehen die Admins also stets in Klartext, wer wann was unter welcher IP-Adresse gemacht hat, haben gleich die entsprechenden Direktlinks für weiter gehende Kontrollen, und können das Actionlog nach Zeitraum und Relevanz filtern, um sich zum Beispiel nur die stark relevanten/kritischen User-Aktionen der letzten drei Tage anzeigen zu lassen.

Bei Aktionen von Admins sowie System-Aktionen (z.B. automatisches Housekeeping-Script) werden diese mit einem passenden Icon dargestellt, damit sie stärker auffallen als z.B. normale Member-Aktionen.

Zusätzlich gibt es ein eigens entwickeltes Access Log, das für weitere Funktionen nützlich ist. Bots werden erkannt und für die Statistik aufbereitet, speziell der Google Freshbot, da dieser für SEO am wichtigsten ist.

Bei einer so komplexen Website mit unterschiedlichsten Modulen sind solche aufwändigen Protokoll-Tools unerlässlich, da man sonst als Admin (in diesem Fall der Kunde) mit einer "Black Box" und sozusagen blind arbeiten müsste.

2.05. Print Layout
Beim Ausdrucken werden alle unnötigen (sonst störenden) Elemente wie Menus, Submenus, Loginbox, AdSense Ads, Nebenkomponenten etc. automatisch herausgefiltert. Ausserdem wird die Schriftgrösse verkleinert, was zwecks möglichst kompakter Ausdrucke sinnvoll ist und zum sparsamen Verbrauch von Druckertinte führt.

Aufklappbare Textblöcke ("toggle blocks") werden beim Ausdrucken automatisch so umformatiert, dass auch "zugeklappte" Textblöcke alle ausgedruckt werden.

Ein spezielles Problem war die Ausdruckmöglichkeit für Datingvorschläge, da dort das obere scrollbare Teilfenster in der Höhe fix definiert ist. Dies wurde gelöst, so dass auch Datingvorschläge in ihrer ganzen Länge (mitsamt Landkarte, Profilantworten, Zeichnung etc.) ausgedruckt werden können.

Die Member-Stats mitsamt Pie-Charts lassen sich problemlos ausdrucken, weil für die Charts auf Multimedia und auf Canvas (IE hat Probleme mit SVG) bewusst verzichtet wurde. Zwar ist das Antialiasing nicht perfekt, dafür kann man die Stats in jedem Browser komplett ausdrucken. Dies ist zum Beispiel dann wichtig, wenn die Website für mögliche Affiliate-Werbepartner präsentiert wird.

Bei jedem Printout wird aus Rechtsgründen der Copyright-Hinweis (gemäss Definition im Adminsystem) unten angehängt.

2.06. Pagefooter
Who's online: Im Seitenabschluss werden die aktuellen Usertypen mitsamt Login-Status ermittelt und angezeigt (z.B. Anzahl aktuell eingeloggter Members). Dabei werden User-Aktionen erfasst, die während der letzten 10 Minuten getätigt wurden. In der Anfangsphase arbeitet diese Funktion teilweise mit einem Zufallsgenerator.

Der Copyright-Hinweis ist so programmiert, dass das Enddatum automatisch das aktuelle Jahr übernimmt. So muss nicht jedes Jahr der Copyright-Hinweis angepasst werden.

Rechts wird ein "Top of Page" Pfeil eingeblendet. Ein spezielles Script sorgt für ein elegantes Scrolling an den Anfang der Seite.

Ganz unten folgen schliesslich die Google Ads, die speziell mit "ad section start/end" und "ignore" Tags versehen wurden, damit Ads ausgeliefert werden, die bestimmte Sektoren ausschliessen. Wenn ein Member oder ein Coach eingeloggt ist, werden ihm die Ads nicht angezeigt, weil diese stören und weil Google gemäss TOS gar nicht erlaubt, dass AdSense Ads in Login-Bereichen gezeigt werden. Zudem musste hier das Problem gelöst werden, dass Google für AdSense keine SSL-Version anbietet und dies auf den Seiten zu fehlerhaftem SSL führt (kleines Schloss-Symbol erscheint durchgestrichen). Also wird AdSense immer dann ausgeblendet, wenn die Webpage via SSL läuft. Die Ads sind speziell so definiert, dass sie beim Ausdrucken (Printout) herausgefiltert werden. Die Ads wurden ans Website-Design (Linkfarbe) angepasst.

2.07. Browser-Kompatibilität
Die Homepage wurde so entwickelt, dass sie auf allen Mainstream-Browsern gleich aussieht. Getestet und laufend angepasst wurde mit Firefox, Safari und IE.

Da noch nicht die Mehrzahl der User eine moderne und grosse Bildschirm-Auflösung hat (1280 Pixel Breite x 1024 Pixel Höhe oder oft sogar grösser), wurde die Website so entwickelt, dass sie auch auf dem alten Format 1024 x 768 benutzbar ist, ohne dass bei Vollbild Scrollbalken entstehen. Das Layout wurde als sogenanntes "Liquid Design" entwickelt, d.h. die Website passt sich dem Browserfenster an.

Für Mac-User wurden alle Webpage-Schriftbefehle so definiert, dass sie nicht nur Windows-Fonts sondern auch Mac-Schriften darstellen können - diese Lösung wurde auch in den Webpage-Editor (im Adminsystem) integriert. Andere Webpage-Editoren definieren in der Schriftauswahl z.B. nur eine einzelne Windows-Schrift wie "Verdana", jedoch existiert diese Schriftart dann gar nicht in Apple-Computern, was dort zu falscher Darstellung führt. Diese Probleme wurden also hier konsequent gelöst - im Gegensatz zu vielen anderen Websites.

Das Zwischenspeichern von User-Aktionen wird normalerweise mit "Cookies" (d.h. simpel) oder mit "PHP-Sessions" (d.h. komplex) gelöst. Die Sessions haben eine maximale Laufzeit von 180 Minuten (3 Stunden), was von der PHP-Konfiguration des gewählten Webhosts abhängig ist. Hierbei ist ein seltenes Problem, dass einige User (vor allem Office-Surfer) keine Cookies speichern dürfen oder diese im Browser gesperrt haben. Zu bedenken ist jedoch, dass die meisten Member-Websites im Web überhaupt nicht bedienbar sind, wenn man die Cookies deaktiviert. Dennoch wurde in dieser Website prinzipiell auf Cookies verzichtet. Statt dessen wird dies aufwändig mit PHP-Sessions abgewickelt. Aufwändig auch deshalb, weil in dieser speziellen Website sehr viele unterschiedliche Situationen für mehrere Usertypen (Visitors/Members/Coaches/Admins) festgehalten werden müssen. Falls im Browser die Cookies gesperrt sind, aktiviert das System einen "Fallback" Mechanismus und die Session-ID wird weitertransportiert, dies musste separat gelöst werden bei Seitenweiterleitungen via PHP "Header Location"). Also laufen alle Hauptfunktionen der Website auch dann, wenn Cookies deaktiviert sind. Diese Site ist somit kompatibler als die meisten Member-Websites im Internet, die ohne Cookies gar nicht bedienbar sind.

Es ist prinzipiell möglich, die Website auch ohne Javascript zu benutzen. Die Navigation funktioniert (weil CSS-Menus), sowie auch die Anmeldung, die Verarbeitung von eingegebenen Redemption Codes (funktioniert also auch ohne "AJAX"), das Matchingfenster, das Messaging-System, das Profil-Editing etc. Im Adminsystem erfolgt beim Webpage-Editor ein Fallback auf normale Textareas als Eingabefelder, auch dieser Teil ist also in jedem Falle benutzbar. Ausnahmen bilden die externen Module Google Maps und Saferpay - beides Systeme, die nur von externen Anbietern kommen können und gemäss deren Programmierung nicht ohne Javascript funktionieren. Falls Javascript deaktiviert ist, erscheint oben in der Website ein entsprechender Warnhinweis (D/E). Es ist allerdings heutzutage so, dass man mit abgeschaltetem Javascript gar nicht mehr vernünftig surfen kann.

Beide Startseiten der Website Deutsch/Englisch validieren mit 0 Fehlern im offiziellen "W3C Validator" sowie im HTML-Qualitätsprüftool "Tidy". Valid Code auf der Startseite bedeutet zwar Mehraufwand (der von anderen Web-Agenturen meistens nicht investiert wird wenn er nicht teuer bezahlt wird), hat jedoch einen positiven Einfluss auf die Indexierbarkeit (Search Engine Readiness) und ist ein immer wichtigeres Qualitätsmerkmal in der Webdesign-Branche.

2.08. SEO
Folgendes zur Suchmaschinenoptimierung (Search Engine Optimization), die für diese Website besonders sorgfältig gemacht werden muss. Die Webagentur GREG.CH hat vielfältige Erfahrung und beweisbare, beeindruckende Erfolge in diesem Spezialbereich. Deshalb einige Hinweise zum Thema SEO: In keinem anderen Bereich des Web-Business gibt es so viele falsche Versprechungen, Halbwissen, und selbsternannte "Experten" die zu Stundenlöhnen von bis zu 480 Dollars von Firmen engagiert werden. Andererseits gibt es Websites, die mit Millionenbudgets entwickelt wurden, aber aufgrund eines ineffektiven Suchmaschinenmarketings kaum im Web "existieren". Und schliesslich gibt es viele merkwürdige Methoden wie das Mieten von Links, Besuchertausch und das Fälschen von PageRanks. Es wird alles versucht.

Teil des Webs ist eigentlich nur das, was rasch gefunden werden kann. Unter diesem Gesichtspunkt kann man behaupten, dass SEO wichtiger ist als die Website, denn Websites ohne Besucher sind überflüssig im Web... Es gibt Webprojekte, bei denen für SEO so viel ausgegeben wird wie für die Entwicklung. Primär wird dabei versucht, mit bestimmten Suchbegriffen bei Google auf die ersten zwei SERPs (Suchmaschinen Resultatseiten) zu kommen. Denn Google regiert das Web und sorgt via Suchresultate kostenlos für Neukunden und damit Einkünfte. Doch Google lässt sich nicht manipulieren. Es ist lediglich möglich, mit einem entsprechenden Zusatzaufwand optimale Voraussetzungen für gute Rankings zu schaffen.

Das Web ist eine Sammlung von Märkten - Angebot und Nachfrage. Lovebumble tritt mutigerweise in demjenigen Sektor an, der momentan am stärksten boomt. Online-Dating ist ein Bedürfnis, das in unsere Zeit und zum heutigen vernetzten Lifestyle passt. Es ist schon lange salonfähig geworden und man spricht darüber - Partnerbörsen werden im Freundeskreis empfohlen. Der Frauenanteil beim Online-Dating liegt gemäss neuesten Studien bei über 50 Prozent. Zudem hatten die Internet-Partnervermittlungen einen Umsatzzuwachs von 63 Prozent und es gibt Anbieter von Dating-Sites, die pro Jahr CHF 1,5 Mio. in TV-Werbung investierten. Die starke Massenwirkung eines TV-Spots übertrifft bei weitem alle anderen Massnahmen. Wenn am TV für eine Website geworben wird, dann handelt es sich meistens um eine Dating-Site. Dies zeigt, wie intensiv um die Chancen in diesem Markt gekämpft wird und damit legt die Konkurrenz im Bereich Online-Dating das Level fest, auf dem effektiv geworben wird.

Eine neue Web-Domain, auf die noch keine Links von anderen und wichtigen Websites verweisen, wird im Normalfall nicht sofort indexiert, sondern bleibt bis zu 6 Monate lang in der Google "Sandbox" stecken. Gleichzeitig werden Dating-Sites der grossen Konkurrenten mit den dort verdienten Millionenbudgets aggressiv gepusht. Im Bereich der Internet-Werbung sieht man sogar AdWords Biddings (Gebote für bestimmte Suchbegriffe) in der Höhe von CHF 1.20 für einen einzigen Klick zu einer Dating-Website. Starke Konkurrenten mit vollen Kassen, doch haben die Anbieter nur Varianten desselben Angebots.

Lovebumble mit seinem innovativen "Top-Matching" (Top 3 Datingvorschläge statt hunderte von Memberprofilen zur Auswahl – siehe dazu das Konzept der Kundenfirma Pamment Projects GmbH) ist ein neuer Konkurrent in diesem extrem boomenden Markt und hat vier Möglichkeiten, um Besucher anzuziehen: Traditionelle Werbung (Inserate, Werbebriefe etc.) mit sehr hohem Streuverlust. Oder darauf hoffen, dass zufriedene Members die Website weiterempfehlen. Oder Partnerschaften im Bereich des Affiliate Marketings eingehen, die aber erst dann verhandelt werden können, wenn man selber einen hohen Traffic (unique visitors per day) und PageRank (mindestens 3) belegen kann. Oder erstmal versuchen, dass Traffic via Google entsteht. Dies beginnt bei der sorgfältigen und aufwändigen Strukturierung der Website:

Die zu indexierenden Keywords wurden nicht etwa als die übliche realitätsferne Wunschliste definiert, sondern konsequent aufgrund der tatsächlich bei Google eingetippten Suchbegriffe im letzten Monat, getrennt nach Sprachen und Territorien (DACH-Länder / weltweit). Zudem wurden dafür die relevanten Keyword-Trendcharts analysiert.

Da alle Search Engine Bots (z.B. der Freshbot) eine Webpage immer von oben nach unten lesen (gemäss dem HTML-Quelltext - nicht gemäss der Darstellung), wurde folgender optimaler Aufbau gewählt:

Zuerst liest ein Bot die sprachabhängigen HTML-Titles (deutsch/englisch getrennt definierbar im Adminsystem) ganz zuoberst im Browsertitel, die auch Keyphrases enthalten müssen (maximale Totallänge der Titles = 130) und zwecks SEO unbedingt bei jeder Seite anders sein müssen. Dies wird durch das spezielle Menusystem vollautomatisch für jede angewählte Webpage erledigt.

Damit die Website innerhalb der SERPs stärker auffällt, wurde ein Herz-Symbol vor den HTML Title gestellt. Im Quellcode folgen danach die sprachabhängigen Meta Tags, die heutzutage nur noch von wenigen Suchmaschinen berücksichtigt werden. Danach stösst der Bot auf das Logo und das Top-Menu. Nun kommt ein wichtiger Punkt: Der Link zur Sitemap steht noch vor allen anderen Hauptmenu-Punkten, nämlich links oben, also im Anfangsbereich des HTML-Quellcodes. So folgt der Bot zunächst dem Link zur Sitemap und erkennt nach Abarbeiten der ganzen Site, dass auch die interne Verlinkung brauchbar strukturiert ist (Stichwort PageRank-Vererbung). Danach wird das Hauptmenu eingelesen und danach der Newsframe links, worin ebenfalls Suchbegriffe im Fliesstext platziert sein sollten. Erst dann wird das mittlere Site-Segment eingelesen, das aufgrund des Layouts nur wenig indexierbaren Text beinhalten kann. Im Pagefooter folgen schliesslich die Google Ads, die speziell mit "ad section start/end" Tags versehen wurden.

Um herauszufinden, welche Keywords und Keyphrases tatsächlich eine hohe CTR (click through rate) erzielen, definierte und schaltete der Entwickler eine AdWords Kampagne.

Zwecks SEO und Verhinderung von Double Content Penalties muss verhindert werden, dass eine Domain mit http://domain.com und auch mit http://www.domain.com aufgerufen kann. Darum wurde ein entsprechender 301 Redirect im ".htaccess" installiert. Zudem sorgt eine in XML erstellte Google Site Map dafür, dass die Seiten gemäss ihrer Priorität indexiert werden - anfangs werden aufgrund des Marketingkonzepts die deutschen Seiten priorisiert. Zudem werden im Haupt-Menu und in der Sitemap diejenigen Links automatisch mit dem Link-Attribut "rel=nofollow" ergänzt, welche Logins benötigen und darum nicht indexiert werden sollen. Und schliesslich sorgt eine "robots.txt" Datei dafür, dass alle nicht zu indexierenden Server-Verzeichnisse und Dateien wie vom Entwickler definiert durch SuMa-Bots ignoriert werden.

3. Zugangsbereich "Visitors"

3.01. Die Startseite
Die Geschlechterverteilung (männliche/weibliche Members in Prozent) wird gleich auf der Startseite angezeigt, da sich Visitors dafür interessieren. Hat eine Dating-Site viele weibliche Members, dann ist sie in der Regel erfolgreich.

Die Quotes (Lebensweisheiten oben) werden per Zufallsgenerator aus der Datenbank geholt (so wie sie durch Admins eingegeben wurden), von PHP nach Javascript transferiert und animiert. Wo es Lücken in der englischen Version hat (nur deutscher Spruch ohne englisches Gegenstück), überspringt der Zufallsgenerator diese. Die Sprüche wurden teilweise durch den Entwickler getextet.

3.02. Member-Map
In der Map ist die Zoom-Stufe limitiert (Zooming geht nicht bis auf Street-Level), um so die Privatsphäre der Members zu gewährleisten. Auch bei Copy&Paste des Map-Links (ein bekannter Hacker-Trick) ist der genaue Standort immer noch geschützt, da die präzis gespeicherte Länge/Breite durch das System zufällig verschoben wird (durch Diffusion), bevor sie an die öffentlich zugänglichen Maps geliefert wird. Während im System nach wie vor der präzise Standort besteht und zwecks Distanzberechnung und Radius-Plotting verwendet werden kann, erscheint gegen aussen nie der präzise Standort auf der Karte. Dasselbe gilt übrigens auch bei denjenigen Maps, die bei den Events oder als Teil von Datingvorschlägen angezeigt werden.

Da der IE ein Buffer Overflow Problem hat, sobald mehr als 100 Map-Markers (teils überlappend) geladen werden, wurde die Anzahl der dargestellten Member Locations auf 100 begrenzt. Ein weiterer Grund ist, dass die Markers animierte GIFs sind, was die Ladezeit im IE noch verschlechtert. Im Firefox ist dies wie üblich kein Problem.

Genereller Hinweis: Die verschiedenen Google Maps Applikationen in dieser Website funktionieren auch dann, wenn eine SSL-Verbindung aufgebaut wurde. Google Maps via SSL ist aktuell ein grosses Problem, wurde aber hier gelöst durch die Programmierung und Integration eines Proxy-Servers.

3.03. Member-Stats
Im Normalfall werden folgende statistische Auswertungen öffentlich angezeigt:

Während der Startphase sind einige dieser Angaben noch ausgeblendet.

Diese Infos sind vor allem wichtig für aktive Members, wenn sie ihr eigenes Memberprofil optimieren, um mehr Datingvorschläge zu erhalten. Die Member-Stats zeigen zu diesem Zweck zum Beispiel den durchschnittlichen Datingfaktor aller bisherigen Datingvorschläge. Dies zwecks Vergleich mit den selber erhaltenen Datingvorschlägen und deren Datingfaktoren.

Die Member-Stats und Charts werden vollautomatisch und live generiert. Üblicherweise ist es programmtechnisch schwierig, Pie-Chart-Segmente in den gewünschten Farben darzustellen. Der erste Chart musste speziell so programmiert werden, dass er die definierten Geschlechterfarben (zwei Farben für Männer/Frauen) anzeigt.

Die Pie-Charts wurden nicht mit Anti-Aliasing programmiert, um so die Ladezeit kurz zu halten. Auf Multimedia-Charts wurde sinnvollerweise verzichtet, denn diese werden beim Ausdrucken (ausser im "schlechten" Browser IE) nicht angezeigt. Canvas (SVG) beherrscht der Mainstream-Browser IE zu wenig gut. Also wurde es mit der "GDlib" gelöst, denn eine voraussichtliche Verwendung der Member-Stats ist, dass die Website-Betreiber diese in regelmässigen Abständen zwecks Performance Monitoring oder Demoing ausdrucken.

Weitere Member-Stats wie die "Matching-Rate" (Vermittelbarkeit), Member-Ratings etc. sind nur im Adminsystem abrufbar.

3.04. Kontaktseite
Falls die Kontaktseite von einem eingeloggten Member benutzt wird, werden dessen Kontaktdaten automatisch eingefüllt, und in der an LB geleiteten Email wird der Membername hinzugefügt.

Vor Absenden des Kontaktformulars wird geprüft, ob alle Pflichtfelder ausgefüllt wurden und die Mail-Adresse des Absenders im korrekten Format ist.

In der Anfangsphase sendet das System eine Kopie aller Nachrichten an den Entwickler, da darin Problemhinweise enthalten sein könnten.

3.05. Member/Coach Login
Die Funktionen der Loginbox mussten ausnahmsweise und zwecks Kompaktheit doppelt programmiert werden, nämlich für Members und Coaches. Es braucht also nicht zwei getrennte Loginboxen. Das System erkennt automatisch, welcher Usertypus sich einloggt.

Alle Logins werden mitsamt IP-Adresse und Browsertyp protokolliert. Im Adminsystem ist die Info "letztes Login am" verfügbar.

Zur Sicherheit sind keinerlei Passwörter in Klartext in der Datenbank gespeichert, wie dies manchmal gemacht wird. Statt dessen werden alle Passwörter mit dem MD5 Algorithmus verschlüsselt. Aufgrund der speziellen "MD5" Verschlüsselung können gespeicherte Passwörter nie mehr zurück entschlüsselt werden - selbst durch Admins oder den Entwickler nicht.

Hat ein Member sein Passwort vergessen, kann über die Seite "Login-Hilfe" ein neues generiert und direkt an die Mailadresse des Members gemailt werden. Wird eine nicht in der Memberdatenbank gespeicherte Mailadresse eingegeben, erscheint eine Fehlermeldung.

3.06. Präsentation
Die zweisprachige Multimedia-Präsentation wurde aufgrund eines mehrmals geänderten Storyboards entwickelt.
Die Sprechstimmen wurden selektiert aus einer aktuellen Auswahl aus Voiceover Talents (Profisprecher/innnen).
Für die Screenshots mussten zuerst realistische Situationen als Beispiele hergestellt (simuliert) werden.

3.07. Member-Anmeldung
Die Member-Anmeldung ist Teil des Zugangsbereiches "Visitors", also im öffentlichen Bereich.

Prüfung vor Anmeldung: Ist das Member bereits eingeloggt oder hat der User sich bereits angemeldet, wird das Anmeldeformular unter Fehlerhinweis entfernt.

Falls die Anmeldeseite mit einem Referrer-Link (durch Weiterempfehlung) aufgerufen wurde, wird die Referrer ID zunächst in einer PHP-Session gespeichert, damit diese Info auch bei Seitenwechsel nicht mehr verloren gehen kann. Das weiterempfehlende Member erhält die für eine erfolgreiche Weiterempfehlung definierte Anzahl Credits (änderbar via Adminsystem) sowie eine Email, in der ihm die Account-Gutschrift angezeigt wird. Im Actionlog wird protokolliert, welches Member die Weiterempfehlung gemacht hat und wie hoch dessen alter und neuer Credits-Saldo ist. Im Adminsystem erscheint im Memberprofil des neu angemeldeten Members der Name des Referrers mitsamt Direktlink zum Memberprofil des Referrers.

Feldänderungen: Wird in der deutschen Website-Version als Wunschpartner "Frau" gewählt, so ändern sich einige Formulartexte automatisch. Aus "Partner" wird "Partnerin" etc. Felder wie Membername sind in der Länge limitiert (Beispiel: auf 15 Zeichen), andere wie das Passwort benötigen eine Mindestlänge. Der Upload des Memberfotos ist punkto Dateigrösse und Dateityp limitert.

Standort-Markierung in der Landkarte: Bei Adresseingabe findet das System in den meisten Fällen automatisch den Standort auf der Karte und setzt den Marker. Hierfür wird die Postleitzahl per String-Cutting herausgefiltert und der ganze Address String von einem Geocoder abgearbeitet. Wird der Standort aufgrund der Adresseingabe nicht gefunden, greift hier ein Fallback d.h. der User kann nun per manuelle Eingabe seinen Standort selber markieren. Die Geokoordinaten werden in zwei verschiedenen Formaten weiter verarbeitet, was für die spätere Kontaktradius- und Memberdistanz-Berechnung notwendig ist.



3.07.01 Eingabe-Prüfung
Beim Klick auf den Anmelde-Button analysiert zunächst ein Javascript die Dateneingabe (zur Sicherheit später noch ein PHP-Script). Bei Eingabefehlern erzeugt das System spezifisch getextete Fehlermeldungen.

Die Eingabe-Prüfung stellt sicher:

3.07.02 Einlöse-Codes
Überprüfung eines eingegebenen Redemption Code: Die Systemlogik musste hier komplex entwickelt werden, um es für die User einfach zu machen. Meistens macht man es beim vorliegenden Funktionsbedarf so, dass die User mindestens zwei Eingabefelder kriegen: Eingabe eines Gutscheincodes, oder Eingabe eines Promotion Codes in einem anderen Feld. Doch auch hier wurde es mit Mehraufwand maximal einfach gemacht, denn es gibt nur ein Feld.

"AJAX" (eine innovative Web-Technologie die für den aktuellen "Web 2.0" Boom steht) wurde hier eingesetzt, um im Hintergrund eine Server-Anfrage loszuschicken und den eingegebenen Einlöse-Code zu prüfen. Das ging nur mit AJAX, denn eine normale Javascript-Prüfung wäre für diesen Zweck völlig unbrauchbar und eine Prüfung via PHP käme zu spät (erst nach Absenden des Formulars). Der AJAX Requester wurde so programmiert, dass er bereits im Standardmodus nur mit "POST" Requests arbeitet. Das hierfür entwickelte Programm ist extrem kompakt, übersichtlich und einfach wiederverwendbar.

Der AJAX Requester prüft und protokolliert Folgendes bei Eingabe eines Einlöse-Codes:
Die allfällig aus dieser Überprprüfung resultierenden Fehlerhinweise werden dem User in Klartext angezeigt, so dass der User sieht, was das genaue Problem ist (statt einfach eine "ungültig" Meldung zu erhalten).

Nach Anklicken des Anmelde-Buttons läuft noch ein zweiter Check, diesmal via PHP, um so zu verhindern, dass Formular-Spam (heutzutage ein riesiges Problem im Web) betrieben werden kann. Hierbei wird auch ein zweites Mal sichergestellt, dass ein Redemption Code gültig ist. Bei Promo Codes wird der resultierende Rabatt in CHF berechnet und zwecks Klarheit innerhalb einer Berechnungs-Tabelle angezeigt (normale Gebühr in CHF minus n% Rabatt in CHF = zu bezahlende Gebühr in CHF), ausser es handelt sich um einen 100% Promo Code.

Im Actionlog der Admins werden alle solchen Aktionen in Klartext und mit Direktlinks zu den einzelnen Bereichen (z.B. Gutschein-Verwaltung) protokolliert, so dass die Admins stets sehen, was genau bei einer Anmeldung passiert ist. Speziell wird hierbei auch protokolliert, falls ein User versucht hat, mit einem ungültigen, abgelaufenen oder bereits eingelösten Code anzumelden. So weiss der Admin im Falle einer Nachfrage oder Reklamation seitens des Members, was das Problem war.

3.07.03 Speicherung
Es wird zur Vermeidung von Doubletten geprüft, ob der gewünschte Membername bereits besteht, und zwar beidseitig durch Vergleich mit der Member-Datenbank (Membername) und Vergleich mit der Coach-Datenbank (hier der Coach-Username). Diese Prüfung erfolgt nach dem Absenden des Formulars.

Das neue Member-Account wird gespeichert:

Der Account-Status wird gesetzt (default: "stored"). Der MG-Status wird gesetzt (default: "blocking" denn erst wenn das Neumember den zweiten Profilteil ausgefüllt hat, läuft der Matching-Generator für sein Memberprofil). Das Passwort wird mit dem MD5-Algorithmus verschlüsselt und ist damit nicht lesbar, selbst für die Website-Admins nicht. MD5 kann man nicht wieder entschlüsseln. Zudem bestehen Sicherheitsmechanismen in der Login-Box wie z.B. eine "Sleep" Verzögerung nach abgelehnten Logins, so dass auch Brute Force und Rainbow Attacken auf Member-Passwörter scheitern würden. Die Laufzeit bzw. das genaue Verfalldatum der Mitgliedschaft wird berechnet. Normalerweise 6 Monate, jedoch falls Anmeldung via Gutschein nur 3 Monate. Auch wird das Alter berechnet und das Sternzeichen für die Anzeige des Zodiac Icon. Falls ein Memberfoto hochgeladen wurde, wird dieses falls nötig auf die maximal erlaubte Höhe/Breite re-formatiert, zudem wird daraus ein stark verkleinertes Foto als "Thumbnail" generiert und auf dem Server gespeichert. Wurde die Anmeldung aufgrund einer Weiterempfehlung getätigt und ein Referrer gespeichert, dann schreibt das System jetzt dem weiterempfehlenden Member die aktuell definierte Anzahl Credits gut und sendet ihm eine Email mit den entsprechenden Informationen (dieser Vorgang wird zusätzlich als separater Actionlog-Eintrag protokolliert).

Zeitgleich mit der Account-Speicherung wird automatisch die Anmelde-Bestätigung versendet. Das Neumember erhält eine Bestätigungs-Email mit weiteren Hinweisen in Deutsch oder Englisch. Die Administratoren erhalten (gemäss ihren individuell definierten Benachrichtigungs-Präferenzen) eine Email mit zusätzlichen Daten wie IP-Adresse, Browsertyp und gewählte Website-Sprachversion.

Der Ablauf ist also unüblich: Die Account-Speicherung und die Email-Bestätigung werden bereits vor einer allfällig noch folgenden Bezahlung abgewickelt. Dies musste so gemacht werden aufgrund der speziellen Anforderungen an diese Website mit den 5 verschiedenen Methoden zur Begleichung der Anmeldegebühr (zwei davon ohne Zahlung, eine als 100% Rabattcode, eine als ein- und ausschaltbare Zahlungsmethode mit späterer Zahlung). Und auch deshalb, weil das Account vor dem Ausfüllen des zweiten Memberprofilteils gespeichert sein muss, da sonst der zweite Teil gar nicht korrekt mit dem ersten verknüpft werden könnte (dies betrifft zum Beispiel die Fragen nur für Männer / nur für Frauen).

Als Sequenz läuft daher Folgendes ab: User füllt das Anmeldeformular aus, akzeptiert die von einem Anwalt ausgearbeiteten AGB, wird damit sofort Member, und erhält sofort die Anmeldebestätigung. Im Normalfall hat er jetzt eine Zahlungsverpflichtung - ausser er hatte einen Einlösecode eingegeben der vom System akzeptiert wurde und ihn von der Zahlung befreit. Dies ist der Grund, warum eine allfällige Bezahlung erst im nächsten Schritt erfolgt.

3.07.04 Bezahlung
An dieser Stelle sind die Ablaufprozesse komplex und mehrspurig, denn man kann die Anmeldekosten auf folgende 5 Arten begleichen: Kreditkarte, Banküberweisung (falls aktuell als möglich definiert), Einlösen eines Promocodes mit weniger als 100 Prozent Rabatt und reduzierter Zahlung via Kreditkarte oder Banküberweisung, Einlösen eines Promocodes mit 100 Prozent Rabatt, oder Einlösen eines Gutscheins.

Zunächst ermittelt das System, wie hoch die aktuelle Member-Anmeldegebühr ist und ob eine Zahlung gemacht werden muss: Falls ein eingegebener Gutscheincode oder 100% Promocode vom System akzeptiert wurde, gibt es keine Zahlung, also wird direkt weiter geleitet zum Hinweis, dass man sich jetzt einloggen und den zweiten Profilteil ausfüllen soll. Falls ein eingegebener Promocode mit weniger als 100% Rabatt vom System akzeptiert wurde, berechnet das System jetzt den reduzierten Betrag und speichert diesen als ausstehende Zahlung. Falls keinerlei Einlöse-Code eingegeben wurde, speichert das System die aktuelle Member-Anmeldegebühr als ausstehende Zahlung.

Die nächste Funktion im Ablaufprozess prüft, ob eine ausstehende Zahlung besteht (ansonsten wird gleich weiter geschaltet). Falls Ja, ermittelt das System, ob gemäss Eintrag im Adminsystem die Zahlungsmethode "Banküberweisung" aktuell akzeptiert werden soll. Falls Ja, erhält der User an diesem Punkt eine Auswahlmöglichkeit in Form einer Dropdown-Liste. Dabei muss er wählen, ob er via Kreditkarte (alle aktuell akzeptierten Karten werden schon hier und nicht erst im Saferpay VT angezeigt) oder via Banküberweisung zahlen will. Falls die Methode "Banküberweisung" aktuell nicht akzeptiert wird, so wird dieser Schritt übersprungen und der User wird direkt zum Saferpay VT weiter geleitet.

Falls Banküberweisung gewählt wurde, erscheinen jetzt die im Adminsystem gespeicherten Bankdetails (deutsche und englische Version verschieden da andere Bankdetails). Zusätzlich sendet das System eine zweite Email (diesmal mit den Bankdetails) an das Neumember, um sicherzustellen, dass die Zahlungsinstruktion nicht übersehen wird. Dies ist nötig als separate Email, weil man weiss, dass viele User eine Anmelde-Bestätigung von einer Website gar nicht durchlesen. Im Falle der Banküberweisung wird zusätzlich eine Rechnung im PDF-Format automatisch generiert, welche die Adresse, geschlechtsabhängige Anrede, aktuelle Anmeldegebühr, Bankdetails und die aktuell im Adminsystem definierten Kontaktdaten der Betreiberfirma enthält.

Jetzt erscheint je nach Situation der Hinweis, dass man sich einloggen und das "Reisegepäck" ausfüllen soll. Falls jedoch Banküberweisung als Zahlungsmethode gewählt wurde, erscheint kein solcher Hinweis und das Konto bleibt inaktiv bis zum Eingang der Zahlung, welche via Adminsystem erfasst wird.

3.08. Gutscheine
Die Erzeugung von Geschenkgutscheinen erfolgt in 5 Varianten, die vom System separat verarbeitet werden:

Kaufvorgang für Members und Visitors: Gewünschte Anzahl Gutscheine auswählen (limitiert auf 50), Adressdaten eingeben (falls eingeloggtes Member werden diese gleich ausgefüllt), und allenfalls einen Spender angeben ("Dieser Gutschein wurde Ihnen geschenkt von"). Falls mehr als 20 Gutscheine geordert werden, erscheint der Hinweis, dass bei diesem grossen Volumen LB die Gutscheine ausdruckt und liefert.

Code-Generierung: Es werden insgesamt 3 Codes erzeugt. Erstens die teilweise zufallsgenerierte Gutschein-Nummer, die auch die Laufnummer des Gutschein-Batches enthält. Zweitens der voll zufallsgenerierte Gutschein-Einlösecode, wobei das System sicherstellt, dass leicht verwechselbare Buchstaben und Zahlen wie "0" und "l" nicht im Code verwendet werden. Drittens der Download-Link für das Herunterladen und Ausdrucken aller Gutscheine im Batch, was deshalb als Code generiert werden muss, weil ansonsten der Käufer nach einem Gutschein-Kauf auch auf andere Batches zugreifen könnte, die ihm gar nicht gehören.

Gutschein-Generator: Das Layout wird automatisch erstellt und enthält ein Hintergrundbild, das Site-Logo, die Gutschein-Nummer und den Gutschein-Einlösecode, das Ausgabedatum, die Laufzeit, Hinweise, und Kontaktdaten der Betreiberfirma. Falls vorhanden, wird Name oder Adresse des Spenders ins Layout integriert. Der PDF-Generator wurde so programmiert, dass das erzeugte PDF auch Fliesstexte enthalten kann. Damit es beim Download keine Überschneidungen der Dateinamen gibt, wird jedes Gutschein-PDF unter einem eigenen Dateinamen (aufgrund des Gutschein-Codes) generiert.

Verarbeitung: Falls ein eingeloggtes Member Gutscheine kauft und mit bestehenden Account-Credits bezahlt, werden ihm die Credits abgezogen (abgebucht) und der neue Credits-Saldo wird berechnet und gleich angezeigt. Falls ein eingeloggtes Member Gutscheine kauft und mit Kreditkarte bezahlt, wird es weiter geleitet zum Saferpay VT. Falls ein Visitor Gutscheine kauft und mit Kreditkarte bezahlt, wird er weiter geleitet zum Saferpay VT. Danach erfolgt in allen Fällen eine On-Screen Bestätigung. Das System berechnet die Laufzeitdaten des gekauften Gutschein-Batches. Abschliessend sendet das System dem Käufer eine Email mit dem aus Sicherheitsgründen speziell codierten Download-Link zwecks Herunterladen und Ausdrucken aller Gutscheine im gekauften Batch.

Das Einlösen von Gutscheinen wird im Kapitel "Einlöse-Codes" beschrieben.

3.09. Blog
Das Weblog ist vollständig massgeschneidert, also eine Eigenentwicklung wie fast alles andere. Das Weblog ist nicht separat und umständlich, sondern kompakt und direkt via Adminsystem verwaltbar.

Der Kalender wurde extra für diese Site programmiert und passt sich automatisch der gewählten Sprache D/E an. Gebloggte Tage erscheinen als markierte Felder und beim Darüberfahren sieht man den Titel und anklickbaren Link des Blogposts. Das aktuelle Tagesdatum ist markiert.

Benutzer des Firefox Browsers können direkt den RSS-Feed bookmarken, sobald sie das Blog aufrufen (RSS Symbol erscheint in der Browser-Adressleiste). Dafür schrieb der Entwickler ein sehr kompaktes PHP-to-RSS Programm, das die Blogposts in XML umwandelt. Das Abonnieren von RSS-Feeds ist die heutzutage übliche Methode, um Blogs zu verfolgen.

Manche Standard-Blogs erlauben es nicht, Videos einzubinden. Hier wurde der Blog-Editor so entwickelt, dass problemlos Videos integriert werden können.

Nur eingeloggte Members können Blogposts kommentieren. Dabei definiert das Member den gewünschten Publikationsstatus (Comment öffentlich im Blog anzeigen oder nur intern weiterleiten). Blog Comments können via Adminsystem gelöscht werden.

3.10. Magazin
Eine Magazin-Ausgabe kann im Adminsystem schrittweise erstellt werden. Das heisst, Admins können beliebig neue Seiten hinzufügen, obwohl die Ausgabe noch gar nicht veröffentlicht ist. Durch das Umschalten des "Publishing Status" wird schliesslich die komplette Ausgabe veröffentlicht.

Für das Magazin wird zusätzlich ein spezielles Printout-Format mitsamt Header und Footer erzeugt.

Seiten blättern: Die Einzelseiten werden in einem speziell gestalteten Paginierungstool angezeigt, falls die Ausgabe mehr als 1 Seite hat.

Nur eingeloggte Members können Magazinseiten kommentieren. Dabei definiert das Member den gewünschten Publikationsstatus (anzeigen oder nicht).

In der Anfangsphase bzw. bis zur ersten kompletten Ausgabe ist das Magazin noch versteckt, alle entsprechenden Menupunkte im Haupt-Menu sowie in der Sitemap sind ausgeblendet.

3.11. Coach-Anmeldung
Das Coaching-System umfasst verschiedenste Funktionen für alle 4 Usertypen (Visitors/Members/Coaches/Admins).

Die Coach-Anmeldung ist Teil des Zugangsbereiches "Visitors", also im öffentlichen Bereich.

Falls bereits mehr als eine Coaching-Anfrage gelaufen ist, wird die Anzahl bisheriger Anfragen den Coaches auf der Anmeldeseite mitgeteilt (als Bestätigung, dass tatsächlich eine Nachfrage besteht).

Das aktuelle Problem der fehlenden weiblichen Form von "Coach" (ursprünglich "Coachman" denn Coach bedeutet nur Kutsche) konnte auch vom Entwickler nicht gelöst werden, denn die in der öffentlichen Debatte vorgeschlagenen Schreibweisen ("Coachin", "Coachess" etc.) haben sich noch nicht etabliert. Also wurde in den Coaching-AGB definiert, dass die übliche Schreibweise auch für weibliche Coaches gilt.

Falls als angebotene Beratungsform nicht "gesprächsorientiert" gewählt wird, dann werden die beiden Formen des Telecoachings (Telefon und Email) ausgeblendet.

Beim Absenden wird geprüft, ob die AGB akzeptiert werden und die Pflichtfelder ausgefüllt wurden (Vorname, Nachname, Adresse, PLZ, Ort, Mailadresse im korrekten Format, Username, Passwort mit mindestens 4 Zeichen Länge). Beim Speichern des neuen Coach-Accounts wird der Accountstatus auf "stored" gesetzt. Das hochgeladene Foto wird nötigenfalls auf maximal 300 x 300 Pixel Breite/Höhe reformatiert. Die aktuell gewählte Website-Sprachversion wird gespeichert. Der Coach sowie die Admins erhalten eine Email-Bestätigung. In der Bestätigung für die Admins sowie im Actionlog steht der spezielle Hinweis: "Bitte Antrag prüfen, die im Adminsystem automatisch generierte Rechnung (PDF) senden, bei Zahlungseingang den Account-Status auf activated setzen". Die PDF-Rechnung wurde nur in Deutsch programmiert, da in der Anfangsphase noch keine ausländischen Coaches berücksichtigt werden.

Bei einer Coach-Anmeldung wird auch geprüft, ob bereits ein Member denselben Usernamen hat (dort "Membername" genannt). Falls Ja, wird die Anmeldung blockiert. Diese Trennung war nötig, weil die Login/Logout-Mechanismen gleichzeitig für Members und Coaches und in derselben Loginbox funktionieren müssen.

3.12. Events
Falls kein Event spezifisch ausgewählt wurde, erscheint eine Übersichtsliste. Diese enthält Links und eine Map mit allen Event-Standorten.

Damit klar wird, dass dies LB-eigene Angebote sind, wurde ein Map-Marker im Design des Logos integriert. Beim Daraufklicken erscheint ein Info-Window mit Detaillink zur Eventseite.

Wer als Member eingeloggt ist, kann sich direkt und mit einem einzigen Klick für einen Event anmelden. Wer sich bereits dafür angemeldet hat, sieht den Hinweis "Sie haben sich für diesen Event bereits angemeldet" und kann sich kein zweites Mal für denselben Event anmelden.

Im Adminsystem werden zu jedem Event alle bisherigen Anmeldungen aufgelistet, mitsamt Direktlinks zu den Memberprofilen.

Die Events werden via Adminsystem erfasst, wo auch die Location präzise auf der Karte gesetzt wird. Für den öffentlichen Bereich wird jedoch die Event-Map so erzeugt, dass die genauen Standorte durch Koordinaten-Diffusion verschleiert und die Zoom-in Levels limitiert werden. Dies deshalb, weil es auch Events als geschlossene Gesellschaft geben kann, deren genauer Standort den teilnehmenden Members nur direkt verraten wird.

3.13. Sitemap
Inhalt und Darstellung der speziellen Sitemap ändern dynamisch je nach Situation. Falls man zum Beispiel eingeloggt ist und das eigene Account auf "expired" steht, ändert sich die Struktur der Sitemap situativ.

Das System erzeugt live die zweisprachige Sitemap aus der Datenbank. Dabei werden auch Links integriert, die aus separaten Modulen stammen wie z.B. Blogposts und Events (jeweils maximal die 10 neuesten Einträge).

Automatische Weiterleitungen von einem Menupunkt zu einem anderen werden mit einem Pfeil und Infotext angezeigt. Auch SSL wird angezeigt.

Die beiden Sprachversionen werden parallel nebeneinander dargestellt. Zwecks Übersichtlichkeit wird jede Zeile beim beim Darüberfahren farbig markiert. Bereits besuchte Seiten werden mit einem Häkchen angezeigt.

Aufgrund der speziellen Navigationsstruktur (sämtliche Menupunkte werden angezeigt mit Pfeilen oder Schlüsseln je nach Zugangsstatus zu einer Webpage) musste ein spezielles Google-Problem gelöst werden. Google indexiert alle Links in einer Sitemap - auch solche zu geschützten Webpages die ein Login erfordern und eine Fehlermeldung zeigen wenn man nicht eingeloggt ist. Es bringt aber nichts, wenn solche Seiten ebenfalls indexiert werden. Also wird in der Sitemap das spezielle Link-Attribut "rel=nofollow" überall dort in den Link eingefügt, wo eine Webpage ein Login benötigt.

Das Printout-Format der Sitemap wurde so gestaltet, dass man zu Entwicklungszwecken bei jedem Menupunkt noch Platz hat, um handschriftliche Notizen zu einer Webpage einzufügen (z.B. "diese Webpage muss noch fertig übersetzt werden").

4. Geschützter Zugangsbereich "Members"

4.01. Member-Login
Das Login erfolgt über das kombinierte Member/Coach Login.

Sehr speziell ist danach im Memberbereich, welche möglichen situativen Weiterleitungen, Blockierungen, Filterungen und Warnungen es gibt:

4.02. Member-Menu
7 separate Menupunkte, dynamisch erscheinend je nach Situation und Aktivität, mit Statistik und Berechnungen drin:

Falls das Account auf Status "awaitpay" oder "expired" steht, wird das Menu ausgeblendet (sowie alle entsprechenden Menupunkte im Hauptmenu und in der Sitemap) und es wird im Menu-Bereich ein rot geschriebener Hinweis angezeigt.

4.03. Erfassung Reisegepäck
Selbstverständlich erwarten Members auch noch eine Art "Persönlichkeitstest". Im Interesse der Members wurde es nun nicht so gemacht, dass bei der Anmeldung gleich beide Teile ausgefüllt werden müssen. Zuerst wird der weniger aufwändige Teil ("Passport") ausgefüllt und sobald man nach Akzeptieren der AGB den Anmelde-Button klickt, ist man Member. Je nachdem mit Zahlungsverpflichtung, falls nicht via 100% Promo Code oder Gutschein angemeldet. Erst nach dem ersten Login (oder im Falle von Banküberweisung nach der Zahlung und dem Freischalten des Accounts) wird das Member aufgefordert, jetzt auch noch den etwas zeitaufwändigen zweiten Teil (Profilfragen mit der prosaischen Bezeichnung "Reisegepäck") auszufüllen.

In einer Gruppendiskussion mit Fachleuten wurde eruiert, welche Fragen die Members dazu bringen können, sich zu öffnen und ihre wahre Persönlichkeit zu zeigen. Ein Teil der Fragen stammt vom Entwickler.

Die technisch äusserst komplexe Problematik bei den Profilfragen war: Man brauchte ein Formular, das vollständig durch Admins editierbar ist (Fragen ändern, Gewichtungen ändern, Aktivstatus ändern, Geschlechterspezifizierung ändern), mitsamt verschiedensten Input-Formaten via ein spezielles Framework (z.B. lässt sich jede Frage definieren als Text, Selectbox mit Text, Radiobuttons ohne Textfeld, Textarea mit Videolinkfeld etc.) und das Ganze dann noch zweisprachig mitsamt dreistufiger Gewichtung pro Frage (wobei eine Frage als Ausnahme nicht zwingend ist) und so, dass auch Members dieses wieder editieren können. Zudem gibt es hier verschiedenartige Uploads im gleichen Formular. Dies klingt alles trivial, war jedoch punkto Flexibilität und Komplexität eine fast unmöglich zu erfüllende Anforderung.

Beim Speichern dieses zweiten Profilteils werden zwei Dinge geprüft:
Ist noch irgendeine der 36 (oder weniger je nach Adminsystem-Definition) zwingend auszufüllenden Fragen unbeantwortet? Falls Ja, wird ein Hinweis mitsamt Fragenummer ausgegeben.
Danach wird geprüft: Sind die Gewichtungen der Fragen überall dieselben, wurde also keine Frage weniger stark oder stärker als der Durchschnitt gewichtet? Falls Ja, blockiert ein Hinweis mit entsprechender Begründung bezüglich Matching-Generator.
Mühsam wäre, wenn das Member seine Antworten eingibt, dann aufgrund eines solchen Fehlers zurückblättert und die Daten weg sind. Dies wurde durch die vorgängige Eingabe-Prüfung gelöst.

Zeichnung: Hier kann das Member frei mit einem speziell dafür entwickelten Online-Drawing-Tool (Sketchpad in Multimedia) zeichnen. Dabei kann die Strichdicke stufenlos und die Farben mittels Farbmixer verändert werden. Sobald die Zeichnung (persönliches Signet) einem gefällt, klickt man auf den "OK" Button und das System konvertiert die Vektorgrafik aus Multimedia aufwändig in einen HTTP-String, der dann via PHP und Datenbank unter dem betreffenden Memberaccount gespeichert wird und schliesslich in Form einer umgewandelten JPG-Grafik in Datingvorschlägen als Teil des Memberprofils erscheint. Das technische Prozedere, damit aus einem Multimediamovie (Vektorgrafik) überhaupt ein speicherbares JPG (Bitmapgrafik) erzeugt werden kann, ist aussergewöhnlich und komplex.

4.04. Matchingfenster

pic

Die Grundlage dieses Bereichs ist zunächst der Matching-Generator, der das Partner-Matching vornimmt und versucht, zu jedem Zeitpunkt maximal 3 Datingvorschläge ("Koffer") für das eingeloggte Member zu ermitteln und diese dann im Matchingfenster zur Beurteilung und Bearbeitung anzubieten. Ferner gibt es hierzu noch eine sehr spezielle und notwendige Funktion: Der eigene "Koffer" ist jeweils bei maximal 3 anderen Members als Datingvorschlag präsent.

Falls man Datingvorschläge erhalten hat, sieht man diese links im Member-Menu sowie im Matchingfenster. Im Matchingfenster werden die Datingvorschläge speziell so dargestellt, dass kleine Koffer gezeigt werden (von links nach rechts geordnet nach Datingfaktor absteigend). Diese kleinen Koffer beinhalten den Membernamen des vorgeschlagenen Members und den Datingfaktor (Übereinstimmungsgrad). Der jeweils "aufgemachte" Koffer wird umrahmt. Im darunter liegenden Teil werden alle Daten des vorgeschlagenen Members zur Beurteilung angezeigt. Dazu gehören das Foto, die "Passport" Daten sowie die "Reisegepäck" Daten, inklusive Landkarte mit den zwei Kontaktradien, Sternzeichen-Grafik, hochgeladene Fotos und persönliche Zeichnung (Signet).

Falls keine Datingvorschläge ermittelt werden konnten, erscheint die Analyse der Matching-Failure Gründe (geordnet von oben nach unten nach Häufigkeit in allen versuchten Matchings) mitsamt Direktlink zum eigenen Passport, um die eigenen Daten und/oder Wunschpartnerkriterien zu ändern. Zudem erscheint hier ein Link zu den Member-Stats, so dass das Member sieht, welche Arten von Members überhaupt in der Plattform sind und zur Verfügung stehen.

Status: Hier wird in Klartext der aktuelle Status des Datingvorschlags angezeigt, und zwar kombiniert für beide der einander vorgeschlagenen Members. Beispiel: "Dieses Member X hat diesen Datingvorschlag am Datum/Zeit akzeptiert und mir 2 Honigtropfen gegeben. Ich habe diesen Datingvorschlag am Datum/Zeit angeschaut aber noch nicht akzeptiert oder abgelehnt". Hierfür gibt es als Grundlage 9 Statusdefintionen und eine Kombinierung aller zweisprachig definierten Statusanzeigen.

Falls das Gegenüber den "Koffer" des Members bereits akzeptiert hat, sieht das Member links im Member-Menu den Hinweis in der To-Do-Liste, dass es den Koffer des Gegenübers noch akzeptieren oder ablehnen soll, falls dies noch nicht geschehen ist.

Foto: Das Memberfoto des vorgeschlagenen Members ist nur dann zoombar, falls das vorgeschlagene Member den betreffenden Datingvorschlag bereits akzeptiert und damit seine Kontaktbereitschaft signalisiert hat. Hierfür wird bei der Account-Speicherung automatisch ein Thumbnail erzeugt - das System erstellt also immer zwei Kopien eines Memberfotos auf dem Server (eines gross und falls nötig komprimiert auf die definierte Maximalgrösse, das andere Foto stark verkleinert).

Map: Um die Kontaktradien beider Members anzuzeigen, erfolgt hierfür eine komplexe beidseitige Radiusberechnung und es werden zwei hellblaue, auf jeder Zoomstufe korrekt gezeichnete Kreise mit animierten Map-Markers und einer Verbindungslinie dazwischen direkt in der Karte angezeigt. Das Member sieht dadurch vor allem, ob der eigene Kontaktradius sich mit dem Kontaktradius des vorgeschlagenen Members überschneidet oder nicht.

Alle Profilantworten ("Reisegepäck") des vorgeschlagenen Members werden angezeigt, mitsamt Bildern wo vorhanden. Falls es Links in den Antworten hat, werden die Links automatisch klickbar gemacht (z.B. YouTube-Links). Zudem werden die individuellen Gewichtungen pro Frage angezeigt.

Danach wird die vom vorgeschlagenen Member erstellte Zeichnung angezeigt (persönliches Signet das im Multimedia Sketchpad gezeichnet wurde).

Schliesslich werden ganz am Ende im "Koffer" die Member-Ratings angezeigt, falls solche bereits bestehen (mitsamt Datum, Membername des Members das ein Rating vergeben hat, sowie Rating-Text).

4.04.01 akzeptieren/ablehnen
Als Teil des Datingvorschlags, unterhalb des scrollbaren Fensters ("Koffer"), steht eine blau umrandete Box mit zwei Input-Teilen:

Vor dem Speichern erfolgt eine Eingabe-Prüfung, die sicherstellt, dass das Textfeld ausgefüllt wurde.

Die Nachricht wird dem vorgeschlagenen Member via Email übermittelt und als neue Member Message in der Website abrufbar gehalten.

4.04.02 Missionsresultat
Falls und sobald ein Datingvorschlag akzeptiert wurde, läuft eine "Mission", das vorgeschlagene Member kennen zu lernen. Innerhalb des Matchingfensters erscheint nun eine weitere Input-Box für den Eintrag des "Missionsresultats" (dient gleichzeitig als Member-Rating weil strukturiert). Es wird auch angezeigt, seit wann die betreffende Mission läuft.

Dem Member werden 4 mögliche Missionsresultate angezeigt, wovon das erste positiv und die weiteren 3 negativ sind. Je nach Resultat wird dieses vom System weiterverarbeitet, z.B. gibt es bei Resultat 1 keine neuen Datingvorschläge. Nun kann es vorkommen, dass ein bestimmtes Member besonders häufig negative Missionsresultate (z.B. "hat nicht geantwortet") erzeugt. Deshalb werden diese Missionsresultate pro Member im Adminsystem aufgelistet und die Admins erkennen dann, welche Members besonders oft innerhalb einer Mission abgelehnt wurden.

Zusätzlich zur Auswahl aus 4 möglichen Resultaten tätigt hier das Member eine Freitext-Eingabe ("Wenn ich über Member X meinen Freunden erzählen werde, was wäre dies"). Auch wird hier definiert, ob das Rating als Kopie an LB geht (wichtig im Falle von Belästigungen) und ob das Rating auch im Blog veröffentlicht werden darf. Je nachdem leitet das System die Nachricht als Kopie weiter, oder speichert einen Hinweis im Actionlog falls das Rating im Blog veröffentlicht werden darf.

Sobald das Missionsresultat/Rating gespeichert wurde, sendet das System den eingegeben Text mitsamt Missionsresultat an den vorgeschlagenen Partner. Falls als Resultat nicht Typ 1 ausgewählt wurde, läuft jetzt der Matching-Generator und versucht, weitere Datingvorschläge zu generieren.

4.05. Member Messaging System


pic
Sobald eine Member Message versendet wurde, erhält der Empfänger eine Email-Benachrichtigung im Richtext (HTML) Format. Darin ist auch das Memberfoto des kontaktierenden Members und das Website-Logo.

Neu empfangene Messages werden zunächst links im Member-Menu angezeigt. Dabei wird die Message auf maximal 60 Zeichen begrenzt, wobei Wörter nicht getrennt werden. Allfällig vorhandene HTML-Formatierungen in der Message werden bei der Anzeige im Member-Menu ausgefiltert.

Die Darstellung der Message-History erfolgt in Dialogform (Antworten des Gegenübers sind jeweils nach rechts eingerückt). Es wäre eine unbrauchbare Lösung gewesen, wenn man einfach eine "Inbox" und eine "Outbox" definiert hätte. Statt dessen musste das Member Messaging für diese spezifisch funktionierende Dating-Website so definiert werden, dass die Message-History pro Partner mit einem eigenen Strang aufgelistet wird (statt alle Partner durcheinander). So hat das Member stets die Übersicht, welche Nachrichten es mit Datingpartner X, Y, Z etc. ausgetauscht hat. Die Message-History kann sortiert werden, entweder neueste Nachricht zuoberst (nach Aktualität) oder zuunterst (chronologischer Verlauf von oben nach unten).

Um die Kommunikation noch übersichtlicher zu machen, wird zu jeder versendeten Message angezeigt, ob und wann das Gegenüber diese Message gelesen hat (mit Häkchen und Datum/Zeit falls gelesen). So bleibt man nicht im Ungewissen, ob eine versendete Nachricht überhaupt bemerkt wurde.

Beim Erstellen einer neuen Message wird der Empfänger aus einer Selectbox ausgewählt. Sobald dies geschehen ist, wird neben der Eingabe-Box das Foto des Empfängers angezeigt, und unterhalb der Eingabe-Box die bisherige Kommunikation mit dem ausgewählten Member. Falls noch keine Datingvorschläge bestehen, wird in der Eingabe-Box der "Senden" Button deaktiviert und ein Hinweis ausgegeben. So lange noch kein Empfänger gewählt wurde, bleibt in der Eingabe-Box der "Senden" Button in jedem Falle deaktiviert (disabled).

Der WYSIWYG-Editor für das Schreiben von Messages beinhaltet Funktionen zur Schriftformatierung, Farbwahl (mitsamt den definierten Grundfarben dieser Website), und einige ausgewählte Smilies (Emoticons) die beliebig vergrössert werden können. Der Editor ist voll zweisprachig und funktioniert ohne Sicherheitswarnungen via SSL.

Auf der Editor-Seite wird der spezielle Cursor (Herz-Cursor) ausgeblendet damit er nicht beim Schreiben stört, zumindest im Firefox.

Beim Klick auf den Sende-Button erfolgt eine Eingabeüberprüfung. Es wird sichergestellt, dass ein Empfänger ausgewählt wurde und dass das Message-Eingabefeld nicht leer ist.

Zum Schutz der Members wurde ein "Smutfilter" programmiert, der zweisprachig obszöne Begriffe herausfiltert (zensiert). Zwar können alle Smutfilter im Web stets durch andere Schreibweisen umgangen werden, doch hier haben wir kein Forum, sondern ein one-to-one Messaging System für zahlende Members. Also stimmt der Ansatz. Der rot markierte Zensurhinweis erscheint sinnvollerweise auf beiden Seiten, beim Sender wie auch beim Empfänger in der Message History. Im Actionlog der Admins erscheinen solche Nachrichten unbedingt in der Originalfassung, so dass die Admins im Extremfall das Member kontaktieren oder temporär bannen können (Account auf Status "deactivated" setzen).

4.06. Weiterempfehlungen
Es können gleichzeitig bis 7 Weiterempfehlungs-Nachrichten gesendet werden, mit Namen des empfehlenden Members und mit speziell codiertem Referrer-Link. Selbstverständlich kann der Email-Text und der Betreff noch vor dem Absenden editiert werden - jedoch nicht der Referrer-Link, da dessen Mechanik sonst nicht mehr gewährleistet wäre. Der Referrer-Link wird also erst beim Absenden in die Emails integriert.

Bei einer daraufhin folgenden Member-Anmeldung speichert das System zunächst den Referrer (Membernummer des weiterempfehlenden Members), welcher Teil des Links ist. Nur so ist gewährleistet, dass der Referrer beim allfälligen Browsing der Website nicht mehr verloren geht. Wird die Anmeldung gespeichert, so schreibt das System dem weiterempfehlenden Member die im Adminsystem definierte Anzahl Credits als Bonus gut und sendet ihm eine Email mit den entsprechenden Informationen.

4.07. Account verlängern
Zunächst wird geprüft, ob das Member innerhalb der laufenden Browser-Session bereits eine Verlängerung vorgenommen hat. Falls Ja, wird aus Sicherheitsgründen eine zweite Verlängerung blockiert.

Das System weiss zu jedem Zeitpunkt, wann eine Mitgliedschaft ausläuft. Normalerweise 6 Monate nach Anmeldedatum oder nach dem letzten Verlängerungsdatum, falls Anmeldung per Gutschein 3 Monate nach Anmeldedatum. Dem Member wird auf der "Account verlängern" Seite in Klartext angezeigt, wie die aktuelle Situation ist (Credits-Saldo falls vorhanden, Credits genügend für Verlängerung oder nicht, Restlaufzeit der Mitgliedschaft, Kosten für Verlängerung gemäss Definition im Adminsystem) und was das Member jetzt tun kann:

Falls genügend Credits vorhanden sind, kann das Member diese Credits für die Verlängerung verwenden und es erfolgt eine Abbuchung sowie eine Bestätigung mit altem und neuem Credits-Saldo. Falls die Credits nicht ausreichen, wird nur die Möglichkeit angezeigt, via Kreditkarte zusätzliche Credits zu kaufen.

Das System arbeitet in diesem Bereich relativ komplex, um alle möglichen Situationen in Klartext zu kommunizieren und je nach Situation weiter zu verarbeiten.

Nach erfolgter Verlängerung wird das Enddatum der Mitgliedschaft neu berechnet und dem Member angezeigt. Falls das Account vorher auf Status "expired" (abgelaufen) stand und deshalb der MG-Status auf "blocking", schaltet das System auf "paid" und "receiving" um.

4.08. Coaching-Anfrage

pic

Nur eingeloggte Members können Coaching-Anfragen stellen, bearbeiten, und bei Testfragen einen der antwortenden Coaches auswählen.

Zunächst wird zwecks Auswahl das Coach-Verzeichnis angezeigt. Falls das Member in der englischsprachigen Website-Version ist, werden ihm nur Anfrage-Links bei denjenigen Coaches angezeigt, die bei Sprachen auch Englisch angekreuzt haben, und zwar so geordnet, dass die englischsprachigen Coaches zuoberst im Coach-Verzeichnis erscheinen. Für Members, die Coaches eines bestimmten Geschlechts bevorzugen, wird das Gender-Icon angezeigt. Damit ein Coach nicht einfach ergoogelt und direkt kontaktiert wird, wird nicht der volle Name, sondern nur der Vorname des Coaches angezeigt.

Als Teil des Coach-Verzeichnisses wurde eine Coach-Suchmaschine mit Multifilter entwickelt. Damit kann kombiniert gesucht und gefiltert werden nach: Coaching-Kategorie, Sprachen, Setting und Beratungsform. Die Coach-Suchmaschine wird erst dann aktiviert, wenn genügend Coaches eine Aufnahme ins Verzeichnis beantragt haben und bewilligt wurden.

A) Coaching-Direktanfrage
Dem Member wird zunächst angezeigt, welche seiner eigenen Basisdaten (d.h. Geschlecht, Alter, Zivilstand) an den ausgewählten Coach übermittelt werden. Das Member wählt das gewünschte Setting, wobei das System nur diejenigen Settings auswählen lässt, die der betreffende Coach tatsächlich anbietet. Das Member kreuzt in einer Mehrfach-Auswahl an, welche Gründe für ein Coaching vorliegen (falls in der Liste aufgeführte Gründe zutreffen). Anschliessend schreibt das Member in eine Textbox, für was ein Coaching benötigt wird (Problembeschreibung), wobei das Textfeld limitiert ist und die Anzahl der verbleibenden Zeichen laufend angezeigt wird. Schliesslich kreuzt das Member an, ob seine Profildaten ("Reisegepäck") als Zusatzinfos für den Coach mitversendet werden, und akzeptiert die Coaching Nutzungsbedingungen. Beim Absenden wird geprüft, ob die Nutzungsbedingungen akzeptiert wurden und das Texteingabefeld ausgefüllt wurde. Die Coaching-Direktanfrage wird nun via Email an den betreffenden Coach gesendet und ist durch diesen in der Website im Coach-Bereich beantwortbar, wobei die Anfrage und die Memberdaten zwecks Übersichtlichkeit nochmals angezeigt werden. Sobald der Coach antwortet, erhält das Member eine Email mit der Antwort und der Email-Adresse des Coaches, um falls gewünscht den direkten Kontakt aufzunehmen.

B) Coaching-Testfrage
Eine Testfrage eines Members wird an alle Coaches versendet, die sich beim Aufnahmeantrag entschieden, am Testfragen-Pool teilzunehmen (oder dies nachträglich in ihrem Coach-Account definierten). Dazu füllt das Member das Textfeld aus und akzeptiert die Coaching Nutzungsbedingungen. Beim Absenden wird geprüft, ob die Nutzungsbedingungen akzeptiert wurden und das Texteingabefeld ausgefüllt wurde. Die Coaching-Testfrage wird nun via Email an alle Coaches gesendet, die am Testfragen-Pool teilnehmen, und ist für diese in der Website im Coach-Bereich beantwortbar, wobei die Anfrage und die Memberdaten zwecks Übersichtlichkeit nochmals angezeigt werden. Alle Antworten der Coaches werden gesammelt und für das Member im Member-Bereich zur Bearbeitung angezeigt. Sobald das Member sich für einen Coach entscheidet, erhält der Coach eine Mitteilung, dass er ausgewählt wurde und kann den direkten Email-Kontakt mit dem Member aufnehmen. Falls nach 7 Tagen kein Coach ausgewählt wurde, wird die Testfrage vom System gelöscht. Eine Testfrage kann auch durch das Member gelöscht werden - oder durch Admins falls die Testfrage gegen die Nutzungsbedingungen verstösst.

5. Geschützter Zugangsbereich "Coaches"

5.01. Coach-Login
Das Coach-Login erfolgt über das kombinierte Member/Coach Login. Auch wird bei einer Coach-Anmeldung sichergestellt, dass der Coach-Username nicht bereits als Membername existiert - dieselbe Prüfung läuft umgekehrt bei Member-Anmeldungen. So lange ein neues Coach-Account noch nicht durch einen Admin aktiviert wurde (d.h. die Bewilligung des Aufnahmeantrags des Coaches ist noch nicht erfolgt und/oder die Zahlung ging noch nicht ein), sieht der Coach eine entsprechende Warnung nach dem Einloggen.

5.02. Coach-Menu

5.03. Anfragen bearbeiten
A) Direktanfragen
Sobald ein eingeloggtes Member eine Coaching-Direktanfrage absendet, erhält der Coach eine Benachrichtigung via Email (je nach Wunsch des Members mitsamt Profilantworten) und kann zusätzlich die Anfrage in seinem Coach-Bereich in der Website abrufen. Hier kann er die Anfrage beantworten, während er zwecks Übersicht gleich oberhalb der Antwortbox nochmals die Memberdaten und die Anfrage lesen kann.

B) Testfragen
Falls der Coach sich bei seinem Aufnahmeantrag für die Teilnahme am Testfragen-Pool eingetragen hat oder dies nachträglich durch Editieren seiner Profildaten tat, erhält er bei jeder Testfrage eine Email und kann zusätzlich die Anfrage in seinem Coach-Bereich in der Website abrufen. Hier kann er die Testfrage beantworten, während er zwecks Übersicht gleich oberhalb der Antwortbox nochmals die Anfrage lesen kann. Der Coach sieht auch sofort, welche anderen Coaches die Testfrage wann und wie beantwortet haben (mitsamt Link zum Profil des antwortenden Coaches). So sieht man als Coach, was die Konkurrenten machen - dies erzeugt eine gesunde Rivalität. Wird 7 Tage lang kein Coach vom Member ausgewählt, dann löscht das System die Testfrage automatisch. Das anfragende Member kann eine Testfrage jederzeit selber löschen.

6. Geschützter Zugangsbereich "Admins"

6.01. Admin-Login und Overview
Das Adminsystem wird hierin nur rudimentär beschrieben. Eine detaillierte Auflistung aller Funktionen wäre zu umfangreich und das System ist weitestgehend selbsterklärend und sehr einfach bedienbar. Zudem wurden für einige Seiten spezielle Hilfetexte für die Admins integriert.

Das Admin-Login erfolgt über eine separate Login-Seite. Hier gibt es eine Anzahl technischer Schutzmassnahmen. Zudem wird im Falle eines misslungenen Admin-Logins eine Email mit allen eingegeben Daten und IP-Adresse etc. versendet, da dies ein Hinweis auf einen Cracking-Versuch (Brute Force oder Rainbow) sein könnte.

Für den Fall, dass ein autorisierter Admin gleichzeitig ein Member-Login oder Coach-Login hat, trennt das System die Zugangsbereiche sauber und konsequent. Ist der User als Member eingeloggt und wechselt danach in den Admin-Bereich, so werden alle Loginsessions gelöscht. Dasselbe passiert, wenn der User als Admin eingeloggt war und danach als Member eingeloggt. In jedem Falle verhindert das System, dass Überschneidungen der Zugangsrechte entstehen können.



Beim Einstieg ins Adminsystem sehen Masteradmins (nicht aber Assistant Admins) sofort eine kompakte, auf 1 Seite ausdruckbare Situations-Übersicht. Die eigentliche Notwendigkeit für solche massgeschneiderten Overviews besteht darin, dass die üblicherweise verwendeten Website-Statistiken wie "AWstats" nicht einmal ansatzweise fähig sind, einem Website-Betreiber die relevanten Informationen zu liefern. Die einzige Lösung ist, mit viel Aufwand für jede komplexe Website ein eigenes Statistik- und Analyseprogramm zu entwickeln, das alle relevanten Infos direkt anzeigt. Für die Auswertung der Visitors pro Tag oder die Sprachwahl-Verteilung werden hierbei Access Log Daten älter als 30 Tage gelöscht, denn interessant ist für diese spezifischen Auswertungen nur die aktuelle Phase d.h. die letzten 30 Tage. So wird verhindert, dass die Datenbank im Laufe der Zeit endlos aufgebläht wird. In der Kurzübersicht werden folgende Analysen live generiert:

6.02. Admin-Menu und Funktionen
Das Adminsystem bzw. Menu besteht aus 10 Sektoren. Die Zugriffsberechtigung jedes Admins auf diese 10 Sektoren wird individuell per Rechteverwaltung definiert. Falls für einen Sektor keine Zugriffsberechtigung besteht, wird der Sektor aus dem Menu entfernt und der Admin kann auch durch direktes Aufrufen der Webpage nicht darauf zugreifen.

A) WEBSITE
B) MEMBERS (mit Anzeige der Anzahl für jeden Filter)
C) MATCHING
D) GUTSCHEINE
E) PROFILFRAGEN
Profilfragen editieren (verschiedenste Input-Formate definieren gemäss hochkomplexem Framework, Anzeigestatus aktiv/inaktiv, Geschlechtsfilter neutral/männlich/weiblich, AddField-Labels, Optionen, etc.)

F) EVENTS
G) COACHING
H) WEBLOG
I) MAGAZIN
J) ADMINISTRATOREN
Unten im Menu steht auch die aktuelle "Who's online" Liste, geordnet nach Visitors / Members / Coaches / Admins, so dass der Admin auch während des Bearbeitens sieht, was "draussen in der Website" vorgeht.

Für die Pagination (Seiten blättern) muss normalerweise für jede einzelne Seite eine eigene Pagination programmiert werden. Schliesslich handelt es sich im Adminsystem um ganz unterschiedliche Datenbankabfragen, Filter, Sortierungen, und ganz verschiedene Ausgabeformate. Um dies brauchbar zu lösen, konzipierte und programmierte der Entwickler einen "Plug-and-Play Paginator". Dies ist ein extrem kompaktes Bedienungselement, das einfach in eine DB-Abfrage eingefügt wird und dann vollautomatisch die aggregierten Abfragen, Sortierungen, Ausgabeformate und anderen Parameter analysiert und in PHP-Sessions zwischenspeichert. Das Paginations-Element erscheint nur dann, wenn mehr Datensätze ausgegeben werden als die definierte Anzahl Datensätze pro Seite. Die Blätter-Pfeile erscheinen nur dann, wenn es rückwärts oder vorwärts tatsächlich Seiten hat. Seiten können auch direkt angesteuert werden durch einfaches Eintippen der gewünschten Seitenzahl - falls zu hoch oder zu niedrig, korrigiert das Paginierungs-Element die Seitenzahl selbständig. Damit beim Wechsel auf eine andere Seite (mit einer ganz anderen Pagination und z.B. anderen Anzahl Records pro Seite) nicht die gespeicherten Settings übernommen werden, erfolgt ein Unset der betreffenden 9 Sessions, sobald der Scriptname wechselt. Eine extrem kompakte, flexible und einfach wiederverwendbare Lösung.

6.03. Menu-Editor und Webpage-Editor
A) Menu-Editor
Alle Webpages der Website werden in einer zweisprachigen Sitemap dargestellt. Auch inaktive Seiten werden aufgelistet. Zusätzlich existiert hier ein Link zum Editieren des Newsframes (auf der Startseite links).



Jede Webpage kann wie folgt definiert werden:
B) Webpage-Editor
Das Editieren und Erfassen von Webpages, Blogposts, Magazin-Seiten und Event-Seiten erfolgt mit einem zweisprachigen Webpage-Editor. Dieser spezielle Editor ist deutlich besser als die üblichen Webpage-Editoren, die man sonst in Content Management Systemen findet. Er ist kompakter, einfacher bedienbar, und flexibler. Zudem gibt es keine der sonst üblichen, aber in Webpages unsinnigen Formatierungen wie "underline". Nachfolgend die Hauptfunktionen des voll funktionsfähigen und nach Tests mehrmals optimierten WYSIWYG (what you see is what you get) Webpage-Editors:

Der Editor kann von HTML-Editing auf Code-Editing umgestellt werden, so dass auch direkt im Code editiert werden kann. Ausserdem gibt es eine Vorschau-Funktion (Preview).

Der Editor ist komplett in Deutsch bedienbar (analog zur Sprache in diesem Adminsystem), könnte aber bei Bedarf sehr einfach auf Englisch umgeschaltet werden.

OnLoad-Focus: Sobald die zu editierende Webpage geladen ist, springt der Cursor sofort in das grosse Eingabefeld des Editors hinein. Man kann also sofort loslegen.

Selbst der Newsframe auf der linken Seite der Startseite kann damit editiert werden, obwohl dieser keine Webpage ist. Auch dies war eine Speziallösung.

Im Member Messaging System wird derselbe Editor eingesetzt, dort allerdings in einer speziell konfigurierten Version (kompakter, weniger Funktionen, keine Uploads und weitere Limitierungen, Smilies).

6.04. Der Matching-Generator
Der MG, ein intelligentes Partner-Matching-Tool, ist eigentlich das Herzstück der ganzen Website und wird primär im Member-Zugangsbereich verwendet. Dennoch ist er dem Adminsystem zugeordnet, da er hier definiert und adjustiert wird. Members haben aus Sicherheitsgründen keinerlei Direktzugriff auf den Matching-Generator.

Einfach beschrieben: Der MG ermittelt, wie kompatibel die Members zueinander sind. Dabei ermittelt er zunächst nur, ob Kompatibilität vorhanden (= Match) oder nicht vorhanden ist (= Failure). Falls kompatibel, ermittelt er den Datingfaktor aus unterschiedlichen Profilteilen und unterschiedlichen Gewichtungen mit einem mehrstufigen Algorithmus. Falls nicht kompatibel, ermittelt er die Gründe für die Nicht-Kompatibilität, um diese einerseits später dem Member anzuzeigen und andererseits für die Website-Statistiken aufzubereiten.

Für welche Members läuft der MG? Der MG läuft nur für "aktive" Members, die ihren zweiten Profilteil ausgefüllt haben und deren Accountstatus nicht auf "stored", "awaitpay", "expired" oder "deactivated" steht. Er erzeugt ausserdem maximal 3 Datingvorschläge für jedes Member, die dann im Matchingfenster des Members abgerufen werden. Der Matching-Generator ignoriert ein mögliches Matching, falls dasselbe bereits in der Vergangheit zustande kam und von einem der füreinander vorgeschlagenen Members abgelehnt (rejected) wurde. Und schliesslich ignoriert er ein Matching, falls das zu matchende Member bereits bei 3 anderen Members mit einem Datingvorschlag präsent ist (diese letzte Funktion ist nicht einfach zu beschreiben aber völlig logisch).

Wann läuft der MG? Der MG läuft für das betreffende aktive Member, nachdem es sich einloggt. Er läuft auch, nachdem das Member seinen Passport (Memberprofil) editiert hat. Er läuft auch, nachdem ein Member mit einer abgelaufenen Mitgliedschaft sein Account verlängert hat und jetzt wieder Datingvorschläge erhalten darf. Er läuft auch, nachdem das Member einen Datingvorschlag ablehnt oder eine diesbezüglich laufende Mission mit Resultat-Typus 2 bis 4 beendet. Er läuft auch dann, wenn Admins zwecks Test zwei Members matchen - dabei werden keine Datingvorschläge erzeugt, jedoch werden alle einzelnen Kriterien-Matchings und deren Detail-Resultate für den Admin sichtbar aufgelistet und farblich markiert. Der MG musste zu diesem Zweck in zwei ganz unterschiedlichen Versionen programmiert werden.

Welche Members versucht der MG zu matchen? Der MG versucht grundsätzlich, jedes aktive Member mit jedem aktiven Members des jeweiligen Wunschpartner-Geschlechts zu matchen. Bespiel: Felix sucht eine Frau und loggt ein. In der Memberbasis sind 200 Frauen. Der MG versucht nun, Felix mit jeder der 200 Frauen zu matchen. Dabei ergeben sich inkompatible Paarungen (die Gründe werden protokolliert) und einige erfolgreiche Matchings, für die der "Datingfaktor" (Grad der individuellen Übereinstimmung) mit einem Algorithmus errechnet wird. Felix wird am Ende in seinem Matchingfenster nur die maximal 3 besten Datingvorschläge (diejenigen mit den 3 höchsten Datingfaktoren) sehen und kann diese akzeptieren oder ablehnen (dieses innovative Prinzip wurde vom Entwickler als "Top-Matching" benannt). Falls Felix ablehnt, versucht der MG erneut, Matchings zu generieren, und schiebt diese im Erfolgsfalle nach.

Da es für ein Website-System auf einem gehosteten Server-Account (nicht eigenen Server) eine enorme Verarbeitungslast bedeutet, wenn z.B. 1000 Memberprofile mit 1000 Memberprofilen durch einen vielstufigen Matching-Prozess einzeln abgeglichen werden, erstellt der MG bei jedem Run eine Vorselektion. So wird die Ausführungszeit deutlich verringert und bewegt sich in einem Zeitrahmen, der es ermöglicht, auch bei über 1000 Members noch problemlos mit demselben Setup zu arbeiten.

Bei jedem MG-Durchgang für ein Member wird ausserdem dessen individuelle "Matching-Rate" (Vermittelbarkeit) berechnet. Um bei dem Beispiel zu bleiben: Falls Felix mit 20 von 200 Frauen matcht, hat er eine Matching-Rate von 10 Prozent. Dieses Resultat wird im Adminsystem angezeigt, um zu erkennen, welche Members eine besonders tiefe Matching-Rate haben. Solche Members haben entweder ihre Wunschkriterien allzu eng definiert oder sind grundsätzlich nicht gut vermittelbar. In beiden Fällen kann ein Admin einem solchen Member durch Hinweise das Problem aufzeigen.

Der MG ist vorbereitend programmiert für 3 abgestufte Durchgänge. Falls der erste Durchgang für ein Member keine Matchings ergibt, kann der MG bis zu zwei weitere Durchgänge laufen lassen, wobei bestimmte Kriterien weniger strikt (also mehr "fuzzy") verglichen werden. In der Anfangsphase läuft nur ein Durchgang.

Bei den Profilfragen-Antworten ("Reisegepäck"), die überwiegend aus Freitext bestehen, ist es unmöglich, die unterschiedlichsten Antworttexte zu matchen. Hierfür wird die dreistufige Gewichtung verwendet ("diese Frage ist für mich unwichtig... sehr wichtig"). Der MG ermittelt nun einfach die Übereinstimmung der Profilfragen-Gewichtungen beider Members. Beispiel: Falls die Frage "Welches sind meine Lieblingsfilme?" von beiden Members mit einer sehr hohen Gewichtung markiert wurden, ist dies ein Indiz für den MG, hier einen Punkt zu vergeben, da diese Übereinstimmung auf gemeinsame Austauschmöglichkeiten hinweist. Dasselbe Prinzip gilt auf jeder Stufe der 3-stufigen Gewichtung: Falls beide Members eine bestimmte Frage als "für mich unwichtig" markierten, vergibt der MG bei dieser Frage einen Punkt, denn auch diese Übereinstimmung deutet auf eine Kompatibilität der beiden Members hin.

Es gibt einige komplexe Spezialfälle im Matchingprozess. Zum Beispiel wird die Information bei "Kinder" nur dann berücksichtigt, falls das Alter der Kinder unter 18 liegt und falls weitere Kriterien erfüllt sind. Beim Matching der Grösse gibt es Definitionen wie "unter" und "über", auch dies wird logisch abgearbeitet. Genauso wie die Definition des Kontaktradius, der auch mit "im selben Land" und "egal wo" definiert werden kann. Besonders komplex ist das Matching der primären Erlebniswelten (genau 5) und primären Eigenschaften (genau 5), woraus der MG ermittelt, wie viele Detail-Items matchen und diese dann für die Punkteberechnung verdoppelt. Oder das Matching von Negativ-Kriterien bei Erlebniswelten und Eigenschaften ("mein Wunschpartner soll NICHT..."), denn hier läuft es so, dass das ganze Matching inkompatibel wird, falls ein einziges Negativkriterium übereinstimmt. Beispiel: Felix interessiert sich primär für Politik und Sabine will keinesfalls einen Mann der sich primär dafür interessiert, also ist dadurch das komplette Matching inkompatibel.

Die Berechnung der beiden Kontaktradien ist ebenfalls komplex, da hier geometrische Formeln eingesetzt werden mussten. Jedes Member kann angeben, dass es z.B. nur Datingvorschläge von Members im Umkreis von 100km erhalten will. Bei einem Matchingvorgang werden nun diese Kontaktradien beider Members verglichen (und in Datingvorschlägen direkt auf der Karte als hellblaue Kreise dargestellt). Berechnet wird die innere und äussere Distanz der beiden Kreise, allfällige Überschneidungen (Algebra) sowie die Erdkrümmung. Dies jedoch nur, falls nicht eines der Members die Option "im selben Land" oder "egal wo" ausgewählt hat, denn dann erledigt der MG die Kompatibilitätsprüfung bezüglich Kontaktradien wiederum anders.

Die Berechnungsformel (Algorithmus) für den "Datingfaktor" (Übereinstimmungsgrad) ist stufenweise wie folgt aufgebaut:
1.) "Passport" Übereinstimmungsgrad in Prozent: Anzahl übereinstimmender Punkte (gemäss definierter Punktezahl für jedes Kriterium) in Prozent der total möglichen MG-Punkte (wie im Adminsystem definiert).
2.) "Reisegepäck" Übereinstimmungsgrad in Prozent: Anzahl Punkte für übereinstimmende Profilfragen-Gewichtungen in Prozent der aktuell aktiven Profilfragen (wie im Adminsystem definiert).
3.) Resultierender "Datingfaktor" in Prozent: Die Berechnungen 1 und 2 werden anteilig so aufaddiert, dass die Berechnung 1 mit 70% und die Berechnung 2 mit 30% gewichtet wird.
Daraus ergibt sich der finale "Datingfaktor" in Prozent, wobei in Datingvorschlägen nur die Zahl ohne Prozentzeichen erscheint.

Es sollte unmöglich sein, als Member den Matching-Generator "auszutricksen". Um die Datenkongruenz zu gewährleisten, wird zum Beispiel verhindert, dass Members beim Editieren ihres Passports ihr Alter und ihre Grösse ändern können. Denn sonst könnten sie einfach "lügen" und diese Informationen anhand der Member-Stats anpassen, um so mehr Datingvorschläge zu erhalten. Auch der Membername kann nicht durch Members geändert werden, da dies in Member-Messages etc. für vorgeschlagene Partner verwirrend wäre. Die vorgängig genannten Daten können nur im Adminsystem verändert werden.

Eine automatische Auswertung der bisherigen Matchings sowie ein Matching-Generator-Log zeigt den Administratoren, welche Kriterien zu "failed matches" führten. Je nach Auswertung können dann einzelne Memberprofil-Informationen stärker oder schwächer gewichtet werden. Der Matching-Generator kann also jederzeit mittels Feinabstimmung adjustiert und an die aktuelle Memberbasis angepasst werden.

6.05. Housekeeping
Das "Housekeeping Script" ist ein zeitgesteuertes Programm, das von einem Cron Job getriggert wird und täglich bestimmte Aufräum-Aufgaben abarbeitet. Dazu gehört zum Beispiel:

7. Verschiedenes

7.01. Naming, Stilkonzept, Logos
A) Naming
Es war klar, dass der Website-Name zwar genügend starke Alleinstellungsmerkmale bietet um eine eindeutige Googlability und Wiedererkennungswerte erzeugen zu können, jedoch ist der Begriff "Bumble" mehrdeutig - im Englischen stehen dafür primär negative Konnotationen (taumeln, peinlich stolpern, unbeholfen sein). Der Auftraggeber wählte zunächst den Namen "Globalbumble", doch der Entwickler wies darauf hin, dass dieser Name übertrieben wirkt, nichts mit dem Grundthema (Liebe) zu tun hat, und von Leuten mit Muttersprache Englisch sogar sehr negativ assoziiert werden kann. Schliesslich kristallisierte sich der neue Name "Lovebumble" heraus. Doch auch dieser Name barg noch das Risiko, dass man dadurch die Website mit der primär negativen englischen Bedeutung des Begriffs "bumble" assoziiert. Damit nicht genug, es war ein Kunstbegriff der wenig Wortsinn ergab. Am ehesten noch "Liebestaumel". Oder irgendwas mit Hummel (bumble bee).

Um dem entgegenzuwirken und die positive Übersetzungsvariante "Das Summen" zu betonen, brachte der Entwickler schliesslich den Website-Slogan: "Catch the Buzz of Love". Dieser passt auch deshalb, weil im Logo das "Einfangen" (Glückskleeblatt und Honigtropfen) visualisiert wird und weil "catch the buzz" gut zur Wortwelt und zum Lifestyle der Zielgruppe passt. Der Vorschlag "die neue Datingdimension" wurde verworfen, da der sinnfreie Ausdruck "die neue Dimension" als Inbegriff billiger Werbesprüche schon seit Jahren für beliebige Angebote benutzt wird - bis hin zu "die neue Staubsauger Dimension" wie Google weiss. Um hierbei trotzdem Flexibilität und Entscheidungsfreiraum zu schaffen, kann der Slogan durch die Admins jederzeit geändert werden (Deutsch/Englisch getrennt) und erscheint in der aktuellen Version unterhalb des Logos.

Name des Magazins: Anfänglich wurde der Name "BumbleLife" verwendet, doch auch hier ergab sich das Problem mit der möglichen negativen Übersetzung. Der Vorschlag "BuzzingNews" des Entwicklers wurde angenommen, da dieser Name zum Slogan passt und äusserst flexibel ist, um darunter alle möglichen Inhalte zu publizieren. So muss man sich inhaltlich nicht festlegen.

Name der Firma: Für die Firma schlug der Entwickler den Namen "Pamment Projects" vor und designte dafür ein Firmenlogo. Beides wurde sofort angenommen.

B) Stilkonzept
Bei Dating-Sites gilt das erfahrungsbedingte Prinzip: Je mehr Frauen mitmachen, desto mehr Männer melden sich an. Im schlimmsten Fall besteht die Memberbasis weit überwiegend aus Männern. Dann würde jedoch der Matching-Generator zu wenig Datingvorschläge generieren können. Um dem entgegenzuwirken, wurde gemäss Konzeption eine Website entwickelt, die in der Gestaltung möglichst alle "männlichen" Komponenten und Signale vermeidet, frisch und freundlich wirkt, und in der textlichen Tonalität offen und informativ ist. Also nicht "in the face" und billige Effekthascherei, sondern vertrauenerweckend.

Das generelle Website-Layout durchlief mehrere ganz unterschiedliche Versionen (Iterationen). Schliesslich lieferte der Auftraggeber einen eigenen Vorschlag, der aber technisch kaum umsetzbar war. Das Problem war, dass Teile wie z.B. die springenden Leute auf der Startseite in andere Bereiche hineinragten und andere Teile sich gegenseitig überlappten, was im stets rechteckig definierten HTML gar nicht möglich ist, vor allem im IE. Zudem entstand das Problem, dass für jeden Bereich ein anderes Layout gemacht werden sollte (z.B. Anmeldung, Magazin, Gutscheine etc.) was dazu führte, dass in einer Seite links ein Programm stehen sollte, in der nächsten Seite rechts ein Text oder eine Zeichnung, in einer weiteren Seite links ein Menu das ein Programm war und oben noch ein Spezialmenu während dann wieder andere Teile ausgeblendet werden sollten, je nach Seite und Login-Situtation und so weiter.

Grundsätzlich geht das nicht, mit keinem CMS der Welt. Denn eine CMS-basierte Website kann nur dann funktionieren, wenn die Layouts wenigstens minimal standardisiert sind, was hier nicht der Fall war. Schliesslich programmierte der Entwickler ein ganz neues Framework und ein Ausnahmen-basiertes CMS, das alle Sonderwünsche erfüllt.

C) Logos
Der Entwickler designte zwei unterschiedliche Logos, ein Website-Logo und ein Firmenlogo.



Website-Logo: Um das Risiko der Falschübersetzung weiter zu entschärfen, brauchte es ein Logo, das mögliche Fehlinterpretationen verhindert und primär auf Frauen sympathisch wirkt. Verschiedene Vorschläge wurden ausprobiert aber passten zu wenig. Der Entwickler entschied sich daraufhin, mehr als 20 Logos zu designen. Diese wurden in einem eigens dafür programmierten Online Logo-Voting System einigen ausgewählten "Testern" vorgestellt, wobei diese für jedes Logo ein Rating und einen Kommentar abgaben. Das Resultat war klar, die Testerinnen und Tester entschieden sich ausgerechnet für das bunteste, frischeste und spielerischste Logo des Entwicklers: Dasjenige, das sowohl ein Glückskleeblatt assoziiert (Glück in der Liebe) und gleichzeitig einen Honigtropfen darstellt (Verbindung mit der Hummel / Bumble Bee als vom Auftraggeber fix definiertes Leitsymbol).

Firmenlogo: Für die Firma designte der Entwickler ein Logo, das die beiden "P" sowie die partnerschaftliche Kooperation in einem zum Website-Logo passenden Symbol visualisiert.

7.02. Hosting
Nach etlichen Schwierigkeiten mit zwei Hostern, und nach zwei kompletten Umzugs- und Re-Install-Aktionen, fand der Entwickler schliesslich einen perfekt passenden Hoster, der aussergewöhnlich schnell und zuverlässig performt (Novatrend). Nur durch den speziellen Effort eines erneuten Umzugs konnte erreicht werden, dass selbst diese komplexe Website eine gute Performance und geringe Ladezeiten bietet.

Auf dem Server wurden die nötigen Schreibberechtigungen für Spezialverzeichnisse gesetzt sowie verschiedene Mailkonten und dazugehörige Weiterleitungen definiert (coaching@ und andere).



7.03. Marketingmaterial
Für die "Under Construction" Phase designte der Entwickler eine Teaser Page in Multimedia (mit Fullscreen-Animation, Musik, Soundeffekten und Sprechstimme).

Druckfähige Grafiken: Gestaltet und getextet wurden Postkarten im druckfähigen 300 dpi Format für den ersten Versand (Memberwerbung) sowie das Site-Logo im druckfähigen 300 dpi Format für Inserate.

"Two Hearts Code Card": Es wurde eine Idee gesucht, wie man die Members motivieren kann, tatsächlich zu daten. Der Entwickler fand eine Lösung und gestaltete eine Code-Karte in Herzform. Die Code-Karte besteht aus zwei passenden ("matchenden") Teilen, einem Teil für Frauen und einem für Männer. Das Konzept ist, dass Members nach ihrem ersten akzeptierten Datingvorschlag den jeweiligen Teil zugeschickt erhalten (nur Heteros). Beim ersten Date nehmen Mann und Frau ihre Herz-Karten mit, legen sie übereinander, und erst dann erscheint eine geheime Web-Adresse in der Karte - passend zum Versprechen, dass man dort ein Geschenk erhält. Diese URL beinhaltet nicht etwa die normale Domain, sondern eine ganz andere, damit dies spannend wirkt. Auf der geheimen Webpage gibt das Member seinen Membernamen ein, dies wird protokolliert (nur einmal einlösbar) und das Member erhält ein Geschenk zugesandt. Auch dieses Geschenk dient wiederum als Motivation für die beiden vorgeschlagenen Members, sich noch einmal zu treffen...

Tramwerbung zwecks Mitgliederwerbung: Der Entwickler textete 11 lustige Werbesprüche für VBZ Tramdachtafeln (Cobra-Tram Zürich).

7.04. Rechtstexte
Diese Website enthält total 6 AGB bzw. Nutzungsbedingungen, was ungewöhnlich viel ist. Zum Beispiel musste für Coaches ein eigenes Regelwerk erstellt werden. Ein beauftragter Anwalt (Dr. Wyss) erstellte die Dokumente in Deutsch und Englisch. Der Entwickler musste daraufhin alle 6 Rechtstexte korrigieren und an die vorhandenen Mechanismen in der Website anpassen. Hierbei wurde darauf geachtet, die Rechtstexte möglichst kurz zu halten - sie sind kürzer als auf vielen anderen Dating-Sites.

7.05. Dokumentation
Anfangs erstellte der Entwickler ein umfangreiches Wiki, in welchem die bis dahin definierten Funktionsanforderungen, Pflichtenhefte und Detailkonzepte im Wiki-Format festgehalten und vom Auftraggeber geprüft wurden. Wie bei allen komplexen, mehrschichtigen Webprojekten erstellte die Webagentur GREG.CH zum Abschluss eine möglichst einfach geschriebene Software-Dokumentation, die hierin vorliegt. Für den Kunden (Website-Administrator) und für Interessenten wird darin nicht etwa beschrieben, wie das System programmiert ist (was für Laien unverständlich wäre), sondern was das System tut. Die Funktionalitäten und Konzepte sind rechtlich geschützt, wie dies im Impressum der Website publiziert ist und wie es sich aus dem URG ergibt. Der Entwickler hat die Verwendungsrechte bzw. Copyrights im gesetzlichen Rahmen auf die Betreiberfirma Pamment Projects GmbH übertragen. Die E-Plattform wurde mithilfe des Entwicklers erfolgreich beim Handelsregister als Sacheinlage in die GmbH eingebracht.

Die Skalierbarkeit der Webapplikation ist gesichert, da möglichst linear, unter konsequentem Verzicht auf verschachtelte Programm-Klassen programmiert wurde. Die zirka 40'000 Zeilen Programmiercode sind an allen nicht auf Anhieb verständlichen Stellen ausreichend kommentiert (direkt im Programmiercode) und alle Programmvariablen wurden nicht kryptisch sondern selbsterklärend definiert, so dass auch andere Web-Entwickler damit weiterarbeiten könnten. Dies war wichtig für den Investitionsschutz.

Internet-Plattformen dieser Grösse und Komplexität werden üblicherweise durch Teams von 5-15 Spezialisten realisiert. Dafür braucht es einfühlsame Kundenberater, lösungsstarke Konzepter, produktive Programmierer, kreative Designer, stilsichere Copywriter, erfahrene Übersetzer, realistische SEO-Experten und innovative Werber. Bei GREG.CH wird prinzipiell alles von einem einzigen Entwickler gemacht – bisher auch Projekte die mindestens dreimal so komplex waren (z.B. bbretrace.com). Das Prinzip "alles aus einer Hand" bringt Vorteile in der Kundenkommunikation und reduziert die Projektkosten deutlich.

Alle Plattform-Tests verliefen erfolgreich und die Feedbacks waren positiv. Vor dem Launch textete der Entwickler eine zweiseitige Pressemitteilung, die via pressetext.com an die Medien versandt wurde. Dies war ein spannendes Projekt.



Das abschliessende Kunden-Testimonial:

"Gregor Lemmenmeier hat für die Pamment Projects GmbH im Auftragswert von CHF 53K alle Detailkonzepte für die Dating Plattform Lovebumble erarbeitet, umfangreiche Beratungsleistungen erbracht, eine äusserst komplexe Programmierung erfolgreich abgeschlossen, das Design der Website gestaltet und wesentliche Textarbeiten beigetragen. Die hervorragend erbrachten Leistungen übertrafen bei weitem unsere Erwartungen.

Lovebumble ist dank GREG.CH keine gewöhnliche Dating Website. Für die ICT-Umsetzung des Konzeptes mussten viele neue Wege gefunden und beschritten werden. Nach den ersten Planungssitzungen war schnell klar: Gregor Lemmenmeier ist ein Multitalent und zudem ein äusserst verlässlicher Projektpartner. Er hat es verstanden, für die sehr komplexe Programmierung von Lovebumble überzeugende Lösungswege zu finden, die mit dem vorgegebenen Budget keine noch so gute Webagentur hätte finden können.

"Wenn es zwei Möglichkeiten gibt, etwas zu tun, nimm die dritte." Dieses Sprichwort beschreibt am besten die Arbeitsweise von Gregor Lemmenmeier. Dank seinem engagierten, kreativen Nachdenken über die gestellten Denkaufgaben konnten zentrale, Match entscheidende Fragestellungen erkannt werden und konnte jeweils in jeder Projektsituation die richtige Antwort gefunden werden. Gregor Lemmenmeier verfügt über ein fundiertes, breit gefächertes Fachwissen, vielseitige Begabungen und hervorragende analytische Fähigkeiten.

Für alle, die für ein herausforderndes ICT-Projekt einen hinsichtlich Output starken Umsetzungspartner suchen, kann ich Gregor Lemmenmeiers Dienste uneingeschränkt sehr empfehlen."

— Martin Greter, Vorsitzender der Geschäftsführung, Pamment Projects GmbH, Zürich
(Martin Greters Website: www.snetz.ch)




Der Entwickler:
Gregor Lemmenmeier (www.greg.ch)