Skip to Content
Technical Articles

Our Journey Towards Better UI (Part 1)

 

Behind each successful product there is a dedicated team with strong technological skills which is able to design and develop such application. However, more importantly there is a team which can provide enough tools and reusable UI elements to make development more efficient and robust. 

The development of an application infrastructure has been part of SAP Ariba’s thinking process for years and is the focus of this document.

But let me give some background first.

 


 

SAP Ariba is known as strong technological company where we also have developed many proprietary technologies. One of the proprietary technology is called AWL (Ariba Web Language).

AribaWeb is a component-based web application development framework for creating rich, AJAX-enabled applications with the minimal code. This enables our application developers to deliver enterprise products with incredible productivity. Since 2008, when the shape of AribaWeb significantly changed, we have established core principles regarding how web applications should be built.

Let me briefly cover what the principles are and how we take the principles into account when thinking about designing a UI Library in order to provide Swiss Army knife – like functionality for application developers.

 

Hide internal complexity 

 

Productivity is the main focus. Application developers should not worry about implementation details or how components need to be structured to make things work. Let me give you example.

Do you want to use these 4 different elements to create your visual HTML control (Date control from google Material Library) ?

<input matInput [matDatepicker]="picker">
<mat-datepicker-toggle matSuffix [for]="picker">
<mat-icon matDatepickerToggleIcon>
   keyboard_arrow_down
</mat-icon>
</mat-datepicker-toggle>
<mat-datepicker #picker>
</mat-datepicker>
Or use this one line instead?
 
<fd-date [value]=“myDate” (onChange)=“WhenDateChanges($sendEvent)”>
</fd-date>

 

Library owner vs application developers

 

Don’t make your library too generic. One size does not always fit all. You need to know your consumers. Do you target library developers or application developers? There are different specifics for each of them.

Just like in the example above. There is nothing wrong with the google code. The composition that it offers is pretty smooth. However, if this has been used every-time you create a page then we are introducing more complexity than we need to. Usually, the application developer ends up building custom wrapper component for things like this. Again, know your consumers!

 

Simplicity over flexibility

 

The more flexibility you give application developer the more time it takes to deliver something.  It increases cost and it  requires more skill to understand the code. Plus, the chance that something breaks is higher.

Building an application is pretty amazing and challenging at the same time, so let’s not put additional load on our application developers.

Don’t take me wrong you do need to provide some level of freedom. But more controlled.

 

Provide more guidance

 

To deliver your enhancements faster and to keep your application up to date you need to have things under control. You need to provide more guidance along with examples to show how it is used, what you allow to tweak.

If there is some missing feature that needs to be build, consider if this cannot be added to your library and used by others. Instead of allowing little copies here and there.

Modern tools like Angular provides certain capabilities which can leverage Typescript compiler API in order to access Abstract Syntax Tree (AST). Understanding internal structure help us understand implemented code to do for instance:  automating upgrades, rolling out new features, analyze code for potential problems, if our best practices are implemented expected way and much more..

 


 

Many more great things happened over the years, but we had to admit trying to maintain a 15 years old framework at that time is hard. You cannot really beat modern framework and keep things up to date. In 2014 we finally decided it was time to move on. The choice was Angular! (after intensive evaluation of other frameworks).

But let’s move to 2020 now where we started our current journey. We established a dedicated team, connected with other SAP organizations and started to work towards common initiative to bring next generation UI Framework based on Fiori 3 called Fundamental Library for Angular powered by  Fundamental Library Styles to life.

And here we are. 

As you will see in the next articles this UI framework is not just about a few components anymore. I will introduce you to each of the layer, you will understand how we work and much more.

To be continued….

 

Want to read more blog posts about Fundamental Library? Check these out. In case you want to be informed, feel free to follow us in twitter, linkedin and youtube.

/
1 Comment
You must be Logged on to comment or reply to a post.