|
|
|
|
|
|
by jameshart
1475 days ago
|
|
|
You can see the same dynamic on precursor systems. Half the complexity in ANSI escape codes for dumb terminals exists to provide form support (and some features added to terminals like ‘terminal status report’ exist to make forms easier to implement). The French Minicom system was built to deliver interactive forms over the phone line to terminals in people’s homes; in the UK there was the similar Prestel, which was mainly used for commercial UIs (huge in the travel industry), and which was basically ‘teletext plus form fields’. Heck, even print technology implemented ‘forms’ technology - there is a standard UX affordance of a dotted line with scissors drawn on it to tell you that a piece of printed material supports cutting out a form, filling it and mailing it in. These forms were showing up in magazines, on cereal packets, back for over a century… the catalog industry was built on this tech. Basically, if you create an information distribution medium, someone will turn it into a form delivery platform. It’s inevitable. |
|
|
The block mode terminals on IBM mainframes (e.g. the 3270) have all the functionality of a basic HTML form if you squint hard enough: the screen is divided into form fields and labels, the user can fill out the fields (and tab the cursor between them) while the terminal is offline/not communicating with the server, and then when the user presses one of the special 'submit' keys the terminal sends all of the data from the form fields to the server and awaits instructions on what to do next.
The 3270 even had hidden fields, so the server could stuff a bit of state information (like a session ID) into the form, which the terminal would dutifully echo back to the server when submitting the form....
It's a very different style of interaction as compared to the conventional Unix/PC character-by-character terminals, and leads to some pretty weird user interface conventions: https://www.youtube.com/watch?v=9qwFSJZSjeA