This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
10 Golden Rules for Fiori Development from Teched 2015 by Robert Eijpe
n SAP Fiori apps follow the SAP Design Guidelines (GR-‐01) n SAP Fiori Apps always exists of a UI part and OData part which must be defined in different sonware
components (GR-‐02) n SAP Fiori UIs are built on top of SAPUI5 framework with a restricted set of the UI5 Controls and wrioen
in AMD syntax (GR-‐03) n It is recommended to built SAP Fiori app with SAP Web IDE, based on the new Fiori templates (GR-‐04) n Every SAP Fiori app must built as a component and defined by a set of metadata, so it can run in a
container as a standalone web app, in the Fiori Launch Pad and as a naMve mobile App (GR-‐05) n SAP Fiori UI Views are always build as XML views and Extension points need to be implemented (GR-‐06) n Always use intent-‐based navigaMon to navigate within a app and between apps (GR-‐07) n Use only the newest UI5 OData Model (v2) to access one OData Service node of the backend (GR-‐08) n Bounded UI5 control must be typed and for OData Models bounded with OData annotaMons (GR-‐09) n Use predefined UI5 style elements and change the look & feel with Theme Designer (GR-‐10)
10 Golden Rules for Design and Build Fiori Apps by Robert Eijpe
• Adopt Design Thinking Process and Prototyping to validate your Design (GDR-‐01) • Design for User Experience not UI (GDR-‐02) • Develop your own Guidelines (GDR-‐03) • Choose the right starMng point for app design (GDR-‐04) • ApplicaMons must support mulM backends (GDR-‐05) • ApplicaMons must be designed with localizaMon in mind (GDR-‐06) • Think about impact of performance and security (GDR-‐07) • Design with reusability and flexibility in mind and think about spliqng up UI’s (GDR-‐08) • Design apps based on a generic virtual data model (GDR-‐09) • Think about capabiliMes of iot, mobility, big data and cloud (GDR-‐10)
+ my 10 Golden Rules for Fiori Development from Teched 2015
Use Fiori Guidelines as an starMng point Develop your own Guidelines
Public SAP Fiori Guidelines are leading • But focus on Fiori 2.0 concepts • Look at other design guidelines like Apple Guidelines for iOS and Google Materials
AddiMonal Developer Guidelines needed • Not only Fiori, but also for UI5, ABAP and Odata development
Introducing naming convenMon • Develop in your own namespace • SAP will generate code, which restrict the length of unique naming
Do not focus on Theming, but adopt exisMng Themes • Customers can build own SAP Themes, which we will adopt for our soluMon, so customers don’t
Design can be simplified by FLP Embedded FuncMonality Choose the right starMng point for app design
No design needed for Home buoon Logo Header Text User seqngs Access to app seqngs About dialog for App Change theme of app No design needed for Contact Support Email integraMon Tel/SMS
AddiMonal design needed for Back buoon App seqngs dialog (opMonal) Dynamic Mle content (opMonal) Trigger to collaboraMon (opMonal) Trigger to communicaMon (opMonal)
MulM Origin Concept on Development ApplicaMons must support mulM backends
Developed Fiori Apps for mulM origin in mind � Collect data out of all systems, out of user default systems or out of a specific system � Metadata version must be the same in all systems
Works fine when system field is part of the result or selecMon for system is made
No go when system field is not part of the result • Duplicates will occur for Dropdowns, Value Helps, Facet Filters • Count, Paging and sorMng in combinaMon with filtering is not working properly
MulM-‐origin is not suitable for large aggregaMon data • AggregaMon is possible for small datasets without server-‐side paging
• Fiori App must use Client Side Odata model for the aggregaMon, count, sorMng, filtering and paging
MulM languages ApplicaMons must be designed with localizaMon in mind
Languages of texts are maintained on different places: • ApplicaMon texts in i18n files • Mimes (sound, video and documents) in mime repositories or content management systems • Field labels generated out of medium texts of DDIC data elements • ApplicaMon texts in standard SO10 Text • SAP backend message text in T100 message table Approach Maintain text in a way customers already do Use an ABAP reports to generate i18n files and use annotaMons in OData services Keep in mind to reload metadata and clear caches
Security and Performance Think about impact of security and performance
Use AuthorizaMons in the backend where possible
Reuse or validate informaMon that is already known
Fiori does not support exclusive locking due synchronically behavior • Inform user when acMon can not be processed because of locking failure • Use dran-‐concept when available
Reasons to split an applicaMon Think about splinng up applicaMons
Simplify an ApplicaMon � “Original” ApplicaMon supports more roles
– Find the balance between every user has its own app and one app will be used by mulMple roles
� ApplicaMons can have more entry points – Tiles start different views of an applicaMon – Overview Page Cards can starts an applicaMons – ApplicaMon can start an applicaMon
Improve the user experience � Combine different devices and act as one applicaMon
Our Take Away Keypoints: 10 Golden Rules for Fiori Design
• Adopt Design Thinking Process and Prototyping to validate your Design (GDR-‐01) • Design for User Experience not UI (GDR-‐02) • Develop your own Guidelines (GDR-‐03) • Choose the right starMng point for app design (GDR-‐04) • ApplicaMons must support mulM backends (GDR-‐05) • ApplicaMons must be designed with localizaMon in mind (GDR-‐06) • Think about impact of performance and security (GDR-‐07) • Design with reusability and flexibility in mind and think about spliqng up UI’s (GDR-‐08) • Design apps based on a generic virtual data model (GDR-‐09) • Think about capabiliMes of iot, mobility, big data and cloud (GDR-‐10)