"I think the ideal would be for most road conditions, detours, and traffic issues to be kept up-to-date on a database that could allow for dynamic routing instead of the car relying completely on markers."
*Crowdsourcing long-term knowledge* Unlike humans, the cars will already know where the road markings are, even when theyâ(TM)re covered: "Collaborative 3D Scanning with Paracosm and Project Tango" â" âoemultiple entities scan different parts of same the space, and join the data to create a 3-D modelâ: http://i.imgur.com/Y4OOdRe.gif.
*Crowdsourcing real-time knowledge* Now in terms of real-time conditions, and winter driving, autonomous cars could constantly refresh each other with new information. Thereâ(TM)s a four-way stop thatâ(TM)s about two blocks from my house. When there is a good sheet of black ice, youâ(TM)ll see car after car slip and slide; itâ(TM)s extremely dangerous. As soon as a driverless car detects black ice, itâ(TM)s going to alert every single other autonomous car, and update them with the new info about that location.
In a video of Eye Tribeâ(TM)s presentation at Techcrunchâ(TM)s Hardware Battlefield, they distinguish between active control, where youâ(TM)re using your eyes to manipulate interface elements, and passive control, such as when your eye gaze approaches the bottom of a webpage of text, it automatically scrolls down.
They emphasize passive control in the presentation, but I think that itâ(TM)s because here, youâ(TM)re using your eyes already. If you look at an interface widget to highlight it, and then touch something to activate and select it, I think thatâ(TM)s passive because your eyes usually go to the target before your hands mechanically react.
Iâ(TM)m guessing that active control, like eyes only fruit ninja, will occur a lot less of the time, since you still have your hands. It would be useful for future computer glasses if youâ(TM)re doing something else with your hands.
Changing the dwell time could be a very common action for web browsing (eye tracking interfaces allow you to activate a graphical widget by dwelling on it, and you can set the time that you need to fixate on the target). For example, if you are on a website that youâ(TM)ve never been to before, you might want to more carefully and slowly examine the hyperlinks, so you might choose to put a longer dwell time for activating links and other web elements. On another tab, you might be on one of your favorite websites, and youâ(TM)re familiar with the location of all the webpage links and menus. Having a âoechange dwell timeâ switch element already up on the screen will allow you to quickly switch to a lower required activation time so you can navigate through your favorite site faster.
*Comfort* I have not seen any examples of a developer doing serious programming on a touchscreen. Iâ(TM)ve seen programmers that operate in a three-monitor environment, and I don't think that repeatedly reaching their arms across to touch the screens would be comfortable over time.
Gorilla arm syndrome: "failure to understand the ergonomics of vertically mounted touchscreens for prolonged use. By this proposition the human arm held in an unsupported horizontal position rapidly becomes fatigued and painful".
Eye control can be much lower in physical exertion.
*Augmentation, not replacement*
Eye control can be an additional input that works together with your hands.
e.g. you can use a macro program like Autohotkey to remap a keyboard button to click.
Appskey::Click
Look at any interface widget to highlight it, and then touch the application key on the keyboard to left-click and select it.
*Bringing speed and concept of virtual buttons like Android launcher icons, and Windows 8 tiles to desktop users*
Lastly, after using Autohotkey for remapping, I soon didn't have enough keyboard buttons to attach macros and lines of code to them, so I'd have to make new scripts that use the same button. After more scripts, it can be easy to forget which button does what.
You can now optionally take away your hands for moving the mouse cursor. Instead, stare at a target on-screen button, and using a keyboard button to click, you can instantly invoke custom virtual buttons that have your macros and commands that are attached to them. Quick activation of on-screen interface elements without a touchscreen is now more feasible. It virtually turns a non-touch screen into a touchscreen. You could pretty much design the buttons and controls to look however you want. Customizable, virtual buttons are infinitely more productive than static physical keys.
*Example:*
e.g. I remapped F1 to launch a google search on whatever is on the clipboard: F1::Run google.com/search?hl=en&safe=off&q=%Clipboard%.
With another script, F1 could execute something completely different. And within that script, depending on the context, such as what program is currently running, or what window is in focus, the use of F1 could change again; it can get confusing.
It would be more intuitive to look at a virtual button that is actually labeled, "Google Search the Clipboard", and then tap my activation key.
*Already using your eyes*
Before you move your mouse to select something, it is very likely that your eye gaze goes to the target first. The same thing goes for touch user interfaces. Your eyes are most likely already âoetouchingâ the interface widgets before you decide to actually reach out and physically touch them.
*Achieving different actions on a target: eye highlighting + touching virtual function buttons vs. touch gestures alone vs. mouse clicking on a desktop*
Eye highlighting + function buttons
If you had eye control on a touch device, you could have multiple go-to, base, function buttons (could be two or three) that you can press after you highlight something with your eyes.
Example: a video
E.g. You look at a video that youâ(TM)re about to watch, and then you could press function button one to open and play it, press function two to preview a thumbnail-sized highlight reel of it, and function three could be set to do whatever other command you want, like go to the comments section.
Touch alone: multiple touch gestures for different actions
Currently, if I take something like the Chrome icon on the home screen of Android, I can tap it to open it, or long-press/hold it to move it. (There's also double tap, triple tap, and swiping that are available for use, but I think it ends there).
Desktop: different types of mouse clicking for different actions
For desktop users, left and right single click, left and right double-click, left and right mouse drag, and the m
Slashdot Mirror
"I think the ideal would be for most road conditions, detours, and traffic issues to be kept up-to-date on a database that could allow for dynamic routing instead of the car relying completely on markers."
*Crowdsourcing long-term knowledge*
Unlike humans, the cars will already know where the road markings are, even when theyâ(TM)re covered: "Collaborative 3D Scanning with Paracosm and Project Tango" â" âoemultiple entities scan different parts of same the space, and join the data to create a 3-D modelâ: http://i.imgur.com/Y4OOdRe.gif.
*Crowdsourcing real-time knowledge*
Now in terms of real-time conditions, and winter driving, autonomous cars could constantly refresh each other with new information. Thereâ(TM)s a four-way stop thatâ(TM)s about two blocks from my house. When there is a good sheet of black ice, youâ(TM)ll see car after car slip and slide; itâ(TM)s extremely dangerous. As soon as a driverless car detects black ice, itâ(TM)s going to alert every single other autonomous car, and update them with the new info about that location.
Active control versus passive control
In a video of Eye Tribeâ(TM)s presentation at Techcrunchâ(TM)s Hardware Battlefield, they distinguish between active control, where youâ(TM)re using your eyes to manipulate interface elements, and passive control, such as when your eye gaze approaches the bottom of a webpage of text, it automatically scrolls down.
They emphasize passive control in the presentation, but I think that itâ(TM)s because here, youâ(TM)re using your eyes already. If you look at an interface widget to highlight it, and then touch something to activate and select it, I think thatâ(TM)s passive because your eyes usually go to the target before your hands mechanically react.
Iâ(TM)m guessing that active control, like eyes only fruit ninja, will occur a lot less of the time, since you still have your hands. It would be useful for future computer glasses if youâ(TM)re doing something else with your hands.
Changing the dwell time could be a very common action for web browsing (eye tracking interfaces allow you to activate a graphical widget by dwelling on it, and you can set the time that you need to fixate on the target). For example, if you are on a website that youâ(TM)ve never been to before, you might want to more carefully and slowly examine the hyperlinks, so you might choose to put a longer dwell time for activating links and other web elements. On another tab, you might be on one of your favorite websites, and youâ(TM)re familiar with the location of all the webpage links and menus. Having a âoechange dwell timeâ switch element already up on the screen will allow you to quickly switch to a lower required activation time so you can navigate through your favorite site faster.
*Advantages:*
*Comfort*
I have not seen any examples of a developer doing serious programming on a touchscreen. Iâ(TM)ve seen programmers that operate in a three-monitor environment, and I don't think that repeatedly reaching their arms across to touch the screens would be comfortable over time.
Gorilla arm syndrome: "failure to understand the ergonomics of vertically mounted touchscreens for prolonged use. By this proposition the human arm held in an unsupported horizontal position rapidly becomes fatigued and painful".
Eye control can be much lower in physical exertion.
*Augmentation, not replacement*
Eye control can be an additional input that works together with your hands.
e.g. you can use a macro program like Autohotkey to remap a keyboard button to click.
Appskey::Click
Look at any interface widget to highlight it, and then touch the application key on the keyboard to left-click and select it.
*Bringing speed and concept of virtual buttons like Android launcher icons, and Windows 8 tiles to desktop users*
Lastly, after using Autohotkey for remapping, I soon didn't have enough keyboard buttons to attach macros and lines of code to them, so I'd have to make new scripts that use the same button. After more scripts, it can be easy to forget which button does what.
You can now optionally take away your hands for moving the mouse cursor. Instead, stare at a target on-screen button, and using a keyboard button to click, you can instantly invoke custom virtual buttons that have your macros and commands that are attached to them. Quick activation of on-screen interface elements without a touchscreen is now more feasible. It virtually turns a non-touch screen into a touchscreen. You could pretty much design the buttons and controls to look however you want. Customizable, virtual buttons are infinitely more productive than static physical keys.
*Example:*
e.g. I remapped F1 to launch a google search on whatever is on the clipboard: .
F1::Run google.com/search?hl=en&safe=off&q=%Clipboard%
With another script, F1 could execute something completely different. And within that script, depending on the context, such as what program is currently running, or what window is in focus, the use of F1 could change again; it can get confusing.
It would be more intuitive to look at a virtual button that is actually labeled, "Google Search the Clipboard", and then tap my activation key.
*Already using your eyes*
Before you move your mouse to select something, it is very likely that your eye gaze goes to the target first. The same thing goes for touch user interfaces. Your eyes are most likely already âoetouchingâ the interface widgets before you decide to actually reach out and physically touch them.
*Achieving different actions on a target: eye highlighting + touching virtual function buttons vs. touch gestures alone vs. mouse clicking on a desktop*
Eye highlighting + function buttons
If you had eye control on a touch device, you could have multiple go-to, base, function buttons (could be two or three) that you can press after you highlight something with your eyes.
Example: a video
E.g. You look at a video that youâ(TM)re about to watch, and then you could press function button one to open and play it, press function two to preview a thumbnail-sized highlight reel of it, and function three could be set to do whatever other command you want, like go to the comments section.
Touch alone: multiple touch gestures for different actions
Currently, if I take something like the Chrome icon on the home screen of Android, I can tap it to open it, or long-press/hold it to move it. (There's also double tap, triple tap, and swiping that are available for use, but I think it ends there).
Desktop: different types of mouse clicking for different actions
For desktop users, left and right single click, left and right double-click, left and right mouse drag, and the m