by bdickason on 3/2/21, 6:40 AM with 528 comments
by atleta on 3/2/21, 2:59 PM
What iphone was a LOT better at than everyone else was UX. Of which speed is one component, of course. It's funny how much people never get it although it happened in front of us, it happened to us. At the time I was working at Nokia Research and I remember my girlfriend telling me how his boss got this wonderful phone that you can take photos with and you can view them, etc. The funny thing is that I had such a phone since 2001. I have been working with smartphones for 6 years then, she knew it, she listened to me when I told her or others what I was doing (and then listen to others responding "yeah, but phones are for making phone calls"). She saw me browsing the net on my phones (a 9210 communicator and then a 9500), send emails from the beach, etc.
Still it somehow didn't register. Because it looked like something that she'd never use. And then the iphone that did a lot less made her and basically everyone understand what a smartphone is. (Even though by then symbian smartphones were pretty common, most people didn't use them as smartphones.)
So no, it's not simply the speed. It's the UX. And even if we talk about speed, it's still not the speed, but it's the perception of the speed, which a lot has been written about: delay (lagging) matters a lot even if speed on average is OK.
by pontifier on 3/2/21, 11:16 AM
The INSTANT I hit the button to complete the order, the built in printer almost spat the ticket at me. I ordered a second sandwich just so I could get a video of that happening again.
Edit: Just found and uploaded the video :) https://youtu.be/TX_-dXIpPvA
Edit2: looks like it was a soda, not a second sandwich.
by jonplackett on 3/2/21, 8:52 AM
Netflix is faster in every way. There’s a button on my TV specifically to launch it, the videos start faster, fast forwarding is faster, there’s less buffering in general. Every single touch point is fast. And it’s because they put the effort in where the others didn’t.
by pdimitar on 3/2/21, 10:22 AM
I'd honestly pay extra for an iPhone where I can disable ALL motion, too. But that's the least of the problems.
I don't want to become the grumpy old grandpa yelling "back in my day!..." but we have waaaaaaaaaaay too much young JS devs who know nothing else.
We need to get back to native UIs. Is it awfully hard? Yes it is. Do the users care? No, they don't. Many people want fast UIs.
But to be fair to all sides -- there are also a lot of people who don't notice certain slowdowns that I scoff at. So there is a middle ground that won't cost billions to achieve and IMO that should be chased after.
by habosa on 3/2/21, 9:47 AM
I can never go back to Android now. I'm sure if you studied the phones under a high speed camera we'd be talking about differences of only tens of ms but when you tap something 1000x a day it really adds up. It's just like how most programmers are hyper sensitive to text editor latency.
by DarwinMailApp on 3/2/21, 10:06 AM
Every second support email in the early days of https://www.darwinmail.app was from users who were wondering why the website wasn't faster to load and operate.
I knew that this was going to slowly kill the product if I didn't focus on optimising the speed immediately. I also heard somewhere that even a 0.01 increase in load times for Amazon's website would cost them somewhere in the region of 100's of millions.
1. I gathered feedback from all users that said the website was slow (in any way and in any page/component/workflow).
2. I created a Trello board https://trello.com/c/PPuhLtW0/95-upgrade-performance for all the feedback.
3. Since that week of initial performance enhancement research and groundwork, I have essentially been completing todo's on that Trello card and adding more tasks as time goes on. I think the more speed improvements I make, the more I learn about what other parts of the application can be sped up. It's like economics, the more you learn, the more you realise you have so much more to learn :D
A few years later and I have not received an email suggesting to increase the speed of the app in several months, although I continue to make speed improvements on a regular basis.
Netflix have been my source of inspiration here. They are leagues ahead of every other streaming service and their custom architecture placed at the ISP level is absolutely incredible and paramount to how the deliver content with such amazing speeds.
by GuB-42 on 3/2/21, 10:59 AM
That's something no other smartphone could do. I don't know how things are today but I looks like Android more or less "solved" the problem by throwing powerful hardware at it.
The killer feature is not really speed, but low input latency. And this is achieved by taking performance in consideration during development. And contrary to the old "premature optimization is the root of all evil" saying, you have to do it early, because while can be relatively easy to increase throughput, latency is much harder to deal with.
This is also part of the success of Google Chrome. While it didn't load pages that much faster than its competition it was great at showing you something quickly. It took ages for Firefox to catch up, and it looks like it did mostly because Chrome became slower over time. How is Servo going BTW?
by riho on 3/2/21, 12:46 PM
There's a reason why it's hard to ever go back, once you've experienced the fluidity of even just your mouse cursor reacting instantly to your movements.
If you've ever used the iPad Pro, there's clearly something special about the experience. It just _feels_ better, and for all the same reasons described in the article.
60hz is far from smooth, and that number is a leftover from days past, not what is actually optimal or good.
Display technologies unfortunately still have ways to go when it comes to high resolution, color accurate panels, with high refresh rates, but the general direction on the market is that high refresh rates are not available in the "productivity" category of monitors, even if sometimes the manufacturer has panels that would fit the bill. You unfortunately always need to look in the gaming category, which usually lack many of the features you'd like in a more productivity centered display. Such as a fully adjustable stand, high color accuracy and viewing angles, virtual display splitting, or just overall design of the enclosure.
I could go on another rant about display enclosure designs... Why isn't there a single company out there (with perhaps the exception of Dell) that's creating nice and minimal display enclosures that aren't covered in cheap plastic and "aesthetic" ornaments? Apple's Cinema Display from 2004 is to this day one of the better looking enclosures out there.
I don't think you can blame this on the consumers really. For the higher end market that I'm talking about in general here, I'd be willing to take a bet on if you build it they will come. I'd certainly be praising any company willing to take this on to high heavens.
I want a great, fast, accurate panel with a nice, minimal, aluminum enclosure. Is that just too much to ask?
by ALittleLight on 3/2/21, 10:28 AM
In our case, our users had a specific flow through the application they would use, and it worked, but it required clicking many (10+) buttons and waiting for a web request on each. People on the team were satisfied that the flow worked and going through it didn't take TOO long... But what people on our side didn't get is that our customers had to go through this flow dozens if not hundreds of times - some users would need to do it this many times regularly. It effectively made our users hate using the product, or they would refuse to, or they'd use it but only a little bit and they'd try to minimize the cost.
I tried to get people on our side to experience the pain points, e.g. asking PMs to follow this flow one hundred times, and things like that, but I never could get through to anyone that we should redesign and refocus on making it usable. Maybe a mockup of a faster flow was what was needed to be persuasive there.
by dragontamer on 3/2/21, 7:53 AM
I always felt like resistive screens were more responsive than capacitive screens.
Case in point: My 3DS resistive screen and Palm Centro responded instantly. I think their downside was the necessary use of the stylus (because of the additional precision, their UIs required you to pull out the stylus before you could do anything effective).
What the Apple iPod Touch / iPhone did, was allow you to touch without using a stylus.
Anyway, I read this post as if its a mirror-image of my reality. The one thing I remember about Apple's capacitive push was that it felt slower than what I was used to. Honest.
--------
With that being said: I've played fighting games vs opponents who can 1-frame link and counter-throws within 7-frames (115 milliseconds). I'm well aware of the human-brain's capability to process data far faster than most people realize.
Musicians, Video Game players, Athletes... I expect most of them to have reaction speeds well above average: below the 200ms typical human. Even then, "average" humans have far better reaction speeds and ability to perceive things that happen in factions-of-a-second (at least, once you make them aware of those things).
UI-speed is absolutely a great feature. I just disagree that Apple's iPod Touch or iPhone was a good representation of that.
by ksec on 3/2/21, 11:57 AM
We can look at Input Lag [1], and Microsoft Research's work [2] on Touch Input. Apple's ProMotion being part of that as well. For the past 20 years we have make 10 - 100x improvement in bandwidth at the expense of Latency. Now we need to do more work on it . Especially if we want VR or AR which are extremely latency sensitive. John Carmack [3] used to talk a lot about it when he was still working on Oculus. How it was faster sending something hundreds of miles away than showing it on your computer screen.
[1] https://danluu.com/input-lag/
by draklor40 on 3/2/21, 10:17 AM
Speed matters. I CAN perceive the latency of using an SPA vs using a native application. I notice. the diff. between executing a GNU binary vs running a js based script.
by baxtr on 3/2/21, 8:51 AM
This. Yet, I’d say it’s not the teams. In my experience it’s usually management that demands new features and doesn’t care about speed.
by theptip on 3/2/21, 4:58 PM
However, speed is not “the killer feature”. Speed does not add any value in isolation; your app needs to solve a need for the user first. If you don’t have PMF don’t think about speed yet.
The article gestures at objectivity by linking some cases where people measured revenue gains from speed improvements, but fails to follow through and actually propose an experiment or ROI calc. If you think your app is slow, run an experiment and measure the impact on conversion. (You can even take a page from Google’s book and _add_ delay with a simple sleep() if you don’t want to spend any time on perf work before you get data. Or just do the first bit of low-hanging fruit and measure the impact.)
Talk to your users and ask them what frustrates them in the app. It might be “takes so long to check out”, or it might be “it just lacks feature X that competitor Y has”. I’d suggest it’s unwise to spend time on perf work if you are pre-pmf and the main feedback was the latter. Again, do experiments too because customers don’t always tell you what they need. In particular enterprise users often don’t care as much about speed, as long as you tick all of the boxes. Many users are used to line-of-business software that is slow and buggy, so your bar in B2B is not always high here.
Finally do an ROI calculation. If a perf iteration is going to cost you $20k in dev resource, and get you 7% improvement on $10k of monthly revenue, that might not be the right thing to focus on. Ideally you’re looking at features that will improve your top of funnel volume more than that.
It’s all a trade-off. It depends on your company’s level of maturity, Product/Market fit, and the value of the marginal feature that you’d be deferring to make your app go faster.
If we interpret this to be a political manifesto carrying the message “you should care more about speed/performance”, I’d prefer the meta-level “you should care more about trade-offs and marginal value”.
by brundolf on 3/2/21, 5:10 PM
1) As programmers we're biased to feel like speed is the most important thing because it's very fun and satisfying to optimize. In reality, for actual users, it's one of many different axes of value that have to be weighed against each other. In some domains it's critical, in some it matters very little, in most cases it's one important factor among many.
2) There are different types of "speed". Generally anything that's supposed to mimic something physical - basic UI feedback, real-time games/simulations, etc - has a much higher speed requirement than some abstract process. Will the process take long enough that it makes sense to show a loading spinner at all? Then the user probably won't mind waiting a couple extra seconds. Will it take <500ms? then the user will approximate it to "instant", and will notice if there's a bit of "lag".
> Phones in 2007 had the same features as the iPhone. The Palm Treo even had a touch screen. The difference was speed.
If the original iPhone had taken twice as long as the Treo to load a web page, but the touch screen was still more responsive, people still would have perceived it as being "faster". The extra seconds matter less than shaving off the extra milliseconds.
by sgeisler on 3/2/21, 10:15 AM
by tempestn on 3/2/21, 8:57 AM
All that said, I do agree with the general thesis. Evernote has just come up with a huge update of all their apps, having ported them all to Electron to standardize development. The only problem is, they're all brutally slow compared to the native apps that preceded them, and it truly ruins the experience.
by renewiltord on 3/2/21, 10:37 PM
Stopped listening to these people for product expertise. Even took a chance on Facebook at $19 when HN was gleefully expounding on how this was obvious and the company was doomed. Glad I did that.
Did it again when everyone on HN was convinced SMCI was spying for China. Worked out again.
I'm going to call it "Tech Enthusiast Inverse Sentiment Index" TEISI. List it on the NYSE and people can make big money doing the opposite of people here. Maybe you get a couple of losses like WeWork and whatever but overall, I think you win.
by lordnacho on 3/2/21, 10:27 AM
I'll never get another Samsung, even though I don't know if they did it deliberately, or if it was even them that did it.
Somehow my current phone has lasted 3 years with no appreciable slowing.
by ancarda on 3/2/21, 12:09 PM
Everything is just too slow -- and it doesn't need to be.
by StillBored on 3/2/21, 9:33 PM
It seems to me that basically 100% of the UI/UX developers at the big tech companies are woefully ignorant of the fact that there is a massive amount of data and papers written about human computer interaction. I'm guessing that is because few comp-sci programs even touch the topic, rather spending all their time on more esoteric/mathematical topics.
In summary, a very large number of studies were done in the 1960s-1980's on the _human_ aspects of user responsiveness (important when timesharing became common), how people learned computer interfaces, and how effective they were at operating them. Despite some of these papers being > 40 years old, none of it has really changed because the studies were about humans, less than computers. The underlying computing may have changed from a time shared terminal to a phone in someones hand connected to a server, but in that time the human cognitive loop hasn't changed.
IMHO, and somewhat backed by the science, any system which isn't responding in under 100ms is broken unless its performing something extraordinary. If its actually interactive (like typing on a command prompt) even that is far to slow. User frustration, and loss of attention are real things, and you can bet when given the choice users will pick less frustrating systems. The saving grace for many of these platforms is that the entire industry is trying to be like the fashion industry and follow the latest trends. So it doesn't matter if BigCoX makes a huge UI blunder all the others will follow it down the lemming hole.
So tell me why some of the conclusions in a paper like http://larch-www.lcs.mit.edu/~corbato/sjcc62/ (1962) are wrong. How about: http://yusufarslan.net/sites/yusufarslan.net/files/upload/co... (1968)
Amusingly other classics like https://www.microsoft.com/en-us/research/wp-content/uploads/... are discovered regularly too (1983).
by bdickason on 3/2/21, 8:43 PM
Thanks everyone for sharing really awesome examples in the comments here - from Games to Receipt Printers to Apps, it's clear that speed is valued.
Or... that there's a big opportunity to bring back lightning fast products :)
by ZephyrBlu on 3/2/21, 9:49 AM
1/3 of a second is already insane lag, 3 seconds is just ridiculous.
by collaborative on 3/2/21, 11:01 AM
by felixding on 3/2/21, 2:06 PM
My first impression was "unbelievable" - how on earth would anyone think a Palm device is slow?! Then I followed the link and saw a Palm Tree 750/V... oh, of course, that thing run Windows Mobile.
A Palm device running Palm OS is blazing fast! I switched to iPhone from Treo 650 in 2009. Almost everything became much slower. The iPhone software was slow, so was the user interaction (in the sense of UX).
Palm only started using Windows in its later years. And there were actually very few Windows Palm phones. Most Palm PDAs and phones run Palm OS and were very, very fast.
by lucas_membrane on 3/2/21, 11:42 PM
Speed always has been not only the most important thing, but virtually the only important thing. Back before most of you were born, there was a review (in PC Magazine, IIRC) of the category of spreadsheet programs. MBA Analyst dominated the others (visicalc and lotus 123, IIRC) in every category except speed, in which it was OK, but not great. That's why you never heard of it.
The speed requirement is closely related to the self-importance fallacy. If a computer needs time to think, maybe we could make good use of a few moments pause, too.
by clarge1120 on 3/2/21, 1:13 PM
For example, Line of Business (LOB) apps are built with ROI in mind. LOB apps help businesses run more efficiently, and employ the vast majority of developers. These are the most used apps in the world, and company owners are much more interested in functionality, automation, and distribution of apps than performance and usability.
by floatingatoll on 3/2/21, 10:54 AM
by bajsejohannes on 3/2/21, 1:09 PM
Examples I can think of: The emoji selector (ctrl+cmd+space) is quite slow. On my brand new macbook, it's a small noticeable pause, and on my old macbook it's several seconds (during which time keyboard input is lost).
> If you can’t speed up a specific action, you can often fake it. Perceived speed is just as important as actual speed.
Second example is facetime on my iPhone. They fake being fast by showing the last opened screen. For me, it's very often the "most recent calls". The problem is that in the meantime there's been another call. Result: I see the person I want to call back, tap on the screen where they are, observe that the content changes and I call the wrong person. This happens often enough that I should learn, but somehow I don't.
by baybal2 on 3/2/21, 10:41 AM
A very strange phone to reference. First iPhone was slow as molasses with all of the excessive visual effects.
It was only around OMAP iphones when they first got proper hardware acceleration.
Palms were noticably faster than WinMo 6, and WinMo 6 was faster than 5 which was indeed painful to use because of input lag.
Ironically, Android is still somwhat slower than WinMo 6 on input lag despite every trick Google is throwing on it.
I read somewhere they even tried to wire the input layer directly to hardware acceleration to make scrolling less laggy.
by mangoman on 3/2/21, 2:02 PM
by ulisesrmzroche on 3/3/21, 5:06 AM
It was the first all-in-one (camera, music player, phone, game system, organizer, etc) that didn’t make you a bully target.
Not saying Speed is unimportant...I’m saying this is straight up lying.
Like back in the AOL days, when dialup was a thing, the internet was dogshit slow, but you still had to get in line to use it. Took hours more often than not.
If people valued speed more than anything, aol would have gone bankrupt. People are willing to pay extra for speed but can live without it as long as features are there.
This is starting to bug me because for startups, this is bad advice. It’s actually harmful since it’s all about product-market fit at the beginning. You’re better off throwing away code instead of optimizing.
by nromiun on 3/2/21, 2:54 PM
But Google Pay released a new update using the flutter framework. And now even scrolling takes ages to complete. I complained on Play Store but the reply said to check my internet speed.
Meanwhile PayTM has also redesigned their app, but unlike Google Pay their updates actually made the app much faster and intuitive. I still check Google Pay from time to time to see if they have fixed their app, but the scrolling is still laggy (it feels like you are in a web page) and the loading page still flickers.
by seanwilson on 3/2/21, 9:32 AM
I think it's fine to say faster page loading makes users happier and will increase conversions but you should avoid generalising with such specific figures (I see this often with page speed article titles where they mention conversion rates changes to 4 significant figures). It's going to vary wildly based on the product, audience, price, exclusivity, custom loyalty etc. and you'll get diminishing returns as well.
The impact page speed has on amazon.com conversions isn't going to be the same as on your side-project website for lots of reasons.
by tome on 3/2/21, 10:19 AM
by CinematicStudio on 3/2/21, 10:33 AM
It's painful (for me, that is :D), but I know it's the right thing to do.
by gnyman on 3/2/21, 7:14 PM
Now turn off the screen with the power button.
Notice the annoying delay when turning off the screen is gone? enjoy :-)
Of course you also don't have a way to invoke the wallet manually, but luckily if you put it near a payment terminal it will auto activate
Probably won't work if you're a heavy apple wallet user but if you use it only sporadically I personally think it's worth it, I found the delay very annoying when I switched to a homekeyless iphone
by ska on 3/2/21, 9:32 PM
Speed (or more likely, perceived speed) is only one part of UX, and how much it matters depends a lot on what else is going on and the users expectation. Even focusing merely on responsiveness feels a bit superficial.
Something a bit closer to the core of it is that whenever a user is focused on waiting for your software, it reduces their experience. That can be articulated better I'm sure - and still is only one part of the (complex) equation.
by bjarneh on 3/2/21, 11:18 AM
by tommilukkarinen on 3/2/21, 10:27 AM
The thing with iPhone was the capasitive screen, which made touch UI work. At the point I had already worked with phone touch UI:s for seven years, and that's the thing that felt like magic.
by dystroy on 3/2/21, 6:46 PM
I was reminded by this today as I installed Debian on a new computer. Why do Gnome makers imagine it's OK to have the *default* on slow ("Animations") rather than instant ? Do they really think we'll be happy enjoying a 200ms or 500ms delay every time we reduce or open a window ?
by pul on 3/2/21, 4:54 PM
by mrvenkman on 3/2/21, 11:34 AM
by phkahler on 3/2/21, 12:17 PM
Those aren't even the right questions.
Change 10 seconds to 1 for the checkout page. And then ask if they ever have to watch a loading indicator. We have no hope if we dont set good goals.
by sverhagen on 3/2/21, 10:06 AM
by fairity on 3/5/21, 1:52 AM
by benlivengood on 3/2/21, 6:04 PM
by buf on 3/2/21, 11:02 AM
For my personal notes, I'm still organizing it in local files (via vimwiki), but for team notes, Notion needs to step up its game.
by lifeisstillgood on 3/2/21, 12:05 PM
by MR4D on 3/5/21, 3:17 AM
Oddly the links were right next to each other.
by bob1029 on 3/2/21, 11:40 AM
You can cheat in some weird and fun ways though. For instance, if you say "no user of this system will ever be more than 50ms away", you get to play some really interesting games with vertical scaling and consolidation of compute capability in an all-in way. I.e. server-side technologies ran out of a single datacenter near the userbase.
If your latency domain fits it, something like Blazor server side can be an incredible experience for your users. First load is almost immediate because there's virtually no client code. Everything is incremental from there. If you are within 50ms of the server, UI feels instant in my experience. The nature of how applications are developed with this tech means that if your business services are completing requests within the performance budget, you can be almost certain the end user will see the same.
Going to the bottom of the rabbit hole, understanding how NUMA impacts performance can make 5+ orders of magnitude difference in latency and throughput. Letting a thread warm up on a hot path and keeping it fed with well-structured data is foundational to ultra-low-latency processing.
You can handle well over a million events per second on a single thread on any recent PC using techniques such as LMAX disruptor combined with a web hosting technology like Kestrel. The difference between a class and a struct can be 10x if you get to that level of optimization. I measure user interactions in microseconds in my stack these days.
A millisecond is a fucking eternity. You shouldn't be doing a bunch of back and forth bullshit in that kind of latency domain. Stream client events to server as fast as possible, microbatch and process, prepare final DOM changeset and send to client all at once. How could any other client-server architecture be faster than this, especially if we are forced to care about a bucket of shared state?
by jmacjmac on 3/2/21, 3:34 PM
by PTOB on 3/2/21, 5:40 PM
by hnnotreddit on 3/2/21, 4:43 PM
by ChrisMarshallNY on 3/2/21, 11:43 AM
That said, I feel like it is sort of belaboring the obvious.
I think that our overdependence on dependencies has a lot to do with UI latency.
by IshKebab on 3/2/21, 12:00 PM
Not saying I necessarily disagree with the premise but they chose a poor example.
by bambax on 3/2/21, 5:55 PM
by swyx on 3/2/21, 4:10 PM
by tuckerpo on 3/2/21, 4:02 PM
by digitaltrees on 3/2/21, 9:03 PM
by m463 on 3/2/21, 11:29 AM
by RocketSyntax on 3/2/21, 3:05 PM
by fireeyed on 3/2/21, 1:56 PM