Hacker News Reader

Comment by kemayo | Hacker News Reader

People are talking about "lag" and performance, as if this was a "the system can't handle it!" issue. This is a misleading description. The actual issue is that some developer at Apple screwed up their animation configuration when implementing the calculator redesign, and nobody tested adding more than two numbers together quickly. Multiple failures, none involving system performance.

What's happening is: the operator buttons have an animation on them, and they don't register inputs while the animation is running. The animation is pretty long, so it's quite easy to tap an operator, tap a number, then tap the operator again and have your input be missed.

Conveniently, this should be a trivial fix. Just abort the animation when a second input is received while it's still running and register the touch. (Or, lazily, make the animations a lot faster.)

Edit: I got operator/operand mixed up while writing this. :P

View on HN

Your solutions are a little off the mark. Treating the animation as the problem is merely treating the symptoms.

What needs to happen here is pressing the button needs to immediately register the press elsewhere in the code. The UI animations and the button tap should be decoupled entirely.

Then the user can tap away as fast as their heart desires and only the animations are going to continue on. That’s an easy problem to solve... by doing as you say and aborting them or shortening them.

But you should NEVER have UI animations and effects block your logic path. They should be parallel operations not serial.

My professor likes to tell this story about keyboard buffers that I never quite understood. Basically, in this old time terminal setup he would start typing the password before the prompt showed up or something and when it did, it would just sail through. Sort of like how I can apt upgrade while apt update is still running but fancier and a couple of decades before...

You can still do this in at least some shells. PowerShell buffers input if the running program doesn't capture it. If I have a build and execute commands in the history, I can hit up-up-enter twice in a row to start the build and queue the execution command.

I remember people doing that on an AS/400 ramming keystrokes for 5 seconds and then waiting 15 seconds for the system to arrive in the right screen, sometimes even already filling the fields from muscle memory. The first five lines of address data were already entered before the screen loaded.

When I was in high school I had a job after school where they still had a PDP/11 w/real DEC VT-100 terminals. The kid next to me used to do data entry and would get far ahead of the input screen. Except when he made a mistake, and he often did, it would beep. But because he was so far ahead when he made a mistake it would beep for 2 minutes straight. Every time. Max-volume.

Soo.. When he left his desk, I went in and hit SHIFT-SETUP, turned the audible BEL off in the VT-100 setup menu and enjoyed the silence.

When I came back in the office the next day, there was a technician from Digital with the terminal in what looked like 100 pieces on the desk trying to "fix" it. He was pretty upset when he realized it wasn't the speaker and the setting was just turned off (why he didn't check that first, I'll never know). Needless to say as a teenager, I kept quiet about the whole thing.. until now..

Oh wow. That is awesome.

That "old time" hurts a bit.. I haven't tried this recently, but I distinctly remember doing this in the early versions of Ubuntu.

The computers at my old job working as a cashier did that. It made working with produce so much faster because as soon as I heard the beep, I could move on to the next item, even if the screen hasn’t updated yet.

That's what happens when you read from a keyboard buffer. Since the buffer is not being read (and not cleared) until a prompt is in the screen, you can type whether you want and it'll get dumped and processed whenever needed. Not that long ago really, that's how it worked in DOS and most other terminals.

It still works. I can ssh into a machine and start typing commands before the shell prompt appears. The commands will appear in the terminal once the connection is established and the shell is ready.

Isn't the keyboard buffer a part of the physical keyboard circuitry and interface? Hitting enter triggers an IRQ to flush the buffer, so if the CPU is too busy to handle the IRQ then things queue up until the CPU can get around to handling it. If that's the case, for this "feature" not to work would require a very low level architectural change to keyboards. (it's been many years since i've thought about this though)

Keyboard buffers are decidedly not on the physical keyboard. The keyboard might have a very small one, but the IRQ is triggered on every input.

The buffer in question is, for a tty, a driver-level buffer that holds on to the data until something reads it. If a command doesn't read it (which things like apt-get update don't) then it'll get read as the next command.

Of course, most terminals these days are ptys accessed via emulators, so the buffer is actually part of the emulator, but the same idea applies.

ah, the more you know :) I would have been shocked if i remembered all that correctly

For some reason my brain still finds it important to remember that the BIOS keyboard buffer is 15 bytes by default, but that you could load tiny little devices drivers in CONFIG.SYS in MS-DOS to make it a whole 31 bytes.

I see that buffer effect all the time still.

> Sort of like how I can apt upgrade while apt update is still running but fancier

You can link two commands together with the "AND IF" operator

    sudo apt update && sudo apt upgrade

Furthermore, you also have `||` which is the logical or, and also `;` which is just a separator which doesn't care what happend to the command before.

Exactly. This is a very general pattern of error in software design - the use of a non-causal pathway to model causality. It is an especially exasperating problem, as it is both more complicated and more prone to failure than doing it right.

This goes well beyond UI design, and there are even physical analogs - for example, the crash of Turkish Airlines flight 981 in Paris could have been prevented if the device to prevent the cabin being pressurized if the cargo door was not properly closed had been operated by the door locking pins sliding home all the way, rather than by a side-linkage off the linkage that was supposed to drive in the pins.

https://en.wikipedia.org/wiki/Turkish_Airlines_Flight_981#Ca...

It is not as easy as that. UI and logic should run in parallel , yes, but they should also be able to synchronise.

Isn't 'never' an oversimplification? Sometimes there is a feedback loop between UI effects and user input, or the user input changes the way the UI registers hits, which means subsequent input depends on complete processing of prior inputs. On a static view like a calculator grid, you should default to non blocking animation, but sometimes blocking is the desired behavior.

What's a concrete example of this?

Tetris

An example that comes to mind is a slider switch (iOS is famous for them)

You don’t want the switch activated until it’s all the way left or right.

An even simpler example is page-based navigation. Can't register UI hits while pages are animating in and out.

What if you want to quickly flick through pages? Having to wait for each page to render would be awful.

Slider controls might be a better example, I think. In that case, the position reached by the moveable element is the data, and it is appropriate to take the value from the UI element (of course, if it lags noticeably, that is a UI design issue.) With slider switches, you could argue it either way, so long as program and UI remain consistent, but again there is a problem if the UI response lags the gesture.

Video games use animations as easy to project information to a player. If your character is “stunned” and can’t move, the animation should play for the duration of the status effect.

Sure. But that’s an inherent feature of the animation. In this case the “never” rule doesn’t apply. If animations are a side effect, you want to treat them as such.

The never rule not applying what what I was giving an example of!

But should any buttons pressed during that time be queued? Command queueing and cancellation is an important part of game design.

My "lazy" solution was absolutely treating the symptoms, yes. Which is why I classified it as a lazy one, even.

But I feel my first suggestion was exactly what you're suggesting -- immediately register the input and apply the operator -- I just phrased it in terms of what happens to the animation.

Also! I certainly feel there are times when letting an animation block your logic is valid. That would be any time when an animation has the UI in a potentially confusing state, such that the meaning of an input is ambiguous. (You should avoid these states as much as possible, of course. And this sort of button-flash comes nowhere even near that category.)

This shows how important UX really is. UI can be all glam and shiny, but the software with the most accessible of UX wins, more often than not.

I always come back to the example of WhatsApp and how it took on SMS, IM, and emails and won. People claiming WhatsApp went in mobile first are getting it only partially right. WhatsApp defined itself as a replacement for SMS: No login passwords, no chat history, cross platform and that led to them being cheaper, better, faster, frictionless. Later added MMS-esque capabilities like media and then email-esque features like Groups with super nice execution on the UX front.

Similar thing for AMP pages: It just works and it is blazing fast.

> Similar thing for AMP pages: It just works and it is blazing fast.

It is already blazing fast with only HTML and CSS, as the Web was designed to be.

EDIT: typo

Add some async JavaScript to onclick, onchange, etc. events.

> cross platform

Only mobile, the web version is shitty because it hosts a web server on your phone which is unreliable. And even with that you can only access the web version from one computer and it does not work well on tablets.

Not to mention you get banned from trying to use any unofficial client if your device/OS happen to not be supported.

WhatsApp also won because it did what most tech companies seem to consider antithetical to their purpose: put international customers on equal footing to US customers. So many companies either don't serve or completely gimp their product outside the US, often for no good reason.

A really important element of WhatsApp's global success is that they had a Java ME app for featurephones.

US-centric competitors would only support iOS and Android, whereas WhatsApp was running on the hundreds of millions of 2003-2010 vintage Nokia/Samsung featurephones that were in daily use in India, Indonesia, Nigeria, etc.

That is also part of UX. When it comes to messaging apps, Snapchat is one extreme of the spectrum -- iPhone-focused, cryptic UI, teen-oriented, majority of users in USA -- and WhatsApp is the very opposite. Both are successful examples of UX focus.

> cryptic UI, teen-oriented

These things go hand-in-hand by the way. And that's not a complaint, it's just funny how "only teens bother to figure this out" can be an honest-to-goodness feature under specific circumstances. Especially if you (basically) need to be "introduced" to a program and all of its quirks through your friends.

I hated it at first, but I've come to really appreciate being able to swipe around through almost all the screens, vs. having to stretch across my phone to hit menus on the far corners in other apps

Agreed. They still need to put in more subtle cues to do things though. Most people don't know you can use multiple filters/stickers or touch a location to change it.

Unfortunately AMP pages don't just work. I've had problems with them, especially with the top menu that is hard to bring back when scrolling up sometimes. Also sometimes the page doesn't load and I have to go back and reopen the page. No consistency on functionality... (Some sites are missing links to important things like comments)

> People are talking about "lag" and performance, as if this was a "the system can't handle it!" issue. This is a misleading description.

Lag doesn't necessarily have anything to do with performance. I really don't think people are talking about performance at all. No one would seriously think that a modern smartphone could be dwarfed by a 35 year old calculator in terms of raw performance.

Well everything nowadays is slowed down by the 20 abstraction layers, so I wouldn't be that surprised if someone managed to make one slower than a 35 year old calculator.

Maybe we should start worrying about "animation creep" as much as we do feature creep or other kinds of unnecessary complexity.

One of the main reasons I don't use iOS or macOS anymore is because of the animations. Even very, very short animations make the whole experience excruciating for me. It feels slow and unresponsive.

So what do you use instead? FYI you can reduce animation in the accessibility menu of both iOS and OSX

When I had a choice, I used Fedora + XFCE for a long time, then Xubuntu. I've been on Windows 10 since it came out, and it's been incredibly liberating not to constantly have to think about my OS and Google my way through its quirks and bugs.

It also takes about 20 seconds to disable all animations in Windows, which makes it feel as snappy as XFCE (even on my 5-year-old machine).

For what I do now (Office, email, programming using IDE hooked into Docker containers), it really doesn't hinder me to be on a non-*nix OS.

One reason I moved from Android to Windows phone was because of the massively unpredictable performance (lag due to background stuff happening).

One reason I moved from Windows phone was the massive delay in switching apps.

Now on iPhone the animations are annoying, yes, but they are at least consistent in length, meaning I expect them and know how long to take a (tiny) pause. I know some work is happening that’s being disguised and that’s why they can’t (all) be turned off.

Every day I experience lag typing something into glitzy web apps because someone made the text box wait for something it doesn't really need to. It's definitely slower than word processors I've used twenty years ago.

True, there are so many layers things aren't up to par. Maybe get back down to basics with languages like Rust and rewrite a few things? But then we'll end up with 20 layers or so of abstraction after 20 more years...

I could seriously think that. A pocket calculator has a ~200KHz processor and an LCD with an update time of maybe 10ms. A single digit calculator operation like addition would be a few clock cycles, so say a total time of 15ms with output buffering. A 60Hz monitor refresh rate is already worse than that without considering the framework stack.

Do you have a source on that clock speed? I've been trying to dig up info on pocket calculators for a while.

(The last time I brushed-but-didn't-quite-hit some interesting info was in https://news.ycombinator.com/item?id=15136939, which I quoted (very tangentially, as a footnote) in https://news.ycombinator.com/item?id=15153262.)

An even easier fix would be to drop the "Animate all the things!!!" mentality.

I agree with you. Why not be more utilitarian and build things for function and not for looks.

I think animations are pretty useful in this context. It reassures you that your sausage fingers didn't hit the wrong number.

I commented to the same effect on reddit: This doesn't ring true to me at all.

The numbers have the same animation, but it's both shorter and interruptible, so the people who built the app seem perfectly aware of the problem and how to "fix it".

This seems deliberate, as if somebody figured that, while it's a legitimate use case to rapidly tap digits to input a longer number, tapping an operator multiple times is likelier to be an input error, so they purposefully block it. Clearly a mis-feature, but a feature nonetheless, rather than a bug.

>Conveniently, this should be a trivial fix

trivial to fix the bug in the calculator app. not trivial to deploy that fix. this would be a full system update, right?

Yeah, it'd have to be a proper OS update, because it's one of the core apps.

But, also conveniently, iOS 11.1 is in beta at the moment. They just released beta 5 today, so it's not like they couldn't slip a fix for this in before the final release if they wanted to.

Whether they will or not, well...

Since iOS 10 the system apps have been on the App Store, and as far as I know, they can now be updated that way, too.

They‘re listed on the App Store but they‘re fake listings. Removing a core app from the home screen does not remove it from the device. Installing it from the App Store restores that link.

That means updates still need to be a part of a system update.

Like IE in Win XP

You are probably correct. Maybe if the developers decided that their precious prefab apps didn't need to come prebaked into every release of android and iOS and instead let the consumer pick, the market would be a bit less full of app bloat.

In iOS 10, reinstalling the News or Calculator apps was instant. In iOS 11, the App Store list sizes for these apps, and reinstalling them takes a few seconds (on my phone and connection).

I haven’t measured data usage, but I suspect this means that removing Calculator’s icon actually removes its code from the system. If that is true, it is potentially upgradeable independent of the iOS system, at least from a technical perspective.

I suspect Apple’s QA and release processes cannot take advantage of this, though.

How this works in Android for system apps: One can only disable a system app. This disable button replaces the uninstall button. It deletes any updates to the app from your phone, since it will obviously still have the original version baked into the ROM, and removes it from the app list. It might also disable any service registrations for the app... Unsure on whether that's true.

Re-enabling the app will basically restore the ROM version. You can then install updates from the store, which I think is basically a full install and the ROM version is ignored again, based on the consumed space of such apps.

That's interesting! I hadn't noticed the change. As you say, it's probably not relevant until Apple can actually release a single-app update through that channel, but it might be a glimpse at a future where that's an option.

Does iOS runtime not use evented I/O? Coming from web, I would expect tap events to queue up while the thread is busy with an animation.

While the button is animating, it simply doesn't respond to touches. There's no thread that's stuck. 1 + 2 - 3 consistently produces the correct result because + and - are different buttons.

It’s a simpler matter of not passing “allowuserinteraction” to the UIView animation options.

CoreAnimation runs animations on a background thread using state snapshots.

The event loop is processing events during the animation. It is up to the programmer to decide if events are ignored or processed during animations because what that means depends on what you want to happen: is the animation interactive and reversible? Does tapping reset the animation or does it start animating to the new state from its existing state?

CoreAnimation does the work based on the policies you select (eg: interpolating between a half-complete animation and the new desired end state).

Correction—CA animations process and render in a render server process. This is why even when the main thread is blocked, animations can continue.

> People are talking about "lag" and performance, as if this was a "the system can't handle it!" issue.

No they're not. The linked thread is literally discussing what you describe as "the actual issue".

> The actual issue is that some developer at Apple screwed up their animation configuration when implementing the calculator redesign, and nobody tested adding more than two numbers together quickly. Multiple failures, none involving system performance.

Unless you were talking about the discussion here on HN? I haven't read most of the discussion here yet. I just wanted to point out that the Redditors get it right just fine, since there's a lot of unheeded shitting on Reddit on HN (has always been the case and I think it's sad. HN has got its own community smells, but at least I hardly ever see Reddit dumping on HN and when they do it's in good natured fun poking and not vitriol like here) (btw your remark wasn't vitriolic, but others are very much so).

For the layman the "system" in this context is the calculator, which can't, indeed, handle it.

> tap an operand, tap a number, then tap the operand

The numbers are the operands.

Heh, yes, you're quite right. "Operator" is what I should have said. Total brain fart. :D

So it looks like this is a case of "operator error."

No, just don't block input during animations.

I can't come up with a good UX reason for that restriction, so either it's an oversight or a technical limitation.

Apple does not seem to test a lot these days...

or they test, find bugs and decide they're not worth fixing...

Speaking of lag, I wish turning on/off cellular data didnt have that 2 second lag. why cant it be instant?

My thoughts exactly.. You are correct

Just checked the Android calculator implementations from Google and Samsung on my phone. They correctly handle button press animation asynchronously. Look like Apple doesn't dog-food their software anymore after Jobs.

Reply on news.ycombinator.com