Master Heading

NPUC Homepage 1997 Workshop 1996 Workshop 1995 Workshop 1994 Workshop 1993 Workshop

Ed Fredkin
Speaker
Audio Excerpt
Internet for Things that Think
Ed Fredkin
RadNet
ed@fredkin.com

Ted Selker: This is Ed Fredkin, that I'm putting a microphone on here. Ed Fredkin is responsible for the idea of swapping in operating systems and many other inventions in computer science. He's also started many companies, and this is not about any company that he is working on. I'm inventing right now as far as I can tell. Let's see what he has to say about machine Internet.

Ed Fredkin: Let's see if we can get this program going. Okay what I want to talk about is something that would be very much like the Internet but it's not the Internet. It's just like the Internet but it's not for people, it's something for machines. What do I mean by machines well obviously just as the Internet is for people for the most part, you use it through a computer what I'm talking about is machines of course using through a computer net and what do I mean by machines, well things like airplanes, ships, maybe some day cars and toasters, who knows. In the beginning things like nuclear power plants and chemical plants, so on or parts of those systems and I envisioned a kind of Internet that would be helpful for those things and one of the things I want to use is a little example that has to do with the weather. We can get weather on the Internet of all kinds, but the kinds that most people get is very much like the kind we get on TV. The funny thing is that I would hate being a weather man because you have to get up each day knowing that yesterday you told a lie about whether is was going to rain or not. So in any case just to make a few points, if you hear on the weather that there's 40% chance of snow today, do you know what that means?

Ed Fredkin: What can you conclude from that statement? There's a fact that you can conclude from that statement that is not bad. Any one have a good idea?

[Talks to people in audience..]

Ed Fredkin: No, no that's too obvious. What you can conclude is that there are five people in the weather office. (laughter in audience) Okay, the next thing is I read the funniest thing in the newspaper. A mathematician wrote to the editor foaming at the mouth because on the weather broadcast, the forecaster said there is a 50% chance of rain this morning and 50% chance of rain this afternoon and the newscaster who is trying to make idle chats this afternoon said that means there is 100% chance of rain today and the guy says yeah that's right. So the mathematician foaming at the mouth complaining about that the media has all this power. If they are going to use percentages of probabilities they ought to know something about mathematics and they ought to be able to calculate what the percentage is. Now let me tell you what the weather picture is, the weather picture is there is a squall line heading this way. You can see it, it's on radar, it's raining under it. They don't know how fast it's going to go, whether it will slow down or speed up, but they know absolutely for certain it will pass over Boston that day. What's the probability of rain that day? It's 100%. The point is all mathematicians think everything is independent because that's the way they grew up. Okay, so the weather information you get is sort of meant for humans who know that the weathermen don't know what they are talking about. And the people who get the weather information don't really care because it isn't that important usually. Okay, so but with a machine getting some information might be important and the nearest thing that could come to that is pilots get weather information. Okay so here's what I'm talking, the idea of Internet for machines only. It probably has a private backbone, but it ought to have Internet available as a sort of backup. And the users, as I mentioned, are computers in all the different machines, but it has a different concept to what's available. I have this idea, and I'm borrowing a lot from the airplane business, the aircraft industry, of what I call certification. What that is, let's say you have a piece of software it's a bit like maybe a part of an airplane. It's supposed to do something. In an airplane if you are building a Boeing 777 and you have a lot of parts, the whole airplane has to get certified and so do all the parts. What certified means that the engineers have to prove the things does whatever it's supposed to do and meet various standards and so on. Okay, so we want to have stuff that is certified and standardized both for software for the information and for data. This is very different than what you get on Internet because on Internet lots of stuff is typed by people. A lot of if is full of typos. It isn't important to check it, it's all evanescent in many ways. So you know that here we are talking about something that will be dependent upon by a kind of dumb machine and therefore it needs to be more certain that it's right.

Ed Fredkin: I think you know it's reasonable to expect that a system like this might have, before too long, maybe a 100 billion users. Where does that come from, that's because it makes sense for almost everything that has something to do to have a microprocessor in it, and it will make sense to almost everything that has a microprocessor to be able to talk to something to find something out or tell something this is the way to do it. Okay, so the reason to not use Internet is we want to be able guarantee access and bandwidth and it's worth a lot more money as I'll explain in a little while. So it probably needs to be a separate system. For various reasons, because companies care a lot about what happens with information that could let someone understand things, this system might as well start of with everything always encrypted. I mentioned fall backs in the Internet and Iridium.

Ed Fredkin: I have in mind a chemical plant. Obviously it talks over a T1 or some other kind of line, whatever, ISDN perhaps and so on. But I envision that plants like that would also have a little Iridium type satellite phone which would just test once a month so that if the phone lines are down and communications goes out it could still make contact.

Ed Fredkin: And this kind of network needs to have various things guaranteed. In this context it turns out that you need lots of agents everywhere of all kinds because there isn't going to be any person to figure things out. So things sort of have to happen right even though they maybe sort different than one suspects, and you want to be able to cope with problems where it isn't true that the programmer thought of everything in advance. You can imagine this Internet thing, but if you take this weather example something like 'its going to snow today' isn't what some plant needs. It needs very specific information like what's the probability and what are the times and it needs it maybe up to the hour and maybe up to the minute once it starts snowing, what's the accumulated snow fall, and things like that. Because some plant may have to shut down or evoke some kind of emergency procedures because of a snow storm and so on. Now, in aviation you get some weather information that is kind of precise and I'll give you an exanple of that in a minute. I was talking to..., I happened to be invited to dinner at someone's house and he had another guest, the next door neighbor, and I was telling him this idea. That guy ran an insurance company, Liberty Mutual. I was describing him this idea. The example I used: say there's a real cold snap. Some plants have piping and there's water in those pipes and if there's a cold snap that's unusual then they need to know about. He said that's very interesting. We were the insurer in a power plant, and there was a cold snap and the condenser out flow valve froze and an emergency happened. They tried to open the valve, it couldn't be opened because the water in it froze, he said the claim we paid was 200 million dollars. I thought that was interesting. So -- pardon?

[Inaudible question from member of audience]

Ed Fredkin: No, but what his point was is insurance companies might pay to see stuff like this developed. Now yesterday, I got a weather briefing on the computer for a flight plan. Not exactly a long trip, it was from San Jose to San Francisco, and there was no weather that day. This is one of maybe ten equal screenfuls of data that's very concise that I got. This talks about what the weather was -- you can see that in Oakland on the 21st of August at 2348 zulu, you know, the wind was 3.10 at 13 knots, 10 miles of visibility, the sky clear, blah blah blah, you know all that stuff. It was telling me what it was at each hour, O.K.? That's pretty detailed, and actually this is almost machine readable form. It also tells me what it's expecting in various places, like there's a forecast for San Jose, forecast for Oakland, for San Francisco, and then NGZ that's a mnemonic for Alameda, the naval air station there -- that's not the best mnemonic. But this is telling me what the weather forecast will be and these forecasts are very short because basically it was just clear yesterday. But when there's clouds coming and rain and snow and smoke and hail and so on -- freezing rain and so on -- all those things get into these forecasts and so on. So, this is an example of the kind of weather that -- you know, pilots care a lot about weather, they care about it in great detail, especially what they call significant weather and their warning sigmets they're called, for significant meteorological conditions, that tells pilots that a thunderstorm is coming, tornadoes are here, hail the size of baseballs and so on. They usually say it in inches. So, now, another thing comes up, which is how would machines make use of this stuff? And I'll tell you that these ideas about machine Internet came to me because I was thinking of a programming problem and this harks back to long ago. There was a time in the seventies when various people thought there could be a thing called automatic programming. Somehow automatic programming would involve you doing something that more or less makes the program but you wouldn't have to program it. It sounds sort of like black magic. There are things that are done without programs that might have used to be programmatic -- spreadsheets are an example of where you accomplish something, you don't have to write a program and so on. But for all of these systems, there's an interesting thing and that is that it is possible to achieve that goal in an almost magical way. If you have a system like this machine Internet and you develop agents of a certain kind which I just explained, it is possible to make a program without programming, but only in a limited domain of applications. That's the problem, this can't be used in general at all. So limited domain has to do with machinery, machines meaning a plant say that has pipes and valves and tanks and so forth. It turns out that if you make an agent floor pump, and that agent is very specific, like if you look on some catalog perhaps on the Internet and you find an agent for Fairbanks Morse 20 horsepower, centrifugal pump, you know, with a bunch of specifications and a model number. You find this agent which is something that knows all about this pump then if you get a picture of it also, if you build a picture of your plant by interconnecting these agents, you stick a few more objects on the plant that have to do with abstract ideas like, say, a servomechanism or the idea that this tank is being used as a input buffer where a software tank car fills it up or so on and so forth, you can put the whole thing together like that, have a few abstract agents that worry about what's the purpose, what you're trying to optimize and so on, and when you're all done the thing would be a process-controlled system that runs it but all you did was make a picture of the actual system. Now, I've looked at a lot of things like that and it turns out that at first it looked like maybe this needed some kind of black magic but we couldn't find any black magic in it when we looked closely and what turns out is that if you don't use agents the way we already know how to do and you have them specific to the actual objects, some of them are parameterized, for example, if you have a four-inch pipe, one parameter is the that it is a four-inch pipe, the other is how long is it, if it has an elbow that's another thing, and so on. So, all those objects can have programs that can model their behavior and can figure out what needs to be done under a lot of different circumstances. So I imagine three kinds of agents like that, something that has to do with things like motors and pumps and tanks, or something that has to do with functions or like a servomechanism or an optimizer or a scheduler or things like that. And finally you would want it to have to do with beta, such as something that gets the price of various things. Now these -- what I'm suggesting is that, using perhaps the regular Internet, these things can all be found at some future date on the Internet and you can -- some of them I think that would run in the server and some of them would run at a vendor site, for instance, and so on, and there would be different functions that it could perform. It's sort of a very different prospect than agents that we think of as working for us, hunting things down or collecting things for us and so on, but in many ways it's similar. The difference is these are dumb, so they have to count whatever it is they are going to make use of and they have to be thought out well in advance.

[Inaudible question from member of audience]

Speaker: ... from some of Rodney Brooks stuff you know, small but dumb, small, cheap and proliferated and also, with that in mind, to what extent are you really talking about integrating sensors, intelligently versus autonomous agents.

Ed Fredkin: Yeah. Well, the answer is that I didn't happen to think of Rodney Brooks as I was thinking this up but it is very similar in many ways. What it is, is that a collection of individual agents just interconnected, you know, making these agents is fairly complicated. For instance, if you make the first centrifugal pump generic agent, that is a lot of work, it might be a man-year or so and then what would happen is, you could specialize it to individual ones. There's an interesting thing about this system, which is this: when I say you can make a process control system with no programming, but only in the case where you find in the catalog as it were, every single agent you need. And then you just position those agents and it all works. Now, there's this interesting thing about the certification process. I imagine all these agents get certified, they get tested sort of to death, as are airplanes, and then they're certified. Now, I own an airplane and I keep getting in the mail -- oh, let's say one thing about the engine in my airplane, it's the most reliable engine that's ever been made of any kind, it just happens to be the case. It averages like 300,000 hours of operation in the fleet of them between having a problem, O.K., much less quitting. But there's a strange thing, every I'd say month or two a little thing comes in the mail that says "oh, there's this thing wrong with the design of the engine and within the next 100 hours you will have to have this part replaced" and I think that's an amazing thing, this design is 30 years old or so and they're still tinkering with it all the time, why don't they leave it alone, you would think "don't a poke a skunk or something, it's working fine", well the truth is they get it to work that well by continually, always, finding, analyzing any accident anywhere in the world, or any problem with this engine and coming up with a solution which they test to death, which they then require you to make. In other words, my engine would lose it's certification if I didn't comply with these notices and I wouldn't be allowed to fly my airplane, and I'm thinking of software that does the same thing, where you have this plant that's running fine, but it turns out that on some island they had a volcanic eruption, it didn't handle it right because the guy who wrote that particular pump thing didn't think about a volcanic eruption so they go and fix it so that if all this ash falls on it, it knows what to do. Now, there would be what I would call an agent worthiness directive -- in an airplane it's called an air worthiness directive -- and one of those would come out and it would have to be replaced, or your whole system would lose it's certification and that replacement could take place by simply it's telling you it has to be done and you say O.K., it would happen. Everything's connected and it would just happen. So, this sounds very frightening for anyone who knows software well but I think it can be made to work because these things are much simpler and there ways to do things like to conduct the equivalent of beta tests much more simply. I would like to mention another thing I've figured out, I have this thing about behavior in different eras. I figured out that one of the things that all kinds of machinery need to do is to treat time differently. They need to treat it as a sort of multidimensional thing, and I'll explain what I mean by that. We know that there's UTC -- Universal Coordinated Time -- what time is it -- that's one dimension of time. But there are other kinds of time. There's the time of a flood, the time of an earthquake, the time of a hurricane. Now what happens to plants during a hurricane? It's a very interesting thing. What happens is the plant may get destroyed by the hurricane and they look and say "gee, if only we had shut it down in the following way, we would have mitigated the damage and only would have lost 50 million dollars instead of 300 million" or something like that. What do they do about it? Nothing. They generally do nothing, they shrug their shoulders and say "well, we've had a plant here for 50 years and that's the first hurricane that hit us and there probably will never be another one, there's no lesson to be learned". Now what you would really like is for any lesson learned anywhere in the world, it gets fixed for every agent everywhere in the world. And so, what you want inside these plants are agents that are prepared to deal with 10,000 strange occurrences and the probability of any one of those 10,000 occurring during the lifetime of this plant may be as low as, say, two or three percent. But the economic value of doing the right thing almost always in that rare event when something really bad happens or some combination of things -- you know, when there's an earthquake there's very often a power failure and so on -- is very great. But just from an economic point of view you might ask "why should anyone pay for this? They're insured", and the answer to that is that there is someone who should pay for it, that's the insurance company, because they're the ones who will get a break. You see, when your plant gets destroyed in that hurricane your insurance pays for it all even though if you had done something slightly different it would have saved a lot of money. So that's where this motivation has to come from. Yes?

Speaker: In your airplane analogy, in fact that's not how it works today, right, because the insurance company says do this or you'll lose your FAA certification and then we won't insure you anymore, they don't actually say "here, we feel good about this, why don't you stick that part in your plane".

Ed Fredkin: Wait, wait. The insurance companies aren't really involved in certification unless you have an accident when you weren't certified or something, then they maybe don't have to pay because you're supposed to operate it according to the law. But the FAA tells you you can't fly if you've lost certification. So here what I'm suggesting is that this certification would be different, the guy could run the plant the way he wants perhaps, but his insurance company might say "your insurance will not be valid unless your plant has a certified consultant". So, I'm imagining there could be a whole economy around these kinds of agents where people produce them and their competitors just like you maybe can have one engine or another engine in the airplane -- on the Boeing 777 you get a choice of three engines -- and you could, you know, use Internet or any other way to find and compare different agents and there could be a competitive market in there. So that's just more on certification. This business of certification needs to be very rigorous and it would need some kind of agency, I don't know if it would be a government agency but some kind of agency has to be created to make it all happen and keep it all functioning right.

Speaker: You say it never changed when you talk about certifying individual parts, but as is well known most of the bugs are in the cracks, I mean in the interaction between the different certified agents and you say nothing about that problem here.

Ed Fredkin: Well, one of the things again, going back to airplane analogy. Of course, when you certify a part and the whole airplane has to be certified, and so there has to be a process by which when you interconnect these things you go through some process to get it certified the same way. For instance, normally if you have just a pump, there's a motor and then the pump and motor become a combination and usually there's a few valves and filters and so on and different aspects of that and that can become another agent, you know a sort of combination of those and those kind of modules could be certified, and then finally when you implement the plant you would have to go through some process of exercising it and one of the things you get with this sort of system is you get a simulator for free and I will say this, a lot of these ideas are modeled by a program called G2 that's made by Jensen and it's used for plant control and other things like that and it has this characteristic that you position icons on the screen and you interconnect them and so on, you end up with a system. Except, G2 is a programming language and the guys who use it have to program up the solution, it doesn't have this property -- not needing programming -- but it has the property that you interconnect things on the screen and G2 can figure out what that means when you've done it.

Speaker: You've postulated a world in which things are composable -- I go out and find the great pump -- and so they can't certify these things in all possible configurations...

Ed Fredkin: Wait, wait. See, you've hit upon a key point and you happen to be wrong but I'm glad you brought it up. Here's the thing: the proof that they go together is that in the plant they have that motor connected to that pump, and they have that pump connected to that valve and that pipe and so on, and it works. Now what happens is, the main function of this model of the pump is to be a model and people are getting very good at building models. Again, if you take airplanes, the models they build of an airplane, like take a Boeing 777 again, they build a simulator first, they put the flight characteristics in, they let the pilots fly it and they complain. They complain, "gee, the rate of roll seemed very low on landing and turbulence", so they go and change the design of the airplane. So the point here is that I said that this is limited to certain domains and it's limited to the domains where you already have, where you're going to hook up these new things and generally the engineers know, if I hook this pump up to this valve and to this pipe and so on, they can calculate whether they'll get water hammer or some other bad thing like that, or cavitation and they follow the rules and do it and these agents would work the same way so they ought to be interconnectible or there is something wrong with them. And of course, we would have to test them interconnected. But after awhile they would have property so close to the original thing that you can rest assured if I connect A to B with software, the way A to B is connected with hardware, then yes it works. Yes? Go ahead.

Speaker: You answered it.

Ed Fredkin: O.K. The other thing that was brought up a minute ago had to do with sensors and it turns out that understanding a sensor is a major problem. If you just take a simple thing like a pressure sensor and you would like to make a model of it that works well in order to make use of a reading you get from the pressure sensor, this is a major undertaking. And the reason is, just think of the way the pressure sensor can fail. The number of ways is just incredible. First of all, it can just drop dead, that's almost too simple. Or it can go out of calibration or it can become microphonic, mainly the pressure depends on what it is listening to, or it can become erratic, it can have two different kinds of modes and it goes back and forth between them and on and on, and you sort of have to deal with all those and understand them. So if you're going to make this kind of automatic programming system what you need is some environment where they can get plugged in. And that's some kind of kernel and, you know, it turns out that Java by just some kind of great coincidence is a very fine model of the kind of programming language you would need in order to make that kind of system. Yeah?

Speaker: One of the dirty secrets of the contracting industry is that every house is unique and every plant is unique and you put two things together and they don't work like you thought they would and so the guy has to go in there and shim them and hack a piece off of this and file that and rewire it and then hopefully maybe it goes back again to what is reflected in the drawings but oftentimes it doesn't and, you know, the plant works partly because it works most of the time when you hook these two things together, but partly because somebody was there and figured out how to get them to hook together the way they really were supposed to go together or the way they work together despite the fact the hookup is different from what the plan said, right? You can't accommodate all of that because every plant has a lot of unique little hacks like that...

Ed Fredkin: Well, first of all there are some plants where that is an insuperable problem, but there are lots where it's not. So what I would say is this, with this software you might have to do a little hacking, adjusting of parameters as it were but not programming. In other words, I don't claim that every plant can be -- get a control system without any programming -- but what I do claim is that a lot of them can. And a lot of them -- you know, the idea of this is that you have to hire someone to document what the plant is, not what it's design was. You need a guy to go out there and discover that, "hey, they were going to use four-inch pipe here but they didn't have any, so they used six-inch pipe", so the point is it's a mechanical job, it doesn't take great genius to document what the plant is -- what?

Speaker: And then get recertified?

Ed Fredkin: No, what happens -- no, I'm talking about the process building one of these systems, say you have an existing plan. You need to go out and document what it is and make a copy of it on a computer screen.

Speaker: (Inaudible)

Ed Fredkin: Well, I don't know, that's a social problem. O.K. The point I'm trying to get at is not that this can solve every problem but that it's a path towards solving a lot of problems. And I think that in the beginning it might handle fairly simple situations and, as I said, you have to have all the agents available. But it turns out in the example I gave, with pipes and valves and so on, there's an amazing number of plants from a brewery to a pharmaceutical plant to a refinery and so on, that are basically made up of tanks, pumps, valves, pipes, and so on -- tanks serving as mixers, reactors, fermenters, distillation things and so on -- and there's a lot of similarity there and many fewer kinds of things than one would think. Let me just give you an example about that. I have a little box in the airplane that does navigation for me, GPS, that simple. When they first came out, or when they came out with LORAN, they would let you put in 20 places. So you could say Place 1 might be JFK Airport and Place 2 might be LAX or something, right? Well, eventually they came out with a bunch of the major airports already in them. We'll take you through all the steps. But today when I get the little box in my airplane, I get a cartridge every four weeks, and what that cartridge has in it is up to date information on every airport in the world, including a picture of the runways and so on, and all the frequencies that are in use and so on, and every navigational fix in the world. They've got them all, that's it. Now if you take -- many better examples have to do with airplanes and I'll try to get to some of that. I'm running out of time so let me skip some of this and see if I -- O.K., ships at sea...ah, airplanes. If a thing called CFIT, it happened in what used to be Yugoslavia with an airplane. It flew into a mountain, the pilot was flying, you know, nothing was wrong with the airplane, it's called Controlled Flight Into Terrain, that means the plane is under control, the engines are running, it just hit the mountain. There's another thing which is controlled flight into a thunderstorm or something like that which can be just as bad. There's a strange thing that you may not realize, that airplanes very often land on the wrong airport. It's a funny thing, you're talking to the tower, say, at San Jose and meanwhile you're landing at Ames or something, you know, whatever. That happens quite often, and sometimes -- I know of a case not long ago when the pilot said, "there's an airplane landing on this same runway in the opposite direction, what does that mean?" and the tower said it means you're at the wrong airport (laughter). So, airplanes go on the wrong runway, they're in the wrong airspace, what do you mean wrong airspace? You know there's all kinds of blocks of airspace all over the United States that are called warning areas and such and why? Because one air force plane is shooting a missile at a drone there and if you happen to fly by at the wrong time, you'll be shot down probably. There are midair collisions, running out of fuel, mechanical emergencies and so on. Now that last thing that says hundreds of changes a week, I subscribe to some service that tells me sort of what's going on at various airports and the approaches. And I get approximately a hundred changes a week of new things. Now all these things could be avoided -- and you need something like an Internet system because, let me give you an example. Controlled flight into something, well, how long does it take to move a mobile crane to move somewhere to raise itself up to 400 feet? It takes about an hour or two, for it to come from nowhere up to a 400 foot obstacle and it could be right near an airport. It's a very dynamic situation, airplanes do run into cranes near airports. So it turns out that what you'd really like is a system like I'm describing with intelligent agents in airplanes and in one fell swoop you could avoid this whole class of accidents, the whole set of class of accidents that are described here, which are things where the pilot just doesn't know where he is, or his airplane doesn't happen to know what's under him and so on and so forth. It's all pretty reasonable now and it could all be done. So this is in the category of things that can be done by this kind of system.

Speaker: I'm wondering about those occasions where the machines connected to these agents may need to call for human assistance and whether you think that will be a major or minor feature in such a system.

Ed Fredkin: Well, yes I think that is an absolute thing. A very advanced one would consider a human to be some kind of mobile robot that can do things that it can't do for itself, right? It would say "go get the following torque wrench, set it to sixty foot pounds of torque and get a 5/8 inch socket, put it on that torque wrench, come over here and tighten this bolt". That might happen someday, yes. But, of course, calling for help, a machine needs help sometimes and the most interesting -- there's a wonderful generalized diagnostic that can find almost any bad thing, which is that you have a model of a machine and the machine's there too, and they part ways. In other words, you're collecting sort of the data that tells you where the plant should be going but it's not going there. And the answer might be that a pipe broke, or something like that. So there are general things and very often the thing to do is to call for help. You might say "come quick" or "something is screwed up" and the guy comes and discovers that a tank has a leak or a pipe...you know, things like that. So the answer is yes. I've listed here a set of sort of simple-minded things that a plant could do, the kind of information that could be handled very easily. If you have plant that's making something that's a commodity and it has inputs that are sort of like commodities, you might want to control according to what the futures market says and things like that. And the trouble with that, today if you decided to do that, someone typed those prices in and they made typos and they shrugged their shoulders when they...they don't even bother noticing, they just type in something new when they get a new price. Well, if you have a big plant, you wouldn't want it to suddenly stop making gasoline and start making diesel fuel because of someone's typo. There's reasons to get the information to be certified just like you might get any other part of it recertified. The entrepreneurial side of me says there's an interesting aspect to all of this. No one is doing any of this, no one at all. And this machine Internet might be something someone owns or might be like the regular Internet and there's a backbone that someone might own. The creation of generic agents is something that is a lot of work and no one in particular profits from it, but the people who specialize those agents to correspond to their pump or their valve would have an easy time once the generic one was made. These are a list of aspects that might make someone want to get involved in this if they thought the idea was any good. (Applause)

Ted Selker: I think this is a completely exciting idea and I would be surprised if we don't hear more of such ideas of this kind of thing happening because I think inevitably it will save people a tremendous amount of focusing on the kinds of things that people are so bad at focusing on and allow people to focus on things that are more specific to the kinds of things people are good at focusing on. If you were going to ask me if these were interface goals as well as other design goals are to taking the tools out of the task.

User System Ergonomics Research (USER)
[ IBM home page | Almaden Research Center | IBM Research | (C) | (TM) ]