3 ms·

>"Show me a commercially viable, available, highly-sensitive touch screen (that responds to fingers) small enough to fit in your pocket (an environment with err

by sbuk 13y ago

>"Show me a commercially viable, available, highly-sensitive touch screen (that responds to fingers) small enough to fit in your pocket (an environment with erroneous input) that is as responsive as the one of the first iPhone and that existed before the iPhone was revealed?" Why move the goalpost? Your claim is that the mechanism is obvious, not that the technology didn't exist. If a line can be reasonably accurately drawn with a stylus (as on the Newton and Palms which followed) then it can track a simple swipe. I played games on my Palm pilot that employed dragging as a mechanism, so why not a security measure? Again, the "swipe to unlock" didn't exist because it was not obvious and you are employing confirmation bias to further a view that influenced by hindsight bias. I did rebut your points; hindsight bias. >"With that in mind, twisting/arcing and sliding are the obvious solutions to anyone with knowledge of locks, digital, physical or otherwise" And the PIN isn't more obvious for digital devices?

malandrew 13y ago
Because it's not a security measure. The keypad is a security measure. You're mistaking the purpose of slide to unlock. It's an erroneous input measure aimed at preserving battery life. When a phone is on the lock screen the timer before it shuts off the screen is very short. When phone is unlocked, the assumption is that the user is engaged with the phone, possibly reading/scanning whats on the screen, so the inactivity timer before the phone reverts to inactive mode is much longer. If a phone can easily end up in unlocked mode repeatedly over the course of normal daily use, then the chances that the battery is not going to make it through the day is much much higher. All touch screens prior to the iPhone really only responded to stylus input. Many had special tip materials to work with the screens they were designed for. With those devices, the chance that anything in your bag or pocket that came in contact with the screen would inadvertently register as legitimate user input was infinitesimally low, thus a simple tap was sufficient. When Apple achieved a high quality capacity touch screen that could legitimately accept continuous human finger movements as input reliably, the goal posts changed. To achieve the quality of input Apple achieved, they needed a screen that was far far more responsive to input than anything prior. This was a necessary hardware innovation for any touch interface that can collect enough input for software engineers to code gestures [0]. With this hardware innovation, they now were exposed to new problem which was not present on previous touch devices. No previous stylus or shitty finger touch device prior to the iPhone was likely to respond to erroneous input. For example, no palm device really detected finger input so you could very effectively handle in daily, like just holding it casually in your hand, possibly fidgeting with it, while you were engaged in conversation with another person. This meant that the opportunities for wasting battery was much much much higher than with any device that previously existed, enough so that it was a problem that had to be addressed. Remember that the first iPhone battery couldn't even last through one full day of regular use. To solve the problem, there was essentially several levels of commits required. Previous devices used the power button to activate the screen and then a stylus could tap to unlock. The chances that the power button would be pressed and then be immediately followed by stylus input could not really occur accidentally, therefore a gesture like slide to unlock was completely unnecessary. Apple then comes along and experiences a problem that didn't need to be solved before. Only they knew of the problem because only they had the technology to experience it. I'm not arguing that they didn't succeed in applying a timeless idea to a novel situation. I'm arguing that it would have been obvious to any interaction designer at the time versed in the state of the art in interaction design. Apple's secrecy affords them a monopoly on being the only people versed in the state of the art that know the problem exists. The thought experiment that needs to be excersized to determine obviousness is to ask if someone else versed in the state of the art would likely have arrived at the same conclusion. The fact that only Apple knew what state of the art is moot here, what matters is the mental exercise of testing obviousness all things considered. This recent vanity fair article does a good job of chronicling the degree of secrecy surrounding the importance of maintaining a an information monopoly on what is state of the art. http://www.vanityfair.com/business/2014/06/apple-samsung-smartphone-patent-war.print http://www.vanityfair.com/business/2014/06/apple-samsung-sma... I currently work at a company where we a similar informational advantage. There are many times over the past year, were I'd see us do something seemingly novel, but are really obvious to interaction designers once they recognize the capabilities of the framework we've created ( https://famo.us/ https://famo.us/ ). In fact, I've on more than one occasion seen people implement the same solution to design problems, unaware (i.e. having never see) of prior internal code/design explorations we've built over the past 2 years in archived code repos. For example, we've made it possible to explore some pretty complex ways to apply some of the 12 Disney Animation Principles to DOM elements. Does it mean that we should get a patent on applying it to DOM? Heck no, the 12 principles are state of the art for anyone version in interaction design. One of our previous designers worked on designing moving interfaces, including the Iron Man HUD interface. He's a textbook example of someone versed in state of the art in interaction design. You drop him in the realm of DOM-based interaction design and he's going to apply ideas not yet explored with the DOM, but that doesn't make those ideas any less obvious to someone versed in the state of the art. We (famo.us) have a few patents in the final assignment stages (of which my name and the names of 3 others are on it [1]), that presents alternate solutions to several of the crown jewel patents at the core of the Samsung-Apple patent trials, including one of key patents ('381 rubber banding) in the $1+ dollar plus settlement (later reduce to just under $1 billion) between those two companies. This is why I'm intimately familiar with all the patents at play between Apple and Samsung. I've read all of them multiple times. Slide to unlock is really one of those stupidly obvious things to someone versed in state of the art. Honestly, there are many obvious things we've made in the past ~2 years since I've been at famous that to someone not trained in the state of the art look novel and worthy of patenting. We haven't done that, because getting a patent on something that you know, but you know you can get away with patenting is a ethically reprehensible. Unfortunately Apple files these types of patents by the bucketload. Personally, I think every engineer at Apple (or anywhere else) that knowingly files one of these patents is abdicating their professional duty (although I with admit that its entirely possible that many have just drunk the Kool-Aid and actually think they are deserving of such obvious patents. Given Apple's culture and former megalomaniac leader, I wouldn't be surprised). They maintain a ridiculously high level of secrecy for as long as possible not only for marketing reasons, but because it gives them a long window to patent all the obvious shit that people would imagine if they knew what Apple was working on at any given time. [0] I've written a few non-public js libraries from scratch that interpret many of the gestures that Apple supports so I know the data requirements here to be able to accomplish what they did. This is why, even though I hate patents, I'm supportive of the patent claims around the capacitive touch screens. They legitimately moved the state of the art forward with regards to the input hardware. Over a year ago I implemented in js: Long Press, Pan, Pinch, Generalized multi finger taps, Debugging modes to visualize touch. What I did not get to before moving onto another project was creating a test mode asking users to perform actions, so I could apply an artificial neural network to tweak the tolerance coefficients. I'm far from a pro in this area, and yeah it was 2012/2013, not 2007, but I'd definitely say that I'm reasonable well versed in state of the art that I can understand the design mindset involved in solving touch-input problems, which is why I'm stressing the conditions/problems that led to the innovation. That's not moving the goal post, that's called performing a thought experiment where you put yourselves in the shoes of a designer at Apple at that time when only Apple knew of the problem. If you can paint a picture of the problem to be solved and the constraints under which they need to be solved, you have enough information to present to any interaction designer at the time and ask, would this be an obvious solution if you had been privileged to the same information/constraints? [1] I personally abhor patents, but its part of the game when you are dancing with 500lb gorillas in your business development deals. Furthermore, our patents actually serve the commons in our case because our library is MPL-2.0 licensed, so members of our community using our code are protected by it against aggressors trying to assert patent claims (like the Lodsys non-practicing entity)
- deleted 13y ago
  [deleted]

by sbuk 13y ago

malandrew 13y ago

Because it's not a security measure. The keypad is a security measure. You're mistaking the purpose of slide to unlock. It's an erroneous input measure aimed at preserving battery life. When a phone is on the lock screen the timer before it shuts off the screen is very short. When phone is unlocked, the assumption is that the user is engaged with the phone, possibly reading/scanning whats on the screen, so the inactivity timer before the phone reverts to inactive mode is much longer. If a phone can easily end up in unlocked mode repeatedly over the course of normal daily use, then the chances that the battery is not going to make it through the day is much much higher. All touch screens prior to the iPhone really only responded to stylus input. Many had special tip materials to work with the screens they were designed for. With those devices, the chance that anything in your bag or pocket that came in contact with the screen would inadvertently register as legitimate user input was infinitesimally low, thus a simple tap was sufficient. When Apple achieved a high quality capacity touch screen that could legitimately accept continuous human finger movements as input reliably, the goal posts changed. To achieve the quality of input Apple achieved, they needed a screen that was far far more responsive to input than anything prior. This was a necessary hardware innovation for any touch interface that can collect enough input for software engineers to code gestures [0]. With this hardware innovation, they now were exposed to new problem which was not present on previous touch devices. No previous stylus or shitty finger touch device prior to the iPhone was likely to respond to erroneous input. For example, no palm device really detected finger input so you could very effectively handle in daily, like just holding it casually in your hand, possibly fidgeting with it, while you were engaged in conversation with another person. This meant that the opportunities for wasting battery was much much much higher than with any device that previously existed, enough so that it was a problem that had to be addressed. Remember that the first iPhone battery couldn't even last through one full day of regular use. To solve the problem, there was essentially several levels of commits required. Previous devices used the power button to activate the screen and then a stylus could tap to unlock. The chances that the power button would be pressed and then be immediately followed by stylus input could not really occur accidentally, therefore a gesture like slide to unlock was completely unnecessary. Apple then comes along and experiences a problem that didn't need to be solved before. Only they knew of the problem because only they had the technology to experience it. I'm not arguing that they didn't succeed in applying a timeless idea to a novel situation. I'm arguing that it would have been obvious to any interaction designer at the time versed in the state of the art in interaction design. Apple's secrecy affords them a monopoly on being the only people versed in the state of the art that know the problem exists. The thought experiment that needs to be excersized to determine obviousness is to ask if someone else versed in the state of the art would likely have arrived at the same conclusion. The fact that only Apple knew what state of the art is moot here, what matters is the mental exercise of testing obviousness all things considered. This recent vanity fair article does a good job of chronicling the degree of secrecy surrounding the importance of maintaining a an information monopoly on what is state of the art. http://www.vanityfair.com/business/2014/06/apple-samsung-smartphone-patent-war.print http://www.vanityfair.com/business/2014/06/apple-samsung-sma... I currently work at a company where we a similar informational advantage. There are many times over the past year, were I'd see us do something seemingly novel, but are really obvious to interaction designers once they recognize the capabilities of the framework we've created ( https://famo.us/ https://famo.us/ ). In fact, I've on more than one occasion seen people implement the same solution to design problems, unaware (i.e. having never see) of prior internal code/design explorations we've built over the past 2 years in archived code repos. For example, we've made it possible to explore some pretty complex ways to apply some of the 12 Disney Animation Principles to DOM elements. Does it mean that we should get a patent on applying it to DOM? Heck no, the 12 principles are state of the art for anyone version in interaction design. One of our previous designers worked on designing moving interfaces, including the Iron Man HUD interface. He's a textbook example of someone versed in state of the art in interaction design. You drop him in the realm of DOM-based interaction design and he's going to apply ideas not yet explored with the DOM, but that doesn't make those ideas any less obvious to someone versed in the state of the art. We (famo.us) have a few patents in the final assignment stages (of which my name and the names of 3 others are on it [1]), that presents alternate solutions to several of the crown jewel patents at the core of the Samsung-Apple patent trials, including one of key patents ('381 rubber banding) in the $1+ dollar plus settlement (later reduce to just under $1 billion) between those two companies. This is why I'm intimately familiar with all the patents at play between Apple and Samsung. I've read all of them multiple times. Slide to unlock is really one of those stupidly obvious things to someone versed in state of the art. Honestly, there are many obvious things we've made in the past ~2 years since I've been at famous that to someone not trained in the state of the art look novel and worthy of patenting. We haven't done that, because getting a patent on something that you know, but you know you can get away with patenting is a ethically reprehensible. Unfortunately Apple files these types of patents by the bucketload. Personally, I think every engineer at Apple (or anywhere else) that knowingly files one of these patents is abdicating their professional duty (although I with admit that its entirely possible that many have just drunk the Kool-Aid and actually think they are deserving of such obvious patents. Given Apple's culture and former megalomaniac leader, I wouldn't be surprised). They maintain a ridiculously high level of secrecy for as long as possible not only for marketing reasons, but because it gives them a long window to patent all the obvious shit that people would imagine if they knew what Apple was working on at any given time. [0] I've written a few non-public js libraries from scratch that interpret many of the gestures that Apple supports so I know the data requirements here to be able to accomplish what they did. This is why, even though I hate patents, I'm supportive of the patent claims around the capacitive touch screens. They legitimately moved the state of the art forward with regards to the input hardware. Over a year ago I implemented in js: Long Press, Pan, Pinch, Generalized multi finger taps, Debugging modes to visualize touch. What I did not get to before moving onto another project was creating a test mode asking users to perform actions, so I could apply an artificial neural network to tweak the tolerance coefficients. I'm far from a pro in this area, and yeah it was 2012/2013, not 2007, but I'd definitely say that I'm reasonable well versed in state of the art that I can understand the design mindset involved in solving touch-input problems, which is why I'm stressing the conditions/problems that led to the innovation. That's not moving the goal post, that's called performing a thought experiment where you put yourselves in the shoes of a designer at Apple at that time when only Apple knew of the problem. If you can paint a picture of the problem to be solved and the constraints under which they need to be solved, you have enough information to present to any interaction designer at the time and ask, would this be an obvious solution if you had been privileged to the same information/constraints? [1] I personally abhor patents, but its part of the game when you are dancing with 500lb gorillas in your business development deals. Furthermore, our patents actually serve the commons in our case because our library is MPL-2.0 licensed, so members of our community using our code are protected by it against aggressors trying to assert patent claims (like the Lodsys non-practicing entity)

deleted 13y ago
[deleted]