Comment by jwilliams | Hacker News Reader

Comment by jwilliams | Hacker News Reader

Parent Full thread

I was all primed to disagree with this article, but it's a pretty well placed piece.

I think an interesting pivot occurs when your start hitting the limits of working memory. Posting a photo is usually pretty immediate and doesn't max out your working memory.

Many years ago, I worked on a project to convert a Loan Application system from a VT100 "green screen" terminal to a Web Interface.

The Web Interface was actually pretty good, but it required too much navigation and too much working memory. We tried to reduce the number of clicks, but then the pages themselves became too slow and confusing.

Finally I got to see someone using the old VT100 app. It was blistering fast, and they supplemented it with codes written on a piece of paper. Crude and it required training, but it was far superior. The main thing was navigation. The codes on the paper were enough of a picture to offload that bit of cognitive processing... With the web interface, as soon as you clicked and had to pause or search - you'd lose the thread.

Unfortunately too late for that project, but a good lesson for me.

Knowing what you now know, what tricks would you use to make the web interface more like the VT100?

My guess would be keyboard navigation, and entering numbers as codes instead of clicking radio buttons.

It's important to remember that discoverability in an interface doesn't matter as much when you can train the workers. Not everything has to be intuitive, especially when you control training (and you can trade eventual speed for immediate understanding).

This is the basis for all the VI/Emacs users who claim to be more productive than in a visual editor/IDE.

I did come up with a prototype, but it went a bit of a different direction.

My theory was the biggest issue was the UI enforced a workflow. Most likely the banker is given a big pile of documents, then they work through it. One confirms your address, the next your income, the other is some other piece of evidence.

I particularly noticed they would be sitting there shuffling back and forth between the paper & then shuffling back and forth on the interface. It caused a lot of rework, and required you to remember where you were at with both.

The Web Interface was waaay to rigid. Want to add a party - you need to enter their name and work details. So you'd have to track down that information. Even if it wasn't 100% required to get a provisional. You could enter whatever value you wanted for the income at this stage, so why force the banker to enter work address and work phone? They can do that at final docs when you're required to provide a payslip (for example!).

Paper & terminal worked because you could move quickly between disconnected parts. Enter the person's name and DOB. Then jump to income. Back to their home address. Over to some kind of KYC information, etc, etc.

So I came up with something that was a bit more of a mind-map. Each node indicated if it (and it's subnodes) were complete or not. You could jump around and enter data in whichever order you liked & not have to think too much about what we left to do. Then the nav was about quickly moving up & down the tree (keyboard being a big factor).

It focused on making the data capture piece much more organic & goal-based. You only needed to enter discrete information to get a provisional, so use flags to tell the user what's needed. Then they can populate the space in any order they like.

Was waaaaaaaaay to weird for a conservative bank to consider :-) So I never really got to try it out. Would have been interesting to see if it made any difference.

Having done similar things, I agree.

1) Make sure that the UI fits with the order they have data on the bits of paper. 2) Let them data in any order they like, and give them a big "Validate" button they can press to check whether what they've entered is all coherent. (Don't check as they go along, or the validation markers will confuse and distract them.)

...or more generally the CLI vs GUI argument

I like your analogy of "working memory".

Oh..whoops. I suppose "working memory (machines)" is an analogy to "working memory (humans)", so your use of "working memory" actually directly refers to humans, and isn't an analogy at all :)

Reply on news.ycombinator.com