Hacker News Reader

Comment by nayuki | Hacker News Reader

> Every IBM product I've ever used is universally reviled by every person I've met who also had to use it

During my time at IBM and at other companies a decade ago, I can name examples of this:

* Lotus Notes instead of Microsoft Office.

* Lotus Sametime Connect instead of... well Microsoft's instant messengers suck (MSN, Lync, Skype, Teams)... maybe Slack is one of the few tolerable ones?

* Rational Team Concert instead of Git or even Subversion.

* Rational ClearCase instead of Git ( https://stackoverflow.com/questions/1074580/clearcase-advant... ).

* Using a green-screen terminal emulator on a Windows PC to connect to a mainframe to fill out weekly timesheets for payroll, instead of a web app or something.

I'll concede that I like the Eclipse IDE a lot for Java, which was originally developed at IBM. I don't think the IDE is good for other programming languages or non-programming things like team communication and task management.

View on HN

The green screens tend to be much quicker and more responsive than the web frontends that are developed to replace them.

I've seen a lot of failed projects for data entry apps because the experienced workers tend to prefer the terminals over the web apps. Usually the requirement for the new frontend is driven by management rather than the workers.

Which is understandable to me as a programmer. If it's a task that I'm familiar with, I can often work much more quickly in a terminal than I can with a GUI. The assumption that this is different for non-programmers or that they are all scared of TUIs is often a mistaken assumption. The green screens also tend to have fantastic tab navigation and other keyboard navigation functionality that I almost never see in web apps (I'm not sure why as I'm not a front end developer, but maybe somebody else could explain that).

I'll defend green screens all day long. Lots of people like them and I like them.

Everything else you listed I would agree with you about being terrible and mostly hated though.

I second the TUI argument here.

Back in ... maybe 2005 or what, in our ~60 people family business, I had the pleasure to watch an accountant use our bespoke payroll system. That was a DOS-based app, running on an old Pentium 1 system.

She was absolutely flying through the TUI. F2, type some numbers, Enter, F5 and so on and so on, at an absolutely blistering speed. Data entry took single-digit seconds.

When that was changed to a web app a few years later, the same action took 30 seconds, maybe a minute.

Bonus: a few years later, after we had to close shop and I moved on, I was onboarding a new web dev. When I told him about some development-related scripts in our codebase, he refused to touch the CLI. Said that CLIs are way too complicated and obsolete, and expecting people to learn that is out of touch. And he mostly got away with that, and I had to work around it.

I keep thinking about that. A mere 10 years before, it was within the accepted norm for an accountant to drive a TUI. Inevitable, even. And now, I couldn't even get a "programmer" to execute some scripts. Unbelievable.

Not just accountants. I remember watching fully “non-technical” insurance admin / customer service people play the green screen keyboard like they were concert pianists. People can cope with a lot when they have to.

There is a learning curve, but not coping. One of the crest things with terminal: with experience one can type ahead, even before the form fully opened one can type data, which is queued in the input buffer and work efficiently. In a modern GUI application a lot of time is wasted with reaching for the mouse, aiming and waiting for the new form to render. That requires coping with it

I had to interact with a windows software which allows you to collect data with a digital form. We used it to digitize paper based survey by mapping free form question to a choices list.

The best oart was that it was entirely keyboard driven. If you can touch type, you can just read the paper and type away. The job was mind numbing, but the software itself was great.

Case in point: the aforementioned accountant obviously hated the new GUI-based app, exactly because of what you said. Aiming the mouse, looking for that button, etc. slows you down.

It doesn't have to. The tab order seems shortcuts are there and very usable... if anyone bothers to implement them.

Not only implement, but implement them consistently and making users aware.

Consistency is a thing. Old windows apps often followed a style guide to some degree, that was lost with web (while it's also hard, as styleguides differ between systems, like Windows and Mac) and wasn't ever as close as Mainframe terminal things where function keys had global effects.

Indeed. One of the things I keep having to tell younger people is: “webapps have no HIG!”

All of the major platforms have a HIG that tells developers how to maximize the experience for users. Webapps have dozens of ways to do things like “search”. Those who never developed for a platform with a HIG do not value it and keep reinventing everything.

In a native single-threaded UI, you can type ahead too. But it doesn't work on the web unless the page effectively reimplements an input queue.

I worked at Best Buy as a high school teenager just before they switched the green screens to some GUI monstrosity. Everyone in the store had to learn how to use the green screens (sales people, cashiers, techs, stockers - everyone) and after a few weeks / months you would get CRAZY fast.

A few years later in college I worked there again and by that point they'd transitioned to a much slower GUI that basically just wrapped the underlying green screen system. The learning curve was slightly better, but it wasn't nearly as fast.

Purpose-built mainframe-based TUIs were amazing. We lost a lot in pursuit of colored pixels.

I wouldn't say, cope, the green screen stuff has predictable field input, and predictable rules around selecting elements.

Despite its obvious downsides, for people who do regular form input and editing, it's often better than the flavor of the day web framework IMO

I mean, I wouldn't choose to use it, but I get it

I was at a ticket window buying concert tickets a couple weeks ago and was surprised to see the worker using the Ticketmaster TUI / Mainframe interface. She flew through the screens. The same experience on the Ticketmaster website is awful.

Things have changed back though - the CLI is hot again at-least amongst developers.

I find it ironic that we developers prefer to use CLI because it's quick, efficient, stable, etc., but what we then deliver to people as web apps is quite the opposite experience.

It's what the default is. TUIs default to fast, stable, high-information-density, so you have to real work to make them otherwise. And I say this next part as primarily a front-end developer the past few years: web apps default to slow, brittle, too-much-whitespace "make the logo bigger" cruft, and it takes real work to make them otherwise.

At the end of the day most people are lazy and most things, including (especially?) things done for work, are low quality. So you end up with the default more often than not.

Easier to sell the initial impression for "modern" web apps (shiny, easy-to-learn, low-skill-ceiling) vs the actual performance of TUI/"desktop" apps (mundane, effortful-to-learn, higher skill ceiling).

Maybe someone has examples of web apps made for also a high skill ceiling?

I've heard Linear, Superhuman does something like that while maintaining a nice interface, but I've never used those

in my experience, many managers tend to try to dumb products down as much as possible, to make it work for the most people. the problem is that this, together with the usual bad ui/ux, makes the product inefficient to use, especially for power users.

then, every couple of years, a startup tries to carve out a niche by making a product that caters to power users and makes efficiency a priority. those power users adopt it and start to recommend it to other regular users. this usually also tends to work quite well because even regular users are smarter than expected, especially when motivated. thus the product grows, the startup grows and voila, a tech giant buys it.

now one of the tech giants managers gets the task to improve profits and figures out, the way to do this is to increase the user base by making the product easier to use. UX enshittification ensues, the power users start looking out for the next niche product and the cycle starts anew.

rule of thumb: if the manager says "my grandma who never used a computer before in her life must be able to use it", abandon ship.

An application I used to deal with was similar, but with a somewhat quirky developer, who would deliberately flip between positive/negative confirmation questions, e.g.:

- Confirm this is correct? (Yes=F1, No=F2) - Would you like to make any changes? (Yes=F1, No=F2)

And maybe sometimes flip the yes/no F-key assignments as well.

In theory this was done to force users to read the question and pay attention to what they were doing, in practice, users just memorized the key sequences.

Ah just randomly pick between F1 and F9 for the two questions and don't necessarily put them in order. Yes=F7, No=F3

We had a tower of bable collapse, when we switched to web UI. We gained a million things and lost a million things. There was an era from around 1985 to early 2000s, where a large majority of applications had a (somewhat) consistent UI, based partially around MS-Windows, partially around some IBM 'common ui' design guide principles. The hall-marks of it was - keyboard navigation was possible - mostly consistent keyboard nav - common limited set of UI controls with consistent behaviour - for serious applications, there was some actual thought related to how the user was supposed to navigate through the system during operation (efficiency)

Post-web and post 9/11, where web browser UI has infested everything, we are now in a cambryan explosion of crayon-eating UI design.

It seems our priorities have been confused by important things like 'Hi George. I just noticed, that for the admin panels in our app, the background colours of various controls get the wrong shade of '#DEADBF' when loading on the newest version of Safari, can you figure out why that happens?'. 'Oh, and the new framework for making smushed shadows on drop-downs seems to have increased our app's startup time on page transitions from 3.7 seconds to 9.2 seconds, is there any way we can alleviate that, maybe by installing some more middleware and a new js framework npm module? I heard vite should be really good, if you can get rid of those parts where we rely on webpack?'

These days most web apps aren’t written to take advantage of the browser’s built-in tab navigation, and unless the dev is a keyboard user, they don’t even think to add it. This is largely the fault of React reinventing everything browsers already have built in, and treating accessibility as an afterthought. Bare metal web apps written in straight-up HTML do have decent tab navigation. They’re still not as snappy as a green terminal app, though. My first summer temp jobs during college were data entry, in the era when you might get a terminal app or a web app, and the old apps invariably had better UX.

>The green screens tend to be much quicker and more responsive than the web frontends that are developed to replace them.

Agree! Back in 2005, I was involved in a project to build a web front end as a replacement for the 'green screen' IBM terminal UI connecting to AS400 (IIRC). All users hated the web frontend with passion, and to this day, I do not see web tech that could compete in terms of data entry speed, responsiveness, and productivity. I still think about this a lot when building stuff these days. I'm hoping one day I'll find an excuse to try textualize.io or something like this for the next project :)

This only matters if "quick and more responsive" is the only thing that matters. Yes of course you can enter payroll timesheets on a TUI if you spend days/weeks/months gaining that muscle memory. The same way you can edit in vim much faster than vscode or Eclipse if you spend weeks/months/years gaining that muscle memory.

The fact that someone who has been doing it for years can do it faster is obvious, and pretty irrelevant.

Take someone who has never used either, and they'll enter data on the web app much faster.

You don't see keyboard nav in most web apps for similar reasons. First-time users won't know about it, there's no standard beyond what's built-in the browser (tab to next input, that kind of thing), and 90% of your users will never sit through a tutorial or onboarding flow, or read the documentation.

For a work app doing data entry, there is supposed to be training for users, because it's somebody's job to use the program consistently all the time everyday.

I would agree with you if we were talking about a customer facing webpage or something. But an app for say an accountant? That should be a TUI or as fast as a TUI. The workers are literally hired to get over the learning curve and become fast with the app, so it's not as big a concern if first-use is more difficult. You arent trying to sell them a product and drive higher percentage click through.

I 100% agree with you for applications for say online shopping. Those should prioritize new user experience over long time user efficiency probably.

Are these really at odds with each other? You can have keyboard and click nav for any app.

Is there a good tuinfor web?

IBM eventually figured out that these products were terrible too, even if they saved money on paper; sold the Rational/Lotus/Sametime teams to an Indian competitor, and discontinued usage internally (I think, it's a big company).

There are people even today who want Lotus Notes back, still mourn its loss.

huh isn't it funny when you dogfood but instead of food it's... nvm

But yeah some elements of that list have convinced me to steer very clear from any products from that company

Heh. I worked on the Mac version of ViaVoice. I joined as I was already an expert in AppKit and Obj-C.

We were given old Macs running Classic to run Notes so we had two computers. One being MacOSX. Notes was the biggest pile of crap I’ve ever had to use. With one exception…

On the OSX box we were happily running svn until we were forced to use some IBM command-line system for source control. To add insult to injury, the server was in Texas and we were in Boca Raton (old PC factory as it happens). The network was slow.

It had so many command-line options a guy wrote a TCL for it.

Adding to that was the local IBM lan was token ring and we were Ethernet. That was fun.

Can we add DOORS to this list please?

I have no idea how/why IBM of all places developed or sold this software but it badly needs to die in a fire.

Database technology which would seem outdated in 1994 with a UI and admin management tools to match.

DOORS is/was a requirement management tool and frankly speaking was crap but I have never seen another software as good and comprehensive in requirement management.

I expect it to be still used in aviation or army related domain, maybe pharma.

> I don't think the IDE is good for other programming languages or non-programming things like team communication and task management.

It works great for Python and C++, honestly. If you're a solo dev, Mylyn does a great job of syncing with your in-code todo list and issue tracker, but it's not as smooth as the IDE side.

However, its Git implementation is something else. It makes Git understandable and allows this knowledge to bleed back to git CLI. This is why I'm using it for 20+ years now.

I remember using Rational Clear case at my first job. Yeah, in that case count me in on the list of people that revile the IBM products they've had to use.

Could this be an employee retention strategy? Making people use bad tooling, so that they can be proud of knowing the bad tooling no one else in the industry uses and when those people feel like looking for something new, "no one values their knowledge" in those obscure tools, so they stay at IBM?

Eclipse was nice but WebSphere Application Developer was pretty horrible - I'm not sure how they achieved that! (WSAD was/was built on Eclipse)

If you used SameTime with Pidgin, SameTime didn't suck. But maybe that's because Pidgin is awesome, and not because of SameTime.

Yeah I was just about to say this -- I used Sametime via Pidgin (I think it may still have been called Gaim back then) on my work Linux machine and it was actually quite nice.

My favourite Sametime feature within Pidgin was, well, tabs (I can't remember if the Windows client had tabs as well..?), which was revolutionary for an IM client in 2005.

But my secret actual favourite feature was the setting which automatically opened an IM window /tab when the other person merely clicked on your name on their side (because the Sametime protocol immediately establishes a socket connection), so you could freak them out by saying hello even before they'd sent their initial message.

And what was that thing they used for email?

You mean Lotus Notes?

ClearCase. You just triggered my PTSD!

Reply on news.ycombinator.com