Designsysteme für die Anwendungsentwicklung – Definitionen und Vorteile

Designsysteme für die Anwendungsentwicklung
© everythingpossible - stock.adobe.com
Bewerten
6 Bewertungen,
Durchschnitt 4,7

Designsysteme der großen Softwarehersteller unterstützen UX-Designer und Anwendungsentwickler bei ihrer Arbeit. Doch die Systeme von SAP, Microsoft und Salesforce unterscheiden sich stark. Was können die Systeme und welche Vorteile haben sie?

Verständliche, aufgeräumte Benutzeroberflächen mit ansprechendem Design sind heute mindestens genauso wichtig für den Erfolg einer Software am Markt wie die eigentlichen Funktionalitäten. Das gilt auch für riesige Unternehmensanwendungen wie ERP, CRM oder Lagerverwaltungssysteme und deren zahlreiche Erweiterungen und Add-Ons. Hier ist es sogar viel schwieriger, eine gute Benutzeroberfläche zu entwerfen, da man oft mit sehr komplexen Daten arbeitet und die User Interfaces (UIs) sehr schnell überladen und komplex wirken.

Für einen User Experience-Designer (UX-Designer) lohnt es sich also stets, Ausschau nach Trends zu halten – und diese finden sich vor allem in den Styleguides der großen Software-Anbieter, die mittlerweile als sogenannte Design-Systeme publiziert wurden. In diesem Beitrag erfahren Sie, was SAP Fiori, Microsoft Fluent Design, SalseForce Lightning Design System sind und was man davon lernen kann.

Was ist ein Designsystem?

Ein Designsystem besteht aus einem Styleguide (Designrichtlinien) und einer Sammlung von Komponenten, die als Bausteine für die Benutzeroberflächengestaltung bereitgestellt werden. Ein gut strukturiertes Designsystem ermöglicht es verschiedenen und voneinander unabhängigen Entwicklungsteams, Anwendungen und Dienste mit einem einheitlichen Look & Feel und einer einheitlichen User-Experience zu entwickeln. Dies ist besonders wichtig für Unternehmenssoftware, deren Web-UI meist aus zahlreichen Apps, Modulen oder Services besteht. Dank eines guten Designsystems fühlen sich Benutzer in jedem Teil des Systems zu Hause, unabhängig davon, wer das System entwickelt hat.

Ein Designsystem ist besonders wichtig, wenn eine große Anzahl von komplexen Business-Objekten verwaltet werden muss. In diesem Fall ist es gewöhnlich eine große Herausforderung, eine verständliche und effiziente Benutzeroberfläche zu entwickeln. Designsysteme standardisieren Werkzeuge und Ansätze und bieten Entwicklern und Anwendern praxiserprobte Instrumente für typische Aufgaben wie Suchen, Anzeigen, Bearbeiten und Ausführen von Aktionen an komplexen Objekten wie beispielsweise Aufträgen, Kunden oder Kampagnen.

Styleguides von großen Unternehmen sind nicht nur für die Entwicklung von Software für deren Systeme wichtig, sondern können jedem UX-Designer als wichtige Inspirationsquelle dienen. Daher lohnt sich ein Blick allemal – unabhängig davon, ob Sie ein konkretes Projekt umsetzen möchten oder nicht.

SAP Fiori und OpenUI5 – Oberflächen gestalten mit SAP

Bereits 2013 war SAP das erste Unternehmen der Software-Giganten, das seine Design-Richtlinien für Web-Applikationen veröffentlichte. Die neue Web-Oberfläche erhielt den Namen „SAP Fiori“ und das entsprechende JavaScript-Framework wurde SAPUI5 genannt. Schon bald wurde eine OpenSource-Version namens OpenUI5 bereitgestellt.

Seitdem werden das Framework und der Design Guide aktiv weiterentwickelt, wodurch die aktuellen Fiori Design Guidelines 3.0 wirklich lesenswert sind! Der Fokus liegt dabei ausschließlich auf Business-Apps. Neben Controls werden ganze Seitenlayouts (Floorplans) für typische Oberflächenelemente bereitgestellt, wie Tabellen mit Filtern, Editoren, Master-Detail-Dialoge, Drill-Down-Berichte, etc. Auch für Dashboards, Diagramme, Indikatoren und andere analytische Elemente gibt es Richtlinien.

Eines der Highlights ist sicherlich die Object Page mit ihrem schwebenden Header und dem gut gestalteten Responsive-Verhalten (Anpassung an verschiedene Bildschirm-Größen). Darüber hinaus gibt es aber natürlich noch viele andere inspirierende Ideen, wie die Filterleiste für Tabellen und Listen, die eine komprimierte, aber interaktive Zusammenfassung des aktuellen Suchkontextes zeigt. Ein weiteres Beispiel ist das Wizard-Control – einer der besten Responsive-Stepper, den ich bisher gesehen habe.

SAP UI5 List Page und Object Page
SAP UI5 List Page und Object Page

Die Fiori-Richtlinien legen großen Wert auf Responsive Design. Sie enthalten detaillierte Anleitungen, wie sich Layouts und UI-Elemente auf verschiedenen Bildschirmgrößen verhalten sollten. Der gesamte Styleguide folgt dem Mobile-First-Prinzip, das einfache Apps mit fokussierten Ansichten fördert, die nicht mit Daten und Bedienelementen überladen sind. Dies führt zu großartigen mobilen Benutzeroberflächen, macht aber das Gestalten großer Desktop-Anwendungen, die viele Daten in einer einzigen Ansicht benötigen, manchmal komplizierter (breite Tabellen, Dashboards usw.).

Die Grundidee von Fiori ist, dass eine große Software – wie ein ERP – in zahlreiche (möglicherweise hunderte!) kleine Fiori-Applikationen aufgeteilt werden, die auf bestimmte Geschäftsprozesse und Benutzerrollen zugeschnitten sind. Diese Apps werden alle von einem zentralen "Launchpad" gesteuert – einer personalisierbarer Einstiegs-Anwendung, die sich um Navigation, Zugriffsberechtigungen, Benutzeranpassungen usw. kümmert.

SAP UI5 Responsive Wizard und ein SAP UI5 Dashboard
SAP UI5 Responsive Wizard und ein SAP UI5 Dashboard

Das UI-Framework für den Aufbau von Fiori-Webanwendungen heißt OpenUI5 (oder SAPUI5 im Falle seiner kommerziellen Version, die in SAP NetWeaver integriert ist). Obwohl OpenUI5 Open Source und somit theoretisch für jedes Projekt verwendbar ist, ist es dennoch sehr SAP-spezifisch. Viele der besonders schicken Features erfordern Daten im eher seltenen OData-Format – meist sogar angereichert mit SAP-Erweiterungen. Wenn Daten nicht aus SAP stammen, ist viel manuelles Coding erforderlich. Während UI5 für SAP-bezogene Projekte nahezu die einzige Wahl ist, ist es für Non-SAP-Anwendungen dadurch unnötig kompliziert.

Technisch gesehen ist OpenUI5 ein Full-Stack Web App Framework, das auf jQuery basiert. Es folgt streng der Model-View-Controller (MVC)-Architektur. UI5 ist für den Aufbau von Single-Page-Anwendungen (SPA) ausgelegt, die idealerweise nicht mehr als 10-15 Masken beinhalten. Das Framework enthält alles, was benötigt wird: Widgets, Daten-Binding, Routing, Caching und sogar das Adapter für verschiedene Test-Frameworks. Trotzdem ist es deutlich anders als die meisten typischen Web-Frameworks: Views werden in XML geschrieben oder (seltener) JavaScript. HTML wird zwar unterstützt, allerdings mit vielen Einschränkungen. Die Erweiterbarkeit ist ungewöhnlich stark eingeschränkt, da es recht wenige und dazu auch nur ziemlich komplizierte Möglichkeiten gibt, Bibliotheken von Drittanbietern zu verwenden. Selbst jQuery-Plugins können nur mit speziellen Wrapper verwendet werden.

Im Endeffekt ist UI5 eine Welt für sich. Entscheidet man sich für dieses Framework, müssen die Regeln strikt eingehalten werden. Und um gute Ergebnisse erzielen zu können, bedarf es einer intensiven Einarbeitung. Auf der anderen Seite bietet das Framework alles, was für die Entwicklung einer "Alles aus einer Hand"-Business-App benötigt wird. Die resultierenden Apps sehen letztlich nicht nur gut aus, sondern lassen sich wirklich auch auf verschiedensten Geräten und Bildschirm-Größen sehr komfortabel bedienen!

Vorteile von SAP Fiori und UI5

  • Großartiger Styleguide für Business Web Apps
  • Herausragendes Responsive-Verhalten
  • Full-Stack-Framework mit allem, was zum Aufbau von SPAs benötigt wird

Nachteile von SAP Fiori und UI5

  • Hohe Komplexität von UI5 (insbesondere für Non-SAP-Anwendungsfälle)
  • Schlechte Kompatibilität zu Bibliotheken von Drittanbietern (z.B. jQuery-Plugins)
  • Keine Charts in OpenUI5, nur in SAPUI5

Die Microsoft Design Language und Office Fabric Framework

Microsoft hat das visuelle Erscheinungsbild seiner Produkte in den letzten Jahren mehrfach verändert. Die Microsoft Design Language (MDL) entwickelte sich langsam von der flachen und farbenfrohen Metro UI (MDL 1.0) zum neuesten Fluent Design (MDL 2.0), basierend auf den Schlüsselkonzepten Licht, Tiefe, Bewegung, Material und Skalierung. Die Microsoft Design Language konzentriert sich hauptsächlich auf native Windows-Anwendungen. Mit der jüngsten Umstellung auf Cloud-basierte Dienste (z.B. Office 365) wurde es jedoch häufig auch für Webanwendungen eingesetzt.

Das aktuelle Fluent Design System zielt auf sogenannte UWP-Apps (Unified Windows Plattform). Sie sollen eine einheitliche Nutzererfahrung auf allen Plattformen bieten: Desktop, Mobile, Web, VR, etc. Das Designsystem definiert sowohl ein generisches Set von Bedienelementen wie Formularelemente, Tabs, Listen, als auch die Grundkonzepte von Navigation, Darstellung, Responsive Design usw. Im Fluent Design System selber wird all das sehr allgemein beschreiben, ohne konkretes Styling wie Farbgebung, Formen, Größen, etc. Die enthaltenen Bildschirmlayouts und Beispiele sind schematisch und damit wesentlich abstrakter als die des Google Material Designs oder SAP Fiori.

Für das konkrete Aussehen sind dann die einzelnen Ausprägungen von UI Fabric zuständig, also beispielsweise für Web, iOS oder Android. An diesen wird offensichtlich noch fleißig gearbeitet: So wurde die Anzahl verfügbarer Controls für Fabric Web allein in 2019 gefühlt verdoppelt. Mittlerweile gibt es gute Beschreibungen mit Beispielen, Do’s and Dont‘s für die wichtigsten Controls. Leider fehlen aber immer noch viele komplexere Elemente, die gerade für Business-Apps wichtig sind wie Charts, Wizards und Dashboards.

Technisch gesehen besteht das UI Fabric Web aus einem Open-Source-JavaScript-Framework auf Basis von React (Fabric React) und einer Sammlung von CSS-Styles (Fabric Core), die unabhängig vom Framework eingesetzt werden können. In der Vergangenheit gab es hier allerdings viel Bewegung, sodass es bis vor kurzem mehrere parallele Versionen zu geben schien: eine mit Vanilla JS (scheint jetzt aufgegeben zu sein), die aktuelle offizielle Version mit React und eine Community-Version für Angular. Die Dokumentation ist im Vergleich zu anderen Frameworks nicht besonders umfangreich. Es gibt nicht einmal eine mehr oder weniger realistische Demo-App.

Microsoft Dynamics CRM Object Page und Dashboard
Microsoft Dynamics CRM Object Page und Dashboard

Unabhängig vom Fluent Design hat Microsoft in den letzten Jahren vieles dafür gemacht, dass alle seine Business-Anwendungen und Cloud-Services wie Sharepoint, CRM und andere Dynamics-Produkte ein einheitliches User Interface bekommen. Diese neue Benutzeroberfläche bewegt sich visuell zwischen Metro und Fluent Design und hat durchaus einen hohen Wiedererkennungswert, obwohl sie keinen eigenen Markennamen erhalten hat. Während die offizielle MDL nicht viel über Business UIs aussagt, gibt es einen sehr interessanten UX-Leitfaden für Microsoft Dynamics CRM. Er enthält nützliche Tipps für geschäftsprozessorientiertes UI-Design sowie einige schöne Ideen für wiederverwendbare Elemente wie Quick-View und Quick-Create Formulare. Obwohl die beschriebenen Prinzipien aus dem Jahr 2015 stammen, sind sie immer noch vollumfänglich gültig. Ein richtiges Framework zu diesen Guidelines gibt es aber nicht.

Ein Beispiel für ein Fluent Design Layout und für eine Office UI Fabric App.
Ein Beispiel für ein Fluent Design Layout und für eine Office UI Fabric App

Unter dem Strich ist also klar, dass Microsoft auf dem Weg zu einem vollwertigen Design System ist, welches allem Anschein nach schon bald auch auf die Business-UIs ausgeweitet wird. Das Fluent Design sieht schick aus und hat mit UI Fabric Web nun auch eine Implementierung für Web Apps bekommen. Diese ist aber noch ziemlich neu und hat eine turbulente Vergangenheit. Momentan spricht das in meinen Augen ausschließlich für Einsätze im Microsoft-Umfeld. Für Stand-Alone-Apps ist das Framework noch nicht ausgereift. Wenn das Ziel also lediglich ein Microsoft-Kompatibles Look & Feel ist, sollte man sich Metro- und Fluent-Themes für etabliertere JS-Frameworks wie Bootstrap oder Oracle JET anschauen.

Vorteile von Microsoft Design Language

  • UIs in Microsoft Office Style, die den meisten Benutzern vertraut sein dürften
  • Interessanter (aber veralteter) UX-Leitfaden für Microsoft Dynamics CRM

Nachteile von Microsoft Design Language

  • Kein klarer Styleguide für Business-Applikationen (keine Dashboards, Charts, etc.)
  • Kleine UI-Bibliothek (gerade im Vergleich mit UI5 oder SalesForce Lightning)
  • UI Fabric ist noch sehr jung

Das Salesforce Lightning Design System

Der Salesforce UI Styleguide wird als Lighting Design System (kurz SLDS) bezeichnet. Genau wie die Fiori-Richtlinien hat es einen starken Fokus auf Business-Apps, konzentriert sich dabei aber deutlich weniger auf mobile Benutzeroberflächen. Obwohl es Hinweise zum Response-Verhalten gibt, ist es definitiv Desktop-first.

SLDL Datentabelle mit Filtern und eine SLDS Object Page.
SLDL Datentabelle mit Filtern und eine SLDS Object Page

SLDS beinhaltet eine große Vielfalt an verschiedenen Komponenten und liefert dazu Designrichtlinien, die vorgeben, wie die Komponenten zusammengesetzt werden können. Diese Richtlinien enthalten ebenfalls verschiedene Seitenlayouts: Master-Detail-Listen, Objektseiten (hier Record-Laouts genannt) und weitere. Während viele Ideen den Fiori-Grundrissen ähneln, sind SLDS-Layouts zahlreicher, dafür jedoch schematischer und weniger detailliert. Leider gibt es keine Demo-Apps, die man ausprobieren kann, ohne sich gleich eine komplette Entwicklungsumgebung aufbauen zu müssen.

Auch das SLDS wird aktiv weiterentwickelt. So sind in diesem Jahr beispielsweise Guidelines für Charts dazugekommen. Dashboards fehlen aber noch.

Das Lightning Design System legt großen Wert auf Workflows und Zusammenarbeit. Neben speziellen Layouts für Feeds und Diskussionen gibt es ein ganzes Kapitel über sogenannte Builder. Builder sind Subanwendungen zur visuellen Entwicklung von Workflows, Prozessen, Formularen und anderen anpassbaren Anwendungselementen. Wenn Sie also planen, einen visuellen Worklow-Designer zu erstellen, lohnt sich ein Blick in diesen Leitfaden.

SLDS Workflow Builder und SLDS Builder mit Überblicks-Panel
SLDS Workflow Builder und SLDS Builder mit Überblicks-Panel

Technisch gesehen, ist SLDS eng mit dem CSS-Framework gekoppelt, mit dem es implementiert wurde. Das Styleguide ist im Wesentlichen gleichzeitig die Dokumentation für das CSS-Framework. Für diejenigen Komponenten, die nicht mit reinem CSS implementiert werden können (Combos, Tabs, Datentabellen usw.), bietet Salesforce ein Open-Source-JavaScript-Framework auf Basis von React. Dieses "Design System React" ist eine typische Komponentenbibliothek mit einer großen Sammlung von lose miteinander gekoppelten Controls. Da das Lightning Design System im Allgemeinen optisch Bootstrap ähnelt, sollten UI-Bibliotheken von Drittanbietern mit Bootstrap-Themen einfach zu integrieren sein. Auf der anderen Seite lassen sich die Designrichtlinien leicht auf jedes Bootstrap-basierte UI-Framework übertragen, wenn SLDS nicht direkt verwendet werden kann oder soll. So wären zum Beispiel die exzellenten Guidelines für das Zusammenstellen von logischen Ausdrücken für Filter und allerlei Bedingungen für viele Business-Apps eine Bereicherung.

Vorteile des Salesforce Lightning Design Systems

  • Eine der umfangreichsten Sammlungen von UI-Komponenten für Business-Apps
  • Richtlinien sind einfach auf jede Bootstrap-basierte Benutzeroberfläche anzuwenden
  • Destkop-first Herangehensweise gut geeignet für typische Backend-Lösungen

Nachteile des Salesforce Lightning Design Systems

  • Wenige mobile oder responsive Komponenten
  • Die Bildschirmlayouts sind schematisch und es gibt keine realistischen Beispiele
  • Wenig Informationen über reale Einsätze vom JS-Framework für React

Fazit: Drei Systeme mit unterschiedlichen Herangehensweisen

Wie Sie sehen, sind die drei hier vorgestellten UX-Designsysteme sehr unterschiedlich.

SAP baut eine eigene Welt mit tollen Ideen, einem der besten UX-Styleguides, aber recht speziellen All-in-One-Frameworks SAPUI5 und OpenUI5. In der Welt der SAP-Produkte ist SAP Fiori alternativlos. Für Stand-Alone-Apps muss allerdings mit erheblichem Mehraufwand bei der Backend-Anbindung gerechnet werden, wenn letzteres keine OData-Schnittstellen hat. Dennoch ist der Einsatz von UI5 durchaus möglich und führt sicherlich zu sehr schicken responsiven Single-Page-Apps.

Microsoft scheint immer noch auf dem Weg zu einem echten Designsystem zu sein: Das Fluent Design ist ziemlich beeindruckend, aber aktuell noch nicht ausreichend für die Gestaltung von Business-UIs. Hier fehlen noch viele Komponenten (Dashboards, Charts, komplexe Filter). Die bisherigen Entwicklungswerkzeuge und Richtlinien für Office- und Dynamics-Produkte hatten dagegen keine einheitliche Struktur und kein einheitliches Look & Feel. Nach heutigem Stand bietet Microsoft für Business-Apps also weder viel Inspiration, noch wirklich brauchbare Tools.

Das Salesforce Lightning Design System dürfte einem typischen Web-Entwickler vertrauter vorkommen mit seiner Sammlung von lose gekoppelten Komponenten. Ähnlich wie bei Fiori, ist das Framework innerhalb der SalesForce-Welt gesetzt. Über Web-Apps außerhalb von SalesForce, die damit gebaut wurden, ist nichts bekannt. Theoretisch ist das möglich. Durch visuelle Ähnlichkeit mit Bootstrap, bietet sich hier aber eher die Übertragung der Ideen aus dem SLDS-Guide auf Bootstrap-basierte Frameworks an.

Individuelle SAP Fiori Apps mit SALT Power UI

Mit unserer Plattform SALT Power UI sind wir in der Lage, exakt auf Ihren Bedarf zugeschnittene Business-Apps mit individuellen Oberflächen schnell und einfach über eine grafische Benutzeroberfläche zu konfigurieren. Sie können Ihren Mitarbeitern individuelle Apps für ihre spezifischen Anwendungsfälle und Rollen zur Verfügung stellen und gewinnen dadurch eine bisher ungekannte Flexibilität. Erfahren Sie mehr darüber!

Keine Updates
mehr verpassen:
1
© everythingpossible - stock.adobe.com

Zurück