Application Development - Browser or Green Screen or both?

There has been continual debate over many years about the relative merits of Browser/GUI operation of applications compared with using green screen/5250 operation. There are those on both sides who can be somewhat dogmatic in their views, but the general consensus seems to be that both have their place.

The problem is that, when creating an application using traditional means, a choice has to be made. There are recorded instances of companies converting/modernising their 5250 applications and then deciding that, after all, 5250 is more productive in their particular environment.

How much better it would be if all the applications that we create could be used with both interfaces and we didn't have to make such choices before or during development.

I have started several previous threads about Application Development in Linked In in AS/400 Professionals and IBM I Professionals. These were -

Application Development - Back to the Drawing Board? (AS/400 Professionals)
Application Development 1 - Our User Requirements Specification (IBM i Professionals)
Application Development (2) - The Drudgery of Separatism (IBM I Professionals)
Application Development 3 - Coping with Complexity (IBM I Professionals)
Application Development 4 - Entities, Attributes and Connections (IBM i Professionals)

The 2nd of these - Application Development 1 - Our User Requirements Specification lists what I believe are the mandatory features of a modern application creation system.

ERROS has all of these features. The ERROS Connectionist Framework provides a sound structured basis on which you can build integrated applications which is done without programming most of the time. ERROS stores all metadata, application definitions and user data in its own integrated connectionist database. No SQL is necessary for queries or to navigate the connections in the database. The concepts of ERROS have been successfully patented.

As ERROS allows incremental development, application creation can be done without a detailed system specification and without any physical data schema. ERROS applications can evolve in line with the ever changing real-world of the business on a "grow as you go" basis. ERROS is extraordinarily productive for both application development and for maintenance. It offers very rapid response times that do not degrade as data volumes grow.

ERROS generates HTML and Javascript on the fly - there are no stored static HTML pages in ERROS. Thus any ERROS application created for 5250 will work at once with a browser. Therefore, application creation can also be done using a browser. ERROS allows browser users to operate function keys just as they would in 5250 mode but, if they prefer, they can operate ERROS in GUI mode, clicking on buttons and double clicking on connections. ERROS allows developers to add additional fields, images, Google Maps and other information to the browser displays. Buttons on Google Maps are "live", working just as they would if being accessed directly through a browser. Very complex internet enabled applications can be created using ERROS yet new program coding is rarely required.

If new program coding has been written, then new HTML coding may be required for update mode only (using CGIDEV2), but this happens rarely. Any such changes are made in ERROS exit programs and no changes are necessary for the main ERROS programs which do not need recompiling. As ERROS is totally object oriented, once any new code has been created, it will automatically be used in any application where appropriate.

A variety of sample ERROS browser screens from several applications in inquiry mode may be found here. It is perhaps worth emphasising that no special HTML or Javascript coding was necessary for any of these screens.