[Jamiecon]

Where I work, our > 15 year old ticket retail system was developed on a platform called Dataflex [0], which provides a character mode user interface. We have since migrated the datastore from the embedded ISAM database to Postgres, and built eCommerce and other web applications around the original schema.

Our administrative and call centre staff continue to use the original character mode interface to interact with the data and do their daily work. The software works and we have no reason to redevelop it anyway, but seriously, you should see the speed with which experienced staff move around the system. Editors can input hundreds of events an hour and call centre staff are amazingly efficient - they can practically use the thing blindfold.

There's a lot to be said for consistent keyboard controls and a distraction free interface in the workplace. Line of business applications from the last couple of decades, mostly mouse driven, are often tragically inefficient.

[0] http://en.wikipedia.org/wiki/Dataflex

[cturner]

Thanks. I have had a similar experience: when I was a teenager I helped with stock-take at a warehouse - once a year, for several years. I saw ladies doing data entry to terminals that were hooked up to an application running from another city on an IBM System/36 mini. They'd get ahead of the screen refreshes, but the UART diligently remembered each keystroke, and they'd power through. When I started out in my career I forgot all of this. I had to convert an existing 4D application a business loved for a multi-user application. I built an intricate system that was web only, with some javascript caching, accessed over a latent connection. The staff had a horrible time with this for several years. It was ultimately abandoned, and they moved to a paper system. I was uncomfortable with the memory but the penny didn't drop until I got into roguelike development. Huge regret - I should have remembered my time in the warehouse. If I had my time again I'd design most of the interaction in a termal as described above. The web is a toy.

[yourapostasy]

Somewhat sadly, it doesn't look like businesses are commissioning such character terminal interfaces any longer. Certainly not in sufficient volumes to support the few boutique shops that published and maintained text window libraries that some developers would use to insulate themselves from the insanity of supporting multiple terminal types on different systems. As far as I can tell from some Google searches, Vermont Creative Software's Vermont Views and Oakland Group, Inc.'s C-Scape are both no longer sold or even have a web presence. If it is true both went out of business, it would be a pity that such codebases are languishing in bit rot hell and could possibly disappear from the historical record. There were and are no comparable open source text window libraries with the polish these products had.

[cturner]

Putty is fine though.

Something that would be useful but which I don't think exists at the moment is a multiplexor. Like GNU/screen, but properly sandboxed. When the user logs in they get a menu program running on "tab 0". This program would spawn perspectives on new tabs.

[cturner]

(Follow-up post after re-read.)

Actually, maybe these things have features that I wouldn't know of being only a curses person. I'd be interested to know more if you wrote up a blog post. Email cratuki at the google mail server.

[yourapostasy]

I'm prone to Yegge-length expositions in a blog, so the HN format might be better. These libraries could be thought of kind of like extensions to curses. In some cases, they actually depended on curses, in others, they did the work curses did and then went beyond that. You could typically draw into a defined buffer that represented a window, then have that window blasted onto the terminal replete with the character ASCII art that decorated the window borders without having to work out the arithmetic drudgery to put the right spaces and characters to draw the borders.

More elaborate libraries let you overlap the windows and would optimally redraw them when you moved the windows. They simply let you avoid having to roll your own text user interface starting from curses and building from there. Open source equivalents never approached the comprehensiveness or polish of these commercial libraries, though the open source ones are pretty good. Now that the commercial libraries appear to have dropped off the face of the earth, the open source ones seem to be all that is left. CDK [1] and NDK++ [2] on Unix and DFLAT [3] on DOS are examples of the open source libraries. I just felt the commercial libraries were interesting pieces of software history that should be preserved.

I personally feel that the kind of high-speed manual data entry optimization that these libraries facilitated is likely on its way out with advances in machine learning and the self-service customer culture of ecommerce. Certainly nothing prevents someone from using a standard web browser to present a user interface that responds entirely from keypresses, should the need for a highly optimized data entry-oriented Javascript library become necessary (something I've looked for but haven't found either for sale or open source). You would need to come up with a way to buffer up all the keypresses locally on the browser and ensure they all make it to the server, but it's doable.

If someone really had a burning desire to have some kind of in-house application presented through a character terminal interface via PuTTY in today's world, then they can still fall back to curses I suppose. Though I sometimes wonder if it would be faster to just write something in Emacs Lisp and autostart that when the user logs in.

[1] http://invisible-island.net/cdk/cdk.html

[2] http://ndk-xx.sourceforge.net/

[3] http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/deve...