UDS ist ein Uniform Design System. Ein System besteht nicht nur aus einer Software mit Programmcode sondern basiert auf einer Idee, einem Konzept, Zielen, Erwartungshaltungen, Menschen die es planen, entwickeln, erhalten und schlussendlich auch nutzen.

Overview Überblick

Für alle diejenigen, die UDS noch nicht kennen und nun denken, dass UDS mal wieder irgendein neues Redaktionssystem CMS ist: UDS ist ein Uniform Design System. Auf dieser Grundlage kann man u. a. auch ein CMS entwickeln. Man muss aber nicht.

UDS befindet sich stetig in Entwicklung. In manchen Phasen geht es schneller. In anderen Phasen geht es langsamer. Priorität bekommt schlussendlich das was entweder von irgendwem finanziert wird oder aber einen anderen Nutzen hat, der den einen oder die andere dazu bewegt, sich freiwillig zu engagieren.

UDS wurde als Uniform Design System geschaffen, um für Planungsprozesse für Web, Print und auch Apps gewisse Standards in der Planung zu haben, was bereits den Ablauf von Planungen und Entscheidungen betrifft. Wir sprechen von Leistungsphasen, Units und Devisions.

Dass man mit UDS nicht nur etwas planen sondern auch redaktionelle Inhalte von über 3.000 Seiten Content formulieren, mit Code- oder KI erzeugen und schlussendlich als Cluster von Websites mit diversen Domains nebst Mehrsprachigkeit rendern und betreiben kann, ist nur ein Nebeneffekt der Idee gewesen.

Wirklich bahnbrechende News, die jeden Bewohner dieses Planeten interessieren werden, wird es wohl zum Thema UDS auf UIO3 so schnell nicht geben.

Informationen aus dem Umfeld unserer Kollegen, Förderer, Partner oder auch Kunden unserer Partner veröffentlichen wir zuweilen aber durchaus, wenn wir einen Bezug zum Thema UDS sehen.

Wenn Menschen mit UDS ein System für Menschen, Code und KI planen und erhalten, gibt es immer irgendetwas, worüber man diskutieren könnte.

Nicht alles, was wir intern oder in Projekten auch mit Kunden und Nutzen abstimmen, erhält eine Freigabe für eine Veröffentlichung eines Artikels. In anonymisierter Fassung möchten wir aber über das eine oder andere doch in einem Artikel informieren.

Neue HTTP GET Parameter für Filter? Neue XSL Templates? Weitere Parameter für die Config von Content Elements? Immer, wenn sich etwas ändert, was für unsere Entwickler oder Redakteure von Bedeutung ist, entsteht ein Blog-Eintrag.

Nicht alles ist wirklich wichtig, aber mit diesem Blog behalten diejenigen, die ab und zu mal reinschauen, den Überblick, was sich tut.

HINWEIS: Unser Blog wird derzeit noch wie andere redaktionelle Inhalte als WebPage Element und damit quasi mit Einzelseiten gepflegt. Eigentlich wurden die Prototypen für BlogPosting Instanzen als neuem Typ redaktioneller Inhalte längst programmiert, aber das LinkedData Schema hat inzwischen zusätzlich zu WebPage, BlogPosting und WebPageElement inzwischen auch noch die Typen WebPageSeries sowie WebPageContent geschaffen.

Wir evaluieren dahingehend vor redaktionellen Umbaumaßnahmen unseres Blocks zuerst einmal die tatsächliche Bedeutung dieser neuen semantischen Datentypen, bevor wir dieses als Stereotypes in UDS übernehmen.

Über unsere internen Treffen informieren wir nur über interne Verteiler. Ausnahmen sind Workshops und Seminare. Über diese informieren wir in dieser Rubrik.

Das Designkonzept, wenn wir uns nun mal auf die visuelle Darstellung und damit die Ansicht von mit UDS formulieren und gerenderten Dokumenten beziehen, basiert teilweise auf unserem eigenen Design System für UI Komponenten, zum anderen Teil aber auf Bootstrap.

Vereinfacht formuliert basierend die meisten Layout-Komponenten derzeit noch auf Bootstrap. Dieses betrifft sowohl das Layout, die Funktionalität, Interaktion oder auch Teile der visuellen Gestaltung wenn es um Randabstände, Schatten, Linien geht.

Für die Formulierung und das Rendering redaktioneller Inhalte hingegen basieren inzwischen 50% oder mehr der Komponenten auf UDS, dh. wenn es um Text-Formatierung, Typographie oder auch die Bezeichnungen geht, werden UDS-Bezeichnungen und nicht mehr Bootstrap verwendet.

Etwa 95% aller Templates für UDS werden derzeit als XSL-Templates, einem W3C Standard wie HTML, CSS, XML oder auch SVG, programmiert.

Eine Migration von Templates von XSL zu JavaScript für serverseitiges Rendering und Processing ist in Planung. Nun wird allerdings XSL durch PHP, JAVA, C# und inzwischen über npm auch für NodeJS unterstützt, so dass wir in diesen Sprachen schlichtweg ein Objekt einer XSLProcessor-Klasse instanzieren müssen und die Templates damit funktionieren.

Ursprünglich haben wir den Begriff Theme ähnlich wie in WordPress verwendet, weil er in diesem Kontext bei den meisten Entwicklern, Partnern und Nutzern am ehesten verstanden wird.

Wir haben mit der Zeit aber erkannt, dass das Prinzip von WordPress-Themes eine konsequente Trennung zwischen Daten, Funktionalität und Design zuweilen vermissen lässt, weil viele WP Themes im Grunde genommen soviel Quellcode für Funktionalität mitbringen, dass ein Wechsel eines Themes in WordPress dazu führen kann, dass weite Teile einer Webseite oder Bestandteile hiervon nicht mehr funktionieren.

Der Begriff Theme bezieht sich im UDS Uniform Design System im Schwerpunkt auf die Darstellung von Layouts und Komponenten, die der Navigation dienen.

Als Skin bezeichnen wir im UDS die Anpassung von Farben oder auch der Typographie und andere Details, welche zwar die Nuancen verändern, nicht aber das grundlegende Layout-Prinzip und darüber hinaus auch nicht die Größenverhältnisse und Proportionen.

Bislang ist es so, dass ein Skin nur Werte für Parameter verändern kann, welche als Parameter bereits über ein Theme definiert wurden.

Wir sind mit dem Begriff „Skin“ nicht so wirklich glücklich, denn der Begriff ist durch Diskussionen zum Thema Rassismus faktisch verbrannt.

In Anlehnung an WebGL/3D-Grafik-Rendering und Grafik-Programmierung orientieren wir uns eher am den Prinzip von Shadern: Ein Shader ist letztendlich ein Programm dem man Punkte, Linien oder Flächen von Objekten mitteilt und welche dann basierend auf der Logik und den Skripts des Shaders diese Elemente farblich verändert oder um zusätzliche Elemente aus gestalterischen Gründen erweitern.

Einige Komponenten ermöglichen Variationen von Layout, Abfolge von Farben und dergleichen. Manches ist hierbei manuell redaktionell anzugeben, anderes erfolgt basierend auf Parametern automatisch Und wieder andere Varianten werden über PostProcessing über User-Templates gerechnet.

Ein typisches Beispiel hierfür ist die Veränderung des Hintergrundfarbe von Sektionen: Die Fläche ist zwar eigentlich auf einen bestimmten Grauwert gesetzt worden, aber über die Variation variiert dieser dann dennoch um ein paar Prozent.

Varianten und Variationen dienen dazu, dass in einer Sequenz aufeinander folgende Elemente nicht zwingend exakt gleich aussehen. Ein Baum hat zwar im Prinzip grüne Blätter, aber jeder weiß, dass wir als Betrachter einen künstlichen Baum daran erkennen, dass alle Blätter exakt die selbe Farbe haben.

Der Grad an Variation und auch die Anzahl von Varianten ist ein gestalterischer Aspekt, hat also mit redaktionellen Inhalten und eigentlich auch Entscheidungen eines Redakteurs im Detail wenig zu tun.

Wenn also bestimmte Abfolgen von Komponenten einem Pattern entsprechend immer leicht variiert werden, so wird das entweder automatisiert durch Skripte ermöglicht oder aber Redakteure werden zuvor darauf trainiert, das Designkonzept einzuhalten und durchzusetzen, wenn man im Design einmal die Entscheidung getroffen hat.

Der grundlegende Trend für UDS besteht darin, dass wir stetig Bootstrap Code aus dem Projekt entfernen.

Erste Versionen von UDS wurden im Grunde genommen, wenn auch mit anderen Bezeichnungen, zwischen 2001 und 2004 entwickelt und haben über die Jahre, als man einst noch 640x480px als Bildschirmauflösung hatte, zig Änderungen überlebt.

Uns sind kurzfristige Erfolge oder auch das schnelle Erreichen von fertigen Features nicht so wichtig. Wir suchen keine perfekte Lösung, weder für uns noch für unsere Partner, die mit UDS arbeiten. Maßgebend ist primär, dass das System funktioniert.

Das UDS Uniform Design System verbindet letztendlich semantisch kodierte Informationen und damit Daten mit deren Darstellung sowie aber über hinaus auch einer Funktionalität, die einen gewissen Nutzen mit sich bringt: information, visual, task.

Konnte man noch bis 2004 Layouts statisch planen, führten zuerst die immer größer werdenen Bildschirme mit immer besseren Auflösungen und schlussendlichd die Smartphones dazu, dass sich die Anforderungen und die Erwartungshaltung an die visuelle Darstellung verändert hatte. Dieses hatte immer auch Einfluss auf die technische Seite.

Unter dem Druck, dass als Webseite gerenderte Dokumente aber auch unter SEO-Aspekten in der jeweiligen zeitlichen Epoche in einem gewissen Umfang im Wettbewerb noch einen Nutzen haben oder auch tatsächlich zuweilen besser sind oder waren oder wie sein werden, greifen auch hier Aspekte bezogen auf Daten und Informationen auf der einen oder entsprechende technische Maßnahmen sowie aber auch redaktionelle Maßnahmen zusammen.

Im Schwerpunkt befassen wir uns in Bezug auf die technische Seite von UDS darauf, eine eine Trennung zwischen Daten, Darstellung und Processing zu ermöglichen. Ein besonderes Augenmerk legen wir darauf, dass sich die zu erwartenden Änderungen und technischen Risiken mit geringem Zeitaufwand beschränken lassen. Dieses führt durchaus dazu, dass wir viele Feature-Requests ablehnen, denn wenn wir nicht erkennen können, wer bei bestimmten Abhängigkeiten diesen Code in 3 Jahren noch wird pflegen können oder wollen, dann verzichten wir lieber auf ein Feature.

Wie auch sonst im Leben gibt es immer Ausnahmen: Alles, was der UDS Core nicht zu leisten vermag, dass lässt sich schlussendlich über PostProcessing mit User-Templates auf speziellen Wunsch dann doch in einem gewissen Umfang bewerkstelligen. Ein solches Feature ist damit aber kein Kernbestandteil von UDS.

Wir haben für UDS durchaus eine ganze Reihe an Guidelines. Viele dieser Guidelines beinhalten allerdings Skizzen und anderes mehr. Nun geht es allerdings faktisch immer auch um Geld, Knowhow und Wettbewerb.

Es versteht sich von selbst, dass wir durchaus transparent darüber informieren, was wir machen und was verfügbar ist.

Wenn es aber um Guidelines und damit die Beratung geht, wie Komponenten zu planen, zu entwickeln, zu erweitern, zu versionieren sind oder wie man grundsätzlich auch an Layouts oder über Web hinaus auch an Print, Video, Icons oder Piktogramme herangeht, sollten Sie eines wissen:

Den wirklichen Feinschliff bekommen mit UDS realisierte Medien in Web, Print etc. schlussendlich durch ein sogenanntes Customizing für den jeweiligen Auftraggeber.

Dieses bedeutet im Umkehrschluss, dass Guidelines, die sich auf gestalterische Fragestellungen, SEO oder aber auch Performance beziehen, letztendlich in Abstimmung mit Auftraggebern und/oder unseren Freelancern erörtert wird.

In dieser Rubrik befassen wir uns mit der technischen Seite der Programmierung von UDS Components und zugehörigen Standards.

Diese Rubrik ist derzeit nur für Mitglieder und Partner einsehbar. UDS basiert zwar auf Open-Source-Technologien. Die zugehörige Planung der Software für Server, Clients, Apps und dergleichen ist allerdings nicht Open-Source.

Themes und Skins: Die zugehörige Planung und Programmierung von Design-Templates sowie die Konfiguration von Skins basiert derzeit auf XSL, einem W3C Standard wie HTML, XML, CSS auch. Wir prüfen aber bereits Varianten, wie wir diese Templates von XSL- auf JS-Programmierung (JavaScript) umstellen können.

Hinweis für Kunden und Nutzer: Auch wir prüfen die Umstellung von UDS Servern und Clients auf Cloud Technologien.

Bei Templates handelt es sich um Programmcode und damit Logik, welche dazu dient, objektorientierte, zumeist in XML serialisierte vernetzte Datenstrukturen in Dokumenten auszuwerten und eine Ausgabe zu erzeugen, welche wiederum ein entsprechendes Dokument ist.

Der W3C Standard für das Rendering von XML-Daten zu HTML5 Ansichten für Web- und Print ist eigentlich einst ab ca. 2001 mal XSL gewesen bzw. die Technik wird noch immer hier und da eingesetzt eben weil es ein W3C Standard ist der für zig Programmiersprachen unterstützt wird.

Hinweis: Dieser Themenblock wird demnächst überarbeitet weil er sich mit Templates im Design-Bereich überschneidet. So basierend Templates nicht nur auf XSL sondern auch auf JavaScript, und zwar sowohl serverseitig als auch clientseitig.

Hinweis: Dieser Themenblock wird demnächst überarbeitet weil er sich z. T. mit Inhalten im Design-Bereich überschneidet.

Hinweis: Dieser Themenblock wird demnächst überarbeitet weil er sich z. T. mit Inhalten im Design-Bereich überschneidet.

In dieser Rubrik befassen wir uns mit Empfehlungen und Informationen über Kriterien für Planungsverfahren und Entscheidungsprozesse.

Document Driven Design, Read-Eval-Print-Loop REPL, Mobile First Strategy, Object Oriented Design, Semantics.

UDS Server sind in der Konzeption eigentlich Konsolenprogramme, welche Sie aber nicht nur über die Konsole unter Windows und Linux sondern auch in Bezug auf HTTPS Requests nach Dokumenten über einen Browser nutzen können.

UDS Dokumente können einzelne WebPage Instanzen, komplette WebSite(s), ganze Cluster von WebSites oder auch nur einzelne Textabschnitte speichern, die man als Content Referenz verlinken kann.

UDS basiert auf Files. Dieses dient der einfachen Übertragbarkeit. Das XML Format dient darüber hinaus dazu, Transparenz zu schaffen, was in diesen Files steht. Auch Menschen können und sollen hier in diese Files schauen können.

Der data-Folder beinhaltet das Datenmodell welches eine UDS Installation verwaltet. Es werden hierbei mitunter clientseitige öffentliche Daten verwaltet wie auch serverseitige Daten, welche für eine Ansicht im Web oder als Print/PDF-File zuerst über UDS gerendert werden müssen.

Die für die Redaktion am häufigsten genutzten Components sind Content Element Components, kurz CE für Content Elements. Components können aber auch andere Zwecke haben. So gibt es beispielsweise eine Component die schlichtweg dazu dient, alle Sprungmarken-Deklarationen auf einer WebPage zu finden, um auf deren Grundlage ein Menü zu erzeugen.

UDS Components UDS Components

Bei User Interaction CEs handelt es sich um Content Elements mit welchen der Anwender vereinfacht interaktiv irgendetwas tun kann. Vereinfacht ausgedrückt handelt es sich um diejenigen CEs wo der Nutzer nicht einfach nur Text liest und scrollt sondern etwas klicken oder auch bewirken kann.

UDS User Interaction CEs UDS User Interaction CEs

Bei Core Components handelt es sich um CEs welche für die Formulierung von Dokumenten mit Daten und deren Zusammenhängen zwingend erforderlich sind. Zu den Kernkomponenten zählen neben den eigentlichen WebPage CEs zuerst einmal die WebSite als Gruppierungselement zur Formulierung von WebSite-Clustern.

UDS Core Components UDS Core Components

Der Zugang für unsere Community wird nur intern kommuniziert.

Prototypen sind neue Komponenten in der Planung oder neue Versionen von bestehenden Components.

Die zugehörigen Inhalte müssen noch von der bisherigen Webseite umgezogen werden.

Pattern sind Entwurfsmuster. Und UI Pattern sind Entwurfsmuster für User Interfaces und den Aspekt des User Interaction Designs.

Für eine Kontaktaufnahme zum Thema von UDS nutzen Sie bitte derzeit die Formulare zum Kontakt von UIO3.

Haben Sie schon einen Kundenzugang?

Haben Sie schon einen Kundenzugang?

UDS Prototypes UDS Prototypes

Wir haben UDS aus Eigeninitiative geschaffen, und zwar schlichtweg deshalb, weil uns genau so ein System und Verfahren gefehlt hat.

Software wie auch Strategien entstehen nicht im luftleeren Raum: So etwas kostet Zeit, Nerven und mitunter auch Geld. Menschen sind, die so etwas erschaffen. Und es sind auch Menschen, die so etwas erhalten. Die KI ist zwar praktisch, aber ohne den Menschen macht die KI bislang (zum Glück) nichts.

Sie können für UDS Support bekommen, indem Sie sich an zugehörige Dienstleister wenden welche über zugehörige Lizenzen verfügen.

Für eine Kontaktaufnahme zum Thema UDS wenden Sie sich entweder an den Support / Service oder aber nehmen über das Kontaktformular von UIO3 Kontakt auf.