Home Java Creating a unified UI without moms, dads and credits

Creating a unified UI without moms, dads and credits

by admin

Hi all, my name is Artyom and I’m a developer in the Operations Support Tools team. Our team develops software for support interaction with users, in order to solve any problems users have.

Last time, one of my colleagues talked about how service interaction is implemented in our Platform. Those who missed that article can find it at link Today I want to tell you about an application that revealed the capabilities of the Contract API from a new perspective. Meet Contract UI.

What is Contract UI and what does it do?

Conversion of applications to strictly formalized contracts allowed us to automate the processes of creating documentation for APIs, and – made it easier to integrate the applications with each other. At the same time, contracts contain enough information: names, types and validations of the fields, when requesting and answering from a contract, reference to the contract documentation and so on. This led to the next logical step, which was to develop a service that would allow us to generate an administrative interface based on contract collections and embed the generated interface into any of the platform tools.

Love and Love : Contract UI (hereafter CUI) is a web application created as a magic universal wrench to bring the imperfect UI world of different applications to a possibly still not perfect, but unified UI world. To state the capabilities of the application more clearly, I wanted to get a tool that could do the following :

  • work with Contract API to retrieve data

  • automatically generate widgets based on contract structure

  • Allow developers to customize basic UI elements using JS

  • Work with user rights and configure visibility for different user groups

  • group widgets to connect in one package

  • Have a simple mechanism for integration with other applications

  • log user activity

A little bit about the architecture of the application itself. The CUI consists of two key parts: the admin area and the public area. The admin area is SPA where all the tools for creating, storing, editing, removing widgets and collections, accessibility settings, and a list of available permissions are collected. The public part is integrated into the application pages and is responsible for rendering the widgets on the pages. Let’s walk through each of them in more detail.

Armchair Dictators Corner

As mentioned above, CUI Admin is a page for working with widgets. Let’s take a closer look at the process of widget creation.

Basic tools to create widgets

Widget creation always starts with selecting a contract that will respond to requests from our widget and give up data. The contract structure itself stores enough information that we can use to create widgets. Let’s look at an example of one of the test contracts.

Creating a unified UI without moms, dads and credits
Figure 5. Example of a simple widget with accruals
Creating a unified UI without moms, dads and credits
Figure 6. Example of a widget with actionlogs

The CUI automatically creates widgets based on the analyzed contract data to make life easier for users.

Creating a unified UI without moms, dads and credits
Figure 12.2 Example of drawing widgets of different sizes at different levels

As you can see from the examples, DUI allowed us to solve issues with the size and location of the widgets on the page. All widgets are pulled by the API, so there is no more need to write extra code to display the widget on the page.

Among the extras we got when creating the DUI:

  • Ability to create private dashboards, which are not available to anyone except their creators;

  • The ability to create multiple dashboards for specific user needs;

  • Ability to set bookmarks on dashboards to find them faster in the list of other dashboards

Intermediate results and further development

After all of the above, I would like to note that the experiment was quite successful. The CUI is an MVP of a real application and needs further development. The idea itself was viable and in demand. Now CUI is in active use by several services, collecting feedback from end users who work directly with the UI without access to the widget code, as well as from the integration and development teams who create their own widgets.

Among the shortcomings of the current MVP are the following points :

  • automatic widget generation works with simple contracts, so developers have to spend time to add more complex structures, elements, etc;

  • the way the application works under the "one contract, one widget" rule, which prevents us from using several different contracts to generate Request and Response form filters dynamically.

The immediate goals we are already moving toward are improvements to the CUI Admin itself. We plan to :

  • diversify the number of items that can be added from the box;

  • Add the ability to validate fields with the UI;

  • Make the admin itself a more global node, from which widgets will be automatically delivered to all regions.

You may also like