Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Another example, which has existed for as long as I have known, is the spinning number selectors on iOS, used in apps such as Clock for setting alarms or selecting times/dates. The new value doesn't register until the animation completes, so if I set my alarm too fast, it doesn't save: Let's say the alarm is set to 09:00 and I change it to 09:30. So I spin the minute field up to 30 and hit Save. If I do it too quickly, the spin animation isn't completely done (even though we're talking just a few pixels), and the alarm reverts back to 09:00. Interestingly enough, the bug doesn't cause the saved value to be 09:29, which is what one might expect it to be, given that that's the last value passed before Save was clicked.


I find the spinner interface is a bit clunky in the first place as well. I haven't found anything as fast to use as the N9-style circle[1].

[1] http://www.nition.co/2014/08/the-nokia-n9-alarm-clock


That seems quite similar to Android's/material design's current time picker, https://material.io/guidelines/components/pickers.html#picke..., which is such an improvement over scrolly scrolly scroll scroll style mobile time pickers


Android 6+ has something like that: no need to spin there tough, all the numbers are already available for tapping.

A screenshot at the beginning of https://stackoverflow.com/questions/37809848/can-we-use-some...

However IMHO it's a big usability regression from the old time picker widget, which was a number pad to enter the four digits a time is made of. I know the time I want to set and instead of typing it straight away I have to look for numbers on a dial. It takes longer.

Design teams are losing their way. Too much eye candy is making them blind to efficiency, pun intended.


I still find a number pad to be the fastest. Why am I spinning something around and trying to position it right when I just just press three buttons 9-3-0?


For alarms and clock times, my guess is data validation. The app could correct or block invalid time entries (e.g., accidentally hitting 2500), or it could restrict the entry set.

It also means the number will be in the correct format. your example, 930, could mean many things (930 seconds? 9:30am or 9:30 pm?)


If all inputs are in hh:mm format, then there is no ambiguity of 930 as 9:30 am/pm. There could be a toggle for AM/PM.

Who puts seconds as an input for setting their morning alarm? MAD!


What's the unambiguous setting of 73:45 in hh:mm format?


3 days, 1 hour, 45 minutes. Simple.

The Android clock app silently corrects 73 minutes to 1 hour 13 minutes.

So for 1:13:45 (hh:mm:ss) you can input "7345" on the keypad and It. Just. Works.


But an alarm clock sets a relative point in time that happens every day. Putting "3 days" into a calendar is fine, but for an alarm clock it makes no sense.


So you add basic input validation.


Yes, but the person who originally proposed this argued that there was no ambiguity.


Invalid input, just as the empty string or a single digit would be.


This is where the alarm would be a grey colour instead of green? I missed alarms this way too in iOS 10. It’s worked so far in iOS 11. A shocking bug. I reported it to apple on twitter. Instead of saying yes we’re incompetent, they wanted to set me up a call with a ‘Senior Advisor’. I just gave up. I don’t want to waste time talking to someone who will tell me I have to set my alarm slower and double check it’s set correctly. It’s not like I paid nearly 1000 USD for the phone or anything...


I missed an alarm yesterday because of this. I can't be believe they still haven't fixed it! If the spinner is still moving AT ALL, nope, it silently fails.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: