I think that wikis should have a visualization tool for paragraphs, highlighting text like a spell-checker in a word processor or a syntax-checker in an IDE. The visualization tool should represent how new, and how frequently-revised, a particular section of text is.
You should give a try to WikiTrust. Last time I used it, it was in a will-eat-your-puppy release. But it offers the features you're requesting, plus weighting each word with a measure of the reliability of its editor.
I hope in the future it will be improved enough to be deployed in the regular Wikipedia.
Is there something wrong with the Pixel Qi model of the Notion Ink Adam?
I've never seen them IRL. But I've been following them through youtube videos, and the problem with Pixel Qi is that under sunlight it only looks good for laptops, but not for tablets. The touchscreen technology requires a reflective glass layer that negates almost all the benefits of the Qi display.
Sounds nice. Be aware of over-relying on the screen edges to take advantage of Fitt's Law, though. Those only work for mouse and trackball on small screens but they offer little advantage for touchpads, touchscreens or users with big screens. For those, nothing substitutes having targets that are big.
Actually the second fasted place for Fitt's Law is not the corner but the radial menu, and it also works well for touch interfaces; I think you should give them a try for your design if you can get over their weird look.
Also don't subestimate the power of Hover to show tooltips; they make interfaces easier to scan and learn. If you want to support touchscreens make sure that the expanded context menus include the description that should be in the tooltip, and test all text labels with users to ascertain that they're descriptive.
I am aware that the Three Laws didn't work as intended:-) That doesn't mean that having a core built-in safeguard is a bad idea.
I wasn't suggesting fuzzy rules, an auto-kill command as you suggest would suffice. A recent robot movie, (Eva), on the lines of Spielberg's A.I., features a literal kill-switch triggered by a voice command, which proves itself useful in the narrative. But I doubt that the Asimo robot includes such a feature.
+1 lateral thinking. I must say that I had in mind some basic behavioral rule that would also prevent killer robots in the army, like the First Law did.
Now how will we guarantee that it doesn't injure humans? I don't care that it may, through inaction, allow a human being to come to harm; that would be like having no robot.
What I want to see is a robot design that won't go berserk if its control program throws an exception, making it move its powerful arms uncontrolled or fail to recognize were its fellow humans are located.
The reason is that it works well and people like it.
You're not been hanging around common people lately nor watching how they use their systems - what you say is true only for highly trained office users, and then only to some extent.
As I said, people are TERRIFIED from using their computers to their full potential, because of the very real possibility to break the system, and because most actions are overly complex even for simple tasks (such as syncing their music folder with their mp3 player). They learn how to perform their usual four or five tasks, and any deviation of their known flow (such as popup error) means that they won't be able to finish the task, diagnose the reason for the unexpected behavior, nor remotely close to fix it.
That's the reason why task-based flow environments work much better than object-oriented environments for these users; auto-contained tasks offer all the information they need to achieve their goal, while in object environments the user needs to hava a thorough understanding of all the virtual objects and their relationships before anything cat get done at all. Users simply don't have the background nor the time needed to learn all those concepts, since the objects are designed in a way that it's hard to make sense of.
The WIMP widgets certainly were extremely well designed and flexible for their time, and that's why they could have survived all those years at all; and if you think of it, they were at first quite task-oriented in the way that I explained above. But they've largely overexceeded their useful life for many purposes, and they're not well adapted to the needs of modern applications (how many menu bars do you see on Twitter, Facebook, Google or Wikipedia?). They've not been replaced because we haven't found an optimal replacement yet, and because the HUGE investment in existing tools (widget libraries, IDEs and peripherals) supporting their model. Those make for a strong conservative force. (Yup, developers are extremely conservative people when it refers to their profession tools).
Certainly some gestural and natural interactions are gimmicky when applied to traditional tasks. The trick is that they will allow for new kinds of tasks, those that have been held back by the dominant desktop metaphor - primarily, sharing information between people on the same physical and/or virtual room, and working on analyzing and editing huge data sets.
In my view there are two kinds of configuration options. The first one allows the user to create new workflows (adding widgets to panels and the desktop, installing apps from the market...), the second one (far too common in FOSS software) is used to get rid of design decisions that get in the way of the preferred workflow.
In its effort to get rid of the second kind, Gnome 3 and Unity seem to have made the mistake to also remove the first one. That doesn't mean that the underlying design, centered around a task model that can be expanded to accomodate new tasks, is the wrong one.
That "kind of thinking", as you put it, is a solid and much needed one. That's why the public is flooding toward the mobile appliances and nobody really bother to try the FOSS alternatives (Plasma, Meego) - no one is able to make sense of them because they're not task-oriented, at least not for the tasks that are more commonly needed.
Good point about computers and consoles, though consoles are single-purpose so non-gaming interfaces are not comparable. When computers are used for gaming, they do best when having console-like interfaces (Steam, web flash games...)
The point is not that touch screens will be the medium for content creation; it's that there will no longer be a single medium, but multiple input/output channels.
Personal computing has been the realm of keyboard+mouse for almost 30 years, but the multiplicity of cheap sensors that is arriving will allow for complex tasks taking advantage of a variety of peripherals, each one good for a particular interaction modality: 3D input, direct selection by touch instead than by a remote cursor, wide gestures for navigation between tasks... they can be done now with more than mouse selection and key combos.
That's true either for collaboration (that is not going to disappear even if works are no longer in the office) or for isolated thoughtful work. A single worker will want to take advantage of multimodal interaction and separate information surfaces to keep track of different subtasks and for multitasking, which are difficult to do on the traditional desktop metaphor.
Tablets, e-readers, mobiles, folding screens, projector whiteboards, tangible UIs like the Reactable... they are here to stay; keyboards will be a wireless peripheral used only when a heavy data input is required. The laptop/netbook without a touchscreen will no longer be the king of content-creation devices.
Complex tasks are no longer done on an isolated desktop environment; they are right now distributed among people using mobile devices, touchscreens, remote applications in web browsers... Kiosk-like devices will be used for collaborative creation on video-walls, big surfaces like the Microsoft table or the Sphere, and gesture recognition like with Kinect and Move. These technologies have been around for a while as prototypes, and they're finally ready to be used as affordable commercial products.
Even single-user tasks will not be performed on a desktop alone. The computer user will want to display data on the multiple available displays; dual screen configurations are only the beginning, and the desktop metaphor is not well suited for it - it was created for a single small screen, and it requires a peripheral bounding box close to the work area which is no longer available with multiple screens.
Users will want to move item lists to be displayed on peripheral devices and have them controlling the main view on the master screen. The stand-alone monitor as the single output device is a thing of the past, and there's where the computer interface will have to converge in order to collaborate with all the other information devices.
let the user decide how they want their desktop configured, because you never know what they want.
All the Usability lore is based on that you can know what the user wants (and needs) and build the system around it. A system designed to cover those needs should ideally require little to no configuration, because the creator would satisfy all the requirements through a single interface - once the optimal design is achieved, any change to it would be worse for the stated needs.
That only works for a particular group of users and contexts, though; there's where Gnome 3 is having problems, because Open Source desktops are used by a bigger amount and variety of users than what Gnome 3 was designed for.
Traditional FOSS applications include lots of configuration options because that's an easy way to reach a wide amount of needs, but that doesn't mean that it's optimal. Non-technical users have problems when there are lots of configuration options, and they tend to stick with the default interface no matter what it is - usually because they're afraid to break things.
If you're interested in how to reduce the need for configuration and how to design for the widest audience, have a look at Jef Raskin's book The Humane Interface. It's based on designing for the cognitive capabilities common to all people, and it has influenced many of the design idioms found in modern in web and mobile applications.
Meet the new slashdot, where technical programming posts that actually give insight are met only with trollish hate and a general lack of understanding. Learn to Google your TLAs before exposing your lack of skilz, kid.
Slashdot Mirror
For an actual touchable hologram, see this SIGGRAPH 2009 presentation. It uses something called acoustic radiation pressure based on ultrasound projection.
Except GNAA, I mean.
As a native Spanish slashdotter, I'm amused by the funny names your lawmakers assign to your acts. For reference:
SOPA -> soup
PIPA -> sunflower pipe
ACTA -> proceedings (at least this one is about a formalized document written on paper)
Or is it because any combination of two consonants with two vowels is a valid word in Spanish?
You should give a try to WikiTrust. Last time I used it, it was in a will-eat-your-puppy release. But it offers the features you're requesting, plus weighting each word with a measure of the reliability of its editor.
I hope in the future it will be improved enough to be deployed in the regular Wikipedia.
So, you don't think there can be a correlation between expertise and odds of winning in a contest that is NOT DECIDED BY RANDOM CHANCE?
Talk about Statistics Fail.
I've never seen them IRL. But I've been following them through youtube videos, and the problem with Pixel Qi is that under sunlight it only looks good for laptops, but not for tablets. The touchscreen technology requires a reflective glass layer that negates almost all the benefits of the Qi display.
That's what makes them far more dangerous.
Where are mod points when you really need them?
You may also want to take a look at the square menu and this menu techniques compilation.
Sounds nice. Be aware of over-relying on the screen edges to take advantage of Fitt's Law, though. Those only work for mouse and trackball on small screens but they offer little advantage for touchpads, touchscreens or users with big screens. For those, nothing substitutes having targets that are big.
Actually the second fasted place for Fitt's Law is not the corner but the radial menu, and it also works well for touch interfaces; I think you should give them a try for your design if you can get over
their weird look.
Also don't subestimate the power of Hover to show tooltips; they make interfaces easier to scan and learn. If you want to support touchscreens make sure that the expanded context menus include the description that should be in the tooltip, and test all text labels with users to ascertain that they're descriptive.
I am aware that the Three Laws didn't work as intended :-) That doesn't mean that having a core built-in safeguard is a bad idea.
I wasn't suggesting fuzzy rules, an auto-kill command as you suggest would suffice. A recent robot movie, (Eva), on the lines of Spielberg's A.I., features a literal kill-switch triggered by a voice command, which proves itself useful in the narrative. But I doubt that the Asimo robot includes such a feature.
Do you have mockups of your design? your design constraints (no hovering, no right click) seem interesting.
+1 lateral thinking. I must say that I had in mind some basic behavioral rule that would also prevent killer robots in the army, like the First Law did.
Now how will we guarantee that it doesn't injure humans? I don't care that it may, through inaction, allow a human being to come to harm; that would be like having no robot.
What I want to see is a robot design that won't go berserk if its control program throws an exception, making it move its powerful arms uncontrolled or fail to recognize were its fellow humans are located.
You're not been hanging around common people lately nor watching how they use their systems - what you say is true only for highly trained office users, and then only to some extent.
As I said, people are TERRIFIED from using their computers to their full potential, because of the very real possibility to break the system, and because most actions are overly complex even for simple tasks (such as syncing their music folder with their mp3 player). They learn how to perform their usual four or five tasks, and any deviation of their known flow (such as popup error) means that they won't be able to finish the task, diagnose the reason for the unexpected behavior, nor remotely close to fix it.
That's the reason why task-based flow environments work much better than object-oriented environments for these users; auto-contained tasks offer all the information they need to achieve their goal, while in object environments the user needs to hava a thorough understanding of all the virtual objects and their relationships before anything cat get done at all. Users simply don't have the background nor the time needed to learn all those concepts, since the objects are designed in a way that it's hard to make sense of.
The WIMP widgets certainly were extremely well designed and flexible for their time, and that's why they could have survived all those years at all; and if you think of it, they were at first quite task-oriented in the way that I explained above. But they've largely overexceeded their useful life for many purposes, and they're not well adapted to the needs of modern applications (how many menu bars do you see on Twitter, Facebook, Google or Wikipedia?). They've not been replaced because we haven't found an optimal replacement yet, and because the HUGE investment in existing tools (widget libraries, IDEs and peripherals) supporting their model. Those make for a strong conservative force. (Yup, developers are extremely conservative people when it refers to their profession tools).
Certainly some gestural and natural interactions are gimmicky when applied to traditional tasks. The trick is that they will allow for new kinds of tasks, those that have been held back by the dominant desktop metaphor - primarily, sharing information between people on the same physical and/or virtual room, and working on analyzing and editing huge data sets.
In my view there are two kinds of configuration options. The first one allows the user to create new workflows (adding widgets to panels and the desktop, installing apps from the market...), the second one (far too common in FOSS software) is used to get rid of design decisions that get in the way of the preferred workflow.
In its effort to get rid of the second kind, Gnome 3 and Unity seem to have made the mistake to also remove the first one. That doesn't mean that the underlying design, centered around a task model that can be expanded to accomodate new tasks, is the wrong one.
That "kind of thinking", as you put it, is a solid and much needed one. That's why the public is flooding toward the mobile appliances and nobody really bother to try the FOSS alternatives (Plasma, Meego) - no one is able to make sense of them because they're not task-oriented, at least not for the tasks that are more commonly needed.
Good point about computers and consoles, though consoles are single-purpose so non-gaming interfaces are not comparable. When computers are used for gaming, they do best when having console-like interfaces (Steam, web flash games...)
The point is not that touch screens will be the medium for content creation; it's that there will no longer be a single medium, but multiple input/output channels.
Personal computing has been the realm of keyboard+mouse for almost 30 years, but the multiplicity of cheap sensors that is arriving will allow for complex tasks taking advantage of a variety of peripherals, each one good for a particular interaction modality: 3D input, direct selection by touch instead than by a remote cursor, wide gestures for navigation between tasks... they can be done now with more than mouse selection and key combos.
That's true either for collaboration (that is not going to disappear even if works are no longer in the office) or for isolated thoughtful work. A single worker will want to take advantage of multimodal interaction and separate information surfaces to keep track of different subtasks and for multitasking, which are difficult to do on the traditional desktop metaphor.
Tablets, e-readers, mobiles, folding screens, projector whiteboards, tangible UIs like the Reactable... they are here to stay; keyboards will be a wireless peripheral used only when a heavy data input is required. The laptop/netbook without a touchscreen will no longer be the king of content-creation devices.
Complex tasks are no longer done on an isolated desktop environment; they are right now distributed among people using mobile devices, touchscreens, remote applications in web browsers... Kiosk-like devices will be used for collaborative creation on video-walls, big surfaces like the Microsoft table or the Sphere, and gesture recognition like with Kinect and Move. These technologies have been around for a while as prototypes, and they're finally ready to be used as affordable commercial products.
Even single-user tasks will not be performed on a desktop alone. The computer user will want to display data on the multiple available displays; dual screen configurations are only the beginning, and the desktop metaphor is not well suited for it - it was created for a single small screen, and it requires a peripheral bounding box close to the work area which is no longer available with multiple screens.
Users will want to move item lists to be displayed on peripheral devices and have them controlling the main view on the master screen. The stand-alone monitor as the single output device is a thing of the past, and there's where the computer interface will have to converge in order to collaborate with all the other information devices.
The convergence is what you find in tablets. And kiosks. And TV media centers. And web applications.
All those examples can be used for hours at a time.
All the Usability lore is based on that you can know what the user wants (and needs) and build the system around it. A system designed to cover those needs should ideally require little to no configuration, because the creator would satisfy all the requirements through a single interface - once the optimal design is achieved, any change to it would be worse for the stated needs.
That only works for a particular group of users and contexts, though; there's where Gnome 3 is having problems, because Open Source desktops are used by a bigger amount and variety of users than what Gnome 3 was designed for.
Traditional FOSS applications include lots of configuration options because that's an easy way to reach a wide amount of needs, but that doesn't mean that it's optimal. Non-technical users have problems when there are lots of configuration options, and they tend to stick with the default interface no matter what it is - usually because they're afraid to break things.
If you're interested in how to reduce the need for configuration and how to design for the widest audience, have a look at Jef Raskin's book The Humane Interface. It's based on designing for the cognitive capabilities common to all people, and it has influenced many of the design idioms found in modern in web and mobile applications.
This approach by Sony shows much more promise in the short and medium term:
http://www.youtube.com/watch?v=inlyXhKDQwg
No walking through the image, though.
Cool! I'll have to try it in my work at modelling schedules for railways and other transport networks.
What kind of models do your applications support, and in which industry (or industries) are they used?
I'd love to hear about how one gets to be an expert in model-driven programming.
Meet the new slashdot, where technical programming posts that actually give insight are met only with trollish hate and a general lack of understanding. Learn to Google your TLAs before exposing your lack of skilz, kid.
ROTFLMAO
Google will find my lost keys!