Emojis are everywhere - from mobile phones to big screens on Times Square. Since chat apps support the quick way to communicate emotions, the success of the little images is unstoppable. With modern intranets and business chat applications, emojis are also part of everyones work-day.
Fortunately, we usually do not need to care about how they work. But it can still be very interesting to look under the hood. Thanks to Jøran Vagnby Lillesand for his lightning talk at NDC Oslo that explained how emojis work. The following is based on the information in the talk and the result of some playing around with javascript and a lot of emojis ;)
The initial question is: How "long" is an emoji?
What's the length of an emoji? or better - how many bytes are needed to represent an emoji in unicode.
'🙂'.length
1// makes sense'👪'.length
2// ook... should be 3 - but javascript is not a math language per se'😎'.length
2// hmmm...'👁️🗨️'.length
5// interesting'👩❤️💋👨'.length
11// wow! the love is big with this one
So, what is this all about? length=1 and length=2 can be explained by javascripts use of UTF-16. In UTF-16 the most used characters are represented by 1 byte, the less often used (not within the first 65536 characters) are represented by 2 bytes.
It's a bit more complex for the other ones. The are actually created from multiple emojis that are combined with an invisible character or - in the case of skin-tones - have a color-modifier behind the main emoji. Click on the following emojis to see what emojis they consist of (or type/paste one into the input area):
Click on an emoji to see its parts.
👁️🗨️
👩❤️💋👨
👍🏾
👨👩👦👦
➔👁️ 🗨️
Try your own:
consists of
Depending on your browser and operating system, you might not see all emojis / parts correctly.
Hallo zusammen! Heute schauen wir uns die vektorbasierte Suche an und warum sie die herkömmlichen Suchmethoden in den Schatten stellt. Lasst uns herausfinden, warum es sich lohnt, gerade jetzt in diese Technologie zu investieren.
Was ist vektorbasierte Suche?
Bevor wir loslegen, eine kurze Erklärung. Vektorbasierte Suche verwendet mathematische Modelle, um Wörter und Phrasen als Vektoren in einem mehrdimensionalen Raum darzustellen. Diese Vektoren erfassen die Bedeutung der Begriffe, basierend auf ihrem Kontext in grossen Datenmengen. Im Gegensatz dazu basieren herkömmliche Suchmethoden oft nur auf Schlüsselwörtern und einfachen, textbasierten Matching-Algorithmen.
Warum herkömmliche Suchmethoden nicht ausreichen
Eingeschränkte Genauigkeit
Herkömmliche Suchmethoden verlassen sich auf die genaue Übereinstimmung von Schlüsselwörtern. Das bedeutet, dass relevante Ergebnisse übersehen werden können, wenn sie nicht exakt die gesuchten Begriffe enthalten. Dies führt zu ungenauen und oft unbefriedigenden Suchergebnissen.
Fehlende Kontextverarbeitung
Kontext ist entscheidend für das Verständnis der Bedeutung von Wörtern und Phrasen. Traditionelle Suchen ignorieren oft den Kontext, was zu irrelevanten oder ungenauen Ergebnissen führt. Zum Beispiel könnte die Suche nach "Bank" sowohl Finanzinstitute als auch Sitzgelegenheiten zurückgeben, ohne zu unterscheiden, welchen Kontext der Nutzer meinte.
Die Vorteile der vektorbasierte Suche
Höhere Genauigkeit und Relevanz
Die vektorbasierte Suche versteht den Kontext und die semantische Bedeutung von Wörtern. Dadurch liefert sie relevantere Ergebnisse, selbst wenn die genauen Suchbegriffe nicht im Text vorkommen. Zum Beispiel erkennt sie, dass "Auto" und "Fahrzeug" ähnliche Bedeutungen haben und liefert passende Ergebnisse für beide Begriffe.
Verbesserte Nutzererfahrung
Dank ihrer Fähigkeit, kontextbezogene und bedeutungsvolle Ergebnisse zu liefern, verbessert die vektorbasierte Suche die Nutzererfahrung erheblich. Nutzer finden schneller, wonach sie suchen, was zu höherer Zufriedenheit und einer besseren Nutzung der Suchfunktionen führt.
Anpassungsfähigkeit an neue Trends
Vektorbasierte Suchmethoden können sich leichter an neue Sprachtrends und -gewohnheiten anpassen, da sie auf umfassenden Sprachmodellen basieren. Dies macht sie zukunftssicher und flexibel gegenüber Veränderungen in der Art und Weise, wie Menschen suchen und kommunizieren.
Effiziente Datenverarbeitung
Durch den Einsatz von Algorithmen des maschinellen Lernens und KI kann die vektorbasierte Suche grosse Datenmengen effizient verarbeiten und durchsuchen. Dies spart Zeit und Ressourcen im Vergleich zu herkömmlichen Suchmethoden, die oft langsamer und ressourcenintensiver sind.
Warum jetzt investieren?
Wettbewerbsvorteil
Unternehmen, die frühzeitig in vektorbasierte Suchtechnologien investieren, können sich einen entscheidenden Wettbewerbsvorteil sichern. Sie bieten ihren Nutzern eine überlegene Sucherfahrung, was zu höherer Kundenzufriedenheit und -bindung führt.
Zukunftssicherheit
Die Welt der Daten wächst exponentiell, und herkömmliche Suchmethoden stossen zunehmend an ihre Grenzen. Vektorbasierte Suchen sind besser gerüstet, um mit dieser Datenflut umzugehen und relevante Ergebnisse zu liefern. Eine Investition jetzt stellt sicher, dass Ihr Unternehmen auch in Zukunft wettbewerbsfähig bleibt.
Kostenersparnis
Obwohl die Implementierung vektorbasierter Suchtechnologien anfangs eine Investition erfordert, führen die Effizienz und Genauigkeit zu langfristigen Kosteneinsparungen. Weniger Ressourcen werden für die Verarbeitung irrelevanter Daten verschwendet, und die Nutzer finden schneller, was sie suchen, was die Produktivität steigert.
Wie viu helfen kann
Wir bei viu verstehen die Bedeutung von fortschrittlichen Suchtechnologien und wissen, wie man sie effektiv einsetzt. Unsere Experten begleiten dich durch den gesamten Prozess – von der Analyse deiner Bedürfnisse über die Entwicklung maßgeschneiderter Lösungen bis hin zur Implementierung und Optimierung.
Mit unserem Fokus auf Ideation & Innovation und einem benutzerzentrierten Ansatz entwickeln wir Suchlösungen, die nicht nur funktionieren, sondern echten Mehrwert bieten. Unser Ziel ist es, dir zu helfen, die Vorteile der vektorbasierte Suche voll auszuschöpfen und deinem Unternehmen den entscheidenden Vorsprung zu verschaffen.
Zusammengefasst
Die vektorbasierte Suche bietet eine präzisere, kontextbezogene und effizientere Möglichkeit, relevante Informationen zu finden. Angesichts der ständig wachsenden Datenmengen und der sich verändernden Suchgewohnheiten ist jetzt der perfekte Zeitpunkt, um in diese Technologie zu investieren. Mit viu an deiner Seite kannst du sicher sein, dass du die besten Lösungen erhältst, die sowohl technische Exzellenz als auch geschäftlichen Mehrwert bieten.
Also, worauf wartest du noch? Lass uns gemeinsam die Zukunft der Suche gestalten!
Obwohl wir in der Schweiz keine vollständige Schliessung hatten, haben die meisten Entwicklungsteams in den letzten drei Monaten von zu Hause aus gearbeitet und werden wahrscheinlich noch einige Wochen in ihren Heimbüros bleiben.
Während dieser Zeit mussten viele Teams Stories für ihren Scrum-Prozess schätzen. Nach einigen Versuchen mit Chat-Nachrichten haben wir schnell ein Tool eingesetzt, das wir einmal an einem VIUday entwickelt haben, um das VUE-Javascript-Framework zusammen mit Firebase für die Datenspeicherung kennenzulernen.
Das Tool ist bei weitem nicht perfekt und die UX war nicht wirklich durchdacht - aber es funktioniert - und wenn du das gleiche Bedürfnis hast und es ausprobieren willst, kannst du das gerne auf scrum.viu.ch tun.
Während dieser Unterschied dazu führt, dass das CMS den Inhalt über APIs in strukturierten Formaten anbieten muss und dementsprechend eine Wiederverwendung in verschiedensten Kanälen möglich wird, ist die andere damit einhergehende Änderung viel bedeutender. Und zwar führt die Loslösung vom Layout im CMS dazu, dass sich die Datenstruktur von «Seiten» und «Komponenten» lösen kann. Der Fokus wird stärker auf den eigentlichen Inhalt und dessen Struktur gelegt. Wohlverstanden, viele «traditionelle» CMS erlauben das auch, aber bei Headless CMS ist es die Grundannahme.
Dies hat einige Auswirklungen:
Fokus auf Inhalte und nicht auf Seiten
Kanal-Unabhängige Inhalte
Kein WYSIWYG Editieren (zumindest bei fast allen Headless CMS nicht)
Keine implizite Navigation (diese würde ja jeweils wieder nur für die Webseite funktionieren)
Gleichwohl werden die meisten Headless CMS Projekte einen oder mehrere «Seiten»-Inhaltstypen haben. Der meiste Inhalt sollte aber nicht in diesen Seiten liegen, sondern nur von der Seite angezogen werden. Der Inhalt kann also auch ohne Seite funktionieren (ein Chatbot, der FAQs beantwortet, sollte keine Links auf Seiten, sondern den Antwort-Text liefern).
Warum ist Headless jetzt in aller Munde?
Headless CMS gibt es schon seit geraumer Zeit – und einige «traditionelle» CMS unterstützen Headless Funktionalität seit vielen Jahren. Das Thema nahm aber erst in den letzten Jahren richtig an Fahrt auf. Dies liegt wohl vor allem an folgenden Punkten:
Die Multichannel-Wiederverwendung von Inhalten nimmt zu
Content Marketing gewann stark an Bedeutung – da hier viel Geld in Inhalte investiert wird, ist eine Wiederverwendung wichtiger denn je
Die unabhängige Implementierung des Web-Channels wurde mit Verwendung von Frontend-Technologien (z.B. React mit Next.js) einfacher
Die Anzahl interaktiver Elemente auf Webseiten nahm zu – diese Komponenten sind sehr oft auf strukturierte Daten angewiesen und können mit «Seiten» nicht viel anfangen
Mit responsiven Layouts mussten sich Editoren schon länger davon lösen, das Aussehen einer Seite genau definieren zu können
Was bedeutet das für Editoren und Marketing-Verantwortliche?
Für alle, die bisher mit «traditionellen» CMS gearbeitet haben, ist es wichtig die Änderungen genau zu verstehen und auch die Gründe und Vorteile, welche sich daraus ergeben, zu kennen. Nur so wird man über das anfängliche «ich kann die Seite gar nicht direkt editieren» hinwegkommen. Wenn das aber geschafft ist, wird auch für Editoren die Arbeit einfacher. Sie müssen sich nicht (oder nur beschränkt) um Komposition kümmern und können die Inhalte in genau den Strukturen abfüllen, welche dafür konzipiert wurden. Jeder Konsument der Inhalte ist dann verantwortlich für eine dem Kanal angepasste Darstellung.
Was bedeutet das für die Entwicklung?
Das CMS ist nicht mehr länger die Basis der Entwicklung. Die Wahl der verwendeten Frameworks und der Programmiersprache ist offen. Dies gibt viel Freiheit und ermöglicht die sinnvolle Nutzung von vorhandenem Wissen oder zum Teil sogar von bereits programmierten Artefakten (Styleguides, die z.B. auf React-Komponenten basieren können sehr leicht für das Rendering dieser Komponenten verwendet werden).
Auf der anderen Seite bedeutet dies auch, dass man auf einiges verzichten muss, was CMS bisher mitgebracht haben:
Authentifizierung / Berechtigungen
Session Management
Personalisierung / A/B-Testing
Navigations-Aufbau
…
Für diese Funktionalitäten gibt es wiederum Services, welche man kaufen kann. Aber selbst, wenn man einen solchen Service zuzieht muss die Integration selbst entwickelt werden. Dies bedeutet initial einen Mehraufwand – im Idealfall spart man sich diesen Aufwand aber an anderer Stelle wieder ein – und kann die Funktionalitäten in anderen Projekten wiederverwenden.
Integrationen
Heute gibt es kaum mehr ein Web-Projekt, welches nicht davon lebt, dass es eine oder mehrere Integrationen in Backend-Systeme zur Verfügung stellt und dem Benutzer damit Zugang zu den verschiedensten Self-Service-Funktionen ermöglicht. Sehr oft wird das CMS als Platform für diese Integrationen verwendet. Dies ist hier nicht mehr möglich. Es gibt prinzipiell zwei Varianten, wie man damit umgehen kann.
Integration über den Browser
Bei diesem Ansatz liefert der Server nur das «Gerüst» der Seite bzw. alle Inhalte, welche nicht aus dem Backend-System kommen. Der Browser lädt danach die Informationen direkt via API vom Backend-System nach. In Praxis wird hier fast immer noch ein weiterer Layer dazwischenstehen – aus Sicherheitsgründen und/oder um die Daten in eine Struktur zu bringen, welche für die Webapplikation sinnvoll ist.
Diese Integration bewährt sich vor allem, wenn eine Authentifizierung gegenüber dem Backend-System notwendig ist. Dabei muss nur der Browser das entsprechende Token besitzen (nach einem Login via Federated Authentication) und kann dieses dann für den Zugriff auf diverse Systeme und Daten verwenden.
Integration über die Rendering-Applikation
Sollten Daten integriert werden, welche unbedingt auch von Suchmaschinen indexiert werden sollen und dementsprechend öffentlich sind, macht eine Integration innerhalb der Rendering-Applikation für den Web-Kanal Sinn. Damit können diese Inhalte auf dem Server gerendert werden und eine Suchmaschine kann das fertige HTML lesen und indexieren. Dies ist übrigens auch einer der wichtigsten Gründe, weshalb Server-Side-Rendering (SSR) für so viele Inhalte wie möglich zur Verfügung stehen sollte.
Anbieter und Tools
Wir haben uns im Laufe der Zeit diverse Headless CMS angeschaut und diese auch teilweise ausprobiert. Dies soll aber kein Review der Anbieter werden. Wichtig ist bei der Auswahl auf jeden Fall, dass man sich (unter anderem) folgende Punkte anschaut:
Preis: Es gibt alles von gratis Systemen bis zu relativ teuren SaaS Angeboten.
Interface / Usability: Die Systeme unterscheiden sich stark in der Übersichtlichkeit, Geschwindigkeit und allgemeinen Editoren-Usability.
«Template»-Vererbung/Wiederverwendung: Welche Flexibilität man beim Aufbau der Inhaltstypen hat beeinflusst die «technische Sauberkeit» der Lösung oft stark und kann auch das Editieren vereinfachen oder unnötig komplex machen.
SDKs / Dokumentation: Für den Bau der Webseite oder anderer Kanäle stehen oft SDKs für verschiedene Programmiersprachen zur Verfügung. Wichtig ist die Qualität des SDKs da dadurch der Aufwand der Implementierung von Lösungen stark beeinflusst wird. Wichtig ist auch, dass die Dokumentation komplett ist und man vom Anbieter guten Support erhält.
Performance & Stabilität: Da viele Systeme von einem Headless CMS abhängig sein können, machen sich Probleme mit dem Headless CMS auch an vielen Stellen bemerkbar und viele Applikationen können dadurch ausgebremst werden.
Sitecore und Headless
Als langjähriger Sitecore Entwickler möchte ich natürlich auch erwähnt haben, dass sich Sitecore auch sehr gut als Headless CMS eignet. Es bringt (schon lange) die wichtigsten Features eines Headless CMS mit.
Freie Definition der Datenstrukturen
API-Zugriff auf alle Inhalte
Was bis 2017 gefehlt hatte war eine SDK für die Verwendung in den bekanntesten Frontend Frameworks. Dies wurde mit JSS aber eingeführt.
Zusätzlich zu den Funktionen eines Headless CMS bietet Sitecore auch Funktionen an, die man sich aus einem Enterprise CMS gewohnt ist, welche aber reine Headless-CMS meist nicht anbieten:
Authentifizierung / Autorisierung
Baumstruktur der Inhalte
Flexible Layouts (falls man die Seiten-Komposition den Editoren überlassen möchte)
Personalisierung / A/B-Testing
Analytics
u.v.m.
Sitecore hat im letzten Jahr klar kommuniziert, dass man in Zukunft (auch) auf SaaS-Angebote setzen wird. Man darf also gespannt sein, ob dies auch ein reines Headless Angebot wird (da dies verhindern würde, dass Sitecore Lösungen betreuen muss, welche Code von Dritten enthält). Mitte 2020 wird man hier wohl genaueres wissen.
Progressive Decoupling
Bei neuen Projekten stellt sich initial die Frage, ob ein Headless CMS oder ein eher traditioneller Ansatz gewählt werden soll. Viel häufiger (zumindest bei unseren Kunden) werden sowieso bereits beide Ansätze parallel eingesetzt. Meist gibt es ein «traditionelles» CMS, welches auch die meisten Seiten «produziert» und gleichzeitig via APIs Inhalte für Applikationen (Single Page Applications oder auch integrierte Komponenten) liefert.
Es ist also möglich die Vorteile beider Ansätze gleichzeitig zu nutzen – und damit natürlich auch einen Wechsel von Traditionell zu Headless schrittweise anzugehen. Dies kann insbesondere bei grossen und schon in die Jahre gekommenen Lösungen ein sinnvolles Vorgehen sein, um eine Modernisierung zu erreichen. Dabei fokussiert man am Anfang vor allem auf Inhalte und Daten, welche sich einfach strukturieren lassen (wie z.B. News, Blogs, Veranstaltungen, …) und bereits in anderen Kanälen benötigt werden.
