IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.
Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be.
EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.
It's more than just an "optimization" that is making UIs on these plenty-fast processors so slow, it's a large scale failure of software engineering, building slow layers on top of slow layers.
The processor is not the reason for slowness, and we've had absolutely responsive UIs not just 10 years ago, but 50 years ago too. The actual reason is economic: cheap engineering. Using freely available components not well suited to embedded devices, writing layers using scripting languages because it's easy, treating the problem as solved when the functionality is there without regard to the speed.
Yes, we won't again have the responsiveness we had 30 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.
> we won't again have the responsiveness we had 30 years ago.
Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response.
Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip.
> the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over.
I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.
W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today.
With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels.
Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.
That's all true, and thanks for an insightful comment!
I would just add though that it's easy to frame things in a way that makes it seem harder than it really is to maintain responsiveness. For example, while yes caching makes guaranteeing exactly repeatable timing a problem, that's an issue at the nanosecond/microsecond level, and not really a problem at the millisecond (human perception) level at all. Today's hardware doesn't have issues maintaining 60hz unless the software isn't even trying.
Another counter-example would be that while yes, browsers and desktop UIs are doing compositing and don't have direct access to the pixel buffer, the compositing is actually done on the GPU via low-latency commands. Direct access to the pixel buffer would actually be much slower than what we have right now. The browser has no trouble responding and rendering at 60hz unless you do things that cause more than the ~16ms of compute you have time for. Triggering page reflows will do that, but compositing an animated WebGL canvas over something else on the page is plenty fast.
For example, Lenovo Carbon X1 4th gen running Windows has about 5x the latency of an Apple 2e.
Just in case you were thinking this is perhaps a counter-example to what I said, I think it's the other way around, it very much supports my claim. The processors have (obviously) gotten faster, and yet for some applications latency has seemingly gone down. Why? Software and requirements are the reason, not hardware.
Terminals also are not an example of the "best systems" in terms of latency. You'd be much closer if you looked at video game latency, or tracked industrial applications that have low latency requirements from the start. The whole reason terminals have gotten slow is that they aren't trying to go fast.
Quite a few of today's most modern terminals have recently added performance as a feature, started rendering with the GPU, and quite predictably, they are restoring super fast response times to our terminals. iTerm2 would be an example of this.
Performance is always a business decision. Most people don't want to pay for it.
Anyway, you mentioned phones: 16ms from touch to response on screen? That's hard for me to believe and I'd love to read up on that, if you got any sources. The ones I've found were not that great but don't paint such a good picture. [0] is an article claiming touch sensors scan only once per frame, aka 16ms at the time. [1] claims ~85ms to response on an iPhone 4, ~55ms on iPhone 5. How were you able to easily beat those by such a margin?
[0] https://www.anandtech.com/show/9605/the-ios-9-review/9#Input...
[1] https://www.cnet.com/news/iphone-5-touchscreen-2x-faster-tha...
Nowadays you have 120hz scrolling on the ipad and the very fast responsiveness of things like the apple pencil, which shows you that responsive hardware and software is definitely possible.
There is no good technical reason for slow UI elements in 2019.
Windows XP on a Pentium 4 was snappier than Windows 10 is on an i7 today.
It's just that modern software is garbage. That's all.
This app ran on a regular computer running normal Microsoft Windows 95. It wasn't terribly complicated, but it also wasn't simple. It accessed a database over the wired network for most everything it cared about doing.
It took some thought and care, but it wasn't impossibly difficult to ensure that the app was always highly responsive.
I think it comes down to priorities. I worked closely with the doctors who were actually using this app on a day to day basis, and working with an app that didn't slow them down was quite important for them.
I cringe every time I see a laggy but 'nice' looking interface. I'd rather see a wireframe with just text, it will still be more useful than a button I can never trust.
But over time things degrade. I don't know why, but every year or so I have to format the internal SD card to keep the OS in shape. If I install too many apps which run in the background the RAM gets crowded and everything starts lagging.
And finally, the app itself is not as optimized as it should be, so that when I use it with the data I enter during a year or so, there are some steps which take a few seconds (rendering a list with >300 items/DOM nodes). By the way, a 'couple of seconds' is unacceptable from a UX perspective.
So this is just one example where you can have a 100% good experience but also a very degraded experience with the same hardware and software, due to different factors (from OS degradation to awful O(n) optimization).
I'm reminded of the discussion the other day about military procurement ignoring software. Prototype the UI first, then choose a processor that's fast enough.
A friend's sister is a doctor. We happened to be visiting her hospital the week they were rolling out a new system. If if I recall rightly, her hospital was part of a multi-hospital company, and they were developing it in house. The developers were in some location distant to the hospital, and my doctor pal had never met anybody who worked on it.
From my perspective, the thing was a disaster. Not only was it laggy as hell, but the interface was dumbfoundingly bad. For a doctor to prescribe something for a patient, the would have to pick the medication name from an absurdly long drop-down. Then they could type in a quantity and pick a unit from a pulldown that had mcg, mg, g, and kg choices. Once that was entered, it would show up on the reports nurses would use to give medication. However, they didn't have the field sizing right on the reports, so 100 mg would turn into 10 mg. It was only nurse experience that kept people from getting dangerously wrong doses of their medication.
The whole thing was hot garbage of exactly the sort made in a big waterfall process by developers who never met the users and never saw them in action. I'm sure every bit of it was technically to spec, but I'd be amazed if nobody died from it.
[1] https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and...
If the progress bar doesn't differentiate which stage it's in then it's purpose is mostly just to let the user know it's doing something.
That has always stood out as one of the more impressive engineering feats I've seen.
In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration.
The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays.
I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.