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
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 :)
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).
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.
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"
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".
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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).
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
Too bad Siri simply doesn't work most of the time. At least half of my requests end in Siri responding with "I'm sorry, I can't process your request at this time". Useless, I just avoid it altogether.
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.
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 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.
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.
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).
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.
112 comments
[ 4.7 ms ] story [ 135 ms ] threadif(x){ taskX(); else { taskY(); taskZ(); }
He was pretty angry when I had only done task x.
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.
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.
Although I've also seen a "Track 0" at a train station.
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.
I'd test it myself but I sold my Galaxy Nexus on Craigslist, waiting for the Nexus 4 to be released.
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.
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.
One of those delicate edge cases that you find once you start using a product.
Did you mean Sunday October 21st, or October 22nd?
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.
If I'm talking to robots after midnight, I don't know the date. This has been proven by scientists.
> without looking at my watch
> watch
ಠ_ಠ
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.
As a bonus, it gives a good estimate on how much sleep I'm going to get.
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 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'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.
[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.
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.
"Why are you asking me about number of hours, Siri?! I just said tomorrow, damnit!".
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.
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.
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.
some people could learn from that idea - even if they already hire 1.5 testers for each programmer.
(yes i mean microsoft)
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.
"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.
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.
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.