resources | tillotson & hopper, 1992 [research interview]
Robert Tillotson & Mary Hopper, Passages from Personal Interview, June 23, 1992
Passage 1
Hopper: Is it your intuition that some of the things we've discovered for good programming purposes are good for user interfaces as well.
Tillotson: Consistency is perhaps the most important issue in a system such as this. A clean system design not only helps the developer, but it also helps the user to work with it more efficiently.
Hopper: So the flexibility allowed by HyperCard may not be as beautiful in a lot of ways. The freedom it allowed didn't create better materials.
Tillotson: Freedom is only good in hands of someone who knows how to use it. It is also freedom for someone who doesn't know what they are doing to hang themselves. (Tillotson & Hopper, 1992 )
Passage 2
Tillotson: Convert-It was intended to convert stacks from HyperCard to Toolbook. The first step was to run the Convert-It stack, which converted your stack into a HIFF file. The HIFF file was an intermediate text representation, which you could then download to your PC. Then, the other part of Convert-It would create a Toolbook stack from the HIFF file. Of course, the conversion would not be complete and you would clean up the resulting stack by hand. In this case, I was taking the HIFF files and moving them to UNIX. I wrote a program to take the data out of the fields in a HIFF file and convert it to a database. The main problem I encountered was with the original format: in the original HyperCard stack the fields were not in the same order on every background, even though they were visually in the same locations on the cards.
Passage 3
Tillotson: The ability to link to things outside the system is also absolutely necessary. Even in a complex structure such as that found on the Mac, it is important to have a way to link to applications that aren't part of that structure. In any structure there will be some things which are not possible, so there must be an easy way to add to the structure later
Hopper: In other words, having a way to use programs that may do something that isn't even created yet? So you should at least have the capability of opening something that didn't exist in the past.
Tillotson: Exactly. This is especially useful if you can run your existing conventional applications even though they aren't part of the structure. If your system can access conventional applications or languages, a programmer who is not familiar with your structures will still be able to produce something that interfaces with it.
Hopper: Eventually, would extensibility be important for a system that could be used on the internet. How far away are we from that type of situation?
Tillotson: It's possible now. In our project, the HyperNews client I wrote was independent of the format of the databases, because it dealt only with a program I wrote to access the databases. I could have easily replaced that with a program that obtained data from WAIS or Gopher, or by some other means. If you already have a large database and a programmer who can write a program to access it, or if you are using a commercial product with an interface library, you can link it with your interface, provided your interface is properly extensible. That is the essence of extensibility. For example, if someone were to write a HyperCard XCMD that worked exactly like the database interface to HyperNews does now, HyperCard could access the same database HyperNews can. If some aspect of the database changed, both the XCMD and the HyperNews database client would require changes, but your programs in HyperCard and HyperNews would remain unaffected. Once you have separated the functions of user interface
and database access, you have set up a barrier between the developer of the user interface and the programmer writing the database access library. As long as the interface between the two remains the same, you need not care where the data comes from. It could come from disk, through WAIS, from some other source - it doesn't matter, since the interface is the same. I think that any system that can't interact with outside programs, at least on the same host, is too limited and has no future. (Tillotson & Hopper, 1992)
Passage 4
Hopper Now, in terms of PUCC, in this environment. You're actually serving dual roles in this project. You have the advantage of being a PUCC person, as well as a developer on our project. What do you do at PUCC?
Tillotson: Well, officially, I've been a general consultant for four years now. Basically what it amounts to is that I've been around enough that I met practically everybody, and most people around here know that I know what I am doing. And I've done volunteer for UNIX group. Not much, but a little bit. So I've had some contact with them as well.
Hopper: How important do you think that's been, in terms of your working on this project? Would it have made a difference if you were a person outside PUCC?
Tillotson: I think it's kind of cut a lot of extra work for me out. Whereas a person outside may have been able to do the same stuff I would, but they may have had to take more effort trying to figure out what they were able to do. Like I already knew the Sun systems were coming in, and had the advantage that I knew what kind of stuff the Sun systems had, where as somebody coming from outside would have had to find that out by coming in and starting to use it. It's just a little bit of an extra. Plus I know some of the people here. It's easier for me to get a hold of some of the people here than it may be for somebody who didn't know any of them. But, it's nothing that somebody from outside couldn't do, but it's just an advantage because of the time it has saved.
© Mary E. Hopper [MEHopper] |
MEHopper@TheWorld.com
[posted 01/01/01 | revised 02/02/02]