What Is the Oldest Computer Program Still in Use?
technologyreview.com
technologyreview.com
In the case of MOCAS I'm going to assume it's all of the standard reasons: weak management, absence of competition, over-reliance on the same small pool of defence contractors that know how to navigate byzantine federal procurement rules, etc.
A lot of it is because they fail the KISS principle.
Obviously in that:
1) It will completely work with your existing clients etc, because it does exactly what the old one does, with no wild new features and untested stuff.
2) It will bring your old legacy app up to date with a modern language, being able to run in modern hardware, maintained by readily available programmers for hiring, etc.
3) It will allow you to start to add all kinds of features a couple of years down the line, as the remake proves a success, and any minor issues are ironed out.
4) It's much less of a risk of some total rewrite, with a new architecture, ambitious plans, and the idea that you can just migrate the data and switch over, since those "second systems" tend to fail, and over-shoot their costs.
>The only way to justify is if the maintenance costs are higher than the redevelopment costs.
You forgot the opportunity costs. Enabling them to be more agile, add new features, take advantage of modern pool of programmers, etc., is important, even if they have first to build an identically behaving version of their legacy app.
(Scary though: this might mean _someone_ is still running a Redhat 5 or 6 linux machine or VM - that's a late'90's vintage Redhat, not Redhat Enterprise Linux. It's _possible_ I updated that Perl script when we moved to CentOS in the early 2000's, but surely if anyne's been updating it since then - they'd surely have taken my personal email address out of it???)
IMHO Google has been so successful because of their user interface and not because of its superior algorithm. In essence it is a REPL where the E part is slightly non-trivial.
But I agree it is the best user interface. Files and processes are a great thing, but the shell built on-top of it glues everything together and for me is the most successful interface. However it would be nice to switch interpreters online, i.e. switch between e.g. Bash or Python and "human language" (like Google Search). Interestingly DuckDuckGo provides something similar via its '!' syntax.
But no doubt the simple and elegant interface helped too, and has helped them stay ahead as the other search engines have caught up with their algorithm.
Jerry Yang and Yahoo did not appreciate this and missed their oppurtunity to acquire Google early on. That said, Yahoo would have fumbled it even if they had pulled the trigger.
There were numerous well-understood PageRank alternatives available at the time (eg HITS was published in 1999[1]).
Google did lots of things right (good algorithm, good scaling, good UI, text-based advertising, spam handling, no portal etc), and to say it was "only PageRank" is just wrong.
http://www.slideshare.net/shatakirti/pagerank-and-hits
http://www.ijarcce.com/upload/2014/february/IJARCEE9J_a_pooj...
The first indicated PageRank has less disadvantages like spam. The second sums up the result here:
"page rank is more popular algorithm... due to the features like efficiency, feasibility, less query time cost, less susceptibility to localized links, etc which are absent in the HITS algorithm"
If that's true, then my claim would stand as HITS wouldn't have been good enough without a lot of modification. Google also got me better results than Ask that used HITS. If such claims are wrong, then you might be right. It would take more than a quick search to know.
Nope, it was the superior algorithm. Other search engine at the time had similarly simple interfaces, but we all moved to Google (back in 2000 or so) because of the superior results.
Hmm. Hasn't this been widely disputed and disproven? I wonder why it keeps being circulated, and with such a bold tone.
The way I understand it, the Navy got tired of supporting that. "If you want more of our money, you'll upgrade this crap." So they did, and now it's one server rack with, wouldn't you know, such modern things like USB ports and 21st century OSs and ethernet capability. But that's crazy talk.
http://www.pcworld.com/article/249951/computers/if-it-aint-b...
My favorite is the 90 yr old Texas company that uses an IBM 402 from 1948. The computer uses plugboards - breadboard-like cards that are programmed by plugging wires like a patch panel. As of the date of the article (2012) they still used the plugboards, as well as a more modern card reader/puncher.
Edit: I just realized my example is also mentioned in the OP article, though there is more detail (and photos) in the PCWorld article I linked.
A barrel organ could be said to follow a 'program', if we're loose enough to mean 'a set of machine-readable instructions that cause a process to take place' but it is in no sense calculating a result based on logical operations.
1. Multi-column layout with independent updates. Useful for presenting prompts and help information beside the main transaction window.
2. AJAX-style dynamic updates on data-selection.
Other than that there were few advantages to Web UI. In fact we had to spend some time developing Javascript functionality such as tab-order and F-key capture that are elementary, 'free' features with green-screen and which greatly improve transaction speed.
Any 5250 terminal emulator from the 1990s onwards offered copy-and-paste and multi-session capabilities so a Web UI didn't offer advantage there.
So, if it's an application where the end user spends a lot of time, a green screen can be more efficient. Things like a call center, or the check-in counter at an airport, etc.
It does depend on a good text and boxes ui though. Green screens had things like pulldowns, copy/paste, etc.
Until you get carpal tunnel syndrome.
How does a user interface? For a web site, primarily with a mouse. So, single touch input. For green screen they have an array of dedicated individual simultaneous input devices (known as "keys"). In addition, green screen often provides near-immediate response, whereas touchscreens can suffer from lag either in the physical interface or the unfortunate multiprocess operating system. Finally, green screen was designed to step quickly through the interface, where web requires lots of hunting around for what you want to do.
You simply can't interface better with an application than a single process dedicated application using fixed multiple inputs with immediate response. It's like web pages are a cart and horse and green screen is a race car.
Anyway, the place still used green screen terminals in 2006 (Mmm, with mechanical keyboards attached). In most cases, the only input required was a single number for each response, so once I'd memorized a script and the responses, I could get through a survey without looking at either the screen or the terminal.
Eventually the company shut down, and needing another job right away, I went to another polling company, who used a web interface for some reason. So there I had to use a vintage mouse (...which obviously did not bring the same joy as a vintage keyboard) to click radio buttons and check boxes and was, frankly, just a painful experience all around.
So, yeah, I agree, there are a surprising number of instances where an old terminal UI is significantly better.
Good modern UI design uses common metaphors that make it easier to learn new systems that are used with mouse if you are familiar with metaphors. They are designed for the beginner. There is nothing that prevents modern UI designer from learning the lessons from old terminals and carefully crafting the application so that experienced users can use different screen layout with fast keyboard navigation. It's just very rare.
I don't think we've even begun to develop optimal user interfaces, and we won't as long as the "common metaphor" idea holds sway.
Think what it would be like if we applied that idea to the real world, so (e.g.) hammers, can openers, toilets, and bulldozers all had to operate using a common set of widgets. It's hard to envision, but I would bet a very large sum of money that the result wouldn't be optimal for any of those jobs.
That's what we've done with computer UIs.
Unfortunately, I don't see any real way out of the trap.
Some new device or application will introduce a new metaphor or technology that eventually trickles into existing software. Unfortunately, last time this happened that new tech was touchscreens, and I fear voice is next. These are both regressions in efficiency for lots of tasks.
Only apps don't do that. Paint apps use brushes and canvases, spreadsheet apps use cell grids, music apps use notation views and piano rolls, writing apps use document screens, games use whatever invented controls and worlds, etc.
What is common is that a lot of stuff we do involves mere text and symbol manipulation (buying tickets, reading news, checking sports scores, entering customer data, etc). For those we use the same widgets, yes.
But in the real world we do build all kinds of stuff, from cars to boats, and from skyscrapers to bulldozers, to pinballs with nuts, bolts, screws, wires, glass panels, etc., too. A hammer is as useful for hanging a frame as it is for building a house.
No, they use skeuomorphic simulations of those things.
(edit, to expand a bit)
We have the capability to put anything on the screen that we can imagine, but we're not doing that. We're limiting ourselves to bad simulations of real-world tools. The "brushes" are just more of the same thinking that gave us "desktops", "file folders" and "trash cans". As others have noted, those things do make it easier for newbies to learn the system, and yeah, that's a point in its favor. It's just disappointing to me that we haven't come further than we have with respect to truly innovative interfaces.
You even see it in VR! You get the same menus, buttons, and whatnot, but, hey, now the components are rendered as high-resolution stereo images. Yay! I guess?
No, they don't. You don't paint moving some virtual drawn brush gizmo, taking to some "virtual water box" to wash it out, etc.
You paint moving a cursor (whether it has a brush icon is irrelevant and not skeuomorphic in the UI sense), and you control properties of the underlying line (color, spread, width etc) with some of them going far beyond what a real world brush can do.
>We have the capability to put anything on the screen that we can imagine, but we're not doing that.
That's because it's not convenient. Except if you have some cool new idea we haven't tried.
The reason is that once you know the codes, you can navigate and enter data at a genuinely incredible rate. If you've ever watched an experienced operator on one of these applications you'd be amazed. For one loan processing application, the terminal was an order of magnitude faster than the Web-based interface that was being deployed.
The key here though, is "experienced". This is someone who has developed the knowledge and muscle-memory to operate at that speed. This also makes the system more brittle (and often harder to change). Critically, it also means it takes a lot of training and time for people to be productive.
The reason many big organizations dropped the terminals - they wanted to be able to train people quicker, not because it was more productive.
The other key is that those people and those "POS" style apps do very little things -- mostly a single task like e.g. bank accounts management.
Yes, it's very fast to someone experienced with it.
Yes, the learning curve is incredible.
No, it will never change because the stakeholder (ie. the developer) is happy with it.
You're average web-skinned 3270 app is generally a direct translation of whatever the app did done by a gang of contractors without any design consideration.
The problem with that is that for all of the most trivial of apps, the use cases were envisioned 30 years ago. That's usually a problem. For example, one app that I looked at that still had old documentation available. Their design was based around 90% of transactions were initiated by a clerk opening paper mail. The obtuse layout of screens was there because they processed mail to dispatch it to appropriate teams of clerks, and it was customized to each function. Today 90% of transactions are initiated by phone or webchat, and are expected to be resolved in one call.
Bad web implementations are common. But it's almost always bad to ape things that aren't understood, which is the case 80% of the time for webified temrinal apps.
Am I?
(Sorry I couldn't resist)
Not everything needs to backed. It's obvious that most people, at least most lay people, find web UIs better and more friendly than terminal style interfaces...
Pleasant is not something objective to be measured comparing TUIs and web UIS -- it's in how people see them, and it's clear that what the article says it true for most people.
A good example of where a simple GUI is useful is POS systems. Sure, you could use a TUI, but you'd have to train every 16 year old kid who works for you for 2 weeks over summer, which is going to cost you.
On the other hand, I've noticed that airlines still use a terminal emulator for their booking and check in system. They're amazingly fast at using it, most of the commands are 1 or 2 letters. But you're dealing with a smaller group of trained and skilled employees, with a much lower turnover and a much higher overall training requirement.
There's probably also legacy reasons why airlines use a TUI, but it seems that the staff never have any issues using it, I've never seen them having to consult a manual.
Usability research proved this to be false again and again but unfortunately text is not showy enough.
Put me in front of an airline booking system, and I'm going to be completely lost. Put me in front of a computer opened to an airlines website, and I can probably figure out how to order myself some tickets.
Not always true. "Type customer reservation number" is very discoverable. A car dashboard has little text but there is no way to guess the meaning of some engine failure LEDs if you have never seen a car before.
It's about usability design. The airline website has been carefully designed to guide inexperienced users.
In the same way TUI can have guided "conversations" that are often easier for complete beginners, and become less verbose over time, as needed.
If everything is ran like a gig economy then simple and wizard like interfaces are a must but for long running companies with long term staff it probably will show less efficient over time although no one will probably measure that in most companies.
A lot of projects we did were web interfaces on top of DOS or terminal projects; usually the companies did not want to replace the legacy because their seasoned employees who basically made all the money for them were very used to the old system. But now short term hires could do some specific tasks as well via the web interface.
My local (tiny) bank went from TUI->GUI->TUI because the, again decade long employees who train their colleagues and follow ups, found it awfully inefficient with all the wizards and forms spread out over multiple pages and design elements where more option buttons could have been. It's not a contest either; for most cases a carefully crafted GUI works better; in some cases, a TUI or very dense (considered ugly) GUI works better. I miss the Expert Mode button in web applications.
Unfortunately, as a company developing POS systems, you can't just tell your customers that.
You're right on the minimal taps thing though. It shouldn't take more than 3 taps to send a basic order through (e.g. a beer).
For most users in a professional setting, they will spend far more time as an experienced user than they will as an inexperienced user. Why optimize to the first 6 months or so of a persons job, when they might work there for years, or even decades?
Apart from low skill jobs, there's also seasonal work. For example fruit picking and packing. There's only 1 or 2 months a year that they're operational, so it makes sense to optimise those systems for inexperienced users.
Sure, there will be some who work every year for decades, but there will also be a lot of seasonal workers who only ever work one or two seasons.