Auf die Developer Experience kommt es an

Einen Schritt in Richtung etablierter, SAP-externer Standard wurde mit der kürzlich eingezogenen Typescript-Unterstützung getan. Nebst den immanenten Vorteilen der Javascript-Erweiterung an sich hat sie vor allem eine Verbesserung der Developer Experience für UI5 zur Folge: Autovervollständigung während des Codings wird durch die TS-Unterstützung des jeweiligen Editors gegeben, Geschäftslogiken ("Controller") sehen als Klassenerweiterung semantisch passender aus als reine AMD-artige Javascript-Definitionen.

• 

Typescript Controller in UI5 (Screenshot: Volker Buzek)

Mit den als Standard-Programmiermodell gesetzten UI5 Web Components für die UI-Schicht ist ein weiterer Schritt näher an einen etablierten Standard erfolgt. Waren vorher sogenannte Controls die gesetzten UI-Elemente, von UI5 direkt im Rendering erzeugt, bieten Web Components einen leichtgewichtigeren Ansatz, der sich in geringerer Dateigröße und besserer Performance niederschlägt.

• 

Quellcode einer UI5 Webcomponent (Screenshot: Volker Buzek)

Vorgefertigte Themes nutzen

Sowohl Web Components als auch Controls folgen standardmäßig den Fiori-Gestaltungsrichtlinen. Dadurch hat man bei der Nutzung des UI5-Frameworks gleichzeitig CSS-formatierte UI-Elemente und grafische Entwurfsmuster zur Verfügung. Sie sind einheitlich in sogenannten Themeszusammengefasst, mit SAP Horizon als aktuellster Inkarnation.

• 

"Horizon"-Theme (Screenshot: Volker Buzek)

Die Anpassung der Optik kann über den Theme Designer erfolgen, einem SaaS-Angebot von SAP auf der hauseigenen Cloud-Plattform Business Technology Platform, oder per CSS. Für den Theme Designer spricht, dass damit nicht nur Themes für UI5 erstellt und bearbeitet werden, sondern diese auch in anderen UI Komponenten von SAP wie beispielsweise Screen Personas zum Einsatz kommen können.

Die Anpassung der Themes per Hand in Stylesheets folgt der Standard-CSS-Entwicklung, etwas komfortabler auch dank der Unterstützung von CSS-Variablen und LESS in UI5. Trotzdem zeigt sich hier ein Nachteil der engen Verzahnung zwischen Optik und Framework: Die Themes an sich sind aufgrund ihres Anspruchs auf Homogenität über alle UI-Elemente hinweg bereits komplex.

Größere Anpassungen bedingen schnell einen hohen Aufwand - und müssten sich streng genommen selbst an die Fiori Design Guidelines halten, um nicht mit den in den Themes enthaltenen UX-Mustern zu brechen. Jedoch werden gerade in solchen Freestyle-UI5-Projekten Regelbrüche bewusst herbeigeführt, um spezielle Design- und/oder Usability-Ziele zu erreichen.

Outside the Box

Für die meisten Anwender wird eine UI5-Anwendung, die in Fiori-Optik erscheint, sofort einer SAP-Anwendung gleichgesetzt - obwohl aus technologischer und Usability-Sicht nichts gegen UI5 und Fiori "da draußen" spricht. Templates und Framework gibt es schlüsselfertig aus der Cloud über das Content Delivery Network zu beziehen, die UI-Elemente müssen nur noch zu einer Oberfläche kombiniert werden.

Innerhalb des SAP-Kosmos führt sowieso kein Weg mehr an UI5 und Fiori vorbei. Beides ist im kompletten Softwareportfolio des Konzerns strategisch gesetzt zur Erstellung von (Web-) Oberflächen. Im Vorzeigeprodukt S/4HANA sollen wo immer möglich SAP-GUIs durch Fiori-/UI5-Oberflächen ersetzt werden. Wer im SAP-Umfeld Software entwickelt, ist daher gut beraten, schnellstmöglich auf Fiori/UI5 umzusteigen.

Quellcode für alle Beispiele dieses Artikels gibt es bei Github.