12 ms·
Almost everything on computers is perceptually slower than it was in 1983 (2017)
- umvi 6y agoBecause each successive generation of programmers grows less efficient with the resources available. A new programmer in 2020 probably treats RAM and CPU as near infinite resources. Hence you have super simple 2D games that are 900MB in size popping up in /r/Unity2D and webpages weighing in at 15 MB and, etc. They just don't know those are unreasonable sizes because they've never tried to make a 100KB game/website.
- The_Colonel 6y ago"unreasonable" is totally arbitrary. 30 years ago 100 KB for simple 2D game would be considered unreasonable.
- npongratz 6y ago30 years ago was 1990. I remember 100KB being fairly reasonable for a 2D game in 1990, even when having to download it with a 1200 baud modem.
- The_Colonel 6y agoOk, looks like I live still in 2010. Make it 40 years :D
- u801e 6y agoThere must have been a large increase in game size between 1990 and 1995. I remember games like Lemmings 2 the tribes and sim city 3000 requiring multiple floppy disks.
- umvi 6y agoNo, 100KB is a bad estimate. Most SNES ROMs are 1-3 MB, though NES ROMs are in the KB range.
- draw_down 6y agoAlright gang, let’s put our heads together and figure out how we can blame it on JavaScript
- tannhaeuser 6y ago(2017) so it's not relevant anymore ...
- oarsinsync 6y agoIt's definitely from 2017, and it's definitely still relevant. My terminal lags more today than it did 10 years ago.
- blandflakes 6y agoIt would only be irrelevant due to age if something had changed significantly between 2017 and 2020.
- jtbayly 6y agolol. I can't believe people didn't get the sarcasm.
- rbrtl 6y ago> one of the primary reasons computers were created was to cross reference data. that is nearly impossible in most software now. Because the data became the hotly-guarded commodity of the "software" companies.
- quattrofan 6y agoHe's right and 100% on Google maps it's awful other than just looking for an address, any kind of planning like maps used to be used for, its shit.
- deleted 6y ago[deleted]
- flatfilefan 6y agoMaybe we could start the revolution by doing away with the caps lock?
- MaxBarraclough 6y agoIsn't that the reason FORTRAN code is so fast?
- azangru 6y ago> perceptually slower Well, interfaces are perceptually very different than they were in 1983 too...
- u801e 6y agoYes, like typing a message in Slack takes longer to render on screen (at least a half second delay in some cases) than typing the same message on a Commodore 64.
- deleted 6y ago[deleted]
- spottybanana 6y agoStatement simply not true. First example is comparing offline interface to online one - more realistic comparison would be to something like first BBS's and the experience with those was generally insanely slow. I didn't bother reading the rant because I think it doesn't make sense but is just personal "feeling" of the author. Objectively speaking computers are insanely faster and can do much more things. For exmple I use Sublime Text editor with multiple plugins and features, and all those feel instant. Also with web apps that I use 95% of time the experience is very instant-like.
- dcabrejas 6y agoTotally, I read about 10 lines and gave up becuase it's just a massive angry rant
- JTbane 6y agohttps://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law
- rplnt 6y agoDon't know about 1983, but a lot of software is definitely slower than it was 10, 20 years ago. Something that used to result in 2MB application with 5MB in memory requirement is now done as half a gigabyte of resources that will spawn dozens of processes totaling at least 1GB of memory. Sure, computers are faster, but not by that much apparently. Looking at all those electron (et al) apps. Cheap to write beats user experience I guess.
- The_Colonel 6y agoI miss some concrete examples. What exactly was faster to do 20 years ago than now?
- burntoutfire 6y agoScrolling text in text editors. Was always buttersmooth on 7 MHz Amiga. Is choppy in many of today's IDEs. I get that IDE does more than a text editor, but it would be great if adding extra features would not compromise existing ones.
- The_Colonel 6y agoSo apples to oranges. Adding features will almost inevitably make software slower. Sometimes the difference is smaller, sometimes larger.
- new2628 6y agoI guess the underlying point is that in the same time period CPU speed has increased thousandfold, so you'd expect that to compensate for the few extra features that were added.
- The_Colonel 6y agoIDEs don't have "extra few features", they have massive amount of functionality added. "extra few features" would fit more to likes of vim.
- napoleond 6y agoI call bullshit. The sort of attitude expressed in this thread is important, because it pushes us forward. The author identifies real UX shortcomings with current software. Nevertheless, the assertion that "almost everything on computers is perceptually slower than it was in 1983" is patently false, and the comparison between online maps and paper maps seems almost intentionally obtuse. Yes, online maps could have even more capability and better UX than they do today. No, it is not more difficult to conduct mapping activity today than it was in the 90s. (For instance, the example given about finding interesting places to stop along a route: the 90s equivalent of that would have been a book, separate from the map, not searchable, and full of things completely irrelevant to your interests. So yes, maybe putting a mark on a piece of paper is easier than doing it in online maps, but every other aspect of that process is way harder without the internet.)
- marcinzm 6y ago>So yes, maybe putting a mark on a piece of paper is easier than doing it in online maps, but every other aspect of that process is way harder without the internet. Only if you know where on the map the place is which you wouldn't since you found it in a book. In Google Maps, I click "Add Destination" and put in the address. Drag it to the right places and it's now part of my route. On a paper map, I need to spend 10 minutes finding the address, referring to the index on the back to find the right square.
- yaktubi 6y agoYes but you’ll know and remember the route after plotting it yourself—and spatial awareness increases making you a better driver. Think of it this way: everything our phones/computers do for us reduces our ability to do the same task in the long and short term.
- mosselman 6y agoThis seems off-topic since the article is about perception of speed.
- 6y ago
- foobarian 6y ago> one of the things that makes me steaming mad is how the entire field of web apps ignores 100% of learned lessons from desktop apps Unfortunately it's worse than ignoring. It's intentionally abandoning, after years of A/B tests optimizing for revenue have found a perceptual sweet spot. Sadly for people who care about fast UI that point is way up on the sluggishness scale...
- MattGaiser 6y agoIs there a reason that is the case? What is it that makes the new Reddit UI in all its slowness nicer to people?
- celeritascelery 6y agoIt looks more modern. That seems to be the only optimization target.
- cowmix 6y agoBack in 1983, i/o was much, much slower... which slowed everything else down. Floppy drives, cassette recorders, 300 baud modems, etc.
- radarsat1 6y agoThis guy never used GEOS. :) (Ok fair enough, apparently it was 1986, so 3 years later..) https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system) https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)
- thibaut_barrere 6y agoSorry I am laughing out loud. In 1983 everything I owned was using a cassette and slow as hell. Rendering was sluggish at best.
- genidoi 6y agoI'd like to see an implementation of Google maps with a 1983 toolchain
- jfengel 6y agoWhat version of 1983 did he live through? My Osborne 1 took a minute to load Wordstar. Searching a document would take more minutes if it was longer than about 30k because it had to swap to floppy disk. Connecting to a BBS was time for a bathroom break. So were compiles. I think most of what is perceptually slower for the author is that it's a small percentage of the 40 years it took to get here. I loved my O1 but it did what little it could do very slowly. My phone in my hands right now is doing a trillion more things better and faster.
- wzdd 6y agoIndeed. Even his first example of library computers seems off. In 1998, my library was part of a small network of libraries in my city, searching the catalogue involved making network requests over ISDN, and, while impressive for the time, it was not fast. I can definitely get behind the Gmaps UX rant, but that's nothing to do with speed.
- the-dude 6y agoI remember our local library got a digitized index in the early eighties ( was card based before? I was very young ). The digitized index was a couple of touchscreen terminals, which were plenty fast.
- newsbinator 6y agoYou're right: this post would make more sense if the author had gone for 1997 or so. Not too many bathroom breaks needed for various operations.
- PJDK 6y agoIn 1997 I was doing IT classes in secondary school. One of our preferred ways to bunk of class was to ask if we could "write up our reports in the library" on the RMNimbus 186s. 15 or so minutes for the computer to boot into some kind of menu system that gave you a "press 1 to start windows 3.1, press 2 to start BBC Basic" type menu, then another 20 minutes to boot windows and then another 5 minutes to start MSWord. Write three lines and then it's time for the next class!
- magoghm 6y agoOn my Atari 2600 all games ran at a steady 60 FPS.
- deleted 6y ago[deleted]
- JulianMorrison 6y agoRandom fact: I've been playing with RISCOS on my Pi 3B+ and oh my gosh how snappy is it? Even relative to pure desktop, non-web apps. It's the last of the true 80s OSes and honestly, I feel it represents a missed opportunity. Computers used to have simplicity enough to start in seconds.
- oarsinsync 6y agoThis is from 2017. Previous discussions: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=almost%20everything%20on%20computers%20is%20perceptually%20slower%20than%20it%20was%20in%201983&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- fractal618 6y agoHere is some self realized, hypocritical advice: Either do something about it, or stop complaining.
- cromwellian 6y agoNope, not on my vic20, c64, c128 and Amiga. Scrolling was slow as hell. BBSes slow. Rerendering a full page of text, slow. GEOS slow. Disk operations hellaslow. This is an example of nostalgia goggles in action. You know how that movie you swore was amazing in your childhood sucks when you rewatch it as an adult and realize it had atrocious acting and writing?
- jansan 6y agoDisk operations? You mean loading from datasette. Using Turbo Tape accelerated loading times by a factor 10, but still waiting a minute for a game to load was common.
- treerunner 6y agoLoading data isn’t! It’s simply not possible to make a blanket statement like this. Computers today are so very different and have so many more layers than those from 1983. I recently refurbished an old Mac Plus. Of course I couldn’t leave it stock, booting from floppies was simply too ridiculous.. So it boots from Zip. Anyways, once I had this machine up and running I was quite surprised at how snappy the interface is - once everything was in place - and that’s the difference. The old interface is paper thin and has nothing going on, no asynchronous, little to no threads, it is just what it is.
- danpalmer 6y agoRequirements change. A search field in a local application opening instantly is not the same as a search field searching orders of magnitude more data on a machine thousands of miles away. Things were "faster" because so much _blocked_. Modal windows suspended applications. Now in the ~100ms it takes to open a window your computer is still doing other things in that application, in other applications, in the kernel, on other cores. We may have traded latency for _throughput_ in some cases, but that's not necessarily a bad thing, and often perceptually much faster still. Lastly much of the speed back then came from things that are not practical for security reasons now. Shared memory makes a lot of stuff possible, and quickly. Temple OS (for all the faults of the author) demonstrates that today there are still really neat (and fast) things that can be done when you don't have to worry about security at all, but unfortunately we don't live in that world anymore, and a cost of our connected world is that security must be a design principle from the outset, and there are performance costs to that at every level of the stack, whether it's memory protection, ASLR, stack canaries, SSL/encryption, process sandboxing, containerisation, etc.
- codingdave 6y agoLog into a BBS in 1983, watch the text slowly render on-screen as it traverses that 300 baud connection. Sure, we shoot ourselves in the foot with bad UX, but a long rant with a false headline and deliberately obtuse examples isn't the strongest way to make this point.
- MattGaiser 6y ago> GUIs are in no way more intuitive than keyboard interfaces using function keys such as the POS I posted earlier. Nor do they need to be. > GUIs require you to learn how to use a mouse, how input focus works, how multiple windows work, how modal dialogs work. Here is the difference. People can learn how mice, input fields, and modals work and use those learnings across products. With keyboard driven input or command lines, people need to read something to make it work. That creates a higher barrier to initial usage. I would bet that the challenge for most software is getting that user to do something for the first time and far fewer people are concerned about whether it is a good long term way to do things.
- topoftheforts 6y agoThis is a repost favorite on HN apparently Previous discussions (from oldest to newest): - https://news.ycombinator.com/item?id=15643663 https://news.ycombinator.com/item?id=15643663 - https://news.ycombinator.com/item?id=15648652 https://news.ycombinator.com/item?id=15648652 - https://news.ycombinator.com/item?id=21831931 https://news.ycombinator.com/item?id=21831931 - https://news.ycombinator.com/item?id=21835417 https://news.ycombinator.com/item?id=21835417 - https://news.ycombinator.com/item?id=22365795 https://news.ycombinator.com/item?id=22365795
- shadowgovt 6y agoI can only assume HN has a critical mass of people who weren't alive in 1983 willing to believe the headline assertion. ;)
- dijit 6y agoI had a c64 and it was what made me fall in love with computers. I tried my friends recently and it really did feel like a joy- it’s basically a toy now, impossible to use for anything meaningful (even IRC). It’s hard to convey in text the “feeling” of immediacy and low input lag. I suppose it’s similar to how some gamers talk about fps, it feels immersive, like the machine is in-tune with you. It genuinely feels like something mechanical that you’re interacting with rather than something that “will get to it”. It’s very subtle but it’s there.
- zadler 6y agoI get that feeling when I switch out of X11 to a TTY.
- taborj 6y ago> impossible to use for anything meaningful I would posit that our definition of 'meaningful' has dramatically changed since the C64 days. Nowadays, if you aren't doing it online or collaborating with someone, it's not considered 'meaningful.' Back in 1983, this was not the case. I think a better comparison would be to do the things a C64 was good at on a modern computer with modern workflows, and see which is easier/faster/more satisfying. I'm talking word processing, gaming, printing, etc. I bet the C64 wins. (Side note: you can get that C64 online and onto IRC or a telnet-enabled BBS; there are plenty of products to do that)
- cheschire 6y agoIt's because in 1983 everyone was riding the white pony
- marcinzm 6y agoI don't get his maps example. It's like he's expecting google Maps to contain all the information he'd ever need for a trip. If it did he'd probably complain the UI was too complicated and heavy handed. He compares it to a paper map but a paper map doesn't have all the information. You used a book to supplement it. Same way with Google Maps you can use TripAdvisor, a separate Google Maps tab, Yelp, etc. The Google Map you use to plot your route is just for that, you put in the addresses and it gives you a route. The research is done elsewhere just like it's always been.
- marcus_holmes 6y agoI used to use UI's like the ones he talks about. And yes, you can get quick at it. But OMG they took forever to learn. And if there wer more functions than could map onto function keys that would fit in the bottom row, then stuff got hidden. Cue people yelling across the room "how do I get into the stock reorder menu?","F3 for stock, then F2 for management, then F5 for reorder", "thanks!" (no help window, or tooltips, or anything). This isn't "easy", and it's certainly not discoverable. And it's only fast if you know exactly what you're doing.
- chosenbreed37 6y ago> This isn't "easy", and it's certainly not discoverable. And it's only fast if you know exactly what you're doing. True. Would it be fair to assume that users would work with a subset of the commands available? If so, once they got used to those it would have been plain sailing 80%-90% of the time. If I'm not mistaken I've seen a few those DOS programs recently in different settings. The folks using them seemed to be getting along just fine.
- temporallobe 6y agoThis mostly sounds like the ramblings of a frustrated user for a particular application who is projecting this to the entire domain of modern applications. The thing is, they’re not wrong. I worked on a multi-year multi-million dollar project to replace an aging greenscreen US Federal government legacy system (originally written in Natural / Adabas). The replacement was supposed to have a modern web application front-end with J2EE middleware and a modern relational database (Oracle IIRC). Literally tens of millions spent, but the project was cancelled. Why? First of all, there was a nasty project management issue I won’t go into now, but the more important problem in my opinion was that basically it sucked. The application was extremely slow and cumbersome, response times were unacceptably long. Users complained they actually preferred the old application because it actually worked and actions were instantaneous. There were key combinations that meant something, etc. In addition to the usual incompetence that abounded on projects like these, my conclusion was that far too much time was spent on the infrastructure and not enough on UI/UX. I am a solid UI developer with no official UX background but I have enough experience to know what pissed users off, and the application design had these issues in droves. All of this also revealed just how much abstraction we use in modern application development. The old greenscreen apps were very interconnected and were run on “bare metal” systems such as mainframes. An action you took immediately got stored in the database and lookups were lightning quick. The modern equivalents to these go through many, many layers of processing that never before existed. Modern application development is hard, really hard. Sure it’s easy to throw together an app with modern development tools, but once you want to make anything Enterprise-grade, customizable, reliable, and actually usable, it takes time, dedication, and talent. Don’t ignore UI/UX.
- jonnypotty 6y agoAppreciate what you wrote here, made me think, basically people can learn a difficult interface and work with it as long as it responds. You never get over a ui that is slower than you are. There is no excuse, apart from to say that it's too difficult so we had to use electron and we know it's slow but what else are we meant to do?
- leeter 6y agoThis reminds me of something Joel Spolsky said awhile back[1] "Never Rewrite from Scratch". I stand by that too.. even if it's a legacy mainframe app it's probably better to use strangler pattern if you really need to extend it an the development platform doesn't suit the need. I'm also reminded of the SABRE rewrite that had similar issues where agents got massively slowed down by the removal of the 10key navigation that ruled the old system and they had to add it back as emulation. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- JoeAltmaier 6y agoHm. I remember Windows 2.1 would composite the screen image right on the tube. You could watch it paint the components in bursts - a window background with holes where the components would go (with other windows showing through the holes!) then components would populate then data be drawn. Could take a second or two. But sure sometimes programmers take advantage of speed and space, to do more. Which can look like "the same thing got slower". But its hardly the 'same thing', since now you can have HTML renderings inside components etc. Takes a moment to reconcile code across the web as well. If we amortize the time it took to update an app from floppies (hours?) to each execution, compared to modern self-updating code over the net we'd see a fairer comparison.
- theandrewbailey 6y ago> Hm. I remember Windows 2.1 would composite the screen image right on the tube. You could watch it paint the components in bursts I wish there were more things like that. I would rather see computers work than see some fancy animation that is there only to look pretty, but ultimately ends up wasting time.
- mmaunder 6y agoI was programming on an Apple IIe in 1983 and this post is ... weird. Firstly some things on the Apple were crazy slow. Gaming for example. And the PFS database system when doing any meaningful work. And disk access was a killer on those burping floppy drives. The Apple has no network, LAN or WAN. I think a modem may have been available but most people didn’t have that. All AJAX apps use network. And you will never get away from some amount of latency, even for edge apps. Which means that for certain things, physics dictates that Apple IIe will always be faster than AJAX. Much of the rant isn’t even related to the comparison. I’m also curious about the author’s broken shift key.
- rsecora 6y agoThe experience of the 80s was slowness, things were so slow that it's unimaginable now. So unimaginable that we don’t remember the feeling anymore. The experience was so slow, that you can play another game while loading [1]. Namco even patented "playing games during load” by 1987 [2]. As an example, I have fond memories of my C64 tape loading Hunchback [3] ... while watching "V". A single tape can take one hour if it fails in the middle and you need retries. All those waiting times were order of magnitude of what a common toddler will expect today. We were so relieved when the fast loaders appears [4] or when a 1541 arrived home [5]. And then we were so frustrated when the 1541 was only 300bytes/s instead of the 300bits/s of the Datasette. The scenario in Xenix or PC-DOS loading from 8" floppies was similar. I'm not arguing that now are better times, I’m arguing that in the 80s we have the best for the time, and those were good times to remember. [1] Mini Games: https://en.wikipedia.org/wiki/Invade-a-Load https://en.wikipedia.org/wiki/Invade-a-Load [2] Nanco patent: https://patents.google.com/patent/US5718632A/en https://patents.google.com/patent/US5718632A/en [3] https://en.wikipedia.org/wiki/Hunchback_(video_game) https://en.wikipedia.org/wiki/Hunchback_(video_game) [4] https://en.wikipedia.org/wiki/Fast_loader https://en.wikipedia.org/wiki/Fast_loader [5] https://en.wikipedia.org/wiki/Commodore_1541 https://en.wikipedia.org/wiki/Commodore_1541
- bluedino 6y agoWe replaced an AS/400 (well, iSeries) accounting/inventory system with the hot new web-based ERP from DATABASE_CORP. People had been using this system for over 20 years. Muscle memory from hitting Tab, Tab, F2, enter...that pulls up the inventory detail. F5, 3, 6, Tab, that brings up the wholesale price. Now, with the 'better' system, people have to move the mouse up to Lists, Items, wait for the Item page to load, then choose the item the want, wait for that to load, then click on the Inventory or Pricing tab, wait for that to load. They can save a few steps by typing 'item: 25630' in the search bar. But of course it loads about 5x slower. You could also hit PgUp/PgDn to cycle through items. Now you have to click the little arrows at the top of the page, and the view resets each time, so if you were on the Pricing tab, you have to click on that again. The old system left you where you were. Sure, the new system has all kinds of advantages in other places, but to most of the internal users, you just ruined their world and they hate the unfamiliar, slower system that costs millions of dollars.
- jcwayne 6y agoThis seems to be a common problem with web-based business applications. Little, if any, consideration seems to be give to user efficiency. I consider that a critical part of UX, but I seem to be in the minority.
- root_axis 6y agoI remember waiting at least 8 minutes going from boot to a usable desktop on windows 95. Opening up IE completely froze the computer for 2-3 minutes while it churned away. Minimizing mech warrior would take 45 seconds as I literally watched the desktop be slowly repainted pixel by pixel. Installing 400mb daggerfall took all of a half hour. Applying an image filter in paint shop pro took 15 seconds at a time... the idea that computers are perceptually slower today than in the 80s is just totally false. I get the sense that people parroting this kind of nonsense are simply invested in an ideological narrative that means to disparage the contemporary programmer as lazy or uninformed because they grew up at a time when you didn't have to manually manage menory... as if that was some kind of computing golden age.
- marcosdumay 6y agoThat's the thing, 95 was not in 83. In 83 you'd boot into the computer ROM or an OS floopy. The floppy completed in a few seconds, for the ROM it's meaningless to talk about wait time. You wouldn't install software. You would load it from a tape, a floppy or a ROM cartige. For the cartige it would, again, be meaningless to talk about wait time. The floppy would load faster than a 95 program from the hard driver (thanks to bloat), and the tape would take minutes. No program would trash your system, because the memory management algorithms that are subject to trashing was only available for mainframes, and people didn't have disposable disk space anyway.
- jdmichal 6y agoMost of this is a rant against Google Maps UI. I'd like to do a shout out to Bing Maps, which does keep a list items as you look them up. You can swap between them, and see all of them on the map. Also, I find the Windows 10 app (called Maps) very smooth.
- bitcurious 6y agoThere are two things happening - one is straight up bad UX, especially for users with poor internet connections. This is called out in the search example, and is fixable. Another is a little harder - if were a professional who used a computer in 1983, you probably only used one or two programs. This means that as a developer, you could reasonably expect your users to become power users, and thus design for them. This is no longer the case for most programs, so you see slower, less information dense, but more intuitive software succeed. Exceptions to this are software which only power users use - 3D modelling software, video editing, etc. These are still fast fast fast.
- jrockway 6y agoI thought this was going to be a rant about how slow modern keyboards are with long debounce cycles and waiting for the USB poll interval. Or if not that, how every change to the screen is buffered and waits until the next vertical sync before being drawn. Those things are quite noticeable once you start looking for them (you can thank me later!) But instead it's "when I write an email to someone, the software looks through every person I've ever corresponded with and suggests an email from that list". The 1983 version of that was waiting 5 minutes for a bounce because you typo'd the address. Now it's taken care of for you in a few hundred milliseconds. Not that bad. As for autocomplete being slow... there isn't really a good reason for this. I've seen PHP apps that add a solid 100ms to every request because they are built in the one-process-per-request model, and the framework does a lot of setup and teardown for every request regardless of whether or not the request uses those resources. Obviously, don't do that. There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms. Websockets and HTTP/2 eliminate TCP setup/teardown overhead. Things could be faster, for sure. How much extra would you pay? Most customers wouldn't pay extra for a faster app, so apps aren't faster. As for why people make mouse-based apps instead of TUIs... it's because the average person has to interact with tens or hundreds of pieces of software on a daily basis these days. If they all work differently, people will never use them. They ask for and prefer fast to learn but slow to use. So developers build on a common set of idioms, even if they are slow in the long run. You'll note that "power user" software is often hard to learn (think Emacs, Vim, Blender, Solidworks) but quite efficient once the user has been trained. People aren't interested in doing that much work these days. Finally, business processes account for a lot of this stuff. I've been to stores that use a nice efficient TUI for their in-store pickup. But my question is: why is software with a UI even involved? You should scan my order number barcode, scan my driver's license barcode, and then hand me my merchandise. (Why even scan my driver's license. Just eat the fraud and save me 5 seconds! That's a business decision, not a software implementation quirk.) Having to navigate around to a bunch of fields and manually type that information in isn't efficient. The UI shouldn't even exist.
- altfredd 6y ago> There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms. This is a wishful thinking. You can't expect consistent 10ms (or even 100ms) response times from network-driven autocomplete. Nevermind a fixed speed of light (which already makes 10ms figure impossible for transatlantic users), you will have to account for all kinds of temporary bottlenecks in network. DNS can take a lot longer than 10ms, and many hosts use short DNS TTL by design. There are some totalitarian countries (Belarus, Great Britain etc.) that use DNS-based website blocking — each time you send a DNS request, it will have to be compared against a bunch of censorship lists. Then there is an ISP throttling/AQM, that will add small delays to each SYN packet... As result, if your autocomplete responds in under 10ms during local testing, it may take between 100ms and 900ms for most of your users.
- foobar_ 6y agoBecause pixels
- buboard 6y agoIt's weird we don't have psychometric benchmarks to capture this trend. How many times a day do you get frustrated thinking that your mouse has broken down because you clicked something and it didn't start spinning (it will be spinners of course, lots of them, and when they stop spinning you 're already fuming and banging at your screen) Can anybody point out an app that has become better at perceived feedback over time? Everything is a horrible, slow mess. And the bigger issue is: due to the choice of language/UI libraries, they are un-optimizable Incidentally, this may help explain the popularity of vim which was posted on another article. Console feedback is truly instant and, importantly, predictable. You can hit a bunch of keyboard commands on vi, and it will execute them 100% predictably even with a slow connection or high system load (of course, it was designed for that).
- ilaksh 6y agoI have an idea about an alternative web browse/protocol that is faster. https://github.com/runvnc/noscriptweb https://github.com/runvnc/noscriptweb. .. although don't have time to code it. Gemini could be pretty fast if they did not insist on TLS and new connections all the time.
- shadowgovt 6y agoComputers were much simpler in 1983.
- geogra4 6y agoDisagree about 1983. Though I would agree with maybe around 1999-2003 era. Web browsing was fast in the web 1.0 era.
- awinter-py 6y agoweb/dom based apps (web + electron) have been particularly bad for text entry there's no satisfying option for text input that doesn't come with various kinds of tricky formatting, scroll jank, periodic slowness, and general trouble the assumption that we can write sophisticated + performant GUIs on cross-platform frameworks may not be right if contenteditable didn't ship in the next v of chrome I think people who maintained CE-based tools would just shrug, assume it was a new compatibility quirk, get it working at some cost to their codebase, and move on without ever checking the doc
- deleted 6y ago[deleted]
- beart 6y agoThis rant is full of "missing the forest for the trees." One example. > On the library computer in 1998 I could retry searches over and over and over until I found what I was looking for because it was quick Now I have to wait for a huge page to load, wait while the page elements shift all over, GOD FORBID i click on anything while its loading Which completely overlooks how bad search results were 20 years ago compared to now. I would rather see the right result in 500 ms than the wrong result in 20 ms. Or to take that example even further, I can now perform that same search on my phone, anywhere, instead of having to travel to the library.
- voldacar 6y agoThere should be an OS that kills any program which doesn't respond to user input within a frame
- koiz 6y agoWhat... lol this is totally BS. Why do people make such absolute statements.
- ballenf 6y agoI think the real issue today is the unpredictability of delays even though computers are overall much faster. When the same action can have such variable response times depending unknowable variables, your brain begins to believe that you're working for the computer and not the other way around. It just changes your relationship with your computer in a subtle yet fundamental way. If you hired a professional cutlery expert to feed you it would be faster but it's no longer mechanical -- they might occasionally get distracted by a text message and 1 in 100 bites are completely missed. Now there's a gatekeeper between you and your meal. When it's working it's way more efficient and awesome, but your brain now understands that your meal isn't really guaranteed anymore. Our relationship with computers is fundamentally different in a way that our subconscious immediately grasps despite being somewhat irrational.
- Koshkin 6y agoI wouldn't say "slower," but the fact remains that the perception indeed has not improved much, and the reason for this is in fact surprisingly simple: the way it's developed, software is like a gaseous substance - it occupies whatever space it is given. If some action or a response cannot take more than, say, 10 seconds, it will tend to take at least 10 seconds; if a program "expects" to be given a machine with 16 GB of RAM, it will take this much space just to run acceptably fast, etc.
- ibobev 6y agoIn his talk "Preventing the Collapse of Civilization" (https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk) Jonathan Blow is defending similar ideas.
- deleted 6y ago[deleted]
- rammy1234 6y agoFunction keys are best about this article. As years passed by I see the usage of function keys have reduced in any software updates. Function keys are thing of past. MacBook doesnt have a dedicated function keys instead I have to go to settings and have the function keys as dedicated one. Why Volume control, brightness,emojis are being brought to the forefront which can be done easily using a better with function keys. I hear some say keyboard is barrier to many new people. But in my experience it is different. They quickly get used to key shortcut and use products like pro. we underestimate our customers.
- jkoberg 6y agoYeah, "Designers" destroyed latency in UX with animation, transitions, and other such noise.
- Seb-C 6y agoThis is completely wrong. I still remember when my Windows 95/98 computer took 10~15 minutes to boot, when launching everything from Word to a game took minutes of waiting, when installing a game from a CD could take one hour or when loading an HTML page with no images took dozens of seconds. God help you if you had to load an image, or even worse: a photo or animated gif.
- ChrisRR 6y agoThis has always bothered me as an embedded C developer. We always strive to squeeze the last drop of performance out of a 32MHz processor in order to reduce battery consumption. Yet in the PC space, CPU manufacturers are pushing the limits of physics to produce faster, more efficient CPUs, and yet it's being wasted to dozens of layers of abstraction and interpretation. Software should be absolutely blazing fast by now, and yet computers feel just as sluggish as they did years ago (ignoring the boost from SSDs)
- kneotrino 6y agoi think is more about a lot of data we received is almost useless, we uploading data while we receive.
- metalliqaz 6y agoThis one again?
- deleted 6y ago[deleted]
- myth2018 6y agoAn interesting experiment: if you have the chance of going to one those decades-old stores using text based interfaces, ask the employees about which systems they like most -- the old-school ones or the new desktop or web based ones. I invariably get votes for the first. And the reasons are basically always the same: they are fast and just work. It feels like the entire user interface field is creeping.
- Zenst 6y agoGiven the latency of CRT compared to modern panels, yes on that aspect alone. Though GUI's and the like would be the main aspect for preception, the added eyecandy, then things like security, encryption... The CPU gods giveth with one hand and the software gods take more with the other hand - has played out many a time. Then the early stuff, machine code to the metal easy as less to know, today we have just fragments of library's used in coding languages that exceed are larger and than early operating systems. So the whole ability to know the whole machine inside and out is very much lost as even if you did learn it all, things would've moved on faster than you could learn. WHich is another aspect, a user could almost know to the bit what their machine was doing, today, so many aspects and with managment cpu's in the background with microcode you can never pick apart, and more grunt and processing than early more simpler systems, the odd's of knowing the level of detail and being that intouch with what's ticking underneath is lost. Bit like moving from manual gear changing (stick as some call it) over to automatic. You lose that connection as it is obfuscated from you. Akin to flying a plane by wire or as is the case today, by electronics - you lose that level of being in touch.
- myth2018 6y agoI believe that one area the author's criticism mostly applies to is that of business applications. I've been working as a user and developer in such field and I see a number of advantages of older applications (and even those text based ones) over the more recent web based ones. Newer technology for web/mobile user interfaces is great, but it shouldn't be the "default" approach, in my opinion, and I think that they are at the heart of that overall disappointment with many applications. They are harder to build and maintain; they are less constrained, leaving room for "creative" deviations from core functionality. In summary, we are spending lots of resources on something that eventually destroys value. I'm aware of a number of anecdotes about companies with 30/40 years old systems beating newer ones in terms of user speed. This, in conjunction with the fact that they are cheaper to develop, is a very strong evidence that we are doing something wrong.
- 6510 6y agohow about this? 1 - https://www.youtube.com/watch?v=HxXhLhTHkD0 https://www.youtube.com/watch?v=HxXhLhTHkD0 Look at that scroll speed!?! and the accuracy!?! Infinite accuracy?!! Being analog it goes infinitely beyond pixel perfect These things can print too! Slow and choppy: https://www.youtube.com/watch?v=tNtuvNO54Rs https://www.youtube.com/watch?v=tNtuvNO54Rs
- lakis 6y agoThis is not how things were. Maybe a few micro-actions were like that. Like turn on a C64. But then it was doing nothing sitting there. Let me tell you my experience that's etched in my memory. While learning image processing, we were suppose to implement a low pass filter in a 512x512 color image. That's a 1MB image. It took 20 minutes to make a modification of a single character. 20 minutes to compile the (C) program. And 20 minutes to run the program. The VAX we had in 1988 had 4 MB of RAM. We were 3 teams going through the cycle. So the machine was constantly swapping. Today it will take me less then a few seconds to change one character in my program, compile it and then run it.