TechTalks Transcript
An Update on Web Development
 Laurie Burns [LB] |
 Greg Marks [GM] |
 Howard Strauss [HS] |
May 13, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
LB: Welcome to the CREN TechTalk series for Spring of 1999 and to this session on "An Update on Web Development." You are here because it's time to discuss the core technologies in your future.
This is Laurie Burns, your CREN host for today, sitting in for Judith Boettcher. And I'm pleased to be here for this session where our technology anchor, Howard Strauss, changes roles and becomes our TechTalk Expert for the day. With Howard as our guest, we also have a new technology anchor, Greg Marks, for the day. Greg is familiar to most of you as a co-host for many previous TechTalks.
Welcome, Greg.
GM: Thanks, it's good to be here, Laurie, and nice to have you co-hosting today. This TechTalk with Howard Strauss is an important update on Web development, a topic we try to cover regularly in this CREN series.
Interestingly, I happened to be checking which version of Internet Explorer was on one of my computers last night and noted that it explicitly gives credit to NCSA Mosaic, sort of as the granddaddy of the Web browsers. And as it happens, I first saw Mosaic in May of 1993 at a conference called Computing in the Social Sciences, which was being hosted that year in Champaign-Urbana by the National Center for Supercomputing Applications that had developed Mosaic. That is within about a week of being just six years from today.
What an amazingly fast period of change, especially when you remember that what I saw was only six months away from even beta release, and all the content was yet to be developed. Of course, the Web has been growing so rapidly because of its great power and usefulness. But another key factor is each individual's ability to decide on their own use of the resource, which is of course reinforced by key open standards and protocols.
Such individual flexibility in taking action has been a central force with other major changes in our use of technology, such as the use of personal computers, and in basic connectivity and access to the Internet. We are now seeing the potential of individual action in terms of our putting our own information out there through what might be called "publishing on the Web."
So today we have a number of questions for Howard on that topic, publishing on the Web. And of course, as the amount of such information continues to explode, it is crucial that we be able to locate information we need, so we'll also ask Howard about search methods and tools. We'll certainly cover a number of other aspects of the Web as well.
You out there listening to us are encouraged to ask questions during this TechTalk on any Web topics you wish. Given you're listening to us, you must have found the Webpage, and it lists the e-mail address for sending questions to Howard, expert@cren.net. Additional information resources are also referenced there. And finally, please remember to tell all your colleagues about the audio and the text archives of this and earlier TechTalk sessions.
Laurie, back to you.
LB: Thanks, Greg, and it has indeed been a wild ride over the last several years as I'm watching students coming into the university every fall and seeing their expectations for what they can get on the Web increase exponentially with each new population coming in. And it's kept us all jumping.
So let me tell you a little more about our guest expert for today's TechTalk. Howard is very familiar to all of you as the technology anchor for TechTalk, and in addition, Howard is the Manager of Academic Applications at Princeton University. In this role at Princeton, Howard keeps a close eye on what's happening on the World Wide Web and specifically how the World Wide Web relates to higher education.
Welcome, Howard, and thanks for being here today and sitting in the Expert's chair.
HS: Thank you, Laurie. Thank you, Greg. This is a certainly an interesting spot to be in. I hope we can at least provide some insight as to where we're going with the Web.
LB: Good. I should remind folks that you can ask questions directly of our expert at (as Greg has already reminded you actually) our e-mail address of expert@cren.net. Let's start with sort of a general question, Howard. How would you say the Web's role on campus is changing as we see more and more -- again, sort of thinking about this notion of students coming in and expecting to see more and more of their sort of academic life played out on the Web?
HS: Yeah, to answer that question I'm tempted to go back to something that Greg said in his introduction. He was talking about the fact that six years ago he'd bumped into Mosaic for the first time, around the time you and I probably bumped into it for the first time. But around the time that Greg was bumping into Mosaic, a lot of folks were using Gopher (if anybody remembers Gopher).
LB: Yes!
HS: And a lot of folks were wandering around and asking me what was going to replace Gopher. Some people said nothing would replace Gopher. Gopher was the be-all/end-all; it was never going to be replaced by anything.
I was running around saying that Gopher would definitely be replaced by something, although I did see this thing called the "World Wide Web," and I said that was definitely not the thing that was going to replace Gopher! But something would replace it.
And so the question really might be, when you ask about how the Web is changing on campus, what's going to replace the Web on campus? That might be an even more provocative question, and I think it has an interesting answer.
At least the answer I would give is that inevitably things get replaced. And the reason we haven't seen the Web get replaced is because the Web has managed to replace itself a couple times. And as long as the Web stays flexible enough to do that, then it's going to hang around.
And the fact that it's replaced itself really has to do with the way students and campuses use the thing differently. In the beginning, what the Web was, it was just a glassed-in bulletin board. It was a place where you kind of put your university or your corporate presence up there and you took every document in the world you could imagine and stuck it up on the Web and everybody just had to be able to go out and browse the Web. And if you could do that, you could read all the university documents.
LB: Right. Sort of a fixed set of information, if you will.
HS: Yeah, right, that had just a bunch of information. It was a place you went to read things. It's the kind of thing that you see in some Third World countries where they'll put the newspaper in a window somewhere, and everybody will run over and read it.
But what happened is, the Web changed. It changed from being this place where you put documents to a place where actual services were offered on the thing, but the services were part of the main-line business that the universities or corporations were doing. So we went from a glassed-in bulletin -- a place where you read documents -- to all of a sudden, you could actually do stuff on the thing.
For example, a lot of universities decided to put their application forms out there. If you wanted to apply to the university, suddenly you could do this service on the Web. And there were a whole series of services that were put up on the Web.
And the fact that this became service-oriented really changed what people had to be able to do. For one, it became more difficult to put stuff on the Web because it's more difficult to put some interactive service-type thing on the Web. Another thing that happened is, once we started doing this kind of stuff, everybody put stuff on the Web. The Web became ubiquitous and people expected everything to be out there.
And the fact that people expect everything to be out there means that if your stuff -- with your ideas, your services, your data -- is not on the Web, for all intents and purposes, it does not exist. And that's not a good thing. So it means if you want your data to exist or your services to exist, you have to be able to publish on the Web (or get it there somehow) or your ideas and services and things don't exist to an awful lot of people.
GM: I recall, when I first saw Mosaic that one of the things they demonstrated was an interface for database queries to SQL -- and it took a long time before very many people started to actually do that. I think it goes very much to this point of these broader applications do involve a good deal more complexity and integrating with other systems.
How do you see campuses helping themselves where there's this constant tension on every campus between sort of centralized functions and then each person doing their own thing?
HS: Yeah, actually, Greg, you raise a couple interesting questions. One point you raise is the fact that a lot of these new things that people expect or want to be able to do on the Web (at least initially) are very, very complicated. They're very complicated because no one has really figured out exactly how to do them -- or figured out one way to do them or established standards.
So in the beginning, if you want to do things like have the Web interact with a database, it's a very complicated thing in the beginning. But then as people develop software for it and standards to do this, it becomes easier -- just like text processing now has become a lot easier, say, than it was when you had to put little tags and do funny things on the thing.
The other question you raised, though, is the conflict between people wanting to own their own data -- and I think they have to -- and the central systems wanting to be able to control the Websites for lots of reasons. They want, for example, to have the Websites always be there. They want to back them up. They want uninterruptible power supplies on them. And also faculty and staff probably don't want to be in the business of running their own Web server. It's an awful lot of work. You've got to worry about security and all the other funny things that Web managers have to worry about. I think the faculty members would rather worry about their specialty, whether it's biology or accounting or whatever.
So we have to find a way to handle both needs, the needs of people to have the services look like they're central services, plus the needs of the individual faculty, staff and students to make it seem like it's their own data -- they control their own data.
LB: There's maybe a third sort of dimension to this which is the need that institutions have to maintain their own identity on the Web as an institution. And certainly for colleges and universities -- sort of going back to your admissions example, where they want to have sort of an institutional identity in the Web world, if you will, so students coming looking for colleges and so forth come across them. And that, in turn, imposes certain amounts of constraint, or could, on individual faculty desirous to publish as a member of that community.
HS: Sure, and that's another kind of thing that some central services could provide. For example, central services could provide style sheets and things like that.
LB: Right, right.
HS: If you're in a university, like most universities are, people will use the style sheets if they care to use them. But at least they're available so that people who are willing to use them could take advantage of them. Without them, then people are going to go out and find things that look different.
LB: Right.
GM: You have examples of what you think, from a university vantage point, you can do to nudge, nudge, nudge and help, help, help all this individual behavior?
HS: Yeah, well, I think you've got it right, Greg, that that's all you can do is nudge. You can't impose any kind of rules, regulations, whatever -- at least in the universities that I've seen. But nudging works really effectively. And yes, there's a couple things you can do and lots of folks have done one variation on this or another.
The first thing you want to do is you want some kind of a file space that people can put their Webpages in. The file space should be some kind of central file space. For example, it might be on a Novell server or it might be on some kind of central Unix server or some central NT server. Or whatever it's on, from a user's perspective, it looks like it belongs to the user. The user has a chunk of this shared file space, and the Web server mounts this file space.
So for example, here at Princeton, lots of folk have some shared Novell file space. So we take my little section of the shared file space and define it on my NT machine or my Windows 98 machine as being a V disk. I take some little Webpage that I want to build and I save it on my V disk. To me, it looks like it's on a local disk. My V disk looks like a local disk to me. The fact that it's a Novell file space, I don't think of too much. And I'm going to have a Webpage out there. I build the Webpage and if I want to change it a hundred times a day, I do it. It belongs to me, yet we have some central server which goes out and mounts that file space.
And to anybody looking into Princeton, it looks like my Webpage is in some central place -- it's backed up, it's on an uninterruptible power supply, and it works very well for those people who want to use it and for me. I don't give up any control, and yet I have all the facilities and support of a central organization.
LB: And you can concentrate on the content.
HS: Right, and I concentrate on the content -- exactly right -- not on the backup security, the managing of the Web server, am I using Apache or am I running some other Web server? I don't need to think about Web servers. And for faculty members and staff and other folks who have other jobs to do (other than the computer stuff that people like me, for example, do all day), it's a wonderful thing not to have to think about that stuff.
LB: Well, yeah, this definitely gets us into what needs to be there for faculty, staff and students to publish on the Web? What do they have to know? What do they need to be prepared to do in order to get their stuff out there?
HS: Okay, we've covered one of the first things, which is if you want to publish on the Web, you need a place to put your stuff, and obviously, you could have your own server, but that's a bad idea. If there is shared file space that's mounted by some central Web server, that's helpful.
It turns out that soon after you build your first few Webpages -- and we'll talk about what it takes to build them in a minute -- but soon after you do that, what you discover is that you really need to offer services, to have some level of interactivity, to collect some data or something like that. And that's hard to do without writing some CGI scripts or using something that links to a database.
For most people, writing a CGI script is more than they can handle and so what many places do is they go off and figure out what the most common functions would be in the CGI script, then they'll go off and write a few CGI scripts and make them available to people who are building their own Webpages. And this solves a great deal of the problem.
LB: Let me ask you to say a little more about what a CGI script is. Maybe a lot of our listeners today know that, but I'll take the lead on asking the "dumb question" and have you explain that a little more.
HS: Sure. That's fine, and I think that certainly is a real danger that we get into. I begin to think that CGI script is English.
LB: Right.
HS: Just one of those normal things like clouds and plants and things like that. And you forget that there was a time -- maybe two years ago -- when I had no idea what they were either, myself!
LB: Right, or two months ago! Given how fast things change.
HS: Right. But CGI stands for Common Gateway Interface -- and that's another example of when you tell somebody what the acronym means, it gives no additional information because the combination of words are just as obscure as the acronym. But getting away from what it means, the acronym -- basically what happens is that if you have a Webpage and you want the Webpage to go out and run some little program, the programs that it runs are usually called CGI scripts.
And the reason you might run them is, for example, you might want to collect some data. Somebody fills in some kind of survey or somebody is taking an exam online or whatever. You're collecting some data from the Webpage and what you want to do is you want to do something with that data. Maybe you just want to save it somewhere, or maybe you want to process and return it to the person or something like that. And it takes a little program.
The programs are often written in a language called PERL, or they might be written in C++ or Visual Basic or who knows what they're going to be written in, that doesn't matter. What matters is that there's a standard way, and that's what this CGI has to do with is the standard way of passing the data to some little program. The little program runs, and very often what the program does is it returns another Webpage to you. So we collect some data from you and this thing comes back and says, "Thank you very much. I have the data." And that's really all a CGI script is.
GM: How about the other facets of it? I mean, for many folks, they'll start and they'll look at doing some HTML and they'll see that there are some easier ways to do it. And then somebody that's a seasoned veteran will tell them, "Oh, no, no, no! You should learn HTML because ultimately, you'll always have to know the HTML, so don't use the simpler stuff." What do you think is the sane way to go about generating these documents?
HS: I think that there's going to be different strokes for different folks here, and that for some people who are going to get very involved with some of the details or intricacies of building Webpages, well, those folks -- at least today -- are going to still have to learn HTML.
But in many, many cases, for the basic stuff that students, faculty and staff are going to do -- although it's always nice if you know a little HTML -- you don't have to know HTML. I certainly don't believe you should go out and teach all your faculty, students and staff HTML. It's difficult to do.
I hear the argument a lot that, "We taught some clerk how to do HTML and the clerk was able to do it just fine." I think you also can teach dogs to walk around on their hind legs and things like that. So just because you can do something doesn't mean that you ought to do it, especially when there's good alternatives.
And one of the good alternatives, one of the simplest alternatives to writing HTML is to take the text processor that you use, and most text processors will generate HTML for you. Certainly, Microsoft Word will do that.
LB: How do you do that? Could you sort of take us through a scenario? Is it as simple as selecting a menu?
HS: Sure. It's very simple, as it turns out. Fortunately, it's very simple.
What happens, I think, is that a lot of students, faculty and staff have documents already written in Word. That's one situation, and in that scenario, a lot of folks are unaware of it, but if they just look at the FILE menu in their Word document, if they scan down it, they'll see a little thing that says SAVE AS HTML. So you take your document and you save it as HTML.
Now of course, you need someplace to save it. But of course we've already set up an appropriate environment for publishing, so you have your shared file space that's mounted by some Web server, and that's where you're going to save it.
If you do save a Word document at HTML -- some random Word document as HTML -- will it do a perfect job on it? Not hardly! In fact, there's some things that it can't do. It can't do them because you can do things in Word that cannot be done in HTML.
A very simple example of that is that in Word, you can put 50 different font sizes, for example, in a single document, whereas in the Web basically you have seven different font sizes. That's it! So if you give it a document with 50, it's going to take those 50 and it's going to turn it into seven, as it sees fit to turn it.
LB: Not always with the right solution.
HS: Not always what you've planned on for it.
LB: Right.
HS: And there's lots more things that it won't do quite right because, in fact, it doesn't know what your intent is.
In the Word document, you have a what-you-see-is-what-you-get kind of thing, whereas the HTML has all these tags. And converting from one to the other is not always a one-to-one thing. Word's rule seems to be "If I can't understand it, I'll either try to pick something close, and if I can't even find anything close in HTML, I'll just ignore the whole thing. I'll ignore that part of the document or that feature."
But still, as a very first cut at things, if you were to take an existing Word document and just save it as HTML and look at it on the Web, you'll find that for simple documents, it does pretty well.
LB: What about for things like forms?
HS: Actually, if you build -- well, okay. Yeah, if you really mean forms, you don't mean tables here, Laurie, right?
LB: Yeah, right.
HS: Because tables do okay. Forms are a little different story.
But actually, Word has two modes. Word has lots of stuff in it, I think, that people are unaware of. And in fact, I find that in teaching people to use Word to put stuff on the Web, the first thing I have to do is teach them Word. There's lots of features in Word.
I'll get to your question in just one second, but for example, a lot of folks are unaware that in Word (forgetting about the Web) that you can put backgrounds in your Word documents. Just go up to the FORMAT menu, go way down to the bottom, and you'll see there's a little Background thing there that most people are unaware was there. It's been there for a long time, and you can put very pretty backgrounds and textures and things in your Word document, even if you never publish on the Web.
But back to your question about forms; forms are kind of complicated because they have all these funny little buttons and little pull-down menus and those kind of gadgets, right?
LB: Right.
HS: Okay. And if you go into Word, you don't find those features there.
But actually, you do, if what you do is you go into Word and open a new document, what it will open, it will open a general document. But you'll see a whole bunch of little paths when you go to open a new document, and the one way over to the left says GENERAL, but the one way over to the right says WEBPAGES. And if you go off and you open a Word document as a Webpage, then what happens is you do have all the facilities to build forms. Everything is there, okay?
And you might want to know where that stuff is. Well, it's under the INSERT menu. If you go under the INSERT menu and you open something like that in Word, you'll notice that there's a new item in there. (Actually, there are whole bunch of new items.) This new item under INSERT that says FORMS -- under FORMS you'll see something that says "Checkbox, Option Button, Drop-Down Box, List Box" -- all the stuff is there.
LB: So you can really create the form.
HS: Yes, you can actually create the form with Word. Not only that, one nice thing about building a document like that (now, you can't take an existing document in Word and do that, but you can build the document from scratch like that) but another nice thing about building a document like that is that Word will not let you use a feature that is not translatable into HTML.
So for example, you can't set the font size if you do this. All you can do is you can make the font bigger or smaller, and it only supports seven font sizes in that mode. So you know if you build it, pretty much it's going to convert.
There's a bunch of little exceptions and things around the edges that one could fuss, but by and large, it works. It works pretty well.
GM: What do you do when -- or your campus users, as they start to use your various support CGI scripts and so on? Do you give them descriptions of sort of the HTML framework around those, or is there some other intermediate step?
HS: Actually, you can even insert them in a Word document. They'll be associated with a form. I mean, we do tell them how to code them in HTML because some people are going to code HTML, but we are also concerned about the fact that folks are going to code a Word document. And when you build a form, one of the things in Word the form will ask you for, it'll ask you for the URL of the CGI script. And you just type in a URL. "This is the CGI script that knows how to build the HTML," so that when you press the SUBMIT button, the thing gets submitted appropriately.
Of course, in Word, you can build the little buttons, too. You can build the SUBMIT and CLEAR buttons. It knows about them in Forms, so you can build them and you can associate a URL, which really is the address of the CGI script there.
So you don't have to tell the user very much, just give them a URL and say, "This thing is the thing that does whatever it does with the form."
LB: And if you've got your CGI script, you're either using one that was developed and sort of kept in a central location or if your institution keeps some kind of central service where you can store your CGI script, presumably --
HS: Right.
LB: So it's always there when people are looking to use that document or form on the Web.
HS: That's right. Now, Word, of course, doesn't help you write a CGI script yourself. It doesn't do that, but folks that are already writing their own CGI scripts are really quite advanced and may not be using Word. A lot of people who are quite advanced Web developers -- I mean, I develop lots of Webpages. I'm pretty adept at HTML and 27 other tools and whatever. And lots of times, I will start using Word anyway because at least it gets the basic HTML written for me.
LB: Right. We're about halfway through our chat today, so those of you listening out there, don't hesitate to send a question in for Howard to expert@cren.net.
GM: One of the questions we'd gotten earlier, before the session -- which is really nice.
HS: That's actually the time to send your questions in because then I get a chance to think about them!
GM: Basically, it ends by saying, "Are we doomed to the World Wide Wait?" And they're asking about what may be expected in terms of bandwidth and/or other things. Certainly my own sense of the various little tools that buffer or look ahead is those are not very good solutions to the bandwidth question. Do you have thoughts about what may happen there, either with Internet2 or other things in terms of --
HS: Yeah, I don't think we have to wait for Internet2. At least out here on the East Coast, and I know in the Southwest, many parts of the country, there's many things that are happening.
Folks at home now have all kinds of options -- I think really, really good options beyond the 56kb stuff that you can get out of a modem, maybe.
There's of course ISDN, which brings you up to 128kb (kilobits per second), but I guess ISDN (which is Integrated Services Digital Network, a service offered by the phone company) -- that really does not seem to have taken off.
The other possibility are cable modems. A lot of the cable companies are offering a service with cable modems. So as part of your cable TV service, you get a cable modem. Those things are very, very fast -- about 1.5 million bits per second, so a lot faster than your modem.
And then there's DSL, Digital Subscriber Line. Sometimes you'll see DSL with a letter in front of it. It might be ADSL, Asymmetric Digital Subscriber Line, or RDSL or whatever. Whatever you see in front of DSL, it's a digital subscriber line. It's offered by the phone company in many, many places, and it's a no-dial-tone service. You connect your computer to this thing, it's always connected, you don't have to dial up a number. And that also has speeds that go as fast as cable modems -- 1.5 million bits per second.
So there's lots of good stuff coming up, but you're going to probably have to part with $40 a month to get these faster speeds -- or more, depending upon the kind of service you get.
GM: But you may save $20 a month for your second phone line that you had to put on because you were always dialed in.
HS: Yeah, and some of these services like ISDN and DSL also give you -- in addition to giving you this high speed data line give you a phone line at the same time. One of the problems in any house that has a computer is that if you start using the computer -- use it lots and lots -- no one can call you any more. In fact, I've had some people (because I have a single line at home) who realize that I've been using the computer and they've gone off, they've logged onto the computer and sent me e-mail because they realized they couldn't call me on the phone.
LB: Talking about these speeds, it's sort of historically been that you typically are going to get a faster speed from your office on campus, let's say, than you might get dialing in at home. And I wonder if some of the evolution of campus networking -- as office buildings on campus, as offices get upgraded, residence halls get upgraded, it may be slower than some of these new technologies for dial-in -- that we might start seeing the bottleneck actually being on campus as opposed to off campus.
HS: Yeah, and that actually might be a reason why more people on campus go to Internet2, to go back and get even higher speeds.
And of course, one thing feeds on the other. One of the reasons that Website designers really fuss a lot about their Websites to keep the graphical content down is because they know a lot of people at home have relatively slow speeds. Now, one wonders what they're going to do if they know that everybody uses DSL or cable modems or whatever. Then we can really get elaborate graphical designs and things like that and putting up a Website that requires you to look at 24 megabytes might not be a big deal, so things will slow down again.
GM: Howard, there was one other question that came in that takes us back to some of the discussion of HTML, and it's boring down a little bit further. And I think the context to put it in is, is there in your mind a way or are there some books that are references with advice on sort of which part of HTML to learn first and how to be smart about how you start out?
HS: Oh, brother! I think that if you're going to learn HTML, then there's no part that I could say you ought to learn first or second or whatever.
The best thing I would suggest is that if you're going to learn HTML, you pick some thing you want to build. Pick a Webpage or something like that that you want to build and learn whatever HTML it takes to build that page.
HTML is fairly boring stuff to do. There's zillions of tags. I don't know of anybody who knows them all, and the ones you wind up learning are the ones you need to use and you use all the time. And I think that's going to be different for different people, depending on what they're doing.
Another thing that people who want to learn HTML ought to realize is they can go off and they can go out to any Webpage and they can view the source of the Webpage. That is, they can view HTML on the Webpage, and that's a very interesting way to learn HTML. Go off, find a Webpage where you think something really neat is happening. Go off and look at the HTML that is up to create the thing. Usually you can see it.
GM: You are obviously a believer in what the educational theorists call "authentic learning." You learn by doing the real job.
HS: Well, I think especially in something like HTML, where there's so many tags and so many nuances and things like that, that it's really pointless to learn all those things and then you wind up never using them anyway. And not only that, a year from now, a bunch of them will have changed. So even though I code HTML fairly regularly -- think I know a great deal of it -- if I'm going to write anything in HTML, an HTML book is usually within inches of me when I try to do this because I know I'm going to have to look at it.
GM: There's lots of commotion and discussion about the next step from HTML being XML. What's that all about? What is XML?
HS: Yeah, XML is actually something that HTML might have been had we not been in such a hurry to get the thing out.
But the basic thing, I think, one needs to understand in terms of understanding the difference between HTML and XML is that HTML describes what a document looks like. It's a formatting language, and XML describes what a document means. It's something that abstracts the meaning of the document.
And if we look at a document and HTML is all we know, if we look at some kind of heading, we know it's a heading. So we know it's, like, well, I guess a heading even tells you a little bit of the meaning. But we don't know if the document is selling used cars or if it's some document that describes something that's happening in the university or whatever.
The idea of XML is that if we can abstract the meaning of the document -- we use tags in XML just like we do in HTML, but the tags describe meaning rather than formatting. And in fact, one strange thing about XML is there's no formatting in it whatsoever. It means if we take an XML document, there's no way to display it because we don't have a clue as to how to format it. Kind of an interesting thing! Whereas with HTML, we know exactly what it should look like, but we have no idea what it means.
In XML, the fact that we do no formatting in the thing means we need some way, some additional way to format the document. And what we do is we take the XML and we pass it through some kind of style sheet -- something that adds formatting information to this abstraction and produce some rendition of the thing. And the rendition might be appropriate to display on the Web, or if we have a different style sheet, it might be appropriate to print or it might be appropriate to do something else with it.
Anybody who's printed an HTML document, you get something on the Web and you print it on the printer, it doesn't look very good, does it? I mean, it looks like it came off the screen. It doesn't look like a printed document, unless it's PDF or something like that. But with XML, the idea would be that you would have different style sheets: one that would be appropriate for, say, printing on a printer; one that might be appropriate for displaying on the Web; one that might be appropriate for storing the whole thing in a database, etc., etc. Since we have the meaning of the document somewhere, now we can do all kinds of things with it.
The other wonderful implication of having the meaning of the document somewhere is it means for the first time we can actually do effective searches on documents. And today, we at best do a so-so job. Oh, not even a so-so job! We don't do a very good job of searching the documents because we don't know what they mean.
GM: We have a question from out there in e-mail land. Do you think XML is going to change Web development in the near future?
HS: Well, it's starting to change Web development already, and it's also starting to change database development. It's being used by a number of people to exchange information between databases.
If you look at XML (and we have several references on the Website) but if you look at it, after a little while, you say, "Wow! This looks like a database description!" And in fact, that's what it sort of does. It takes a document and breaks it in little pieces so that it would go very nicely into a database.
And what a number of people are doing is, they're saying, "If I can take my database and extract information from my database and turn it into XML, and if I can take XML and feed it to my database, then we can use XML as an intermediate format so that we can exchange information between any two databases." So folks are doing that.
Some folks are also using XML already on the Web to do some special things. For example, Microsoft's Active Desktop uses XML to produce its active desktop. So today, it's being used in specialized places and more and more, it's going to be used by everybody.
And even the browsers today are becoming -- or are, actually, already XML compatible. The current versions of both Netscape and Internet Explorer are XML compatible. They can look at XML and they won't fall over on their face if you give them some.
LB: As we get sort of closer to the end of our time, let's go into the whole topic of searching a little more. Are there any new features out there that make browsing and searching easier?
HS: Yeah, there's actually one that's kind of nice, and it's kind of a feature in both browsers. (When I say both browsers, I guess there's somebody out there who thinks there's a third or fourth browser out there, but we're really talking about Netscape Navigator and Internet Explorer.)
But one of the difficulties in the past has been, if you want to find some company like American Airlines or something like that, if they don't have a URL that's obvious, it's difficult to find. You've got to go up to a search engine.
And today, if you just go into the little area on a browser where you would type a URL and type AMERICAN AIRLINES, for example -- capital A, space, capital A, space, airlines -- the thing will look up the URL for you, get you directly there. So that's kind of nice, and that works for many, many URL's. Both browsers have an extensive list of URL's that they'll look up for you. So it just makes things a little quicker.
LB: Right, although there might be differences between the two. Do the browsers sort of keep up with each other in terms of the information they've got that they can do the translation?
HS: Laurie, as you discovered, they don't quite. They don't have the same list, and so sometimes what works in one will not work in the other. And that's unfortunate. It's unfortunate they couldn't share the same database, but at least today, they're competing with each other.
And I think, as you discovered this morning or whenever you were taking some pokes at it, it seemed that Netscape had a more extensive database or URL's, and I've seen the same sort of thing. And of course, for the people listening, that could change by tonight!
LB: That's right.
HS: And in fact, if somebody at Microsoft hears this, it may change by tonight?
LB: Right.
GM: Howard, is it your view that there are some major developments on the way in terms of search engine technology, or are we at a kind of lull point in which the search engines spend all their time instead creating portals and doing frilly things all around the search engine?
HS: Yeah, I think that -- I mean, I hate to say that we've gone about as far as we can go because every time somebody says that, they wind up looking completely silly (and I really don't want to do that).
GM: But you said it!
HS: But I've said it. I think that in terms of the way the search engines work today, that because we're indexing every word -- and because we're indexing every word in HTML and HTML only gives you formatting information -- it does not give you the meaning of the thing. It doesn't give you any abstraction of the document. I think we're doing about as well as we can do.
And yes, the search engines are going to index more things and they might add a couple more features. But until we get XML out there -- which I think will change everything when it comes to searching -- we're not going to see any real breakthroughs in the search engine technology that we have, except perhaps in the area of indexing things faster.
We might see those kind of things, but in terms of new functionality or new features -- or every day, a new search engine announces that it can do natural language searches. I don't understand how that can be done effectively indexing every word in HTML documents which don't tell you what the document means. Maybe there is somebody out there who is in some research lab who understands how the search engine can figure out what it is I'm really thinking and what the person who built the Webpage was really thinking and can put those two things together. I'd love to hear about it.
LB: Those are natural language queries you can use for standard vendor search engines out there?
HS: Yeah, with a lot of search engines' language, you can use natural language queries. And I've never seen one that works effectively.
And I don't even understand how one could work effectively. I'm going off and I want to find all the places that list used cars for sale. Well, I come out and I say, "Tell me about all the used cars that are for sale," and all it can deal with is the words in that thing.
And no matter how well it understands those words -- let's say we have some search engine that is incredibly clever and uses artificial intelligence or whatever, and it really understands what my query was all about. It's got all these Websites out there and there's nothing in those Websites that says, "We have used cars for sale." There's nothing that distinguishes a Website that is talking about how one sells used cars from one that really is selling used cars because all we can index are the words.
LB: We've got another e-mail question here that takes us back a bit to the publishing question -- but in terms of multimedia, not just talking about publishing text -- and wondering about what types of services should be offered to help faculty understand how to put multimedia documents out. Like lectures with both text, audio and video.
HS: Boy, that is such a vast area! In fact, I believe that would be the complete topic of our last -- no, maybe not. We talked a little bit about doing that.
Some of the multimedia stuff is very easy to do. So, for example, if one wants images out there, images are very easy to put out there. Even in a Word document, images can be included.
A step beyond images are animated GIFs. You want an image that moves a little, the easiest way to get an image that moves is to use an animated GIF. And there are shareware programs, actually, that let anybody who has a little draw program or a program that can create pictures make simple animations.
Beyond that, building sound files, movies, QuickTime files and things like that goes a step further. I think universities have to decide what it is they want faculty to do, and I think for most faculty members, they're going to need some help as soon as we get very far into multimedia.
LB: Right.
GM: I think RealAudio in particular -- there are ways to do it relatively easily, but it takes people a while unless they've got a knowledgeable person to guide them to find the easy way.
HS: Yeah. One thing that we've done here pretty effectively (and it's very easy to do) is if you're giving a lecture and what you want to do is you want to capture the lecture, you want to capture what I consider to be the important parts of the lecture -- the important parts of the lecture, I think, are the audio portion of the thing and anything that appears on the screen. We're not talking about capturing the lecturer's face, arms, image or whatever.
There's a number of programs, one of them is called Snagit. It's shareware, it's inexpensive, very easy to use. And what it does is, it captures the audio portion plus anything that appears on the screen. It does not matter what application you're using. You could be using the Web, an operating system, or whatever. And it turns it into synchronized audiovisual Web presentation. I don't think we have a link to it out there, but we can certainly provide one.
GM: Good. Another one of the questions that's come in is a broad one about Web developers. And basically it says so many tools are becoming powerful enough to make basic and intermediate Web offerings simple. What skills should Web developers focus on to stay useful?
HS: That's a very, very difficult question, and I think one that one can't really answer because the Web is such a broad kind of thing. It really depends on what you're doing.
One of the big concerns, for example, that a lot of universities have today is e-commerce, because we, for example, have a faculty member who's developed a Website and would like to charge other universities for the use of that Website. And so all of a sudden, here we are. Everything out on the Web was either free or you couldn't get to it. Those were the two situations. And now we have this situation where we want to be able to charge for the use of a Website, and we want to be able to let people come in and register them.
And so there's a whole bunch of issues and tools and things associated with e-commerce. So one might say, "Gee, go out and learn all about e-commerce, you Web developers!" On the other hand, lots of people in the scientific area -- and not only in the scientific area, but in the academic area in general -- want to do some interesting simulations. And simulations are done very nicely with Java applets, so one might tell developers, "Go off and learn Java and learn how to write Java applets."
And I think one could go on and on, depending upon which area. There's a whole bunch of specialties now within the Web. Perhaps you should go off and learn graphic design or something else like that. So I think you have to decide which area you want to concentrate on. I don't think that anybody today can now be a Web developer that can do the graphic designs, the design of the security systems, the page layout -- I mean, all the different parts that are required to do a Web design.
LB: I think we have time for maybe one more very short question or comment.
GM: Let's talk a little bit about recently, I think, an important set of guidelines were published with respect to use by people with disabilities and various impairments and so on. Can you bring us up to date on that, Howard?
HS: Yeah, that's a very important thing, and that's something that I think a lot of folks have been waiting for. I certainly have been waiting to see -- that I get asked about that all the time, and the question comes up with, if you are designing a Webpage, what kind of accessibility guidelines should one have.
And I always carried a few around in my head, and so did everybody else, but now the W3C (the World Wide Web Consortium) has published some guidelines. (I believe we have a link to it on our Website.) They've done some content accessibility guidelines and they provide, actually, 14 points there about the kind of things that one should consider when you're designing a Webpage to take into account the fact that not everybody has the latest browser or the fastest network, or not everybody can see too well or hear too well or maybe not hear at all. People have all kinds of disabilities and things.
And these guidelines are just that. They're guidelines, they're not, "You cannot do this and you cannot do that." But they really -- END OF SIDE A�
HS: -- don't think much about the fact that there are color-blind people out there or that there are perhaps people who don't have color monitors. So don't go up and say, "Click on the red button" where that's the only clue, for example, as to what you're supposed to do because some people are not going to be able to see the color. And there's a whole bunch of guidelines like that.
LB: And they are linked on the CREN Website, if you look on the page that references the session. It's under Additional Resources, and it's very useful. I think a lot of people would actually like the guidance, and as you say, Howard, thinking about things that might not ordinarily occur to them.
We are, unfortunately, at the end of our time. I want to thank you all for being here with us today and hope we managed to get to most of your questions. If you have more, please do send follow-up questions to expert@cren.net and Howard will be happy to answer them individually or on the Web.
And be sure to mark your calendars for May 27th, just two weeks from today. The TechTalk that day will feature two experts in the area of Windows NT (also known as Windows 2000). This is a session looking at Windows 2000 from the management perspective and is titled "How, When and Why Do I Do NT?" The two experts are Ken Klingenstein, from the University of Colorado, and Mark Pepping, from Carnegie Mellon. Plan on joining this session and inviting your friends and colleagues to help in deciding when, how and why to deploy Windows 2000. Check the Website for upcoming Spring events, and as always, we welcome suggestions and feedback on what an whom you would like to see and hear on TechTalk.
Thanks to all who helped make this possible today: the members and board of CREN; our guest expert, Howard Strauss; technology anchor, Greg Marks; Web content producer Terry Calhoun; Harold Ansell and Lee Perlis of CREN; Paul Bennett and Martha Vander Kolk of UM Web services; and Laurel Erickson, our TechTalk editor; Judith Skiff, our transcriber, and all of you for being here. You were here because it's time. Bye, Howard. Bye, Greg.
GM: Bye-bye.
HS: Bye, Greg. Bye.
