In a context of incoming 4th version of Green Screens Service we want to share our thoughts about challenges creating automated modernization engine, limitations and future development direction.
As you probably know, there are 2 types of terminals. Line based and matrix (grid) based as 5250 terminals which has 2 resolutions of 24x80 and 27x132 cells.
To convert such screens into web UI few approaches are available with its own pros and cons...
Classic solutions
Having for an example 24x80 resolution it is actually easy to map screen blocks (text and field segments on terminal screen) row/col positions to the web x/y pixel position calculating zoom size based on screen resolution and font used. Many such solutions use a term "modernized screens" and as a result you will get exactly the same look as the original terminal has and with few simple UI tricks to get a nice UI input boxes. However, you might get disappointed with the result.
With such an approach it is easy to create a visual UI editor with drag/drop elements, map terminal blocks and put a tag on the product "modernization feature".
Some 15 years ago, desktop environments were common, modernized terminals was built for desktop client applications. So, resizing such applications will give vertical and horizontal scrollbars and using fixed position approach was not a big deal.
Products containing fixed UI positioning use a simple trick to give screens a little fresher new look. Such solutions do not contain mobile and tablet support and as long as they have fixed positioning, mobile and tablets will not be supported.
Solution would be switching to the responsive layout which means re-coding the whole project and loosing visual UI editor some products has. Why?
Responsive solution
In the era of mobile and tablet devices, different screen sizes and orientations, web technologies etc., many companies tried to create a web-based business application replicating windowed UI with fixed position elements which turns out to be a problem. That resulted with a new concept - responsive design.
Responsive design concept is UI web development approach where UI components adjust not only it's size but ordering and layout based on screen size and screen orientations. Developers needed such approach to reduce development time and cost to support desktop, mobile and tablets with a single UI design.
New solution solved fixed positioning approach issues and limitations; however, it created a new set of problems.
First problem is with UI designer tools. It's not easy to create a UI editor for responsive elements as it is for UI with fixed positioning. Especially for web environments.
Second problem is to create a good UI detection engine which will not use simple row/col to x/y pixel position calculation but a real self-rendering and self-adjusting UI solution.
After a lot of research and being on the drawing board for months we came up to our own multidisciplinary approach using and combining different concepts... GS-UI.
GS-UI Solution
GS-UI is our approach to the problem but let's recapitulate the differences first.
| Approach | Classic | Responsive |
|---|---|---|
| Positioning | Fixed (x/y) | ✔ Relative, responsive |
| UI Editor | ✔ Easy with D&D | Hard, nonexistent |
| Automatic render | ✔ Easy, 1-to-1 map | Hard, custom |
| Manual developing | ✔ Almost none | Time consuming |
| UI Styling | Fixed, manufacturer | ✔ Flexible, any fwk. |
| Flexibility | Low | ✔ High |
| Extensibility | Low | ✔ High |
| Mobile/Tablet | Bad | ✔ Excellent |
The main problems to solve are:
- how to map screens hard or impossible to automate
- how to enable dynamic UI layout (orientation and screen res.)
- how to detect parts of the screen into groups / segments
- how to make it work in mobile app
- how to make if fast and responsive
- how to make manual templates easy
- how to support UI editor
This is exactly the table we created during our R&D process while searching for a solution, and we came up to a conclusion that responsive design is a clear winner despite some hard parts which needs to be solved.
UI-Editor
It is hard to develop D&D UI editor for responsive layout for web/browser technologies and also keeping flexibility and long term thinking to easily support future UI frameworks and high level of customization. Instead of going into our own UI editor development we decided to use a simple online HTML editor with custom self-rendering components which reduce manual templating to a few minutes per screen.
Custom Components
They are custom HTML tags registered in the browser to do self-rendering. For an example, nonstandard 5250 screen design is almost impossible to automate for modernization as design is all about creativity, and we saw several hundred screens which does not follow any design principles. For such screens manual templating is required.
With such cases the developer would have to learn a specific framework and consume a lot of time to manually map the screen. Instead, we are using custom components which will render Bootstrap HTML tags to dramatically reduce development time. Components are generic, so they can be updated to use any other CSS.
For an example, to create a web form with all the fields on the screen, the developer will use <gs-form> tag which will use all available fields and automatically build a Bootstrap form card. To create a multiple form cards, the developer will use <gs-form row=5 col=10 rows=5 cols=50> as a region from where to extract fields and generate Bootstrap responsive UI.
Bottom line is to use a simple semantic web rules to link terminal screen data blocks to custom-built components which will take the rest of the work.
Flexibility
As custom components are just XML tags, web UI screen template is extremely flexible as it allows mixing standard HTML tags and GS-UI custom ones. Adding new CSS or additional CSS, framework or library as a replacement or as an additional feature gives extreme freedom to developers not tiding them to a specific framework.
Open source
The whole library will be open sourced for multiple reasons. We want to build a community of users which will share their own custom 5250 UI components, but also to share knowledge and to improve rendering and detection engine that will benefit to all using our product. Also, we want to enable every company using our product to have a full control over modernization, styling and adopting the engine to their needs.
Being flexible, open sourced, companies will be able to use some other styling frameworks instead of Bootstrap, or to improve and update existing one without being dependent on our release management.
Automatic rendering
It is important to understand that there is no silver bullet when we talk about automatic modernization. There are 5250 screens which follows design recommended standards and such screens are quite easy to detect and modernize with nice results.
However, there are screens impossible or almost impossible to modernize automatically and manual templating is required. So, how automatic modernization will work in a specific environment depends on the principles used. In some case it will cover the most of the screens with nice automatic UI, in some cases it will be 50-50 chance, while in some cases it won't be of much help.
The point about automatic modernization is to be a helper tool for increased productivity in UI modernization reducing time to modernize hundreds of screens. Combined with custom self-rendering GS-UI components time for modernization is reduced to the minimum. And being open source, brings an opportunity to get many people involved in further improvements.
Local rendering
Many products do server-side rendering which not only makes a lot of pressure to the server side, especially when many workstations are used, but also create additional pressure on the network making 5250 terminal responses even slower.
Our approach is to offload this to the browser and use desktop processing power. This also brings the possibility to support modernization in our mobile application without extra network usage. Having responsive UI technology as the main element brings easy screen fitting to different screen sizes which is impossible with fixed UI positioning approach many products use.
Using AI for screen rendering
Being offloaded to the local rendering opens some new exciting possibilities - use of AI in screen modernization. This is our future goal for now. Will it happen, frankly we do not know. Many factors will influence that. There are several companies working on AI models to generate UI.
AI is an advanced statistical analysis tool which might tell what some parts of the 5250 screens are. To build the UI, other elements are needed also. And we have them all already. We have all other ingredients for future AI usage in screen modernization in our mobile app also.
Already today, some Android devices has AI hardware embedded. In 2-3 years, this will become a standard part of every tablet or smartphone.
Only what is missing is to create a community of users for this engine which will bring new ideas, new knowledge and possibly AI integration in the near future.
Conclusion
As we noted on our website main page, it's all about performance, security, reliability and flexibility. Opening modernization engine code to the public with hope to be well accepted is a first step. What will happen from then, it's up to the future community members.