Comment by ursasmar

I had the great fun, no sarcasm, of modernizing a TUI system that had been in use at a company from the mid to late 80s. It was a DOS app, I don't recall the name, that let you build "screens". Each screen would have multiple fields, possibly multiple pages, and would write data to a CSV (colon separated file) with a max size of 2MB. Each screen had its own file, and screens could not "talk" to other screens. Each screen had 3 modes, search, data entry, and record paging. There was a fourth type of screen called a report. This was basically the search screen, with slightly different operators that would mainly produce counts of whatever fields were being searched for, and would send that to a printer.

The search was interesting. I don't remember the specifics of it, but it was fairly powerful. A user would enter values in fields they wanted to search on. Say they wanted to find a customer named Bill who had ordered in the last 30 days. They would move the cursor to the First name field, enter "Bill" ^ "William" (the caret being the OR operator, I do remember that one), then move to the Order field and enter "30D-", hit enter, and get their records back.

The company had about 20 of these screens, and the way they used the program was fun. Everyone in the office had a Windows computer with a network drive that pointed at the storage server. The storage server had all of the screens CSV files. There was one screen in particular that everyone used. It was the product orders screen. When someone in the office was using it, they flipped a switched on the wall next to their computer that turned on a small red light for everyone else letting them know that the product screen was in use, and no one else could touch it. Once the light went off, someone else could jump in. I heard that it was usually a race to be the next one to use it, and arguments would pop up if someone was hogging the product orders screen.

I was brought in around 2009 to modernize the system. I was told that it has to look, feel, and work exactly like the old one, but be multi user. They also gave me a list of 15 of the screens that they really needed implemented in the new system. Being that I am a web developer, that is what I reached for. PHP backend, a JS frontend, and MySQL for all the data. The first order of business was ingesting all of the CSV's, and then relating all of the data. With orders, work orders, customers, company contacts, people contacts, inventory, etc this took awhile. Next was building the API to access the data. This was fairly simple. The truly hard part was the frontend. At that point, I had little to no JS experience, but I soon learned.

By the end, I had a website that when loaded had a main menu that looked exactly like the main menu of the old app. Each screen was listed with a keyboard shortcut next to it that would load a particular screen. By default screens were in search mode. I spent a lot of time with the built in help menus of the old program, and talking to the people who used it, to get a list of all of the search functions and how they worked. Then had fun writing a parser for this that would translate the searches into SQL queries.

Hitting Page Down while in search mode would start paging through records. The challenge here was the speed. In the old app, they had at most 2MB of data on a local file. The new system of course was a web page calling an API, which was querying a database that had 30 years of data in it. Users biggest complaint is that this was just way to slow. So I reached for the new at the time web workers API to preload 100 records in the background so that paging through records became nearly instant. And this worker would start filling the record cache once it got about half way through its current list.

One of the most challenging things in the build was the keyboard navigation. In the old app, if you pressed the down arrow you would move to whatever field was directly under the current field. But, if that field overlapped 2 fields below it, and the cursor was in the far right of the field, and the user pressed down, it would move to the first location in the right side field that was under it. I basically came up with a mapping system for fields so that when a user pressed the down arrow it always went to the correct field. Another fun part was the left and right arrows. If there was no data in the field, it would just move to the next field left or right. But, if there was data in the field, it would only move left if you were at the start of the field, or right if you were at the last character written in the field.

Another challenge was keyboard shortcuts. There were key press handling libraries at the time, but none of them did quite exactly what I needed, especially with each screen mode having slightly different shortcuts. This lead to me writing my own keyboard handling library that was aware of what state it was in.

And something I had fun building was the printing capability. The old app had a companion app that could be sent data, and it would put it into a pre-built form that was then sent to a printer. So something like an invoice would be created, data was sent to the other app, it had a pre-built invoice form with a company header, and data placeholders for all the incoming records, and print that out. For my solution, I had a print.css file for each screen. When a user hit the Print Screen button the page would swap in the print.css, trigger a Ctrl-P, wait for the user to select print in the browser, then swap back to the normal css file.

I got to do so many things with a web app that first of all I didn't know were possible, and second, I haven't had the pleasure of doing since that app.

To this date, its the most fun I have had working on any project, and its still in use today. So in another 15 years, maybe someone else will have to come along and update my web TUI to whatever new technology is around.