Managing the New Web

In this section of "Untangling the Web," we're going to cover managing the new Web.

Here's our session plan: first we're going to cover a bunch of administrative issues because it's really important that you understand how to manage the new Web. Then we're going to cover some resolved issues. You'll notice there's a big question mark after the word "resolved," and that's because you might not agree that some of these issues are resolved. But that's okay; there's going to be lots of disagreement whenever we talk about managing anything. Then we're going to talk a little bit about users and user support. This is an important thing in dealing with the Web, and after that, we'll talk a little bit about some emerging uses of the Web. There's all kinds of new uses of the Web, and we'll talk about a few of them. We obviously can't talk about all of them because there's so many. We're going to talk briefly about Web access to legacy data. This is a relatively new use of the Web. What it enables you to do is to take your legacy data, all your MIS systems and all the data that you've collected over the last years and months and decades, and actually use the Web to access that data. This may be the cheapest way to get hold of that data. We're going to talk a little bit about Web security, and then we're just going to give you a brief introduction to live documents. Now, we're going to talk a great deal more about live documents later, but this will just be a brief overview.

First, there's some legal issues. Cornell University has a full-time lawyer on its IT staff, and the real question is, should you? Well, not a lot of universities really need that kind of thing, but I think it illustrates the fact that Cornell thinks it's important enough, that legal issues are important enough, that they actually have a full-time lawyer, and that's something you really ought to think about. Another issue is the whole issue of copyright, pornography, plagiarism, racism, sexism, and all those kind of things -- all the potential misuse of the Web. And of course, there's access to the alt.. newsgroups. You probably have all heard about those; no need for me to go through them. But this is probably the reason that the Web gets the most flak, is just because of a few a little off-color newsgroups. But a real question is, are you going to give your students, faculty, and staff access to them, and if you don't, are they going to be able to get access to them anyway? Probably they will. At any rate, you need some kind of policy. Another question is, what's fair use? We sort of know what fair use is when we're dealing with printed documents and things like that, but the Web changes quite a bit of that. It's also, as you know, very easy to copy text, images, software, etc., from the Web, and you can put it in your own stuff. Lots and lots of students do that. How are you going to protect against that? What are you going to do about that? Those are all issues you're going to have to deal with.

I think that, in most cases -- and most universities have discovered that in most cases, it's just enough to take the policies that you already have in place; the policies you already have about plagiarism, stealing, cheating, and all those kind of things and just extend them to the Web. An important thing to do, though, is to talk to your legal folks before you do anything kind of strange. For example, at Princeton University, we decided to put up a ride board. The ride board was a relatively simple kind of thing. What we wanted to do was, students at Princeton -- like at other universities -- often during breaks go and travel to all parts of the country and all parts of the world. Let's say that I'm trying to go up to Boston, and I'd like a ride. What I could do is, I could go up to the ride board and say, "Gee, I'm interested in going up to Boston," and see if anybody else has posted something that say they'll take me. But suppose the person who takes me turns out to be a terrible driver or a maniac or some kind of strange person. What's going to happen? Well, before we put this ride board up, we went off to our legal folks; and our legal folks said, "Well, you could do it, but here's the text of the warning that you have to have in front of this thing on the Web." So that's the kind of thing that you're going to have to do. Another thing that's really very important is to listen to your users' sensitivities. A lot of things that you might think are legal -- and in fact, that might be legal -- all your users might be real sensitive about. I think a good rule is that if your users are sensitive about something, you ought to pay some attention to it, even if it doesn't raise a legal issue.

There's also some issues about record keeping. The Web lets you log the IP addresses of people who are using your Web site. Should you keep those things? Well, you could keep them, but there's all kinds of issues of privacy if you keep them. An example of that is that we have all kinds of AIDS information out on the Web, as many universities do. We could log information about which users access that, but I think that's an invasion of privacy. Do you? It's something that you're going to have to decide at your university, and decide what you're going to do. Another problem is that you really can't log URLs that users use at some other site, other than your own, unless you have something like a proxy server behind a firewall and you enforce the use of that thing. But again, even enforcing something like that is difficult to do. If you do keep logs, who should have access to them? That's just another touchy issue that you're going to have to deal with.

Another issue is pointers. When you build a website, especially if you build your own home pages and things like that, you're going to have pointers to all kinds of other sites. Now, you might decide that you're responsible for what's on your Website, but what about the stuff you point to, and how many levels down? We built a Website several years ago that pointed to something that looked perfectly okay -- in fact, it was perfectly okay. But the thing we pointed to pointed to something that we would never have put on our Website. Who's responsible for that? How far down are you responsible, and what are you going to do when users complain? Again, going back to the idea of dealing with users' sensitivities, a good policy is that if a user complains and you look at it and there's any merit at all to the thing, pay attention to your users. You're doing all this for your users anyway, so you ought to really pay attention to their sensitivities, again, whether it's legal or not. Generally, if you find something offensive, just get rid of it.

Another legal issue is citations. More and more, students, faculty, and staff are citing things that are not in the library, but are things on the Web. And when you cite something on the Web, the stuff on the Web tends to move around. So you point to something today; tomorrow, it's not even there. Or you point to something today, and tomorrow, it looks quite different. Or you point to something that's a multimedia site. How are we going to do this? A lot of folks have suggested that what we do is we might treat references to a Website as a conversation, as references to a conversation. So, if I talk to someone, I could cite the conversation, and of course, there's no real record of the conversation; and people tend to move around and things like that. But that might be a possibility to do.

Another very important issue is network security. Now we could talk for days about network security, but the basic point about network security is that every server will be attacked. Not every server might be attacked, or some servers might be attacked. Absolutely every server will be attacked. In my own office, I have a computer that is never used as a server except really, really infrequently; sometimes 15 minutes a week. As soon as I turn that thing on, within minutes, people come in and try to break into my server. They must be out there lurking all the time. I strongly recommend that you look at the book Firewalls and Internet Security; Repelling the Wily Hacker by Cheswick and Bellovin. These are two folks from AT & T who are responsible for AT & T security. It's an incredible, scary book. If you find the book too technically challenging, give it to your folks responsible for the Web. They ought to read it and they ought to tell you what your plan is to protect against security threats. If you don't have a plan, you're in real trouble. Another important issue is whether you're going to have home pages and servers for students, faculty, and staff. There's actually no way you can really avoid letting these folks have home pages; the question is, are you going to advertise them? Are you going to link to them, and how are you going to deal with them? This goes back to the pointer problem. If from your home page, you point to home pages of students and students do disgusting things or strange things or, at any rate, things you would not want done, what's your responsibility? Our scheme at Princeton is not to point to these things at all, though we encourage all these folks to have them, especially students to have these pages. What we do do is, though, we make it so that it's easy to find these things. All student home pages have names that are easily derivable from the campus phone book, so anybody can find a student home page, yet we don't point to them directly. In the case of faculty in departments, of course, all those folks can have home pages and we'll point to them if they'd like us to. Another issue is that on your Website, you're going to have all kinds of information providers. It's hopeless for a computer center today to own all the data; in fact, it actually was always hopeless for a computer center to own all the data, but in the past, we thought we might have been able to do that. Today, what you're going to have to do is you're going to have a bunch of information providers, and what you have to do is, we're going to have to certify these information providers. For example, are student organizations okay information providers? Well, they might be, they might not. Even departments -- are they certified information providers? You're going to need some scheme to decide who are these people and how you decide if they can put stuff on your Web.

Web page design has also changed unbelievably. As Dorothy said, "We're not in Kansas any more." Web page design in the past just required you to know a little bit of HTML. That's not true today. Today, there's Java, JavaScript, ActiveX, Shockwave, RealAudio, Live Audio, all kinds of things that you really need to make a good Web page. And a good Web page now requires real technical skills and real design skills that go far beyond knowing HTML. Don't think you can put up a simple HTML page any more. Your users are just not going to buy that any more.

Alumni support is another important issue. Are you going to give your alums free e-mail or E-mail directories? Both these things can be expensive and time-consuming to do, but you've got to remember that your alums now, at least a lot of them, have grown up using computers on campus; and even those that haven't, now the Internet is ubiquitous, and even my mother likes to use E-mail and things like that, and certainly, when she was in school, she never had access to E-mail, so all of your alums are going to sort of expect this kind of thing to happen, and you've got to think about how much service you're going to give to your alums. There's obviously good reasons to give these services to your alums. For example, your alums generate a lot of income for the university, so you'd like to do good things for them. Are you going to give them special Web pages? Are you going to have class home pages, personal pages? Are you going to make all this free? Are you going to do forwarding of E-mail? That seems like a cheap thing to do, but it's an administrative headache, and a lot of alums would like you to do this for them. Are you going to give them dial-up access, or are you going to go off and get some volume contracts with an ISP, an Internet Service Provider. That's actually an interesting thing to do. Instead of sitting here and doing all the work yourself, you could go out to an ISP, get some kind of contract, and when an alum calls and says, "Gee, I'd like Internet access," you can say, "Well, we have somebody who can give it to you at a really inexpensive price." And what about access to alumni legacy data? There's all kinds of data that you keep on alums -- who's in each class, who's done all kinds of wonderful things -- and alums are going to ask for that kind of information. And at Princeton, we've made a lot of that information available to alums, and we believe that's been very, very effective.

There's also some organizational issues. As you can see, there are a lot of things to consider in taking care of a Web. You're going to have some kind of management and technical team, and you've got to decide who's going to be on these teams. Who decides what's on your servers or in your Web pages? Who prioritizes requests? If you're successful, you're going to get lots and lots of requests coming in; which ones get done first? Faculty members are going to ask you to do all kinds of things, and that's neat. That means everything is working real well. But it's going to take a lot of work, and who decides who gets in front of the line? Also, who decides what features that you can use or avoid? There's a lot of features that are only available on certain browsers. For example, Internet Explorer has very special features. Are you going to allow them? What about newer features like frames or Shockwave or things like that, that some people won't be able to get access to? Are you going to allow those things, or are you going to prevent them?

Another organizational issue is, what services are you going to offer? Are you going to build Web pages for people? They'd love you to do it! Are you going to build CGI Scripts, applets -- there's a real challenge! Are you going to teach courses, are you going to build courseware? There's a hundred things that you could do for people, and you've got to do a bunch of them. But which ones? And to what level? And how's this going to all get done? And how are you going to manage software versions? That's almost hopeless. Today, anybody can go up to the Web and get the latest software version; not only can, but will. We regularly get questions from people who sit there and ask us about some software and we say, "What version are you using?" They tell us they're using a version much later than anything we've seen, and we're the technical people out here. This kind of thing happens all the time. And what kind of skills do you need on your team? It used to be, you just needed a couple techies that were hanging around the computer center. No more! Now, you need people who can do multimedia design and layout. What's your Webmaster going to look like? Are you going to have people that can do Java programming, technical writing, all those things suddenly become skills that you need, one way or another, on your team.

There's also some structural issues. You have to decide what the network and server structure is going to look like, who can put what on which server, what's the security level of servers, what kind of hardware you're going to run, and all this stuff changes every day. So you can't make this decision and think you've made the decision and it's all done. This stuff keeps changing. What about secure servers? Well, there's an easy answer for secure servers. You need them. In fact, it would be really a good idea to make all your servers secure servers. The way things are going, every server ought to be a secure server. That will allow you to do authentication and will also allow you to encrypt the data as it moves around the network. Believe me, you really need to do this. And what are your home pages going to look like, and who's the audience? You could say, "Well, we know what our home page is going to look like, and surely the audiences are users." But your users are lots of different groups. Your users are students, faculty, staff. You could have just home page for all those folks, or you could have different home pages for all of them. Now you might think that you have to have one page for all of them because you really want to give all your users just one URL, but with some advanced features in the Web (like something called cookies, that we'll talk about) what you can really do is you can give different constituencies the same URL, and they can all see home pages tailored to them. That's something you really ought to consider.

A lot of your users are going to consider running their own server. Why are they going to do it? Well, one reason they might do it is there's no central server; that is, they're forced to do it. Since there's no central server, we have to run our own Web server. Another reason that users run their own server is they want control of their own data. Well, everybody wants control of everything, and so that's not an uncommon thing. They also want to change their data a zillion times a day. At any rate, they want to change their data at time inconvenient for you if you manage the central server. Another reason people want their own server is they need to write CGI (that's Common Gateway Interface) scripts and the central server won't allow it; and in fact, the central server shouldn't allow it. Writing CGI scripts on the central server is a real security risk, so it's not surprising that those folks won't allow it.

There's some reasons not to run your own server. If you are successful, it's going to consume your entire computer. In most cases, you're going to need a dedicated computer for Web server. That's not the way it starts out. You start out using the same machine that you do text processing on as a server, but very, very soon -- again, if you're successful -- very, very soon, the whole machine is gobbled up. And in fact, you'll soon decide to buy another machine and the new, better, wonderful machine you buy -- that's not going to be the machine you work on. No, that's going to be your Web server because that's going to need more resources than the machine that you're using. You might think that you can write your own CGI scripts, but they require really serious programming skills. Are you really good at writing Perl, or C, or C++? If you're not, don't even think about it. You might think you can get a student to do this for you, but getting students to do things creates all kinds of problems, especially when students do things like graduate or get involved in exams and things like that; so this is probably not a good solution to this. Servers also require things like uninterruptible power supplies. You do want your server to be up all the time, don't you? You'd also like to back it up. You're also going to have the problem of software upgrades, and you have the problem of security. Every server is going to be attacked. Now, you might think that, "So what if my server's attacked? I'm making all this information available publicly anyway. Who cares if people break into my server and see the stuff that I'm going to show the whole world anyway?" Well, that's not the only kind of attack. That's not the only kind of way we can attack a server. One thing we can do is do denial of service attacks, where we come in and we tie up your server in such knots that nobody else can get to it. Or we go in and gobble up all your disk space and make your server fall off the edge. So there's all kinds of attacks, other than just looking at the information. And if you have your own server, all these are going to be your problems.

The question, should you have a central Web server? -- a lot of folks say NO, and here's some of the reasons they say NO. They say what you should do is you should empower your users, make them run their own servers and code their own HTML. Coding HTML is great fun! And why deprive your users of such great fun? Another reason that people give is that it's okay to let users fail. Well, it is okay to let users fail, but you as a service organization, I don't think want to do that too often. You'd like to do things to stop that if you could. MacHTTP, which is the most common Web server --that's a free Web server that runs on the Mac. There's a version that you can pay for called WebStar, which is a little bit better, but they're really the same. MacHTTP is rumored to be pretty easy to run, and, in fact, I've run it. And lots of people have run it. Hundreds, thousands of people have run it, and it's not that hard to run. It's just a nuisance to run, and, if you're in the English department -- or even if you're in Computer Science and you're interested in some research project, the last thing on earth you want to be doing is fiddling around with some Web server. The point has also been made that anybody can learn HTML. I've heard story after story about people who could barely learn to speak English who have learned to code HTML, but anybody can learn very simple HTML. It's doing anything serious with HTML that's a real problem. But there's a more important point. The point is that even if you could learn HTML, why bother? Why go through all this? Lastly, the point has been made that information technology shouldn't do people's jobs for them. The people who are doing all the technologists should just get out of the way. Well, I agree. The technology should get out of the way and they should let people do their jobs as faculty members, as staff members, and things like that. People's jobs aren't really running Web servers -- except, of course, for the people in the information technology group.

Some reasons why you should have a central Web server. Let's take a look at Princeton's solution. What we do, is we empower users by helping them, not by controlling them or making them do everything themselves. Just because you have a central Web server doesn't mean you control the data. The data still belongs to the user, and in fact, what we try to do is help the users, not get in their way or take over their lives or anything like that. And while it's true that anybody can run their own Web server, we make it so that no one has to. You have the choice. And we support folks who do and who don't; it's your choice. However, one of the things we do do is we hang enough carrots out in front of people to make it so that there's very little reason for people to run their own Web server.

In talking about running your own Web server, we have to address the problem that users do want control of their own data, but they don't want control of information technology. And as I mentioned before, users' jobs are being faculty and staff, not being computer technologists. And information technology folks are in the service business. They do not let helpless users fend for themselves -- unless, of course, the users want to and then they can do whatever they want.

Let's talk about one way to empower users. What you should do is you should support and encourage the use of HTML translators and HTML builders like Microsoft Office 97, Microsoft Word 97, FrontPage, PageMill, and all those kind of things. These things enable your users to generate HTML without knowing any HTML at all. Another thing you should do is give users access to some user file space or Novell server or other network file space. Then what users can do is users can take their Web files and Web pages and they can store them on this Novell server or other network file space and it looks just like it's a regular user disk. Then you run a Web server that accesses these user disks, and so it looks like you have a central server accessing users' data. And in fact, to users, it looks like users own their own data, and they can update the data as often as they want.

From the user's point of view, it's their own data. What they do is they build an HTML file with Word or some simple HTML creator, or if they really want to, they can build HTML with some simple editor. However they build the HTML, they build it themselves and then what they do is they tuck it away in some file space that's accessible from a Web server. And it appears on the central Web server. It looks like they've actually added it to the Web server. The user owns the data; the data appears to be on a user disk, and the user can update it any time.

Why would a user run their own server if they could do something this simple? Well, one reason is a user might still want to be able to do CGI scripts. Here's what you might do to solve that problem. First of all, many of the CGI scripts that a user wants are very similar. There's some common things users want to do, so pre-build them. Go off, figure out what the common things are that CGI scripts ought to do, and pre-build the common CGI scripts. For example, a user wants to gather data from a Web form. This might be a quiz, a survey, a department form, a registration form, or something like that. And build some CGI script. We'll call the CGI script "mailform," okay, that effectively what it's going to do, it's going to gather the fields inside a form from the Web and it's going to e-mail it to some person or some list of people. So we're just going to take the data off the form and we're going to mail it somewhere. If we do this, there's going to be really little need for your own scripts.

Here's an example of how this might work. In the upper right hand corner, you can see what a user might see on the screen. There's a simple Web form which asks you to enter a color, a brand, and the doors for some kind of car that you want. Now, I know you haven't seen much about HTML yet, and me talking about HTML might be a little bit premature, but let's talk about HTML briefly right now to show you how simple the HTML is that supports this kind of thing. When we define a form, what we've got to do is we've got to specify some action; and in the action, we basically have to specify the name of the CGI script. And we've done that; you can see, on the line that starts <form.method=post action= a bunch of stuff, and it says mailform?mylist@princeton.edu. What this pre-built CGI script does, this mailform CGI script does, is it says, "Take the information in the fields 'color,' 'brand,' and 'doors' and send it off as electronic mail to whatever is at mylist@princeton.edu.

Here's what the people at mylist -- that might be one person or lots and lots of folks -- get. What they get is a file that says color (that was the name of the color field) = and in quotes it says "crimson tide." And that's what somebody typed in on the form. Then it says brand = and the value is Ferrari. Then doors = 2. So what happens is this pre-built CGI script sends off to whatever e-mail list you want, it sends the name of each field and the value that a user typed in. At that point, the user can go off and process this e-mail any way you want. Now this might not be ideal.. Perhaps you'd rather have this in a database or somewhere else. But the fact is that you can do this kind of thing without ever writing a CGI script.

Now you can't pre-build every possible CGI script, but you would be surprised at what just building a few of them can do. That takes care of so many cases, it's really unbelievable. But you can't build every one, and it's really too dangerous and it's too time consuming to let users put their own scripts on your secure servers. Your servers are all secure, aren't they? Well, they ought to be! That's still no reason to have users run their own servers. Here's how we solve the problem.

What you can do, and what lots of folks have done, is build a CGI script facility. You let users write scripts, with some restrictions, on a special server. The server is not your main server, and it's not a secure server, either. You should make your users register to use the facility and have them swear to abide by some of the rules; and if they don't, don't let them use the server. You let users code anything they want, in C, Perl, etc. Now, that means that you're not going to have a lot of people doing this because this is really serious stuff; coding in C, Perl, Java, or other things that you can write CGI scripts in is not easy. You back up the server; you put what security you can on the thing, and the worst case is that the CGIs that these users write will kill each other. They'll destroy each other's scripts, but it's not going to take your main system down. And users understand that. Our experience at Princeton in running a CGI script facility is that the people who really need to write CGI scripts find this is a wonderful facility, and, in fact, nobody has hurt anybody. People who want to use these facilities use them with some responsibility.

Now I'm going to talk about some resolved issues. Again, as I warned you, you might not agree that these issues are resolved; but they ought to be, and, at any rate, I think they're resolved. And we ought to take these issues and push them aside and move on. The first resolved issue is Gopher is dead. If you have a Gopher server, get rid of it. Put everything on the Web; that's where everything belongs. Now I've heard that there are still people out in the world who don't have the facilities, computer hardware, software, whatever, to handle the World Wide Web. Well, that's the way the world is going, and we should spend no more time on Gopher. Everybody who wants to have access to the Web today has access to the Web, or can get access to the Web pretty easily. That's students, faculty, staff, parents, alums, children, whatever. You can assume that there's a Web browser on every desktop. I mean, the Web browsers are free, so anybody who has a desktop can get a free Web browser. In fact, there's competition among which free Web browser you're going to get. Now, you do need a solution for people without desktops; and there are lots of people without desktops. A lot of maintenance people on campus and other folks who don't have offices tend not to have desktops, and you'd like them to be able to get access to the Web because you're going to do things on the Web that assume that everybody has access to it. So you're going to need something like Kiosks or computer labs or something like that. Also you can assume that anyone can have e-mail. In fact, anyone can have free e-mail. There's a company called Juno; you can go off to URL www.juno.com and Juno will give anybody free e-mail. I'm not kidding. I don't mean that there's some catch or trick here or limited e-mail or whatever. Juno will give you totally free e-mail. It will give it to anybody -- your mom, your kids, your relatives, whatever. Well, there is one catch; the catch is that Juno puts ads all over your screen when you do e-mail, and you have to put up with those ads. But the ads are very targeted, and that's how Juno makes their money. But remember, anybody can have free e-mail access. And more and more today, there are companies now that offer free Web access as well. So anybody can have access to the Web or to e-mail.

Another resolved issue is that users have to have easy access to the Web, not just from the office, but at home and on the road, everywhere they are. The Web now delivers such important information and services that people need access to it everywhere. Users also must be able to publish on the Web. It's not enough any more just to be able to read the stuff on the Web; you want your stuff on the Web, and you want to be able to update your stuff on the Web. And that includes scripts and animations and all kinds of stuff on the Web, not just dull pages of text and things like that. Users also have to have the current versions of the browsers, utilities, plug-ins, and all this kind of stuff. Now, most of this stuff they can get right off the Web itself, but your organization has to do something to make it possible for them to know that they have the latest versions.

Another resolved issue is that some users are going to code their own Web pages. Actually, most users are going to code their own Web pages and you have very little control of this, so what you have to do is you have to leverage this to your advantage, and you also have to make it so that users have an easy time of coding their own Web pages. To do that, you should encourage them to use things like FrontPage, PageMill, Live Wire, Microsoft Office 97, and other things that create HTML and that manage Web pages. We can also assume that all new software is going to have some kind of Web or Internet component. In Microsoft Office 97, for example, every single component of that allows you to publish on the Web, making Web publishing easy for people to do. People can now publish on the Web with stuff they probably have on their desktop anyway.

Now, the Web has changed dramatically over the past year. You might wonder which year I'm talking about. It doesn't matter. This will always be true. This will be true a year from now, or two years from now. We could say the Web has changed dramatically over the past year. We can expect the Web to continue to change dramatically every day. Web pages have become much more interactive. It used to be that you just went off and looked at a Web page. No more! Web pages hop up and down, move around, allow you to provide input, things like that. The Web today delivers services, like calculators and stock market trades and virus checks and software updates -- all kinds of stuff, not just multimedia documents. This is a basic shift in what the Web is doing. We don't deliver documents; we now deliver services. Also, today it is now possible to have secure interactions. In fact, secure interactions are common. Secure interactions mean we do authentication and encryption.

The economics of the Web today are that you need a Web server anyway. I mean, you have to have one. Can you imagine a university without a Web server? Can't imagine such a university any more. So, since you need a Web server anyway, the cost of adding one more document to a server is minuscule. it costs you practically nothing to do that, therefore you might as well add everything to the Web. You might as well put everything out there. You might go off and look at the Delta Airlines site, at www.delta-air.com. You'll see. They have more information out there than you could imagine. You might say, "Why do they have all that information out there?" Well, it's so cheap to put out there, why not do it?

One thing that hasn't changed, and it's an important point, is that while all this fancy technology has changed dramatically, your users haven't changed; and your users expect pretty much the same things they used to.

What do your users want, anyway? Well, they want to get their work done. They don't want to fiddle with technology. Now, I'm in a technology area and I love to fiddle with technology. That's my work. But if you're a user and you're a psychology professor, or if you're in architecture or something like that, what you want to do is you want to get your work done, and all this talk about the latest version of the browser or the neatest new plug in or all this kind of stuff -- who needs that? You just want to get your budgets out or you want to teach better. Users want to be more productive. They want to be more efficient, they want to have systems that reflect their needs, not techies' desires. Techies have all kinds of strange desires for all kinds of fancy things, but that's not consonant with what your users really want. Users want systems that are reliable, that are secure, that are fast, that are intuitive. Have you seen things on the Web that are not quite like that? The Web hasn't changed any of this.

What are user priorities? Well, you're going to have to meet your user priorities. No one's going to applaud live movies from Uganda when they can't get their budget figures out, and yet a lot of times, that's what we do for our users. We give them these neat things on the Web while they're sitting there and still struggling with their budgets. Well, I guess budgets are less interesting to technologists. If you give them an on-line report and it takes 100 seconds to get it, that's still poor response time. A lot of times, I've heard people argue that, "Well, it used to take them three hours to get this batch report." Well, the Web is on-line, and 100 seconds is horrible response time. And horrible response time is horrible response time, no matter how bad things used to be. Also, in many cases, the existing systems have horrible security, but Web applications can't have horrible security. And it's no excuse to say that, well, your old applications had so-so security, so why should the Web be any better? The Web has got to be a lot better. You've got to deliver secure, authenticated systems.

Some other user priorities are that, on the Web, it is now possible to display greenbar reports. It's easy to do, but it's also unacceptable. We're on the Web now, and greenbar reports just don't look good on the Web. When we discovered about a year ago that, in fact, we could do this, that we could actually take our greenbar reports and, in a very simple manner, display them on the Web, someone suggested that, "Couldn't we have a background that looked like the greenbar paper that users were used to using?" Well, that's going in totally the wrong direction. The good news is that, by adding a tiny bit of HTML to these greenbar reports that you're pulling off the Web. you can make them look wonderful, and that's what you should do. Greenbar reports are simply unacceptable to display on the Web. Your Web applications are going to be compared to the commercial websites, and you know what the commercial Websites look like. So you've got to look pretty good, too. Don't forget that just because your users don't complain doesn't mean that they're happy.

What's it going to take to support your users?

Users are going to download software from the Web, including beta software and the latest browsers. They're going to do that no matter what you tell them they can do. They're going to do it because they can do it and they want to do it, and they're going to be able to do it. You can't decide any more what Web software and applications users are going to use. You can have an official version; in fact, you should have an official version of the software. But you're going to have to try to keep in front of your users, and for information technology folks, that's a new and strange thing -- staying in front of your users.

Here's some technical imperatives. Even though this Web stuff has really changed things pretty dramatically, you still have to plan, document, fuss with details, consult with users, and generally exceed their expectations. None of this has changed with the Web. You have to try to make your Web pages consistent, and that might mean giving your users some guidelines and showing your users examples of good design. Your users really need your help here. The Web is a new medium. It's not a book, it's not a printout, it's not a 3270 screen, and lots of folks talk about putting books on the Web. That's a bad idea. There really has been a media shift here, and books on the Web just don't work. Web pages require Web design expertise. Make sure when you design your Web pages that you include some of that expertise.

Here's some Web wisdom. Well, we hope you get Web wisdom throughout this talk here, but here is some concise Web wisdom. Make your Website sizzle, but don't forget that sizzle is no substitute for content. Content has still got to be pretty good. After all, that's why people are going to look at your Website. You're never going to have the latest version of all Web software, so don't even hope that you will. Use stuff that works and, when the Web software changes, which it inevitably will, then go off and get the latest stuff. You should also use HyperText links appropriately. I'd like to say, sparingly would be even better. You all remember when the Mac first came out and people discovered they could have 64 fonts instead of just one, that people started writing documents with all 64 fonts. During that time, every memo I got looked like it was some kind of ransom note. I'd get a memo and I'd say, "Okay, we'll pay the money!" That's what a lot of documents look like today with HyperText links. There's HyperText links all over the place where they don't make sense. Think about why you're using these things. And lastly, don't forget the cutting edge service is much more important than cutting edge technology, though as a technologist, that hurts a little to say.

Here's some emerging uses of the Web. Now, it's impossible to cover all of the emerging uses of the Web, and no doubt you know lots of uses that we're not going to cover here. But here's some interesting uses of the Web that will establish some of the interesting things the Web can do. In education, there are thousands of free sites. Actually, most of the things, as you know, on the Web are free. There is an interesting biology site, Access Excellence, which actually is a commercial company puts up, aimed at students from K-12. It's really a wonderful site, and you really ought to take a look at it, not because you want to know biology, but to see just how a good site is put together. There's a wonderful biomolecules site that Harvard University has put up that's also worth looking at, and there's also a wonderful chemistry site -- in fact, lots of wonderful chemistry sites around.

There's lots of education sites where folks actually expect you to pay for these sites. I don't know what's going to happen to these things. I don't know if these are going to be successful or not, but many things on the Web obviously are going to require that you pay, and so I'll mention a few of these sites. One of the strongest sites is a site called WEST, which offers a complete course management system for the Web, and they charge for that. Another place is Peregrine Publishing Incorporated's Biology Place, also a site where you'd have to pay to get services to learn something about biology. And Addison Wesley Longman is selling CD-ROM-based Web tools and Websites where you pay for the CD-ROMs and you get to do stuff related to physics and chemistry and mathematics on CD-ROMs.

Now, why would people want Web courses on CD-ROMs? Well, you probably realize there's lots of CD-ROM courses, but how do we tie the CD-ROMs to the Web? Where's this strange link between CD-ROMs and the Web? Well, in these Web courses that Addison Wesley offers, the HTML and all the necessary support files, even a browser -- they're all on the CD-ROM. And it runs very fast from the CD-ROM, and that's the point. If you want really elaborate simulations and videos and fancy things and you want to download them from the Web, it takes a long time to do. So Addison Wesley has just popped the stuff onto CD-ROM, and they use the same Web tools that you use on the Web to access the CD-ROM and it looks like you have a very fast network connection, but you don't. What you have is a very fast connection to your CD-ROM. And if you want, you can take the CD-ROM and you could copy it to a local Web server, still faster than a remote server, and it still gives you the ability to modify the thing and update the thing by going out to Addison Wesley's site. I think we're going to see lots more of these hybrid sites where we take the things that take a long time to download, the fancy videos and the fancy simulations and things like that, where it takes forever to get these things off a remote Website, and just pop them on a CD-ROM, so we'll kind of split the information. Some of the stuff that's slow will be on a CD-ROM, and some of the stuff that needs to be current will actually be out on the Web.

Other emerging uses of the Web are newspapers. The New York Times has been on the Web free for a long time now, and it's the complete New York Times. USA Today is out there, the Texas Observer is out there, newspapers from Uruguay, Mexico, around the world. There are thousands and thousands of newspapers out there, and most of them (except for the Wall Street Journal) are free. There's also student newspapers. If you go out and search the Web, you're going to discover that most colleges and universities now have their student newspapers on-line, but if you look closer, you're going to discover that the Jefferson, Indiana, High School has a newspaper on-line, and more and more high schools and now elementary schools even, put student newspapers on-line. You've got to think about the fact that if you don't have your student newspaper on-line that you're totally in the backwater of technology now. There's also E-zines, that is, electronic magazines. There's thousands of these things out there. Things you've heard of, like Car and Driver, Time, Biking, and things you've never heard of, obscure little magazines. Almost everything is published on the Web, and again, most of these things are free.

There's all kinds of journals, everything from the Annals of Internal Medicine, the Chemical Educator, Electronic Geology, there's just thousands and thousands of journals that are out there. Some of these you have to pay for, but an awful lot of them are free. There's all kinds of digital archives. Mellon's JStor project, for example, has over a million pages of electronic journals on-line, and an interesting thing about these electronic journals is not only can you search them (which you might expect) but you can also see exactly how these things look. So the journals are stored in two ways; they're stored as text to make them searchable, and they're stored as images, so you can see exactly the typography. You can even see little smudges and tears on the pages. Everything is reproduced perfectly. And this million pages is expected in just a couple years to grow to five million pages. There's also newsletters; Edupage, for example, from EDUCOM, and many, many, many other newsletters, including little newsletters from universities. For example, your information technology group probably has a newsletter, and you really ought to publish that on the Web. Almost everything is published on the Web. What happens in a lot of universities is, folks first start publishing their newsletters on the Web, and they continue to publish the paper copy. Then after a while, they realize nobody's reading the paper copy anyway, and at any rate, the paper copy's too expensive to produce, and they stop producing it. You might want to do that too.

Another emerging use of the Web is all kinds of streaming audio. Now, it used to be in the past -- the past is, like, weeks ago in Web time -- in the past, if you wanted to hear an audio file, what you did is you went off, you clicked on something on the Web, and then you downloaded this audio file. And that took anywhere between minutes and what seemed like days to get this audio file down. Then you started the audio file up; it played for a couple seconds, and you were done. Not very satisfying! With RealAudio, which is a form of streaming audio, what happens is we download the very beginning of a file; typically about eight seconds of the file. As soon as we have eight seconds or so downloaded, we start to play the thing, so you start hearing the thing after we've only downloaded a few seconds of it. And then while we're playing it, we continue to download it. We continue to keep this little eight-second buffer filled. This creates all kinds of possibilities. For example, you could listen to a radio station on the Web. You could say, "Well, you could never do that in the past, because we'd have to download 24 hours of audio. That would take weeks to do!" Now, what we could do is in just a few seconds, we download the beginning of the broadcast, just delay the broadcast by a few seconds, and we can listen to live audio on the Web. And in fact, there are many, many. many radio stations that broadcast live on the Web using RealAudio or other kinds of streaming audio. There's also all kinds of Web robots out there. Now some of these things are not really, strictly speaking, Web robots, but we're not going to get into the semantics of exactly what a Web robot is. But normally on the Web, what you do is you go out and you get what you want. With something like Pointcast, for example, Pointcast broadcasts on several channels and you go off and you pick the channels or the information that you want. So you kind of tune in to the particular kind of information you want. Really, properly, this is called a Server Push kind of thing rather than a Web robot. A Web robot would actually wander all around on the Web and gather information for you. And some of these things are beginning to pop up, and the concept of user profiles, where you sit there and you say, "Here are the things I'm interested in. Go up to the Web and get these for me." These kind of things are going to become more and more common. There's also all kinds of photo archives out there, including some from Microsoft and from Weststock and from other folks. What they've done is they've taken all kinds of photographs, standard photographs, and they've digitized them, and you can look at them on the Web. You can say, "Wait! Wait just a second! If I can look at them on the Web, I can steal them, or I could take them. And how do these companies make money?" Well, what they do is they give you little thumbnails of these images. Find an image you like, send some information back to the company, and you get to use the real thing -- all done electronically. Another thing that's being done on the Web is auctions, real electronic auctions. There's a place for example, at www.onsale.com, and they conduct an electronic auction on the Web, and you can go out there and you can bid against all other people on the Web, and you can buy stuff. This is real stuff. Folks in my office have actually bought some of this stuff, and it's good electronics and other kinds of products. This stuff can really be done.

There's thousands of other uses of the Web. There's phone directories, there's medical information, there's Yellow Pages, there's maps -- thousands and thousands of other uses. It would be impossible to tell you everything that's out there because today there's over a hundred million URLs out there, and new uses are emerging all the time.

The Web has become the marketplace for goods, services, and ideas. This is really quite different than what it was just a short time ago, where it was a place where you could see a document with maybe a picture in it or something like that. Because of the Web's becoming the marketplace for goods, services, and ideas, people expect easy access to it; from their offices, from home, and from on the road. They also need to be able to put their own stuff out there, so they need to be able to publish on the thing really easily. Universities, which used to be able to provide all the services, today can really only provide some of the services. A lot of the services, universities are going to have to go out and buy, and it might be that some day, universities are going to have to buy all of the services as commercial firms are able to do this stuff cheaper and more effectively than universities can. We're not there quite yet.

Now I'm going to talk about some more emerging uses of the Web, and one of the ones that has gotten the most press is the Intranet. As one of the ads says, Intranet is not misspelled, though it might look it to you. What the Intranet is is taking the Web tools that you use to browse the Internet and use them at home. We do this because we discovered it's very useful to Web surf at home. The same Web tools that are good for doing stuff out on the Web are good for teaching and research and for publishing, organizing, accessing, and managing your own data. Another strange thing that's happened, which legitimizes the Intranet, is we've discovered the Web is a legitimate MIS tool. That is, the Web can actually be used to do some of the financial back-office stuff in your office.

What kind of things might you use the Intranet for? (That's Intra-Net.) Well, you might use it as your Campus-Wide Information System, or CWIS. You probably had Gopher up before you used the Web, and that was probably just a Campus-Wide Information System. Well, Gopher doesn't exist any more and you can take all those local files and things and just put them on the Web. You can also put forms on the Intranet, and there's lots of different ways you can do this, but I'll bet you have dozens if not hundreds of forms wandering around the university, Some of them really aren't even university forms. For example, some insurance forms really often don't go inside the university, and in fact, if you chat with insurance companies and other folks like that (as we have done) it's sometimes difficult to build these forms on the Web. What would be best is if these companies would just build the forms for you. What you might do instead is scan the forms, pop them up on the Web. It means that you can't key information into them, but at least people don't have to call your HR office and get copies of the forms, which they never have, of course. You could also put forms up on the Web that you actually fill in and print. You could make the forms come alive; that is, you could do computation right on the forms by using JavaScript or something like that on the forms, and you also might want to make your forms secure, authenticated, and electronically routed. So somebody fills in a form on the Web, the computation is done on the Web, an electronic signature is captured again from the Web, and it's routed to where it ought to be. So forms are never filled in by human beings on paper and never moved around on paper. This would be a great idea to do. Has anybody completely done this? Well, I don't know of anybody who's completely done this, but a lot of folks are moving in that direction.

Other things that you might have on the Intranet are interactive calendars. Many companies who make calendar software have the ability to publish on the Web. Software distribution -- you probably know that you can distribute Web software on the Web. You're probably doing that, but all kinds of software, totally unrelated to the Web, can also be distributed on the Web. And you can do course management and things like RealAudio for language labs and all kinds of other things on the Web to support instruction and administration.

The Intranet, with the new browsers that are available, also supports multimedia e-mail, general e-mail, class lists, committee lists, faculty and staff lists, and all kinds of things that you'd expect in campus mail. What's happened is the browsers, which just used to browse the Web, now include all kinds of features in them that go really quite a distance outside the Web. There's also multimedia newsgroups. Now, you probably have some experience using newsgroups, and they're kind of dull to look at. If you do have anything included in them, any kind of pictures or graphics or whatever, it's a real difficult thing to include them. No more! With the browsers that are available today, it's just as simple to include some multimedia element in the newsgroup as it is to include it on a Website, which is pretty easy. The robot I talked about before, Pointcast, which lets you go off and subscribe to certain channels and things like that and have information delivered to you on the Web also exists in a local form. That is, you can have local channels, so instead of getting something from some company off in some corner of the world, you can get something from the president's office. Essentially, you could take control of some of these channels here and people can tune in on the Web and find out what's going on in your own university, a really fine use of the Intranet. Things like elections -- our student elections now are all done on the Web, another use of something inside the university using the Web tools that are available.

Let's talk about access to legacy data.

The Web can be used to access data on mainframes and servers. One way to do this is a browser can be used as a client or HTTP (HyperText Transport Protocol) can be used to download an application that serves as the client. This might be the quickest way to get legacy data apps on-line. This is one way to move to multi-tier, object-oriented applications, which a lot of you, I know, want to do.

Why should you use the Web for legacy data? Well, if you use the Web, the Web is platform-independent, but you really ought to make sure it really is. Some solutions work only on PCs. When I say it's platform-independent, I mean that the browsers run on PCs, Macs, UNIX boxes and everything. A lot of times, when you have legacy applications, you've got to write special applications for each different kind of client, and that's a nuisance (not to mention that it's very expensive to do.) It's also Operating System independent. There's no need to worry about some new version of Windows, like Windows 2001 or whatever they're going to call it when it comes out. A Web browser is also ubiquitous; everybody already has one, and they're free, so this is a great way to get a client on everybody's desk. And it's cheap; the browsers are free, the plug-ins are free, but don't forget: you're going to need some development tools, and those can be very expensive. There's also going to be a great deal of time in doing this kind of stuff.

There's three basic models. Whenever anybody says there's three ways to do something, you know there's about ten or 12, and there are probably ten or 12 here, too. But I'm going to talk about three of the more common ways to do this. One way is to have a Web browser go off to a CGI script, that is the Common Gateway Interface script that we talked about a bit before, which goes off to some kind of mainframe server that starts a batch job, and HTML is returned. This is a very simple kind of thing. This takes your batch jobs that live on your mainframe, starts them up, runs them, captures the output of the thing, and just returns some HTML. It means your output has to have a little bit of HTML in it, but this is really not a very difficult thing to do, and the results are pretty dramatic and pretty easy to do, not very much effort involved here. We can take a Web browser and we can go to a Web server API. That's an Application Program Interface that accesses a database. HTML is also returned. This is much faster than CGI and there's also all kinds of automatic techniques today to make this even easier. And lastly, you can have a specialized client. You can use a browser to load it and play it. This gets you outside of HTML entirely. What you do is you just download the special application, run the special application. In this case, the Web is only used just to go off and grab the application.

There's lots of examples of this browser-to-server API; for example, Netscape Live Wire does that, Oracle WebServer does that, and Microsoft's Internet Database Connector (IDC) also does that. And there's lots more examples.

There's also a flood of Intranet products. There's Backstage and JAM/Web and Web SQL and dozens and dozens of products and new ones announced every day, and all of these are trying to make it easier for you to go up and use the Web to access and manage the data that you have already built at great expense.

Now we're going to talk briefly about security on the World Wide Web.

The first level of security on the World Wide Web involves access restrictions, and you can use access restrictions to allow or deny access to any directory by domain name, by host, by full or partial IP address, or by user ID or password. What this means in English is that you can decide who is going to get access to any directory any way you can imagine.

How do you beat first level security? Perhaps this shouldn't be in this presentation, but people are going to go out and do this, so you ought to know what you're up against. The first thing to do is attack the server. Your server should be behind a firewall. If it's not, attacking the server becomes very easy, and there's lots of very clever people out there. You probably have some of them in your computer science classrooms. You're probably teaching them how to do this, so get your server behind a firewall. If your server is behind a firewall and the firewall is very good, what you can do is you can attack a machine that's trusted by the server. For example, you probably have people accessing your server using SLIP or ARA, and what you can do is those machines are usually trusted, so we'll attack one of those SLIP or ARA machines and get into your server that way. Also, the access restrictions might seem to be secure but they're really only secure enough to protect things like software and things like that. They're really not sufficiently secure to protect things like payroll or other things you'd like to really keep secure.

You can use passwords to protect any Web program or any Web document or any directory, and these passwords are as secure as Unix passwords. Again, on the screen, you might see that after the word "secure," I have a question mark, and that's because, as many of you know, Unix passwords aren't all that secure. And that's all the security you're really getting. The way this works, the browser prompts for an ID and password, the data transfer of the ID and password is not encrypted, so anybody sitting on the network could listen and see your ID and password come through in the clear, and then they can go off to a nearby machine and do exactly what you just did.

How do we implement security on the Web? First, as has been mentioned before and likely will be mentioned a few more times, use a secure server. All the major server manufacturers and developers have secure servers so you can get them from anybody. It doesn't matter whose you're using. Next, do bidirectional authentication to insure the identities of the client and server to each other. Now what I mean by bidirectional authentication is I'm sitting at a browser and I think I'm talking to my bank. Well, I'd like to really know it really is my bank, not somebody else pretending to be my bank. That's one way authentication. But it would be nice if my bank also knew that I was me. That's the other direction that we want to do authentication. So on the Web, what we want to do is we want to make sure that both sides have authenticated each other to each other. You'll also want to do encryption of all transactions. That says you want to scramble the passwords, you want to scramble the IDs and you want to scramble all the information that goes back and forth. Does that give you perfect security? No, but that's a good start, and you've got to really consider doing at least that.

One technique for implementing security is to use a private key. This is probably the thing you're most familiar with. What you have is you have one key that's know by both parties. This is probably what you use when you log on to some mainframe system. The key is used for both encryption and decryption. That is, we take the key, we apply some fancy algorithm, and that encrypts the thing; and we take the same key and we apply typically the same algorithm and it decrypts the thing. The danger here is that passing private keys might not be secure. We need some way to get the private key to the other party without anybody seeing it. Some examples are DES, which is the Data Encryption Standard, or RC4. These are really fast and they're good for data streams. But they're not too good for authentication.

MIT has a scheme called Kerberos, which does private key passing. This is a scheme that actually uses private keys and it does it in such a way that the private key is really never passed over the network, so it's very secure. Many Web browsers now include tools to enable you to implement some kind of Kerberos private key passing scheme.

Public key schemes are more often used for authentication than encryption because they tend to take a long time to do. These tend to be computationally intensive. The way this is done is you have a public key known by everyone. Now this doesn't seem very secure, but stay tuned here just for a second. There's also a secret, private key and the secret, private key and the public key are related to each other. What you can do is you can encrypt with either one and decrypt with the other. Some examples of this are RSA; it's very slow, but it's very good for authentication. You would not use this for data encryption. And this is the most common scheme used, is the RSA scheme.

When it comes to secure Web servers, secure Web servers use something called SSL, the secure sockets layer. They support client/server digital certificates. This is the way they do bidirectional authentication. They use a scheme called HTTPS. You've seen HTTP; that's HyperText Transport Protocol. This is HTTPS; it's HyperText Transport Protocol Secure. This suggests that we're using a slightly different protocol that does secure transactions. You'll notice if you're using, for example, the Netscape browser that there is a little key in the lower left hand corner. You've probably seen that hundreds of times. If you look again, you'll notice the key is usually broken. When you're doing a secure transaction, the key will come together. There will also be a blue line near the top of the screen indicating to you that this is a secure transaction.

How does SSL encrypt the data? Well, what it does is use RC4. This is some kind of streaming encryption scheme with a one-time session key. The United States used to limit the key to 40 bits. Well, a 40 bit key can be broken by students in days, and students have the days to do it -- and they will do it, no question about it. A 128 bit key is now allowable. It's much more secure, and with computers as fast as they are today, that would take years to break, even by aggressive students. We should be aware, and certainly all the security organizations of the United States are aware that faster computers are going to reduce the time to break these keys, but that should be a simple matter of just making the keys longer.

Let's talk about secure server authentication using digital certificates, or IDs. On the Web, these typically are from VeriSign, and what they do is they authenticate the server to the client and the client to the server using an RSA public key encryption. In case you're wondering what RSA stands for, it doesn't stand for anything except for the names of the people who developed the RSA encryption scheme, so don't struggle with trying to figure out the acronym. There are server digital IDs and there are client or personal digital IDs. These work with Netscape, Internet Explorer, and almost every server.

How do personal digital IDs work? Well, they're issued to individuals or to certificate authorities by VeriSign. A certificate authority issues the personal digital ID to subordinates. The certificate authority is any trusted central administrative group that can vouch for the identity of those to who it issues personal digital IDs. VeriSign does this because otherwise it would be a nuisance to have to issue these things to every individual.

How do these personal digital IDs work? Well, you carry lots of paper IDs now. You carry passports, driver's licenses, university ID, Blockbuster Video cards and all that kind of stuff. And each one of those conveys a different level of trust. For example, your passport says that the INS, the Immigration and Naturalization Service, believes that you are you. Now when you go off to travel, you try to cross into Canada or something like that and you show them your video card, they say, "No! We're not going to let you in here." Why not? Well, because the folks at the border do not trust the people at the video store to vouch for the fact that's who you are. And this is exactly what the certificate authority does.

The certificate authority issues a digital ID and says you are you. The digital ID is as trustworthy as others feel the certificate authority is, just like the INS issues your passport or when Blockbuster Video issues you a video card. Obviously, the amount of trust in these two organizations is a little bit different. The certificate authority might be the information technology office, the university ID office, Human Resources, or something like that.

Here's how we do client authentication. The personal digital ID processing is almost identical to the server digital ID processing, so these things are really bi-directional. In doing this, the client could be sure who the server is and the server can be sure of who the client is, so secure Web commerce is possible.

Now we're going to take a quick look at live documents, things that go beyond HTML; things like JavaScript and CGI scripts and RealAudio and QuickTime and Java and Shockwave and bubble viewers and gif animations and all this kind of stuff that of course you're going to add to the very next Web page that you build!

Java is one of the things that makes documents come alive, but not the only thing. Very briefly, Java is just a programming language from Sun MicroSystems. There's also something you might have heard of called HotJava. HotJava is a World Wide Web browser that's written entirely in Java. It's a very early browser written to use Java and it was written by Sun MicroSystems, and it's totally unnecessary today. You don't need to use this. You needed to use it when there was no other way to use Java with any browser, but today, every browser supports Java, so there's no reason to do this at all. Java enables you to write little things called applets. These are little programs that can be downloaded from the Web and actually can do things outside of HTML, so you can get CD-ROM quality applications on your screen. Now there's some debate as to whether Java is going to change the way things are done on the Web, but the applet concept, the concept of taking a little tiny program, downloading it on the Web and having it do something on your screen is going to totally change the way things are done on the Web. And there's going to be lots of competitors to Java. In fact, there are lots of competitors to Java today.

What Java gives you is it gives you platform and operating system independence. You remember that the Web did this for documentation. You could write HTML and write it once, and then it could be used on Macs and PCs and Unix boxes and everything, and you can do the same sort of thing with Java. You write an application once with Java and then it can be used on PCs and Macs and Unix boxes. So Java does for applications what HTML did for documents.

There's lots of other ways to make live documents. CGI scripts, we've talked about those briefly. You can write them in Perl or Visual Basic or AppleScript, or almost anything else. It's a little script that enables the Web to do a little bit more than it normally does, but the way they work basically is that you fill in some form, you go off, execute something on the server, then the server returns some HTML. So this typically takes at least two transits back and forth between the server, which means that CGI Scripts tend to be slow. Also difficult to write. Gif animations are taking regular gif files and putting multiple frames behind them and making them move around. This is very simple to do. This is something that you can do easily yourself. There is free or shareware software that enables you to do this, and as far as the Web browser is concerned, these gif animations, which are quite elaborate and quite cute and you see them all over on the Web, as far as our Web browsers are concerned, they're just gif files. They're plain, ordinary gif files. There's also client pull and server push. With client pull, what you do is once you display a web page, the Web page continues to pull information down from the server, so things tend to move around. With server push, you download a Web page and the server continues to push more stuff down onto the page so again, the page looks alive. There's also QuickTime movies. These are movies that open in small screens on your Web browser and little things move around and you can also get audio with them. There's also plug ins. Plug ins are little programs that become part of the Web browser. Some of them do animation, some of them do all kinds of things. They do animation, they do crossword puzzles, they do all kinds of things you can imagine, and more of them are being invented every day. All these things used together help make your documents come alive.

Briefly, comparing just a few ways to make your documents come alive: Java; it's very powerful, it's very general purpose. It goes far beyond HTML, giving you stuff that you could never do with HTML. It's CD-ROM quality interactions, but it's very hard to code and very hard to develop, at least today, though things are getting a bit better. JavaScript is another way to make documents come alive. It's fast, it's only moderately difficult to code, but it's quite a different thing than Java. What it is best for is for HTML interactions. JavaScript is essentially an HTML scripting language and it runs with HTML as opposed to running outside of HTML, the way Java does. ShockWave is a Macromedia player that lets you play macromedia presentations. It's not as general purpose as Java, but it gives you great multi-media stuff without the panic and pain and difficulty of doing Java.

ActiveXs are another way to do live documents. This is a proprietary product. It's from Microsoft, it's not platform independent, though rumor has it it will soon be available on Macs and Unix boxes and things like that. It can be used instead of Java or it can work with Java, and there's many interesting demonstrations of that on the Microsoft Website. It's probably less secure than Java, though it's really much more powerful, and the reason it's more powerful, it doesn't have as many restrictions. These things sort of go hand in hand. The more powerful it becomes, the less secure it becomes. And there's also millions of plug-ins. The plug-ins tend not to be platform independent. You have to rewrite them for every single platform. And there are literally zillions of these things to choose among.

About CREN

© CREN, 1999

Contact Us