Ein «System» (Teilsystem, Gesamtsystem) bezieht sich üblicherweise auf einen Problemlösungsraum, hat damit immer Grenzen und muss auch immer klare Grenzen mit Schnittstellen haben. Ein System und umfasst hierbei nicht nur Softwarelösungen oder bunte Bilder wie Piktogramme und Icons sondern in seiner Gesamtheit Normen, Guidelines, Tools, Datenformate, Bezeichnungen, Vorgaben und Ergebnisse von Services und damit nicht zuletzt immer Menschen.

Ein CMS wie WordPress, TYPO3 CMS oder alternativ der UDS Core HTTP Server als Referenzimplementierung für das UDS Designsystem, mit dem wir mitunter auch diese Webseite betreiben, kann also Teil eines Systems und damit ein Teilsystem sein, muss es aber nicht zwingend sein.

Wir streben danach, UDS Teilsysteme mit den diversen Gewerken und Leistungsphasen so zu strukturieren, dass Teile wahlweise komplett fehlen und/oder hierbei sinngemäß durch Standards des Systems ersetzt werden.

Ohne an dieser Stelle die Inhalte eines Fachbuchs zu Medien- und Kommunikationsdesign, Content Marketing oder Vertrieb vollständig zitieren zu wollen, lässt sich Redaktion und Content Marketing durchaus gut trennen:

Redaktion hat vereinfacht ausgedrückt im Schwerpunkt mit der Veröffentlichung von Informationen zu tun. Da wird gekürzt, verweitert, umformuliert oder auch schlichtweg im Copy-Paste-Verfahren gearbeitet. Ein Teil hiervon bezeichnen wir als Content Management, den Aspekt der Qualitätssicherung oder auch Freigaben dann wiederum als Endredaktion. Es sind zuerst einmal Tätigkeiten als Teil des Prozesses.

Content Marketing erweitert Informationen und Daten um den Transport von zusätzlichen Botschaften, Meinungen, Handlungsanweisungen; all dieses mit dem Ziel, die Außendarstellung, Reichweite, das «Image» eines Unternehmens oder seiner Leistungen (Services), Produkte oder auch Veranstaltungen (Events) zu verbessern.

Während die Redaktion mancher Inhalte nur 1x formuliert wird, bedeutend Content Marketing hierbei, dass die immer gleichen Informationen über möglichst viele Kommunikationskanäle und das auch mehrfach übermittelt werden; dieses wiederum unter der Prämisse, dass es sich im Hirn der Empfänger einerseits einbrennt, andererseits man diesen wenn möglich nicht komplett auf die Nerven geht.

Ja und nein. Bezogen auf den Marketing-Mix eines Unternehmens, Vereins, einer Initiative oder auch von Selbständigen ist es so, dass man immer irgendein «Gesamtsystem» bestehend aus Menschen, Software, Hardware, Tools, Frameworks, Druckprodukten, Verlagen, Hosting, Social Media Portalen wie eben auch vielleicht ein CRM oder CMS einsetzt. All dieses Aspekte sind aber Teilsystems des Gesamtsystems.

Das UDS Designsystem bildet die Grundlage für sowohl Web, Print, Grafik sowie auch Text. Bezogen auf Webseiten hatten wir es phasenweise seit 2004 auch für TYPO3 CMS und ab 2015 für WordPress geplant, mussten aber etwas entnervt feststellen, dass wir mit jeder Komponent für Layouts, Daten, Filter oder Grafik, die wir planten und realisieren, diejenigen Kunden, die unbedingt mit «Templates» und «Themes» und «Dokumentvorlagen» in der Redaktion alles selbst machen wollten, zu kompliziert wurden.

Man könnte also meinen, dass es im Web also Teilsysteme für den Marketing-Mix wie WordPress und TYPO3 CMS sowie auch zig Baukastensysteme im Web gab und bis heute gibt.

Wenn Sie aber an dem Punkt sind, wo Sie über die Jahre ein paar Hundert kleine Erweiterungen programmieren, Mitarbeiter von Kunden oder auch Freelancer in Prozesse, Verfahren, Schnittstellen eingearbeitet haben, dann haben Sie als IT- und Medien-Dienstleister in Bezug auf den gesamten Marketing-Mix, den Sie bei mittelständischen Unternehmen, Vereinen, Initiativen und Selbständigen betreuen, weder Zeit noch Nerven, um sich wieder mit irgendeine Sicherheitslücke oder einer neuen Version eines CMS befassen zu müssen.

Eines der für uns und auch unsere Kunden wirklich sehr wichtigen Ziele war, ist und bleibt der Langzeit-Aspekt: Es ist uns und manchen unserer Auftraggeber irgendwann schlichtweg zu blöd geworden, wenn wir jährlich mehr Aufwand mit Updates für ein CMS und Probleme mit Abhängigkeiten von Plugins und Frameworks haben als mit der kompletten Neuentwicklung mancher Webseiten.

Bei WordPress denken Anbieter maximal bis Jahresende, denn das ist die Laufzeit für zig Themes und Plugins. Zum Vergleich: XML Datenformate mit zugehörigen Schemat für Daten und Informationen können mit zig Programmiersprachen seit über 25 Jahren gelesen und verarbeitet werden. Auch das DIN A4 Format wird sich nicht verändern.

Bei Softwarelösungen dachte man phasenweise mal in LTS Versionen von 3 Jahren. Man hat also, wenn man auf die aktuelle Version setzt, quasi für 3 Jahre Updates. Es bedeutet im Umkehrschluss, dass aktuell gerade das letzte Jahr der Vorversion läuft und die kommende Version schon getestet werden kann.

Das Problem hierbei: Redaktionssysteme und Softwarelösungen sind nur ein Aspekt rund um Content Marketing, Redaktion, Grafik, Web, Print, Hosting, Tracking, SEO und was sonst so kommen mag.

Um also sicherstellen zu können, dass uns nicht mit jedem Problem oder jeder Änderung bei Redaktionsverfahren das Gesamtsystem und damit die Zusammenarbeit mit auch Kollegen einen Schaden nimmt oder erst einmal wieder Zeit, Geld und Nerven kostet, begannten wir, das vormalige Designsystem um eine Referenzimplementierung und damit die Programmierung eines Redaktionsverfahrens zu erweitern.

Wir können also in UDS Veränderungen in Designkonzepten und der Software, wenn es um Web geht, besser planen und synchronisieren, während wir bei anderen Open-Source-Systemen dann zur Unzeit wieder über Veränderungen oder zuerst einmal Sicherheitsprobleme informiert werden.

Jeder kennt es aus dem Privatleben: Sie haben Hunger. Sie sind nicht damit nicht allein. Sie können die Thematik durchaus mal 15 oder 30 Minuten diskutieren, aber in den meisten Fällen wollen Sie in den nächsten 2 Stunden das Essen auf irgendeinem Tisch stehen haben. Es geht nur noch darum, ob Sie selbst allein oder zusammen kochen, braten, eine Pizza vom Discounter in den Ofen schieben, sich online was liefern lassen oder aber irgendwo vor Ort essen möchten.

Diese 2 Stunden mit grob 1.50, 1.75, 2.00, 2.25, 2.50 grob die Dimension, in welcher wir für die Redaktion und Gestaltung neue Layout-, Inhalts- oder Daten-Komponenten planen, den Prototyp realisieren und das faktisch dann auch live oftmals schon einsetzen können.

Von so einem Zeitplan konnten wir bei TYPO3 CMS und auch bei WordPress im Grunde genommen nur träumen, wenn es um Eigenentwicklungen geht. Bei WordPress kamen wir mit WordPress Shortcode Plugins phasenweise an dieses Tempo heran, aber mit den Änderungen von WordPress 4.9 zu 5.x oder auch TYPO3 CMS 4.x zu 6.x (weil das Team der 5.x Version sich als Spin-Off von TYPO3 verabschiedete) hieß das einst für uns, dass wir Hunderte unserer Plugins und Widgets hätten nun überprüfen oder überarbeiten müssen.

Zu jeder Aufwands- und Kostenbetrachtung sollte also immer auch die Frage beantwortet werden, ob eigentlich bei Systemänderungen wie einem CMS auf die bestehenden Erweiterungen Rücksicht genommen wird?

Es sind Menschen, welche ein System nutzen, es diskutieren, planen, realisieren, erweitern, dokumentieren, optimieren und immer wieder auch andere Kollegen in Teilaspekte in Nutzung, Design, Entwicklung, Hosting, Druckformate, Hersteller-Vergaben für Produkte einarbeiten. Systeme können richtig eingesetzt viel Zeit, Geld und Nerven sparen. Unser System wie jedes andere auch ist nicht perfekt. Wir haben nicht den Anspruch, jeden Hype sofort mitmachen zu müssen. Manche Trends greifen wir pro-aktiv auf bevor unsere Kunden sich das wünschen. Andere ignorieren wir weil wir Alternativen empfehlen.

Der erster Gedankensprung, den wir jedem unserer Auftraggeber in Fällen, wo wir mit UDS als Designsystem und dem UDS Core HTTP Server als Referenzimplementierung arbeiten, empfehlen, ist folgender:

Beginnen Sie zwischen Designsystem, Daten und Content Management auf der einen Seite von dem, was Sie bislang rund um Webseiten und CMS wie WordPress gekannt haben oder bereits nutzen.

Das Grundprinzip eines Systems besteht darin, dass es für einen Problemlösungsraum schrittweise geplant, realisiert und darin genutzt wird. Eine der ersten Zielsetzungen in diesem Kontext für UDS bestand und besteht darin, dass wir mit UDS nicht nur digitale Medien wie Webseiten sondern auch Grafik, Druckansichtne, Print-Layouts und APIs mit Schnittstellen abdecken.

Das System mit dem UDS Designsystem und dem UDS Core HTTP Server ermöglicht durchaus die Redaktion und das Rendern von Webseiten mit 1 bis 10.000 Pages (oder auch mehr). Es reduziert sich aber nicht nur auf ein CMS für Homepages sondern lässt sich am ehesten als Headless CMS verstehen, nur es in UDS egal ist, ob wir damit die redaktionellen Inhalte für ein 700-seitiges Fachbuch oder aber die grafischen Objekte für einen DIN A0 Plan als Zeichnung formulieren.

Ein System kann in der Planung immer weiter sein als die eigentliche technische oder organisatorische Umsetzung, dh. selbst wenn wir schon für neue Komponenten die Layouts entworfen und sogar programmiert haben, fehlt für den Einsatz noch immer die Information, Aus- und Fortbildung der Menschen, die mit UDS arbeiten.

Der UDS Core HTTP Server als Referenzimplementierung ist hierbei eine Software, mit welcher sowohl testen als auch zeigen, dass Bestandteile des Systems von der Planung über das Prototyping in die Produktion überführt werden oder bereits überführt wurden.

Das Primärziel im UDS Designsystem bezogen auf Druckmedien bezieht sich bislang auf bestimmte Layout- und Daten-Komponenten für in Europa übliche Standardformate, darunter im Schwerpunkt das DIN A4 Format im Portrait Mode, dh. DIN A4 hochkant.

Das zweite Formate, auf das wir Druckansichten optimieren, ist das DIN A4 Querformat.

US Formate wie US Letter Varianten weichen von DIN A4 im Format ab, werden aber in zukünftigen Versionen berücksichtigt werden können, wenn denn der Bedarf besteht.

Eines der Primärziele für die Planung und Entwicklung des UDS Designsystems und der Referenzimplementierung mit dem UDS Core HTTP Server war die Unterstützung einer Mehrsprachigkeit.

Zum Thema Mehrsprachigkeit muss man wissen, dass deutschsprachige Text stets grob 30% länger sind als englischsprachige Texte. Chinesische Übersetzungen hingegen haben oft nur 33% bis 50% der Länge englischer Texte und sind damit sehr kompakt. Das hat Einfluss auf Layouts, Layout und Satz sowie Weißraum.

Im Chinesischen entspricht jedes Zeichen einer Silbe, so dass ein Wort wie Beijing mit 北京 nur noch aus zwei Zeichen besteht. Hinzukommt, dass im Chinesischen viele Worte im Text, die in anderen Sprachen erforderlich sind, im Chinesischen fehlen können.

Wir haben UDS als Designsystem in Bezug auf technische Features dahingehend geplant, dass wir mit einer UDS Core Installation mehrere Webseiten mit verschiedenen Domains betreiben können.

Redaktionelle Inhalte lassen sich referenzieren, so dass mehrfach vorkommende Inhalte nicht mehr manuell kopiert werden müssen sondern nur noch die Referenzen auf diese Inhalte. Es handelt sich auch nicht nur um Textbausteine sondern Referenzen auf zuweilen komplette Sektionen mit allen möglichen UI-Komponenten um Auf- und Zuklappen, ohne hier ins Detail gehen zu wollen.

Jeder weiß, dass Unternehmen, Vereine, Initiativen und Selbständige mehrere Domains haben, und wenn man diese nicht selbst alle hat, so hat man wiederum Kollegen und Kooperationspartner.

Überall, wo Sie also mit Ihren Inhalten, Leistungen, Produkten, Terminen, Preisen oder auch nur einer Erläuterung von Fachbegriffen sich austoben haben Sie ein Problem:

Wenn Sie nur eine eine EINZIGE ÄNDERUNG vornehmen, wissen Sie oftmals gar nicht mehr, wo bereits auf welchen Webseiten und Domains eigentlich Kopien vorhanden sind. Wen müssen Sie benachrichtigen? Bis wann ändert dort jemand das dann? Zu welchen Konditionen, Preisen, Reaktionszeiten machen die das?

Doch selbst wenn Sie alle Ihre Webseiten mit 2 Domains für DE- und COM-Domains selbst verwalten sollte, haben Sie noch immer ein Problem: Viele Redaktionssysteme CMS verwalten Inhalte immer nur für eine Domain.

Wenn sich mittelständische Unternehmen, Vereine, Initiativen oder Selbständige für Semantik, LinkedData und SEO interessieren, dann geht es zuerst einmal nur darum, dass eine Webagentur doch bitte für «WordPress» irgendein Plugin installieren möge, mit dem das dann «einfach irgendwie automatisch passieren» möge.

Kopfschmerzen? Irgendeine Tablette schlucken. Noch keine Kopfschmerzen, aber vielleicht im Laufe des Tages? Einfach schon vorher eine Tablette schlucken! Plugins installieren, Tabletten schlucken, sind im Prinzip die gleiche Liga: Man verdrängt die Details einer Problemstellung, sucht nach einer Lösung, ohne zwischen Ursache, Wirkung, Zielen und Optionen differenzieren zu können.

Diese beste Variante, wie man Informationen für LinkedData und SEO semantisch auszeichnen kann, beginnt an dem Punkt, dass bereits das Redaktionssystem und Redaktionsverfahren eine semantische Auszeichnung von Informationen in eben der Redaktion ermöglicht. Damit muss man das also nicht mehr später nachträglich mit irgendwelchen Tools (z. B. Google Tag Manager) machen.

Das für UDS realisierte Redaktionsverfahren unterscheidet sich von einer klassischen Reaktion von Inhalte über Formulare in Software-Lösungen oder einem CMS dahingehend, dass Informationen in UDS mit XML Markup erweitert werden.

Typische semantische Stereotypen sind beispielweise «Product» oder «Services» oder «Organization» oder «Person». Bei einem Begriff wie z. B. «Ariane» haben Sie ohne eine semantische Auszeichnung keine Ahnung, ob das die Exfreundin des Geschäftsführers, eine Marke für Baby-Windeln, das Raketen-Programm der ESA, irgendein Asteroid oder auch schlichtweg nur der Verweis auf die griechische Mythologie sein soll.

UDS löst Probleme. Und es sind Designer, Redakteure, Entwickler, welche mit UDS die Probleme lösen, nicht unsere Kunden selbst. Ausnahmen bestätigen die Regel.

Im Falle von WordPress bezeichnet man das Prinzip als Shortcodes, aber UDS setzt konsequent auf W3C- und ISO-Standards in der Syntax und unterstützt hiermit konsequent auch XML Namespaces, damit Beteiligte bei Namensgleichheiten für Komponenten diese über Namespaces klar nach Standard differenzieren können.

Das Denken in Stereotypen, Daten und Komponenten ist den meisten mittelständischen Unternehmen, Vereinen, Initiativen und Selbständigen zum Zeitpunkt, wo man eine neue «Homepage» oder einen «Flyer» will, doch ziemlich fremd. Man hat zumeist nur etwas von WordPress gehört, interessiert sich gewohnt erst einmal nur für den Preis und will auch nichts anders.

Wozu nun Objektorientierung? Die klassenbasierte Objektorientierung wurde 1986 einst mit C++ in der Software-Entwicklung eingeführt und bedeutete zuerst einmal, dass Elemente, die mehrere Daten verschiedener Typen wie z. B. Name/Text, Geburtsdatum/Datum, Schuhgröße/Zahl als sogenannte Structures nun im Zuge der Klassizierung von Datentypen als «class» bezeichnet wurden.

Was bezogen auf Listen von Datensätzen solcher Typen, Objekte genannt, noch zu Beginn in einer Excel-Liste tabellarisch mit einer Spalte je Eigenschaft hätte erfasst werden können, bekommt in der Objektorientierung aber eine weitere Dimension.

Dadurch, dass ein Wert nicht nur ein Text, eine Zahl oder ein Datum sondern ein Objekt eines weiteren Typs sein kann, ist es bezogen auf ein Excel-Denken möglich, eine komplette Tabelle als Wert in einzelnes Feld von Zeile/Spalte zu schreiben.

Damit aber nicht genug: Wenn bei einer Person «Manuel» im Feld «Ehepartner» eine zweite Person «Manuela» angeben wird und auch diese eine Eigenschaft «Ehepartner» hat und man auch dort wiederum die objektorientierte Datenstruktur von «Manuel» hineinkopiert, haben wir eine Zirkularbeziehung bei welcher Sie bis zum Erreichen des Speicherlimits des Rechnerns beim Kopieren der Daten in Manuel, Manuela, Manuel, Manuela über diese Beziehung zwingend sogenannte Objektreferenzen benötigen.

Im Gegensatz zur auf Klassen basierenden Objektorientierung, wie man diese in zig Programmiersprachen kennt und auch in Schulen oder Universitäten unterrichtet, baut das UDS Designsystem auf Stereotypen auf.

Der maßgebende Unterschied hierbei ist der, dass die klassische Objektorientierung bei einer semantischen Betrachtung, Formulierung und Verknüpfung von Informationen schlichtweg an Ihre Grenzen kommt, weil wir nicht nur eine Mehrfachvererbung bräuchten (die in den meisten Programmiersprachen nicht unterstützt wird) sondern darüber hinaus Constraints und Guard Conditions, um die Zuordnung von Objekten zu einem bestimmten Stereotyp prüfen zu können.

Beispiel: Ein «DIN A4 80g/qm Blatt» ist also eigentlich zuerst einmal nur ein Blatt Papier. Den Typ des «DIN A4 80g/qm Blatt» erfüllt es nur dann, wenn das Papier die Eigenschaft der Grammatur von 80g/qm, Breite 210mm und die Höhe von 297mm hat.

In der Objektorientierung entspreche es vielleicht einem konfigurierten Objekt der Klasse «class PaperSheet». Erst eine Prüfung von Eigenschaften aber zeigt, ob das Objekt dem Stereotype entspricht.

Das UDS Designsystem und die Referenzimplementierung mit dem UDS Core HTTP Server ist komplett objektorientiert.

Wer eine Webseite mit einem CMS pflegen will, interessiert sich nicht groß dafür, wie die Daten dort abgelegt werden: Man kann davon ausgehen, dass die Daten in SQL Datenbanken liegen. Das Problem hierbei: Jedes CMS hat seine andere Datenbank-Struktur. Jedes Datenbank-System hat wiederum seinen eigenen SQL-Befehle welche über den Mindest-SQL-Standard hinausgehen oder von diesem abweichen.

Wenn es um Datenspeicherung und das Laden geht, sollte man eines nicht vergessen: Daten sollen auch Export oder an Dritte übergeben werden. Wäre es nicht auch sinnvoll, wenn man die Daten, die man dann als Datei hat, auch Prüfen kann, ob diese formal betrachtet korrekt formatiert sind?

Der W3C Standard, den man für HTML5 für Webseiten kennt, den gibt es mit XML Extensible Markup Language auch für reine Datenformate. XSL XML Schema Definition Dateien dienen der Definition von erlaubten Datenstrukturen, auf deren Grundlage man XML Files prüfen kann.

Druck-Ansichten von Webseiten sind letztendlich die primäre Strategie, wie man im Medienmix seit 2012 unter dem Aspekt des Responsive Web Design, kurz RWD, imn Grunde genommen bei HTML Dokumenten im Browser mit CSS Media Queries dafür sorgen könnte, dass die Informatione, welche Sie gerade im Browser anschauen, auch in einer druckfähigen Variante vorhandenen sind.

Die Voraussetzung hierfür besteht nicht nur darin, dass entsprechende CSS-Styles für die Druckansicht programmiert wurden: Die Problematik beginnt von Beginn an damit, dass das Papierformat für Druckansichten immer ein Limit nicht nur in der Breite sondern auch der Länge hat.

Hinzukommt die Problematik, dass mitunter in den USA das Papierformat ein anderes ist als das DIN A4 Format, wie wir es in Deutschland und Europa kennen. Genau genommen haben die USA sogar mehrere verschiedene Papierformate.

Jedes Unternehmen steht also vor dem Problem, dass man für Druckwerke für Europa, USA und die Welt immer verschiedene Formate berücksichtigen müsste, während man im Browser längst responsive gestalten kann.

Das UDS Designsystem berücksichtigt also im Idealfall als kleinsten gemeinsamen Nenner auch für Print-Layouts verschiedene Papierformate, damit die selben redaktionellen Inhalte sich nicht nur für Web sondern auch Print anpassen können.

Auch wenn wir noch immer irgendwo manuell Formulare ausfüllen und unterschreiben müssen oder bei Broschüren oder Webseiten dann die Domain manuell abtippen müssen oder dann bestimmte Unterlagen über die Webseite zwar anfordern, die aber dann wiederum auf dem Postweg bekommen: Jeder weiß, dass es digitale und gedruckte Medien gibt und wir Schnittstellen brauchen.

QR-Codes: Spätestens seit 2015 kennt das eigentlich jeder, auch wenn es immer mal Varianten ähnlicher Systeme gibt: Man scannt einen Code mit einer App über das Smartphone, und dann dann kann die App aus dem QR-Code Texte, Daten oder eine Adresse auslesen.

Der Haken an der Sache: Es gibt viele Varianten solcher QR-Code artigen Verfahren, dh. man möchte ja meinen, dass sich die Menschheit auf ein System hätte einigen können, aber dem ist eben nicht so.

Bezogen auf ein Designsystem und eine Referenzimplementierung bedeutet das, dass es für die Wege zwischen einem Medium und einem anderen Medium Teil eines Systems sein müssen. Da auf eine Visitenkarte oftmals nur 1 Code passt, muss man sich also entscheide, ob man für Print zu Web auf QR Code oder Instagram setzt.

Solche Codes erfordern in Layouts aber auch einen gewissen Platz. Sind also Grid-Layouts und Raster bereits Teil eines Systems, muss die Größe von z. B. QR Codes limitiert werden was wiederum dazu führt, dass auch der Informationsgehalt in einem QR Code ein Limit erforder.

Inhalte, Parameter, Config, IDs, Versionsnummer, Änderungsdatum

Jede Information, egal ob es sich um Text wie Überschriften, Links, Absätze, Bildadressen oder aber auch das Erstellungsdatum, Änderungsdatum, den Autor, Kategorien, Tags, Layout-Variante, Style-Variante sowie nicht zuletzt aber auch schon der Typ von Objekten und deren Versionsnummer handelt, sind einfache oder komplexe Werte und damit Daten.

Das gilt über Web hinaus auch für Druckwerke, 2D-Grafiken, 3D-Rendering oder Parameter für bei Herstellern zu produzierende Objekte. Wenn also Druckvorlagen noch aus 2007 stammen bedeutet Zustand/State zuerst einmal, dass wir wissen wollen, für welche Version des Designsystems etwas geplant und erstellt wurde.

Beispiel: Sind Standardformate für Firmenschilder Teil des Designsystems, und verändert der primäre Hersteller nun die Position vom Schrauben, hat das einen Einfluss auf das Layout und damit wiederum auf Vorlagen. Ein Designssystem berücksichtigt also nicht nur die eigenen Zustände sondern auch die Zustände von Schnittstellen.

Jede Informationen und damit alle Daten in einem Gesamtsystem und auch jeden Teilsystem unterliegen Veränderungen in Bezug auf einen Lebenszyklus. Daten werden erstmals erzeugt, werden für eine mögliche Veränderung dann gelesen, werden über die Minuten, Stunden, Tage, Wochen, Monate und Jahre möglicherweise mehrfach erweitert, gekürzt, umformuliert oder korrigiert und letztendlich möglicherweise auch gelöscht.

Auch das Datenformat des Systems wird über die Zeit Änderungen haben, dh. es gibt immer neue Komponenten, Veränderungen an Komponenten, neue Parameter, neue Varianten oder aber eben auch mal den Fall, dass bestimmte Komponenten in der bisherigen Syntax oder auch vom Typ komplett entfallen sollen.

Maßgebend zum Verständnis ist von Beginn an, dass ein System aus Software, Templates, Frameworks, Files, APIs, Hardware sowie aber auch realen Menschen, die es entwickeln, erhalten, nutzen, nur funktionieren kann, wenn in jedem Zustand alle Teile zusammenpassen und Menschen wissen, wie man mit dieser Version arbeitet.

Normalerweise ist es also so, dass z. B. das Datenmodell für Version 1.5.3.12 möglicherweise noch dem Templates für 1.5.3.40 verarbeitet werden kann, nicht aber mit 1.5.2.x oder 1.6.x.

Was tun, wenn eine Sicherungskopie für eine alte Vesion ist?

Das UDS Designsystem setzt maßgeblich auf Data Driven und Document Driven Design im Kontext von XML W3C- und ISO-Standards. Die Besonderheit des XML Datenformats besteht hierbei darin, dass Datensätze für bestimmte Datentypen wie z. B. ein Datenformat für ce:Product eben nicht nur den Typ und Namen Product haben sondern über den XML Namespace-Prefix ce: auf einen Namensraum «Content Elements» verweisen und damit immer den aktuellen Standard meinen.

Wenn nun ein altes Dokument mit einem ce-Namensraum geladen wird, wird über den XML-Prolog die tatsächliche Version angegeben, dh. für das Processing von Dokumenten ist das System in der Lage, alte Dokument-Formate auch dann erkennen zu können, selbst wenn der XML-Code zuerst einmal gleich aussieht.

Einige Komponenten ermöglichen Varianten und Variationen, dh. anstelle der Planung und Realisierung einer völlig neuen Komponente verwenden wir für das Datenmodell weiterhin zuerst einmal die bestehende Syntax, ermöglichen aber über einen Zusatzparameter die Auswahl von eben einer Variante.

Ein typisches Beispiel für Varianten und Variationen sind mitunter die Hintergrundfarben vieler Sections auf dieser Webseite: Es handelt handelt sich hierbei um style-variant Parameter.

Wichtig zum Verständnis ist hierbei, dass viele Komponenten medienübergreifend geplant sind, dh. eine style-variant Information gibt es also nicht nur für Web sondern sinngemäß auch für Druckwerke. Die technische Umsetzung kann eine andere sein, aber die Bezeichnung im System ist die selbe.

Wir setzen seit über 20 Jahren konsequent bei der Zusammenarbeit mit Unternehmen, Vereinen, Initiativen und Selbständigen clientseitig auf Windows und serverseitig auf Linux.

Die fehlende Erwähnung von Apple/Mac werten manche Kandidaten als Kritik an Hard- und Software von Apple, aber das ist ein Irrtum. Die Bedeutung von Mac/OS auf Serverseite ist faktisch null. Das gilt auch für Desktop-Anwendungen bei unseren Auftraggebern.

In Java, C# sowie NodeJS entwickelte Desktop-Anwendungen sind über zugehörige Runtimes für Mac/OS auch auf diesen Geräten lauffähig. Die Entwicklung von Desktop-Anwendungen spielt aber bereits seit Jahren faktisch keine Rolle mehr. Anwendungen laufen auf Serverseite und werden über Browser-Clients bedient und/oder über APIs gesteuert.

/// SNEWMEDIA setzt mit UDS auf Komponenten, Document Driven Design, Standard over Configuration, XML als W3C- und ISO-Standard, Datenformat für die Serialisierung objektorienter Datenstrukturen, semantisch ausgezeichneter Informationen, Server- und Domain-übergreifenden Selections für Echtzeit-Rendering von Webansichten und Grafik.

Zum Vergleich: Das Datenbank-System von TYPO3 CMS oder WordPress sowie Datenbank-Dumbs und damit Datenbank-Exporte von TYPO3 CMS oder WordPress sind KEINE W3C Formate und damit KEINE W3C Standards.

Der für /// SNEWMEDIA maßgebende Standard im Web ist das W3C World Wide Web Consortium.

Webstandards des W3C sind mitunter: HTML CSS XML XSD DTD XSL SCXML JSON LD+JSON WebGL

Frameworks sind letztendlich Programmbibliotheken für die Client- oder Serverseite von Webabwendungen, egal, ob es sich nun um Webseiten, Portale oder Software handelt. Wichtig zum Verständnis ist hierbei aber auch, dass bei einem Medien-übergreifenden System auch stets an Druckwerke, PDF-Downloads, Produktionsverfahren für Beschriftung von Objekten und an Schnittstellen und die Versionisierung gedacht wird.

Frameworks und Techniken von Google (Angular), Facebook (React) oder Dritten wie SCSS und LESS CSS Compiling sind ohne Frage beliebte Techniken. Es sind aber keine W3C Webstandards

UDS ist kein CMS im eigentlichen Sinne sondern zuerst einmal eine Norm für die Planung und Gestaltungskonzeption und Redaktion von Inhalten in Web und Print.

Mit der Programmierung einer Referenzimplementierung des Datenmodells wurde es möglich, Informationen strukturiert zu erfassen und in Ansichten rechnen zu lassen. UDS wurde darauf dimensioniert, 1 bis 5.000 Dokumente bei HTTP Request verarbeiten, auswerten und in Ansichten umrechnen zu lassen. Dass es mit Caching auch 50GB an Daten sein könnten zeigt das Prinzip von Open-Street-Maps. Wir gehen grob von 3 bis 50 Seiten je Webseite oder Rubrike einer Webseite aus.

/// SNEWMEDIA betrachtet Problemstellungen unserer Auftraggeber vorzugsweise ganzheitlich dahingehend, dass zwischen Expressive Sets und Productive Sets in Gestaltung und Kommunikation differenzieren: Productive Sets sind Medien oder auch Dokument Vorlagen und Verfahren, wo unsere Auftraggeber im Tagesgeschäft mit üblichen Mitteln von Word über Excel, Powerpoint, Video und was Sie sonst noch nutzen, handlungsfähig bleiben.

Der Expressive Mode mit Expressive Sets betrifft Medien und Präsentationen, die aufgrund höherer Anforderungen von uns oder von Ihnen beauftragten Dritten mit mehr Erfahrung und zudem anderer Software bearbeitet wird.