But ray tracing scales better than today's popular rendering methods. According to TFA, a ray tracer will render in O(log n) time. They found that software ray tracers catch up to hardware rasterizers when scenes approach 1 million triangles. So a few simple cubes would be *much* faster with the hardware rasterizer, but it would bog down with the second scene you describe, while the ray tracer would handle it more gracefully.
Do you mean each pixel would have a brightness filter in front of it? I suppose that would work, although this display would be useless unless you have fairly white light to use it in. Your palette would consist only of the colors shining on the thing. It would probably work great in sunlight though (aside from being possibly blinding).
Wouldn't a display built like this be able to display fewer colors than a regular one? In particular, I don't see any way to control brightness or saturation with this setup.
There's no law that computer screens have to be vertical. An optimum angle would probably be 20 to 30 degrees from horizontal. I agree that working on a vertical screen for a long period of time would be unpleasant, but it would be much better on a slanted one.
I don't think there's a problem with moving your hands around. There are lots of activities that require sitting and moving a lot, and they're generally not more tiring than using a computer. I think that the extra movement would help keep us limber, and make using a computer more pleasant, rather than less.
Touch screens are not suitable for precision work, mainly because your fingers are too big. This is where it would make sense to integrate a pen as well.
That's not the fault of the touch screen. I agree that they would suck for Photoshop work -- fingers aren't precise enough, and they block your view. This would be akin to attempting to finger paint something that looks like it was drawn with a pen. For Photoshop work, you'd probably want to use a pen on a slightly slanted screen. Just like a Wacom Cintiq.
3d spatial gestures are another interesting idea, but I worry that their lack of tactile feedback and their requirement for holding your arms up would pose a problem
I think you're selling multi-touch displays short. While I agree that a device doesn't have to do everything, it's clear from the number of people who are dissatisfied with human-computer interfaces that the things they do could be done better. You're also underestimating the amount of mousing that people do. Touchscreens are no replacement for the keyboard, but they are a good replacement for the mouse (except maybe in FPS games, a special case).
Computers have a few things they do well: accept textual input, display data on big screens, and multi-task. From those it follows that anything graphical or textual is a good fit, and that while "one device to do everything" is a bad idea, one device that does many things that it happens to be good at is a great idea. For example, it's extremely common that a person wants to access the web while working on a project. It's better to have one device that can help you gracefully juggle everything you're trying to do than to have a typewriter, a web browser, a CD player, your clock, a "download machine" and a telegraph key (for IMing), each with its own chassis, competing for desk space. Up to a point, combining functions makes sense.
Computers also do one thing very badly: they don't accept input from anything other than a keyboard very well. Specialized fields do have devices that work well: graphics tablets for graphics artists and MIDI keyboards for composers, for example. The driving force behind multi-touch displays is that the "interface for the rest of us", the mouse, is a difficult and inefficient thing to use. We all have ten built-in pointing devices which we can use with aplomb -- some people even manage to use their toes as a few more -- and multi-touch displays are a way to make use of those. Much as I dislike the desktop metaphor, I must invoke it here: using a mouse to interact with a computer is akin to using a single stick to push your papers around on your desk. It's just not the best way to go about it.
I very much doubt that it would be stressful to use a multi touch display for a long time. In fact, I suspect that it would be much less stressful than making the constrained motions required by a mouse. Joints are *made* to move. It might still be a little exhausting at first.
I agree that UIs are best when they are simple... but simple is in the eye of the beholder. To me, a UI that allows me to use my skills in a direct way is a simple one. Using my fingers to move on-screen objects = simple to me. A complex UI is one that requires me to perform actions in ways that take more effort than the direct way. The direct way is the way I would do it if I were manipulating physical objects. For example, menus (especially nested ones) and window managers that don't (i.e. I have to drag and position windows myself, when the window *manager* should do it) are complex to me. Above all, attempting to convey a huge variety of instructions by pushing a box around and clicking buttons on it is complex, because it adds another layer I have to work through. If I ever my my GUI fairy godmother, I'm asking her for a laptop with a touch screen. Maybe a multi-touch screen if she looks generous.
My biggest gripe with today's computer interfaces is that attempting to funnel everything you might want to do through a mouse plus (if you're lucky) a keyboard forces you (as an interface designer) to make a difficult decision: either waste huge amounts of screen real-estate on functions you need to include, or hide them away.
What we need are interface devices that aren't so bandwidth limited. When we want to make the computer perform an action, all we are generally able to do is locate it on the screen and say "Do." On systems with multi-button mice the situation is somewhat better. Most Firefox users are familiar with "left click to follow a link, middle click to open it in another tab, and right click to get an [ick] context menu" idiom. Scroll wheels are another instance of a bandwidth-increasing addition to the system. Rather than clicking an arrow to scroll, we are now able to spin a wheel while pointing in the general area of the thing we wedant to scroll.
Some systems put the physical controls available to even better use. The Sam text editor, its successor Acme, and basically all of the Plan 9 operating utilize the mouse buttons to perform distinct and consistent actions. In Plan 9, button 1 selects, and the other two buttons, when used in conjunction with it, perform other useful actions. The exciting feature of this setup is that it moves the selection of possible actions out of the computer, where navigation is inefficient, and puts it literally under your fingertips. Rather than selecting an object on the screen then selecting an action, or vice versa, one can simply point at it and say "do this." The ability to convey specific actions in one fell swoop is what makes command line junkies (myself included) swing the way they do. What could be more exciting than marrying that power with a GUIs flexible expression?
An even more extreme example is the five button keyboard (for the left hand) + three button mouse featured in the Doug Engelbart video linked from the summary. I'm not sure how his system used them, but this setup allows for eight functions using the most obvious mapping, many more than modern interfaces. Not only that, but with chording, it's possible to increase the number of possible actions to a dizzying 255, which is probably way too many to actually make use of*: Engelbart's system uses typed commands as well as clicks rather than attempting to assign a meaning to each combination of button presses. One good way to cope with the number of possibilities is to assign a general funtion to each button, and to combine those functions to perform actions. For example, if the left mouse button selects text, the middle button pastes it, and the right mouse button cuts it, one can copy by selecting with LMB, then pressing RMB, MMB in succession. Other button actions might be "system" to trigger global system functions, "window" to do window management and "inspect" to look more closely at an item. What might happen when you press these together? Exposé, anyone? But without reaching for the keyboard.
Anyone interested in user interfaces should take a look at the Sketchpad computer program for starters, which was simply amazing, and at "Alan Kay: Graphical User Interfaces" on Google Video. GUIs have a rich history that is not evident in modern interfaces.
* This is a good thing! Even when a the system allocates a set of global button presses and applications implement their set of commands, there will still by plenty left over for the rest of us to allocate as we see fit. This is the one point where I disagree with Bunions: I love that multimedia keyboards aren't standardized, because it means that programs don't depend on the buttons they provide, which in turn gives me 32 keys (on the keyboard I have) that I can bind to any action I want, without losing any functionality.
Yes, it is invaluable. I use it to bring up a drop-down terminal, Quake-style, and the Menu key gets to bring up my keyboard-controlled program launcher. Mine are way off in the corner of my keyboard, so I use them as single-press keys rather than as modifiers.
I'll never understand the "lets take keys off the keyboard" crowd. The Windows key's default binding is barely useful (I'm amazed that Windows doesn't provide a built in facility for assigning it to other actions) and the Menu key is completely useless (what the hell did they even think this was for?) but why would any sane person want to give up the possibilities they provide? You *can* remap them, you know. For example, my Windows key drops down a Quake-style console, and my Menu key brings up a wmii style menu that lets me launch any program quickly. I'd much rather have plenty of customizable keys with no particular purpose than have only a small set of indispensable ones.
That's why you have two control keys. Of course, the best way is to make both Caps Lock and Enter act as control keys. Control where God intended + symmetry = happy camper.
That's what the other control key is for. Trying to hold control (or Shift, or Alt) with the same hand that's pressing letter keys is just asking for a typing related injury.
How do you know any program isn't a key logger? This program's key counting nature just puts the idea in your head, but in reality, there's no need for key loggers to tell you that they listen to your keyboard. You could just as easily hide one in a clock or make a screen saver that starts a key logger.
So I guess the moral is "only run open-source software."
Wow, do Gentoo and Ubuntu really have that many packages? I thought Ubuntu had around 18,000.
I think there are around 7000 packages in Arch's repos, not including unsupported user-submitted packages in what's called the AUR. Arch's repos are pretty good, meaning that most of the things I want are in there. Certainly enough to build a solid system. I'm not suggesting that Arch is a perfect fit for everyone, but since we were talking about minimal base installations, I thought it was worth mentioning. I suppose it depends on what you want to do with the system. I think most Arch users use it on the desktop, but I don't see any reason that you couldn't build a server on it either, since programs like Apache and the SQLs are in the repos (I don't know exactly what goes into a server though). This would probably be a Bad Idea anyway, due to Arch's frequent updates.
You say "full-fledged Ubuntu-like", and you also say "I'm sure it's got desktop stuff, but how many apps does [it] really have?" referring to Arch. I'm not sure what distinction you're making here. Isn't Ubuntu a desktop distro? Arch has fewer apps than Ubuntu in its repos, but I don't know exactly what it is that Arch lacks. I can't make a comparison.
I don't see how this is a significant distinction. The question, in terms you might prefer, is how virtualization using specialized hardware compares to doing the same thing in general purpose hardware. There doesn't seem to be any semantic difference. Are you just pointing out that a hardware implementation's performance is predicated on its design?
I thought to myself, "Surely this article mentioned that it's generally not a fatal disease." So I took the time to RTFA, and sure enough, it did say that. Perhaps you would have been less worried if you had taken the time to read to the fifth paragraph.
Slashdot Mirror
"...unblockable ads...."
Perhaps you are not familiar with Firefox's Adblock extension?
But ray tracing scales better than today's popular rendering methods. According to TFA, a ray tracer will render in O(log n) time. They found that software ray tracers catch up to hardware rasterizers when scenes approach 1 million triangles. So a few simple cubes would be *much* faster with the hardware rasterizer, but it would bog down with the second scene you describe, while the ray tracer would handle it more gracefully.
There would have been no contradiction, since it's the *current* standards that they deem inadequate.
Do you mean each pixel would have a brightness filter in front of it? I suppose that would work, although this display would be useless unless you have fairly white light to use it in. Your palette would consist only of the colors shining on the thing. It would probably work great in sunlight though (aside from being possibly blinding).
Wouldn't a display built like this be able to display fewer colors than a regular one? In particular, I don't see any way to control brightness or saturation with this setup.
There's no law that computer screens have to be vertical. An optimum angle would probably be 20 to 30 degrees from horizontal. I agree that working on a vertical screen for a long period of time would be unpleasant, but it would be much better on a slanted one.
I don't think there's a problem with moving your hands around. There are lots of activities that require sitting and moving a lot, and they're generally not more tiring than using a computer. I think that the extra movement would help keep us limber, and make using a computer more pleasant, rather than less.
Touch screens are not suitable for precision work, mainly because your fingers are too big. This is where it would make sense to integrate a pen as well.
That's not the fault of the touch screen. I agree that they would suck for Photoshop work -- fingers aren't precise enough, and they block your view. This would be akin to attempting to finger paint something that looks like it was drawn with a pen. For Photoshop work, you'd probably want to use a pen on a slightly slanted screen. Just like a Wacom Cintiq.
3d spatial gestures are another interesting idea, but I worry that their lack of tactile feedback and their requirement for holding your arms up would pose a problem
I think you're selling multi-touch displays short. While I agree that a device doesn't have to do everything, it's clear from the number of people who are dissatisfied with human-computer interfaces that the things they do could be done better. You're also underestimating the amount of mousing that people do. Touchscreens are no replacement for the keyboard, but they are a good replacement for the mouse (except maybe in FPS games, a special case).
Computers have a few things they do well: accept textual input, display data on big screens, and multi-task. From those it follows that anything graphical or textual is a good fit, and that while "one device to do everything" is a bad idea, one device that does many things that it happens to be good at is a great idea. For example, it's extremely common that a person wants to access the web while working on a project. It's better to have one device that can help you gracefully juggle everything you're trying to do than to have a typewriter, a web browser, a CD player, your clock, a "download machine" and a telegraph key (for IMing), each with its own chassis, competing for desk space. Up to a point, combining functions makes sense.
Computers also do one thing very badly: they don't accept input from anything other than a keyboard very well. Specialized fields do have devices that work well: graphics tablets for graphics artists and MIDI keyboards for composers, for example. The driving force behind multi-touch displays is that the "interface for the rest of us", the mouse, is a difficult and inefficient thing to use. We all have ten built-in pointing devices which we can use with aplomb -- some people even manage to use their toes as a few more -- and multi-touch displays are a way to make use of those. Much as I dislike the desktop metaphor, I must invoke it here: using a mouse to interact with a computer is akin to using a single stick to push your papers around on your desk. It's just not the best way to go about it.
I very much doubt that it would be stressful to use a multi touch display for a long time. In fact, I suspect that it would be much less stressful than making the constrained motions required by a mouse. Joints are *made* to move. It might still be a little exhausting at first.
I agree that UIs are best when they are simple... but simple is in the eye of the beholder. To me, a UI that allows me to use my skills in a direct way is a simple one. Using my fingers to move on-screen objects = simple to me. A complex UI is one that requires me to perform actions in ways that take more effort than the direct way. The direct way is the way I would do it if I were manipulating physical objects. For example, menus (especially nested ones) and window managers that don't (i.e. I have to drag and position windows myself, when the window *manager* should do it) are complex to me. Above all, attempting to convey a huge variety of instructions by pushing a box around and clicking buttons on it is complex, because it adds another layer I have to work through. If I ever my my GUI fairy godmother, I'm asking her for a laptop with a touch screen. Maybe a multi-touch screen if she looks generous.
Agreement here too.
My biggest gripe with today's computer interfaces is that attempting to funnel everything you might want to do through a mouse plus (if you're lucky) a keyboard forces you (as an interface designer) to make a difficult decision: either waste huge amounts of screen real-estate on functions you need to include, or hide them away.
What we need are interface devices that aren't so bandwidth limited. When we want to make the computer perform an action, all we are generally able to do is locate it on the screen and say "Do." On systems with multi-button mice the situation is somewhat better. Most Firefox users are familiar with "left click to follow a link, middle click to open it in another tab, and right click to get an [ick] context menu" idiom. Scroll wheels are another instance of a bandwidth-increasing addition to the system. Rather than clicking an arrow to scroll, we are now able to spin a wheel while pointing in the general area of the thing we wedant to scroll.
Some systems put the physical controls available to even better use. The Sam text editor, its successor Acme, and basically all of the Plan 9 operating utilize the mouse buttons to perform distinct and consistent actions. In Plan 9, button 1 selects, and the other two buttons, when used in conjunction with it, perform other useful actions. The exciting feature of this setup is that it moves the selection of possible actions out of the computer, where navigation is inefficient, and puts it literally under your fingertips. Rather than selecting an object on the screen then selecting an action, or vice versa, one can simply point at it and say "do this." The ability to convey specific actions in one fell swoop is what makes command line junkies (myself included) swing the way they do. What could be more exciting than marrying that power with a GUIs flexible expression?
An even more extreme example is the five button keyboard (for the left hand) + three button mouse featured in the Doug Engelbart video linked from the summary. I'm not sure how his system used them, but this setup allows for eight functions using the most obvious mapping, many more than modern interfaces. Not only that, but with chording, it's possible to increase the number of possible actions to a dizzying 255, which is probably way too many to actually make use of*: Engelbart's system uses typed commands as well as clicks rather than attempting to assign a meaning to each combination of button presses. One good way to cope with the number of possibilities is to assign a general funtion to each button, and to combine those functions to perform actions. For example, if the left mouse button selects text, the middle button pastes it, and the right mouse button cuts it, one can copy by selecting with LMB, then pressing RMB, MMB in succession. Other button actions might be "system" to trigger global system functions, "window" to do window management and "inspect" to look more closely at an item. What might happen when you press these together? Exposé, anyone? But without reaching for the keyboard.
Anyone interested in user interfaces should take a look at the Sketchpad computer program for starters, which was simply amazing, and at "Alan Kay: Graphical User Interfaces" on Google Video. GUIs have a rich history that is not evident in modern interfaces.
* This is a good thing! Even when a the system allocates a set of global button presses and applications implement their set of commands, there will still by plenty left over for the rest of us to allocate as we see fit. This is the one point where I disagree with Bunions: I love that multimedia keyboards aren't standardized, because it means that programs don't depend on the buttons they provide, which in turn gives me 32 keys (on the keyboard I have) that I can bind to any action I want, without losing any functionality.
But I do not want to see your ugly mug.
Yes, it is invaluable. I use it to bring up a drop-down terminal, Quake-style, and the Menu key gets to bring up my keyboard-controlled program launcher. Mine are way off in the corner of my keyboard, so I use them as single-press keys rather than as modifiers.
You're insane. Why would you bind a useful key to nothing?
Whaaa? "=" doesn't belong in the main area? Are you for real?! I'm going to go out on a limb here and guess that you've never written a line of code.
I'll never understand the "lets take keys off the keyboard" crowd. The Windows key's default binding is barely useful (I'm amazed that Windows doesn't provide a built in facility for assigning it to other actions) and the Menu key is completely useless (what the hell did they even think this was for?) but why would any sane person want to give up the possibilities they provide? You *can* remap them, you know. For example, my Windows key drops down a Quake-style console, and my Menu key brings up a wmii style menu that lets me launch any program quickly. I'd much rather have plenty of customizable keys with no particular purpose than have only a small set of indispensable ones.
That's why you have two control keys. Of course, the best way is to make both Caps Lock and Enter act as control keys. Control where God intended + symmetry = happy camper.
Too bad you accidentally took out the shift keys too.
That's what the other control key is for. Trying to hold control (or Shift, or Alt) with the same hand that's pressing letter keys is just asking for a typing related injury.
It's nice that you don't type in all caps, but typing using only lower case letters is just as bad. Try reaching a happy medium.
How do you know any program isn't a key logger? This program's key counting nature just puts the idea in your head, but in reality, there's no need for key loggers to tell you that they listen to your keyboard. You could just as easily hide one in a clock or make a screen saver that starts a key logger.
So I guess the moral is "only run open-source software."
Wow, do Gentoo and Ubuntu really have that many packages? I thought Ubuntu had around 18,000.
I think there are around 7000 packages in Arch's repos, not including unsupported user-submitted packages in what's called the AUR. Arch's repos are pretty good, meaning that most of the things I want are in there. Certainly enough to build a solid system. I'm not suggesting that Arch is a perfect fit for everyone, but since we were talking about minimal base installations, I thought it was worth mentioning. I suppose it depends on what you want to do with the system. I think most Arch users use it on the desktop, but I don't see any reason that you couldn't build a server on it either, since programs like Apache and the SQLs are in the repos (I don't know exactly what goes into a server though). This would probably be a Bad Idea anyway, due to Arch's frequent updates.
You say "full-fledged Ubuntu-like", and you also say "I'm sure it's got desktop stuff, but how many apps does [it] really have?" referring to Arch. I'm not sure what distinction you're making here. Isn't Ubuntu a desktop distro? Arch has fewer apps than Ubuntu in its repos, but I don't know exactly what it is that Arch lacks. I can't make a comparison.
You're assuming that it would run long enough to actually capture a screenshot.
Why would you use such a bloated WM? It's over a megabyte in size!
Yes, let's move it to our costly, proprietary, and complex hardware instead!
Not to say that you're wrong or that hardware should be free-as-in-freedom, but the irony was to great to resist.
I don't see how this is a significant distinction. The question, in terms you might prefer, is how virtualization using specialized hardware compares to doing the same thing in general purpose hardware. There doesn't seem to be any semantic difference. Are you just pointing out that a hardware implementation's performance is predicated on its design?
I thought to myself, "Surely this article mentioned that it's generally not a fatal disease." So I took the time to RTFA, and sure enough, it did say that. Perhaps you would have been less worried if you had taken the time to read to the fifth paragraph.