4 ms·
At one of my previous jobs, I was responsible for designing and building a webapp to replace a high speed data entry system that had been written in cobol that
by tynpeddler 7y ago
At one of my previous jobs, I was responsible for designing and building a webapp to replace a high speed data entry system that had been written in cobol that was used to input large legal documents (several thousand lines of data in some cases). We had two objectives, data entry had to be as fast or faster than the old system and the training time on the new system had to be faster.
We blew both objectives out of the water. Training time went from 3-6 months to about 2 weeks. We had a variety of modern UI concepts like modals, drop downs and well behaved tables that dramatically simplified the work flow. We also had a full suite of user defined hotkeys, as well as a smart templating system that allowed users to redefine the screen layout on a per use case basis (the screen would be reconfigured based on what customer the user was entering data for example).
For performance, cobol typically requires a server round trip every time the screen changes. We simply cached the data client side and could paginate so quickly that it actually caused a usage problem because users were not mentally registering the page change. The initial screen load took slightly longer compared to the cobol system, but the cobol system required 40 screens for its workflow whereas our system could do everything on a single screen.
I guess my point is that modern systems are capable of much better performance and user ergonomics than cobol systems. We have a lot more flexibility in how UI's are presented that let us design really intuitive workflows. The flexibility also lets us tune our data flow patterns to maximize performance. But most modern development processes do not have this kind of maniacal focus. Systems don't perform because most product owners don't really care that much at the end of the day. Once you care enough, anything's possible.
- fareesh 7y agoHow long did it take? What frameworks/libraries did you use?
- tynpeddler 7y agoWe used Angular 1. Took about 2 years, but it was just me for about half that time and we were all learning js and the web ecosystem. The new system had been prototyped a few years earlier using java swing. That really helped nail down the design requirements.
- momofarm 7y agoHas this meet expected budget? Compare to continue maintain existing cobol system?
- nulbyte 7y ago> For performance, cobol typically requires a server round trip every time the screen changes. Round trips aren't the problem. Waiting for IO is. CICS solves this by not waiting for IO. It dumps the screen and moves on. Then it becomes the terminal's responsibility to wake CICS up with an attention key. If a front-end application is stuck waiting for terminal input, it's written wrong.
- aetherspawn 7y agoIn my last job we wrote a front-end that ran the COBOL and streamed the presentation information to the client over a websocket. It allowed them to use 30+mil LOC of existing apps. The resulting webapps were made automatically responsive for the web and could be run anywhere - desktop, tablets, phones and apps could open tabs that invoked other apps for multitasking. We also added some custom commands to the COBOL so that they could invoke web based graphs, reporting, printing, pdf generation, etc. The client supported native typeahead, so the web apps behaved very much like desktop apps whereby pressing a number of shortcuts simultaneously resulted in them being played in order and overcoming any latency. This made the apps completely superior to normal web apps for their application (i.e. POS, ERP systems). The utility that COBOL provided, coupled with a modern web based runtime written in React, was remarkable. Truly a hybrid of both the best parts. When I left, they were working on wrapping the React webapp into a React Native app.
- murphy214 7y agoFor "presentation information"are you saying you just stream back the normal text on the screen (for that piece of information in the COBOL app) and then parse it into some sort of API? I have no idea about COBOL at all but I've done something like this before with a client mainframe scripting/macro language, it was not fun. Basically I had to hard code a bunch of key inputs to get the information screen I needed finally read that screen back out in plain text and parsing that into some sort of structure. It was a mess but worked for what it required at the time.
- aetherspawn 7y agoThings like buttons and windows are streamed across.
- earthboundkid 7y ago> Once you care enough, anything's possible. People should bring back sigs, so that can become a meme.
- nivethan 6y agoHi, I'm curious how you designed the app? Did you use the existing application as a base and try to duplicate it in the web or was it a completely different beast? Do you have any book recommendations or even blog posts for how to upgrade legacy UI? It's a topic I'd love to dive more into and I don't hear as much success stories as I would like.