CfCH LOLA Display Concept Scene (mouse over to enlarge)
To help promote LOLA, Alan Cooper had previously created a possible display to exhibit at a suitable venue, hopefully at the The Centre for Computing History in Cambridge, where the LOLA papers are archived.
To help engage visitors, part of the exhibit includes an interactive display called "The Green Screen Demo" (now "Rates Green Screen Rebuild").
Photo shows a 3D impression of the display. Maybe the furniture should be more change the scene to 1970's, including a filing cabinet!
Purpose
Green Screen Terminal with a Rates Application
This interactive display allows visitors to experience what a 1970's computer system was like to use as if they were a user in the Rates department of a council.
Then, few computer systems were interactive, and those that were had monochrome terminals with plain text. No windows, no images and no mice!
This demo will also demonstrate the power of database processing. Visitors will be able to experience how the data is inter-linked: Names link to Properties and these link to Rate Assessments; Assessments have Accounts that are linked back to Names. And of course, Accounts have Payments.
LOLA used the then new and revolutionary database system called IMS - software developed by Rockwell, Caterpillar and IBM to support the Apollo moon landings. This allowed data to be cross-referenced so that different applications could share core data. This avoided data duplication that was usually out-of-sync.
This diagram shows LOLA's high level database architecture with the scope of the demo in red.
The Application
The demo replicates some of the high-level enquiry screens of LOLA's first application: Rates. Rates was the key application for a council as it collected the local property tax that funded their operations.
The 4 London councils (boroughs) in the LOLA partnership already had various Rates system. Hackney for example, ran their system on a LEO III computer with a design dating from the 1950's.
This demo would complement a LEO exhibition. In the 1980’s, in-order to retire Hackney's ageing LEO, IBM wrote a LEO emulator so that the critical Payroll and other applications could run on LOLA's IBM computer.
This could be another panel adjacent to the display.
The LOLA Rates system, with Names and Properties at the core, was the foundation for over 13 council applications and 300 programs, and probably 1,000 screens, developed over 2 decades and covering most of the council services.
The Interactive Demo
The interactive demo, called The Green Screen Demo, closely mirrors the LOLA Rates system. This includes the screen layouts and the use of function keys to interact with the system.
This diagram shows the main functions provided.
Hardware and Software
The Green Screen Demo runs in a browser window on a standard PC linked to a web server. The web server can run on the PC making it entirely stand-alone
It runs in the browser Kiosk Mode when only the browser content is shown. There are no browser menus or tabs etc. and no Windows desktop or task-bar.
The PC screen needs to be a large wide screen (24" / 60cm minimum diagonal). This is because the 1970's terminal is displayed on the right-hand two-thirds with a help panel in the left third. The terminal display is then about the size of a real terminal.
Some technical notes follow at the end.
The Rates Demo Screens
The Welcome Screen
This screen is the default screen when nobody is using the system. It's purpose is to ‘catch the eye’ of visitors and encourage them to try the demo.
The screen shows a log-in facility. This is not required in its current form.
If the demo was to allow data to be changed, then each user would have their own copy of the databases. They could log-off and then log-in later in the day. At the end of the day their data and user id would be deleted.
Terminals in the 1970s:
were black with green text or white text. The author finds this very difficult to work with, hence black text of green has been used. A configuration button allows the user to swap the colours around.
the data fields in the LOLA application were white text on black background. In the demo are shown in a lighter shade of green, again for ease of use. A configuration button removes this for a more authentic experience.
early LOLA documentation showed user commands were simply typed, e.g. C3 for choice 3. Later documentation shows Function Keys used (this maybe when Raytheon Cossor terminals were used). The demo uses Function Keys.
After logging-in the visitor is presented with LOLA's main Transaction Selection screen (aka Home screen).
The Transaction Screen
This is what the Rates clerk would have seen when the system started. This is portrayed in the Open University course video on database systems.
The visitor is able to select one of the 3 demo transactions: Name Enquiry, Property Enquiry and Rates Enquiry. Simply entering X00, X01 or R11 takes the visitor to a search form for that enquiry.
The terminals used by the LOLA application systems used a transmit key to send their request to LOLA's computers in Enfield. A standard PC extended keyboard has no suitable key, so visitors will use the Return key.
Optionally, like the contemporary Rates system, visitor can enter a reference number. Provide it refers to a valid record (Name, Property, Assessment or Account) then the visitor is taken to the details for that account.
The User Help & Configuration Options
Beyond the guidance in the left panel, there are a number of options to provide help and make the system more realistic. These are actioned by the icons at the bottom of the screen (icons to be improved).
Sample Data
A pop-up window provides random sample data that the user can search for. There are Names, Properties, Accounts with linked Names, Assessments with linked Properties, Agents with Accounts, and Streets with Properties.
The intial data reflects the current transaction, but the footer buttons allow the other data types to be seen.
Text & Background Colour
The screens shown here are Black text on Green background for clarity. For 1970's realism the user can select Green on Black, or White on Black.
Data Fields Highlighted
The screens shown here use a light green background to highlight the data fields. For realism the user can remove this.
The demo will continue to hightlight the current data entry field with a black border. This is a substitute for a flashing cursor.
Text Scrolling
Currently new screen appear instantaneously. For 1970's realism the user can experience being at the end of a slow telecommunications line. There is an initial 8 second delay and then the text gradually appearing over about 10 seconds.
The X00 Name Enquiry Screen
Here the visitor can enter Name search criteria.
Like the real LOLA system, this Green Screen Demo uses Soundex to search using a code based on how the surname sounds. This aided the Rates clerk who maybe responding to a telephone enquiry when they were unsure of the spelling.
Likewise, the demo differentiates persons from company names as LOLA separately identified these in the Names database.
To assist visitors there is a button to pop-up a window of sample Names within the database that they can use to search.
At the bottom of this screen can be seen the function keys. They will be discussed later. Also the final line displays any error messages.
Provided some Names can be found, then the visitor is shown a list of matches.
The X00 Names Enquiry Matches Screen
This screen displays up-to 8 possible matches, The use can press function keys F1 to F8 to choose one, or press F10 to go back to the search form.
The screen layout is based on the one in the Open University Case Study book.
To aid the visitor's experience, the demo has embellished the results:
C or P indicates if the Name is a Company or a Person.
R or C on the address line indicates the relation with respect to the Property.
Every Property had Responsible Name, the legal owner of the Property who was the Ratepayer. Optionally some Names were the person to Communicate With about the Property, typically an accountant or managing agent.
Two names do not have addresses. Either they are database orphans (records where the links have been damaged) or an address outside the council area. LOLA held such "foreign" addresses within the Names database, but this demo does not implement that.
This X00 search results screen does not currently display more that 8 name matches, but given the small demo database this is not a limitation.
Having made a selection, the visitor is shown the Name details.
The X00 Selected Name Details Screen
This screen shows the selected Name and all the Properties they are associated with.
No screen layout has been found so this is based on the known Name attributes. The Name's address could be added as line 2, but most cases this is the same as the Responsible for address.
First listed are those Properties they are owners of and therefore responsible for paying the Rates.
Second listed are those Properties were they are the person / company to handle Communications. There are Properties owned by other people and they are the managing agents.
In this example Manners & Sons have an Agent Number. Companies with a large portfolio of properties were sent a single Schedule Rate Demand, listing all the Properties. This demo does not implement the Schedules database.
The 50xx reference is the Property number, added to help the visitor cross reference records.
The visitor can press the appropriate function keys to go to the Property Details. This screen is shown shortly.
The X01 Property Enquiry Form
The Property enquiry, matches and selection follows the same pattern. Again, layouts are are conjectured but follow the same style as known screens.
In making a search of the Properties database, the demo removes common prefixes and suffixes like Street, Rd., The.
Again the layout is based on the Open University Course book.
Like the Names Enquiry, is planned to have a button to pop-up a window of sample Property addresses in the database.
The X01 List of Properties Found
This page list the possible matches. There is a choice number and the property reference number.
Again the layout is based on the Open University Course book.
An 80xx Assessment number has sinced been added before each address and the 50xx Property Ref. moved to the end.
The X01 Selected Property Details
As well as the full Property address some key Rates information is shown.
Every Property is related to an Assessment that records how the Rateable Value was determined. From the Rateable Value the actual Rates payable is calculated.
No screen design has been found so it includes all the Property attributes known plus key Assessment data Rates Payable is calculate just like the real system!.
The 50xx reference is the Property number, added to help the visitor cross reference records.
Incidently, HMRC have been responsible for over 100 years in determining Rateable Values. Every Property is supposed to be re-evaluated every 10 years but this has often been skipped due to costs. Historically, it represented the rent a property could let for.
Again, there is a cross reference to the Responsible Name (owner/Ratepayer) and any Communicate With Names.
The function keys allow the related Assessment, Ratepayer (Responsible Name) and Communicate With Name details to be seen.
The R11 Rate Account Enquiry Form
It appears from LOLA documentation that the R11 Account Enquiry was the main "gateway" transaction into all Rates information, even though Accounts were subsidiary to Assessments.
Entering an Assessment number will list all the Accounts below the Assessment.
Every Property is linked to 1 Assessment and then Assessments linked to all the Accounts. Typically there will be only 1 Account but if a Property changes ownership in a financial year, then there will be 2 Accounts: the 1st for the 1st owner and the 2nd for the 2nd current owner.
The LOLA database schematics appear to show 2 Account database entities. It is guessed that the second is for previous financial years and/or outstanding payments.
Entering an Account number will list that Account but give access to any other related Accounts related to the Property or the Name.
Agent No. and Street are not yet implemented. They will likely to give many Accounts and a selection list is probable (if implemented).
The R11 Rate Account Summary - page 1
This is based on contemporary LOLA documentation slightly simplified to reduce clutter. It is a 2 page summary.
Page 1 (shown here) provides the basic Ratepayer and Property details as well as the important Rateable Value from the Assessment.
The lower part shows the Account Balances. Many Ratepayer chose to pay by 10 monthly instalments rather that biannually when the Rate Demands were sent out (a huge print and enveloping job using noisy equipment prone to breakdowns!).
Some attempt has been made to generate realistic data for the year 1972-73 but more information is sought as to the Rate attributes and calculations.
The R11 Rate Account Summary - page 2
Again based on contemporary LOLA documentation. Page 2 is primarily focused on Instalments and Rebates.
Whilst the demo has tried to generate realistic looking Instalment data the Rebate data has been left blank due to lack of information and complexity.
The function keys highlight the rich variety of cross references that a database approach provides.
Whilst the IMS database software used by LOLA was a 1st generation hierarchical based system, LOLA implemented very flat hierarchies (usually 1 main table and links). So it was more akin to a 2nd generation network database model.
The demo today uses a 3rd generation relationship model with SQL (developed by IBM in late 1970s). Due to LOLA's excellent database design (for which the author takes some credit!) it has been very easy to replicate the data structures in relational tables.
One of the function key option is Payments [F6].
The R11 Rate Account Payment
This page shows up-to 10 payments, with a 2nd page for further payments.
Like the real Rates system (and Council Tax today), the demo calculates the instalments with a first "odd" payment and 9 identical payments based on the Rateable Value and the council Rate set for that financial year.
It is unclear if Payments includes credits or whether credits were always dispatched to the Ratepayer.
Conclusions
This Green Screen demo:
creates a realistic simulation of a 1970's terminal based system.
realistically replicates parts of the LOLA Rates system.
provides a stimulating and engaging experience for museum visitors.
demonstrates the power of relational databases.
Software Environment
This Green Screen demo used the following software:
Flask - a lightweight web framework written in Python that allows developers to build web applications quickly and easily.
SQLAlchemy - an open-source Python library that provides an SQL toolkit and an object–relational mapper for database interactions.
SQLite - an open-source relational database engine more lightweight that MySQL.
Python V3.13.1.2 - the Green Screen Demo is written in Python.
phpLiteAdmin - an open-source tool written in PHP to handle the administration of SQLite databases.
PHP 7.4.33 - needed for phpLiteAdmin.
Abyss - a lightweight yet powerful web server. The common Apache web server should also work.
Additionally, Alan Cooper created an interface framework between the Python application and the Flask web page rendering. It:
defines a data dictionary of the transactions, screen layouts and help pages. These are stored within the SQLite databases along with the LOLA databases.
takes the data to be displayed and formats the content of the green screen and the help panel.
Deployment
Production Limitations
The software above has some limitations for deployment beyond a stand-alone PC (e.g. to the world wide web):
Flask development version is not secure in a multi-user environment. Instead it advises the use of a:
dedicated WSGI server
reverse proxy like Nginx or Apache
Update: [F7]
The following functionality could be added:
button to display sample data the user can search on.
button to change the screen text/background colours from black/green to green/black or white/black.
button to remove the light green background to the data fields.
screen text to slowly display the text as though it were coming via telecomms line, plus a button to set the speed and an initial delay.
time-out to return to the Welcome screen after a period of inactivity.
catch Python errors, log and return to the Transaction screen.
catch hot-keys that can escape the kiosk mode.
add the missing R11 Agent & Street searches.
add some screens so visitors can change the data - this will require:
a separate copy of the LOLA database for each user.
removing these copies and users profiles daily.
Add additional data or rebuild all the data
Currently there are 20 Names, 19 Properties, 20 Assessments, 22 Accounts and 142 Payments.
More data / more realistic data, ideally auto generated (as the Payments currently are).
To do this, I would appreciate some help as to understanding the Rates data items and how they were updated (formula).
Plus some further testing is required to make it more robust.
Currently the Back (F10) key looses track of it's history ("breadcrumbs").
It is possible to circumvent the Kiosk mode.
Ideally the demo is re-written by someone experience in Flask & SQLAlchemy.
Next Steps
1. Feed Back Please!
If anyone wants to try it (and provide Feedback) then I could produce installation instructions. Installation may well take an hour and needs some DOS level knowledge.
2. Find a Venue to Host
Beside the The Centre for Computing History there is the National Museum of Computing (TNMOC) at Bletchley. The LEO Computer Society has an event there on 28th and/or 29th of November. Given the LOLA-LEO links this might be possible. Either venues might inspire longer term hosting.
A local authority focused society event might well be interested. Anyone know of such?
Maybe as part of a larger exhibition into historic computing, or into the development of database systems.
3. As-is or Rebuild?
Pending outcome of the above, either use as-is or find a skilled developer able to re-write the system. After all, this is meant to be a concept model, not a production ready system!