Since they can probably tell you about themselves better then anyone, this is how they describe themselves:

Jellyvision is a small interactive media company currently concentrating on conceiving and developing original interactive experiences for CD-ROM and the Internet. Our mission is to discover, invent and evolve new categories of experience that are positive, engaging and meaningful for the widest possible audience. Jellyvision has set out to create interactive programs that can coexist and compete on the same screen as television programs.

Jellyvision is the offspring of Learn Television, which was established in 1989 with the intention of creating educational films with a comic twist. In 1991, Learn Television released the award-winning film, "The Mind's Treasure Chest." Despite the film's success, film is by nature a passive experience. New multimedia technologies presented an opportunity to create an active learning experience. Using the lead character of "The Mind's Treasure Chest" as host, Learn Television partnered with the Follett Software Company and developed "That's a Fact, Jack!," a reading motivation CD-ROM game show series covering young adult fiction.

With this project in development, Jellyvision decided to test the adult waters of interactive entertainment by beginning a partnership with Berkeley Systems and developing the game You Don't Know Jack. Released in the fall of 1995, this too was in a quiz show format but combined high culture with pop culture. In October of 1996, You Don't Know Jack: The NetShow was launched on the Internet.

Jellyvision's biggest asset is its ever-expanding staff of writers, editors, actors, media producers and interactive directors. Jellyvision prides itself on creating programs that are clever, thoughtful and original. In addition, the company's commitment to testing helps insure that its programs actually appeal to their intended audiences.

Ed: My name is Ed Lott. I have a Computer Science degree from the University of Central Florida. After school, my first job was working on a large Fortran system [that commanded/controlled] satellites in the Navy. I then went to work for CSX railroad where I did my first Macintosh GUI (Graphical User Interface) development in a system that provided a graphical interface to people who manage locomotives. So, we drew maps where they could see the rail lines. We drew graphic pictures of railroad yards so they could visually see where all the different assets that they had to manage were located, what status they were in. That project was successful. Based on that project, I ended up getting hired by Apple to be a field system engineer, and that’s how I got moved up to Chicago. That lasted seven months until one of their first big re-orgs, and then I became a consultant. I got hooked up with Learn Television as a consultant. One of their early projects was "That’s a Fact, Jack", which is a game similar to "You Don’t Know Jack", only it’s focused on children’s literature. I was the senior engineer for that product. That was all written in C++, and it only ran on the Mac. Since that time I hired on here, being a consultant and being an employee, I now take care of the tools and I am the architect for our current Java Engine.

Dave: Jellyvision became what used to be called Learn Television, but when they started getting into entertainment products with educational products, they figured that people weren’t going to go out and buy a game that said Learn Television on the front. So, they changed the name.

Ed: I was one of the first developers here, so since I’ve started I’ve done a lot. I maintain writing tools, which are entirely written in HyperCard. I did a couple of HyperCard prototypes, like Dave mentioned, for one of our products. I did the C++ application work for "That’s a Fact, Jack". I sort of came up with and organized the architecture that we have now for doing our new multimedia stuff where we try to merge the benefits of what we learned from our HyperCard prototypes with actual performance. What we learned with doing HyperCard prototypes is that HyperCard is basically a slow language. But as long as you call native code to do the hard things, like actually play audio, that slowness isn’t really noticeable. In terms of the time between when HyperCard can detect a key being pressed and when it can start a sound playing, it is small enough that for our experiences, people didn’t notice that. They would have noticed it if we tried to use the HyperCard’s file handling to read in an audio file and stream that to a buffer. So what we sort of discovered from that experience is that there probably is a way where we can use a scripting-like language, it may be slow, to articulate everything that experience has to do, as long as you can get your native code to actually do the bit blasting. Then you would have to call in your development department. That is what we sought to realize with Java. We wanted to use Java as a control, because the programming model is a lot friendlier than others, like a lot of the people doing prototypes in C++. A C++ development process for that would have been a lot more error prone and there would have been a lot more time spent doing things like memory and stuff. That all happens quickly in Java. So we’re using Java as that. The other benefit, and the reason why we picked Java. is that there is an attempt to have that program to run on other platforms. We ran into issues with HyperCard in that no one is trying to make HyperCard run on other boxes. We looked at Macromedia, and we have some similar worries that no one is trying make the lingo in the environment run on other boxes. Macromedia is trying to, but I’m not sure that anyone else is.

Dave: Right now, we build something that runs on the Mac, and runs on Windows, but eventually we want to be able to build something that runs on a Web TV box or on a console like Playstation, that type of thing. So we’re looking toward the future with Java in that sense.

Ed: Our hope is that our game play code will be written in Java, and all we have to do when we go to another platform is import our native multimedia library. That library tends to be fairly focused on more then just the whole computer functionality. So it makes sense that you would have to implement that for another box because various boxes do the multimedia fairly different.

Dave: But that’s got a very clear set of API’s that basically, if we wanted to, we could either build ourselves, or we can find someone else and pay them to build, say, a dll that does this, this and this, and it is all very clear as to what it needs to do. As opposed to the game play code where we need it to play this sound, then move this across the screen, and all that kind of stuff, where it is more aesthetic and less technical.

Dave: Most of the company is writers, editors, and that kind of thing. By putting them in charge of projects, we get better products because they are more fun and it’s not like a programmer has decided how this thing should be. But it means that we basically have a lot of iteration where you would say, well, I want it to look like this. Try this. And then [you say] oh well that didn’t really work, lets try putting in a little piece here that does this. So there is a lot of quick iterations, lots of focus through testing. Then once we get it nailed down, we start to move into using real art, and sometimes we re-record some of the audio.

Mike: We have been trying to do a game, and it has been the same way. Every turn we find some new issue, and it's pretty much a complete change-around about every week. For example, how are we going to implement the character into the environment, then it’s, well... we can do this. Then afterwards we don’t want to do that.

Dave: It doesn’t get any better after you get out of school. It’s still the same sort of stuff. But it’s good because when you’re done, the product you come out with [doesn’t have] a lot of surprises. We know how people are going to react to it, we know they are going to like it and we know that it’s fun. Then it’s just a matter of adding bells and whistles. If we can get people to really enjoy a game that is in black and white with hardly any graphics, just text would be on the screen and sound, and they can really enjoy it to the point where some people will say ‘can I take the prototype home with me’ [we have succeeded]. Once we get to that point, and once we add color and that kind of stuff, we know that it’s going to be a good thing. Of course at first when they walk in there they don’t want to take the prototype home with them. They say ‘it’s kind of boring, and it’s black and white’. Once we get it to a point where people really like it, then there aren’t a lot of surprises when we do it, which is good.

Ed: Answering one of your questions about our business models, in the past the thinking was, we would do all of the design and all of the media production, because ultimately that is what we are all about. We are about storytelling. We have got a quarter of Jellyvision’s employees that are non-writers and non-performers. Everybody else is in that, and that’s ultimately what we are about, and that’s a good thing that you are into good storytelling. But, our original business model was that we would use the design of the experience, do the writing for it and do the media production. Then someone else would do the engineering. That’s the model we approached when we did [the game] Jack originally. Our partner, besides doing the engineering, would also do the marketing and distribution. So, we would be focused on the things we like to do, which is to create new experiences and write.

Dave: That’s where Berkeley came in.

Ed: Yeah, that’s where we basically had the opportunity to show Berkeley the prototype of Jack. They saw the vision that this could be a blockbuster, and so we pursued that model. The difficulties with that model were that our prototypes tend to be very rich and detailed. They tend to be audio complete, and somewhat in terms of event-driven timing, they tend to be complete. The problem we had before is that when we would get this detailed prototype done, we would have to re-communicate that all to another engineer who would implement it with a different technology. That presented a slowdown in terms of process. In a sense we would do a prototype and quickly threw it all out. We couldn’t cut and paste parts of it or anything. So that was an issue, and we also wanted more flexibility in terms of projects. We would basically communicate to Berkeley what we would want this engine to do. Then we would want to do an education product, which isn’t a market they are going after. So we would be stuck if we want to do this. Then we have to find somebody that wants to do education products and also build this engine, which we already described in a sense, debugged for something else we’re using. So those two things motivated us to bring the technology part in house. Our current push is to have our own playback technology so we can do anything we want with anyone. We also want to marry the prototype process with the final production process. We would like to do our prototypes in a form that can ultimately resemble the final product. In that sense, we want to use our playback engine during the prototype stage.

Dave: So, we don’t have to throw away a whole bunch of HyperCard code because there is no way to really translate that into Java.

Ed: Or C, or whatever it is that you chose to do it in. Besides having control over the playback technology so that we can do everything we want, we wanted to make it so that essentially going from the last phase of the prototype to a perfected product is where you are just upgrading the art, upgrading the audio and adding other packaging things, organizing media so that it works with your installer, issues like that.

Ed: As far as how to go from high school to doing this kind of stuff, for me it ended up being a really broad journey. I’m not sure how much this has changed in computer science, but back when I was going, the good experiences I had were in a good C programming background. C++ was sort of new when I was in school. Also, a good data structures background, good experience writing a large program, being able to keep track of what’s going on. But, in terms of how do you write software for micros, that was severely lacking in terms of how to productively write programs for Windows, how do you productively write programs for Macintosh, how do you write event-driven programs. These were gaps that simply weren’t in the curriculum. What I discovered, at least with working with academia at the time is that there was sort of a gap between what people were teaching and what the latest technology was doing. There was a lot of good foundations and stuff in terms of Boolean logic classes and elements of operating systems. But there wasn’t a focus on micro operating systems for instance, and how do you go about productively doing a GUI application. That was all the stuff, and I had to learn on my own. I had to read my own books, I had to buy a computer and a compiler and that stuff. To get to what I’m doing now, I had to make a huge investment in staying current. There wasn’t an easy way to say if I go to school this will happen because that wasn’t the case. Academia gave me a good background but I can’t say that it was enough. In the terms of breaking into this market, we were doing a lot of recruiting, we are still doing some, but the things we look for on resumes were actual experience with the platform. There were lots of people experienced with the coding, with experience, at least, at an academic level, and took a C course, or a C++ course, or a data structures course. It was harder to find people who had actually put their hands around a micro project, or [could say] I wrote a big game. That would have stood out more, of course, when we were going through resumes than [to say] I just went through a programming course.

Dave: I remember when I was in school, one of the things that we didn’t get until senior year, and it was something that when we got it, they [the faculty] were like, you guys should have got this a lot sooner. It sounds like the kind of thing that they do now with team projects. You did programming all by yourself up until your senior year, then you get in a group with three or four people or something, and then when you get to interviews, everyone is like, so how have you been working in a team. Then when I started working with Andersen Consulting , you realize it’s a whole different thing because you’re doing a small piece of something and how you work with the team is almost more important then you’re ability to just sit down and write a lot of code. So that was something when I was getting out of school they were starting to realize and they were starting to get into. That was also the first class where I did any real programming on a micro computer, because before that it was mostly UNIX stuff where I can write a big file, and then it’s [asking], how do I compile this thing for the Mac or whatever. So, I don’t know how much that’s changed.

Mike: Maybe a little bit of both, with more focus on challenges you are having here.

Ed: Probably the biggest challenges we have here is keeping up with the iterative nature of the creative process. [Another,] being able to respond quickly and in a timely enough fashion. We need to change it if it doesn’t work! We need to change if it isn’t done creatively. That’s been mostly a system integration skill set. We do a lot of piecing together existing technologies to make our process work. We don’t have time to write a sound editor or write an animation development program. So we piece together. We use Macromind Sound Editor for all our audio production. We have integrated that program within our HyperCard authoring environment so that ultimately we are managing and cataloging what is being created, but we are using external editors to actually do it. So I would say that probably the biggest challenge is keeping up and right now the skills for that is adept system integration, or to be able to productively integrate something off the shelf into your process.

Dave: This next generation of stuff we are working on now, when we brought it in house, we thought maybe there is something out there we can use. We can just buy it and it would be something that we can use to build these kind of experiences like Jack or the other things, which have the same sort of feel. We looked around and we realized there just wasn’t anything that was quite what we were looking for because, and some of this was coming from the creative side, there are certain things that are really important to us that no one in the world besides us cares about. A lot of it has to do with aesthetics and making sure there are no breaks in the audio, making sure the text is an alias, and looks good. We really couldn’t find anything that solved the problem. It was better, putting together something that worked which involved cobbling together a few other tools. Important aesthetic issues drive a lot of the difficult technological issues.

Dave: It’s sort of like problem based learning. It’s like, we need something that will compress this art to the point where we can fit it all on a CD-ROM. So someone goes looking on the web and buys books to learn about various ways, to learn enough about compression schemes, probably not to write our own, but at least to know how compression schemes work and how to integrate the latest compression stuff into what we are using, as opposed to knowing, I’m going to need to know about compression six months before you need to know about it. As we are building the things, we know what the issues involved are. We can research those issues. One of the key skills, it’s not like compression technology is the key skill to know, is being able to learn about things that are going on.

Ed: It’s learning quickly on it.

Dave: Yeah, and researching things is really important.

Dave: It used to be that a program was a program, and you would write the code for a program. Now things are so big and whatever you’re writing code for, say web pages or generating web pages, it’s not really a program. Or, you’ll be building databases without really writing the code for the database. It’s still a pretty technical field with database design and stuff. I think it’s getting more specialized that way. I think that in general, the skills that are between them are similar enough that a good programmer, a good technical person, could in general have the ability to go to switch specialties or pick up a new specialty to some degree. I don’t think just because you focused in on one thing you’re going to be left behind on the other things.

Ed: A typical day for me sort of revolves around the roles I play. If someone is coming to me to make changes, they are most likely using a writing tool that I made. So if they want to add new dialogue to this question title, they tell me what they want, and I give it to them. So that is one thing that drives my activity. I’m also doing a product similar to what Dave is doing, so I’m working with the director. So they basically say, ‘here is some new media or here is some new artwork, plug it into the prototype’. When you take a prototype out and test it, there will be a lot of changes. There will be a new flowchart, new media and new art work. Some of those changes are quite simple and some of them take a little bit longer, like a day or two. That’s another activity that I respond to. A third is tweeking the engine. That’s where people doing prototype programs like Dave will maybe ask is there a way to quickly model something so that we don’t have to do this. In the past, for instance, we would draw animations and play sound effects, like when something wipes on and there is a sound effect that goes with it. Those would be two things that the programmer would implement. The programmer would, say, start an animation, and then the programmer would play a sound effect. Well, it got to be a very common usage pattern that every time you do animations or sound effects. So we ended up changing it so that the information starting the sound effect is now embedded in the animation itself. The programmer doesn’t even have to be aware of it. That’s an example where we saw something where we were writing twice as much code as we needed to do. We changed the process so that creative people don’t even have to tell us. They just put it in their animations and when we just play the animation, the sound happens automatically. That’s an example. So when working with the engine, if there is a better way to do things, we will implement that.

Dave: One of the goals is, eventually, we want to make writing of the actual game play code, the sort-of top level code, easy enough that we can take someone who is creative typing, and have them write some of these prototypes. Or, make it simple enough so that we can build a tool so eventually it doesn’t take a director coming to us with a flowchart and a list of sound effects and saying, ok, play this sound effect here. Eventually, they can put that in themselves, at least for the first round of prototypes. That will make that process much more streamlined.

Mike: Oh, I am not sure, I think they are elm trees.

Dave: Yeah, I liked the elm trees. I liked the little spinning things because they were a lot of fun when I was a kid. So, to bring joy to all the young kids, I think would be me.

Ed: I grew up in Florida, and my favorite tree was the orange tree. It would have fruit on it in the spring time, and it was the best snack to go pick one off. So, I would be an orange tree.

Mike: This was more a psychological inquiry, I guess you can find out a lot about a person based on what tree they would like to be.

Dave: A friend of mine was doing this whole thing, and she would ask, describe your favorite color. Then someone would say, my favorite color is green, and I think of it this way, this way and this way. And that was how you felt about something. [For example] Describe the ocean, and however they described it, that’s how they felt about sex.

Ed: Is that Tom?

Dave: We think it’s Tom. We think it’s the founder’s brother who used to work here.

Ed: I think he moved to LA.

Dave: Yeah, we followed the website’s advice and didn’t ask what the guy was doing.

Mike: Yes, actually I’m in competition with my girlfriend and we just love the names you guys come up with. There were some very strange things, but awesome none the less.