Great design from Apple on an interaction with Siri | Hacker News Reader

Great design from Apple on an interaction with Siri

37signals.com

288 pointsjoeyespo109 comments

That's one of the things I liked about the Android alarm app that I miss on my iPhone; when you set an alarm and tap "Done", it would say "Alarm set for 9 hours and 22 minutes from now" (or whatever), a quick sanity check to make sure you didn't confuse A.M. and P.M. or accidentally put in the wrong day.

And a fun fact: it even calculates it correctly across a daylight savings time change. I noticed that when the clocks went back; instead of just subtracting the times, my Android phone accounted for the change and added the hour that I was getting back. Awesome!

I'm sure it's using the UTC time to calculate this. The UTC never goes back.

That's a sarcastic "awesome," right? Because that sounds like a bug. If you need to do something after x hours, this is useful. If you have to do something at a certain clock time, then this could be infuriating.

I'm sorry? He said he wanted to do something at a certain clock time, and the phone correctly told him how many hours away that time was.

Oh! I thought it changed the alarm time. A technically adept friend recently complained about this happening with his Android phone - the 8am alarm went off at 7am - so I had that in mind, though it seems like I was misreading here. Sorry about that.

This happened to me too; the alarm went off at both 7 am and 8 am instead of just 8.

Haha, if it adjusted the clock time, that would be double or triple bad depending on how it was implemented. The alarm would be wrong unless it were shifted back when the time changed again, thus defeating the point of having altered it in the first place.

Yes, I love this little detail. The posted Siri example could use the same thing - since I don't always know the date, it would be nice to see it as a relative time (i.e. Did you mean: 8.5 hours from now, or 1 day 8.5 hours?).

This thing is indeed a lifesaver, not just because of time of day but because alarms could be previously set to only go off on certain days. So when I'm told the alarm won't go off for 80 hours or something, I can correct it immediately.

As a bonus, it gives a good estimate on how much sleep I'm going to get.

In iOS the alarms are sorted chronologically, so if you have more than one alarm set up, it's pretty easy to notice if you accidentally did PM because your alarm ends up at the bottom of the list instead of the top.

Not that I'm saying this is better than what you're describing. I'm just saying this in case any iOS users didn't realize that and it's helpful.

Android also sorts them chronologically, but that alone only helps if you have multiple alarms (and a sufficient number that sorting gives you the needed feedback).

Whilst that is evident if you are aware of that design, it isn't immediately obvious to the average user.

Interesting, I didn't realize that since I only ever have one alarm at a time.

One of the many benefits of using a 24-hour clock (which is the default on the iOS alarm app in my country). Not that I'm disagreeing with you; I think that's a great solution on Android's part.

That only helps with the AM/PM issue, not with the wrong day issue.

Agreed. It's one of the first setting changes I make on new devices; if it's supported: changing the clock to 24 hours

Indeed, just to give some props to Nokia, my (now retired) Nokia N8 running its latest Symbian OS does the same thing for its alarm functionality and tells you the time duration before ringing.

It also displays the time of the next alarm on the lock screen. This is a really nice sanity check: A quick glance at the screen when going to bed ensures that it will wake me up at the right time the next morning.

Heh. My Nokia from '07 does this, too :)

And it will even turn itself on to actually wake you up.

That's the only thing I miss from Nokia: alarm goes no matter if the phone is on or not.

This isn't unique to Nokia. All phones I've used will do this. There was one alarm in my HTC Desire that kept going off once a week for a month before I finally realized where the noise was coming from (it was in my closet, so the first few times it happened I thought it was a neighbor's alarm).

I thought the iPhone (and most phones) did that too.

Not like a Nokia device. It will power the phone on from complete off (not sleep or standby) and sound your alarm. Freaked me out when I turned off and boxed up my old N95 and then a week later it turns itself back on and sounds an old alarm I forgot to delete.

Yes, but the headline "Great Design From Nokia", or even Android, is unlikely to make the HN front page.

One of my favorite features! Before I had an Android phone I can't tell you how many times I bone-headedly picked PM instead of AM. Even with this feature I catch myself getting it backwards sometimes, but I get to correct it right then instead of when it's too late.

This is actually very useful and Symbian (Nokia N73) alarm app also used to do this! Saved me many times from setting wrong alarms. :)

It's all about the little big details that reduce friction in user experience. This attention to detail:

1) reduces errors and user frustration,

2) substantiates the thought in the user's mind that "the software will do what I want", and

3) teaches users that the software will accomodate them, instead of requiring the user to accomodate the software.

It would have been better, actually, if the dates also mentioned the day of week, like "Thursday, October 21 / Friday, October 22". I'm more familiar with what the day of week it is, but not necessarily what the date is.

If it mentioned the weekday, I would be able to answer "Thursday" immediately, since I know that I intended it for Thursday, but I wouldn't necessarily know that it was the 21st without looking at my watch.

>better, ... if ... also ... day of week

If I'm talking to robots after midnight, I don't know the date. This has been proven by scientists.

That's interesting. Source?

> but I wouldn't necessarily know that it was the 21st without looking at my watch

> without looking at my watch

> watch

ಠ_ಠ

Wouldn't your phone have the date?

If I'm in Siri mode, then I would have to a) turn the phone off and on again to get the lock screen date, or 2) ask Siri, both of which would interrupt this prompt and require you to ask the original question again after finding out what day it is.

But if you say "Today", and it says "8th or 9th" — You immediately know it doesn't mean "Last week, and in a month." You know it's morning and it means today, or tomorrow.

Oh. Yeah, you're right, that's a great point.

This is what causes my love-hate relationship with Siri: when it works, it's a fantastic experience and gets little details like this spot-on; when it doesn't, it's off by a mile. More frustratingly, it doesn't seem to improve much between major iOS releases despite being mostly a thin client to Apple's services.

To be fair, I generally prefer obvious failure rather than quietly doing the wrong thing (which is what probably would have happened here), but even really simple stuff like "take me home" only seems to work as expected half the time.

(I'm ignoring situations where the voice recognition fails outright, since that's a totally different problem - this just relates to handling of correctly-interpreted commands)

Like many others, I wonder what Apple's QA and user feedback processes look like with Siri. Unlike Maps, there's no way (AFAIK) to report a crappy Siri response, so while I'm sure they have stats on low-confidence speech-to-text results, I'm not sure what they do to determine "you heard me right, but you did the wrong thing" or "doing X instead of Y would have been a lot more useful". As such I assume most of it is internal QA process, and Apple's secrecy around new features (fortunately Siri no longer qualifies as such) definitely hurts QA that requires a lot of real-world usage.

If you're aware that Siri is "mostly a thin client to Apple's services", why would you expect it to update with iOS releases? If it's a thin client, it can be updated (or not updated) at anytime on the server side.

That's my point - I expect it to get incrementally better between major releases[1]. That doesn't seem to happen - at least not on the response handling. Voice recognition seems to improve slightly, but that's the nature of having lots of training data.

[1] On new functionality that requires resources installed on the phone (the new sports scorecard things, for example), I understand that only happening on new releases. When I say "take me home" and it only starts navigation sometimes, it clearly has the ability to start nav based on something, so I expect that to happen more reliably.

I'm not positive it is.

If you are in Canada and ask Siri for something like "where's the nearest coffee shop", in iOS 5 you get "I don't support that in Canada", but in iOS 6 you get the expected results.

I'd assume the device version + iOS version + device ID is sent in the request and Apple maps this to the corresponding Siri version/database/API.. there would be no technical reason why iOS 5 can't see the same POI's as 6, only whatever business policy Apple has decided to implement. eg. freezing updates to the 5's database.

I'm sure the back-end processing is the same, but because 6 supports or will support new commands, then they are running separate instances & databases which results in varying update schedules.

As long as they don't restrict based on device model (only iOS version) then I'm happy with that.

They said it doesn't improve between releases. As opposed from from release to release.

Actually, this isn't the best possible design. As others here have already pointed out, a better design would be presenting the options as:

4 hours from now

28 hours from now

This one doesn't require me to know the current date and also works as a sanity check to make sure I'm not confusing AM and PM.

I think the majority of people would react poorly to that.

"Why are you asking me about number of hours, Siri?! I just said tomorrow, damnit!".

But you don't need to know the current date to know which one comes first. Well, unless the dates were in the past.

Great point. I think Fried's example is a little confusing to us because we don't remember right now what days Oct 21 and 22 were. But in the context of the interaction it should be fairly clear that, "Oh, it's just after midnight, Siri's confused because I actually meant today not tomorrow." The actual dates (21 vs 22) wouldn't matter, the two days Siri is trying to choose between is obvious in the moment.

I think the best would have been learning your tomorrow/today pattern and monitoring your use of the phone. For example, a "common" person will continue to use to tomorrow post-midnight until they have slept. The phone should monitor for lack of movement and use over 4-6 hours to identify a sleep schedule that is the person's day divider (patent pending!).

I think it's highly probable that if Apple put in enough thought to implement this feature at all, they thought of and tried out all the possibilities. Number of hours seems unnatural to me.

>they thought of and tried out all the possibilities

This doesn't guarantee to come up with the best implementation.

Do you always naturally know the date? Personally, I don't.

I will, however, always know how long 4 hours are, even if I travel to another planet someday. It also has the additional benefit of working as an AP/PM check.

My only complaint with this is that I often have no idea what day it is. I'd love it if it added the day of the week as well. "It's after midnight, did you mean today, Tuesday, or yesterday, Monday the Xth day."

I too have seen this a handful of times and thought, "Wow, that's really clever Siri!" only to realize a few seconds later that Oct 21st vs Oct 20th does not help me and I am still screwed. Then I cancel out and go look at the calendar day and then re-sirify it.

Then again I am not that smart.

Hint: You don't need to know the date to know which option to pick.

maybe you do if you're close to falling asleep.

I don't understand why so many people are taking issue with this and missing the obvious point. You don't need to know what the current date is. It's not asking you to schedule something in the past or in the distant future.

It's showing you the next two occurrences of the time you requested and asking if you want to be notified on the next occurrence of that time or the following one.

So why show something you don't really need? The day of the week makes things much more obvious.

You have a point. Fuzzier dates are often better. Perhaps it's a space constraint.

I wonder what the workflow is in the Apple teams that allows them to catch stuff like this. Is this the work of a single, smart programmer, or a good QA team?

It's most likely from a strong culture of interaction design and usability testing. During the design process, you usually do usability tests with would-be users and they can help illuminate issues with your design. In this case, it may have even been during testing that a person said, "well that's not what I meant by tomorrow."

Pretty much every time I do a usability test or study, random users catch small things like this that help make a product much better. When you design without feedback, you have your own mental model of how everything is supposed to work. But you're the designer and the expert, and users are not. They often find different ways to use your product than you intended.

But it's even more impressive because you could do usability testing all day long (during work hours) and never catch this issue. It's when someone's _really_ using it where something like this comes up.

I'd imagine someone was dogfooding and had an 'ah hah!' moment when they hit a similar issue. Often the best way to spot anything missing.

Like talking into a prototype iPhone at 00:35 while drunk in a bar? :D

Considering it is Siri, it is not a good QA team. Probably a programmer who set an alarm shortly after midnight one time and had an unexpected result.

It's possible this wasn't actually an Apple designer - Siri was fairly well featured when they acquired it.

This has to be internal user testing feedback.

One of those delicate edge cases that you find once you start using a product.

It's called user experience design.

I've also benefitted from this condition once but it would have been helpful to show a day of the week beside the date for added clarity.

Did you mean Sunday October 21st, or October 22nd?

Boy I can't wait for the day when we look at this screenshot and chuckle that it was even needed. My problem with Siri and others is that if I have to look at the screen after every command, it kills away a huge chunk of the benefit. If Siri was a human, it is the equivalent of having the human repeat what he heard every time you made a request to confirm he understood you correctly. That would be annoying. And often just easier to do it yourself.

This is one area there is massive room for innovation. I'd give it a few years before we can say a command like "hey iphone, text mom that I am home" and within seconds, hear back "done!". I'd know with confidence that the right message was sent. Even more importantly, I'd be able to do all this without needing to lift my phone, or have to get closer to the phone or speak too much louder than whispering the request to an assistant.

Whilst that may seem like intellegent design, you'll notice that you can't see the current date anywhere on that screen without making assumptions.

This screen would make me feel uneasy and over-analyse the options. (Does it mean yesterday or today? today or tomorrow?)

It would be nice if it also showed the day of the week on each option.

Discussion on Reddit from a month ago: http://www.reddit.com/r/apple/comments/10f3al/clever_siri_if...

In that thread, I commented:

In my opinion a much better question would be "Do you mean in 9 hours?". If you say yes, set it for today. If you say no, then it's tomorrow.

I think

"Alarm set for 9 hours, is this correct?"

Is less intimidating for the user, this way they aren't being asked to calculate something, rather being asked to confirm a calculation.

The difference is trivial and subtle.

Sure, this is even better.

Does anybody know how "Google Now" handles this?

Got this: http://ompldr.org/vZzZtNA

I believe if you don't say 'tomorrow' it will work correctly. It is pretty annoying.

I'd test it myself but I sold my Galaxy Nexus on Craigslist, waiting for the Nexus 4 to be released.

Yes, it did work: http://ompldr.org/vZzZtaA

Which means you'll have to sleep after midnight if you want your Android phone to wake you, or wait for an update (like Sleeping Beauty.)

Android alarms work a bit differently to what you are thinking. The basic alarms are set around times, and when the time comes around, the alarm goes off. So as long as it's after 9:01 am when you use this command, the alarm will go off at 9am the next day correctly.

To deal with days the alarms have a 'repeat' option, listing which days the alarm should go off. Google Now can't handle these kinds of alarms yet. If you needed an alarm for a specific day then you'd probably use calendar alarms, however I don't think they're fully linked into Google Now at the moment.

Yeah this is not the case. It just sets it for the next available 9pm.

Google Now doesn't do specific dates yet.

I constantly check this website for nice little touches that usually go unnoticed: http://littlebigdetails.com/

Maybe this was apparent to everyone using Siri, but today I asked it/her "Who is my girlfriend?" it replied what is your girlfriends name? I told it It then set the alias "Girlfriend" to her and now I can say "Siri send a message to my girlfriend saying I love you"

which I think is totally awesome. Im late to the Siri party though...

I just want to point out that this must be a recent innovation, because only two weeks ago I got screwed over by telling Siri to create an appointment "tomorrow" after 12am, and she booked it for the day after and told me she created the appointment for "tomorrow" (no date).

One time I had to set my alarm for 4am (early flight) and Siri said, "OK, but don't wake me up!". On the one hand that's pretty funny of course, but on the other hand, I think it's a helpful sanity check for you to make sure you didn't actually mean 4pm.

On the other hand, 4 and 16 are hard to confuse ;-)

This is the difference between a programmer's understanding of "tomorrow" and a user's.

My girlfriend insists that, as soon as the clock ticks over to 12:00AM, "tomorrow" means a full 24 hours later. I still insist "tomorrow" doesn't change up until you sleep (or stay up all night).

Your girlfriend is correct, obviously, they always are, even when they aren't. Especially if you're planning on getting anything other than sleep in that next "full 24 hours"

Funny, me and a few friends have the same logic of 'if you've not slept it's the same day', thought we were just odd as I've come across no one else that had the same opinion.

My friends do something similar, so you're not alone. I think it's just something that night-owls do.

You're both wrong. If I don't sleep for 48 hours (which has happened more than once), I haven't only elapsed one day. Her definition means that "tomorrow" can only ever refer to one instant in time which doesn't seem to fit the "common man" definition of "tomorrow".

I had a miscommunication with an old boss once. He had sent me an email asking me to do a few tasks. He had written "do x or y and z" His intent in the email was for me to do either task x or task y, and regardless then do z. However the way he had written it I had parsed it as

if(x){ taskX(); else { taskY(); taskZ(); }

He was pretty angry when I had only done task x.

When not using parenthesis, humans speak in an unqualified (as in no special clarifications) left to right order.

Think of someone vocally (because that's often how people type --- as though they're speaking) telling you a series of arithmetic:

One plus two times three minus four plus three times two.

To vocally say that, in the above order, with proper math, it would probably be something like: One, plus the result of two times six, minus four plus the result of four times two.

For reference, we have no idea what you meant by "One plus two times...". There is no meaning to us until you add commas or add some intonation or canter so that we can determine pauses to do sort of local evaluation. I can pretty easily read that to mean:

One + (2 * 3) - (4+(3 * 2)) ("One; plus two times three; minus four plus 3 * 2")

Or (One + (2 * 3) - (4+3) * 2) ("One; plus two times three, minus four plus three; [1] times two).

But in reality, even the times two is still quite vague, even being generous with taking pauses as groupings. That's why people say things like "... all times two." or more importantly why we rarely do math purely vocally and why we have "The quantity [...] plus the quantity [...]" etc.

edit: HN, it's 2012. Frigging implement Markdown and get it over with.

I was recalling how my mother would, in the past, relay me numbers for accounting, for example. Usually it was a large sequence of plusses; and, people don't always put pauses when they're rattling off numbers. That was my point. Glad to hear it confused you :)

In Japan (where they use a 24 hour clock), opening hours for stores/restaurants, or broadcast times for TV shows will often be written as something like "27:00", which would mean 3 AM (24+3).

Although I've also seen a "Track 0" at a train station.

I really really love that here in Germany, places will refer to e.g. "Friday 24:00" to mean 00:00 on Saturday.

The phrase "Friday at midnight" actually means six hours after 6PM on Thursday, of course, so using 24:00 versus 00:00 to disambiguate which day is meant is wonderful.

One way to avoid any confusion when timetabling things is to always schedule stuff for 23:59 or 00:01 -- then it's unambiguously inside one of the days.

Math in spotlight on os x showed me that there is someone in the company who pays attention to how a user uses the system. Not just the math part, but the fact that you can copy the result to the pasteboard with the keyboard shortcut

But it always annoys me when selecting the result doesn't open the same math problem in the calculator app (like how QuickLook will open a video at the exact same playhead position + window position)

True, very true. I hate when I mistakenly hit enter and it opens a blank calculator. One would assume that the calculator has an api where you can send queries to it, maybe it doesnt have one for 'open with predefined equation'

I wouldn't assume that — a Cocoa application process is an insane amount of overhead for a simple arithmetic expression evaluator, so who'd bother using it? Assuming Spotlight uses the same underlying evaluator, it's a safe bet that it's implemented as a library shared between the Spotlight search UI and the app. To be even more specific, on 10.8 at least, both Calculator.app and Search.bundle link to a private framework called Calculate, which may be relevant.

When I first saw the Siri Query, I was anticipating it would try to disambiguate A) remind me (to inflate my tires tomorrow) (at 9:00) vs. B) remind me (to inflate...) (tomorrow at 9:00). I guess I was overthinking it.

This seems common sense to me, I would most likely have done it this way if I were designing a voice operated alarm module. Hence it follows Apple is already likely to have a patent on it.

Someone once said that the best things about good software are the things you don't notice but improve your life. Case in point here.

I wouldn't call it great design. I'd call it lack of bad design. I feel like asking which day you're referring to is an extremely obvious step in selecting a time. The fact that we're surprised by it is a testament to how terrible most productivity software is.

This is why everyone should test things... stuff like this falls out of good testing if you miss it on a first pass. :)

some people could learn from that idea - even if they already hire 1.5 testers for each programmer.

(yes i mean microsoft)

Excellent. I would love to know who, from Apple, suggests this details.

This particular feature may been less a function of Apple design philosophy and more a function of Siri being built on top of a contextually-sensitive disambiguation engine.

Yeah, it's not about the literal details, but how the user perceives the details.

I love this post so much. Please upvote onto front page so more people can be made aware that Apple and Siri exists, and they are the bestest.

Reply on news.ycombinator.com