Java Success Story—Quiz Studio Embodies the Latest JDK, JFC Components, and Java Plug-in

  Java Report Online's Daniel Brookshier interviews the developers responsible for Quiz Studio.

Thierry Levy, Founder and CEO of Quiz Studio, Inc., a subsidiary of Paris-based Elti SA, has a decade of experience in marketing, business applications, and product development. His main roles as CEO are to direct product strategy and to manage sales and marketing.

Dan Serfaty, Vice President, Development, came to Elti SA with several years of experience in software development, specifically in writing educational software programs using C++. Since late 1996, his primary role at Elti has been to manage the development team of the Quiz Studio software package, but he also writes code. He personally developed the "author" module of Quiz Studio.

Are you looking for a Java success story? Are you wondering how companies are faring with Java technology? Daniel Brookshier interviews the founding developers of Quiz Studio—one of the most successful Java technology developments. Find out how to do Java development from a company that has gone through a full development cycle and now has a commercial success using Java technology (including JDK 1.1.6, JDBC, RMI, JFC/Swing, and Java Plug-in).

Looking for Success
At JavaOne this year, Daniel Brookshier spoke with companies that were using Java for commercial applications. There were many Java success stories this year—one of the best examples is Quiz Studio.

Quiz Studio, to put it mildly, was a huge effort. Even more amazing, the end product is an applet. There just aren't too many companies out there that are creating robust applications that run on the Web as an applet. This is especially amazing considering that most applets are written to Java 1.02 standards because of implementation differences between Netscape and Microsoft.

Quiz Studio also uses the latest 1.1 Java virtual machine (JVM). To get their applets to run on both Explorer and Netscape, they are using the new Java plug-in technology. Even more amazing, Quiz Studio is taking full advantage of Java Foundation Classes (JFC, also known as Swing). Simply put, Quiz Studio is at the bleeding edge. We were very impressed by their willingness to push the edge and to succeed in doing so.

Upon Quiz Studio's release it has become a much-respected name in the testing and survey world. Their job wasn't easy, but most problems encountered during Quiz Studio's development have now been solved. Java development has its difficulties, especially at the edge of new technologies like JFC. But, the team was much happier with Java's capabilities than they were with their existing C++ development environment and Quiz Studio is working as designed. Mark up another Java success! A new commercial product is using the latest JDK, JFC components, and the Java Plug-In. Despite a few bumps, Java is proving itself ready for prime time.

What Is a Quiz Studio?
Quiz Studio is a user-friendly, point-and-click authoring module that can be used by novices to design multimedia tests, exams, quizzes, or surveys. The application is designed to take advantage of drag-and-drop, area-pointing to create and setup the reporting and scoring of questions.

Dissecting a Java Success Story
We spoke with Dan Serfaty, Vice President, Development, and Thierry Levy, Founder and Chief Executive Officer about the how and the why of Quiz Studio's development process.

JR: What got you interested in developing Quiz Studio in Java?
Before we decided to develop Quiz Studio, Elti (Quiz Studio's parent company) was the editor of WinKwiZ, a Windows-based questionnaire-authoring tool written in C++. WinKwiZ worked pretty well as a stand-alone application but, as many of our customers reported to us, users began to find trouble when they wanted to export their questionnaires to use them with our runtime or when they needed to retrieve the results from the runtime.

Actually, the real design problem was that a questionnaire is meant to be something alive. The questions change each time the topic they are related to changes. So, each time a question was modified, users had to go through the process of exporting/ importing data all over again. We definitely needed a way to centralize data. Besides, a lot of WinKwiZ users had to carry their laptops around to allow people within their companies to take the tests.

In 1996, we began considering adding new features to WinKwiZ, so users could take tests on the Internet, but we did not know yet what was possible, as it was not easy to program applications for the Internet in C++. Besides, we knew how expensive C++ code maintenance was.

After a few weeks, we decided to rewrite WinKwiZ completely so that we could include everything for the network (the Internet) and for most databases. The specifications were clear: the Quiz Taker module had to run in a browser and data should be stored using major SQL databases.

When the product's main features were defined, we had to consider all tools and languages that would allow us to develop the product according to our specifications. We first thought of using Borland Delphi. Delphi was good to make our software run with SQL databases. On the other hand, it was easy to design Graphical User Interfaces (GUI) with these tools. The problem was the network access. It was clear that if we chose Delphi, we would have to develop a plug-in for each browser in the market (using C++ again). We wanted to avoid using different languages for the application in order to maximize reuse of our components.

We could also have written the Quiz Taker module using HTML and CGI scripts, but again, we would have to use different languages. Furthermore, we needed to allow authors to design advanced types of questions, such as drag-and-drop, associations, etc., which is impossible to do with HTML.

After a few weeks, Java clearly seemed to be the only answer to our specifications. Sun's promise of "Write Once, Run Anywhere" seemed very interesting, but we knew how difficult it is to deliver on this kind of promise.

The question then was: "Will Java really make it?" Java was young in 1996. Besides, we did not like Version 1.0.2 of the JDK (Java Development Kit) and Version 1.1 was still in beta. We were clearly going to be "guinea pigs" for "real-life" Java development.

In March 1997, when we finished the specifications of the product, we had to face another problem. The choice of the tool used to write code in Java. There was no real visual tool at this time that would allow us to develop with Version 1.1, so that we could benefit from the major enhancements of the framework such as the new event system and the new JDBC version (Java Database Connectivity).

JR: What was your primary Java IDE?
After a few weeks using the Window's notepad, editor, and testing beta versions of new tools, we decided to choose IBM VisualAge for Java, which had a serious version control system. As we already knew IBM's VisualAge Smalltalk version, we knew it would be a good choice for a big project.

JR: What were some of your biggest problems to solve?
We mostly encountered the question: "Should we write this component, or can we use some third-party one?" For instance, one of the implications of applet security is that the applet can only connect to the machine it was downloaded from. This means that if you have to get data from a database, the database has to run on the same machine as the Web server, which is not always possible. Today, there are a lot of vendors providing solutions to this problem, placing an interface (based on top of JDBC) between the client programs and the database. But when we began development of Quiz Studio, however, there was no real solution available, so we had to write our own interface.

Let's take another example related to the GUI design of Quiz Studio. VisualAge does not come with graphic components besides those provided with the JDK Abstract Window Toolkit (AWT). We needed more complex components, such as tree views, buttons with icons, etc.

There were some graphical component packages available from different vendors but none were a standard, and this was a problem because the browser would have to download the whole framework to run the applet. So we decided to write what we needed.

A week later, the JFCs (Swing) first beta version was released and could be downloaded from the Java Developer Connection (JDC) on JavaSoft's Web site. When we read the specification of the Swing package, we concluded that we had to use it because its architecture seemed good: using the MVC (Model/View/Controller) model, Swing separates GUI and data. Besides, Swing was going to be a standard and would be included in the next release of the JDK.

The big problem with Swing was that it was in early beta. [It was difficult] to work with beta APIs to develop a commercial product. APIs are changing with each new release and so is your own code. We were clearly warned in the Swing documentation, but we had no other choice to meet our constraint of having the smallest applet possible to download.

There was another problem with Swing or I should say with VisualAge. Currently, VisualAge for Java does not allow you to upgrade the JDK version in the system, and it uses Version 1.1.1. Each Swing release was written on top of the latest version and needed this version in order to work properly. Consequently, it was not always possible to visually design our user interface within VisualAge. We are still waiting for the next version, which should correct this shortcoming [VisualAge for Java 2.0 is now available].

When we released the first beta version of Quiz Studio, we had to deal with another unexpected glitch: JDK bugs and, in particular, memory leaks. The JVM also had random crashes with Windows 95. This was a real problem, as we had no control over this. Fortunately, this has been corrected with the latest version of the JDK (1.1.6).

The last problem, but not the least, was that browsers could not follow the evolution of Java. We used Java's Remote Method Invocation (RMI) feature to access our server. RMI works with Netscape's browser but not with Internet Explorer. We are using Swing, which is not included in Communicator, nor in any Microsoft product.

The answer to this problem surfaced when Sun announced the Java Plug-in (formerly Java Activator), which ensures that the browser run the latest version of the Java platform. These problems, along with the Java platform immaturity created tremendous difficulties in keeping deadlines for the kind of project we were working on, at least in the past year.

JR: How do you feel about the state of Java and JFC now that things have stabilized?
Now that we are about to release the final version of Quiz Studio, the Java platform seems to have reached maturity. Sun has corrected many bugs in the JDK and has added a framework with real graphic components. Besides, the next release of Java (1.2) should correct the last criticism one can make to this language: it is still slow. I now think we made the right choice when we chose Java and Swing, but it was clearly a risk.

We should say that many answers to the problems we had to face were given by other developers in Java-related newsgroups. These problems have made the development of Quiz Studio an exciting project, but thanks to Java developers' solidarity, the adventure ends well.

JR: What was the development timeline? Were there any triumphs or glitches that were important to the schedule?
Table 1 shows a list of important dates in Quiz Studio's development. The problems were mostly when things were not progressing as expected (like Netscape not being 100%). The highs were when we were recognized for our efforts at creating a premier Java application.

JR: Did you create a formal design or work from prototypes?
We had a standard formal design process. We started with a list of specifications and went through an analysis process, coding, and then some testing.

JR: Did you have independent test personnel and/or beta testers?
No independent test personnel, but some beta testers.

JR: Are you using the Java Plug-in right now? Have you had any problems with the released version?
We are currently using the Java Plug-in. It works fine because it recognizes the JFCs. The applet worked without problems under windows (Netscape and IE) and under Solaris (Netscape).

JR: Describe the size of the project by the number of classes that were created.
There were approximately 450 classes.

JR: How many components were custom and/or third-party?
We used two commercial components. The first was the ICE Browser because we needed a way to present information without writing our own formatting. The ICE Browser gave us the flexibility to use HTML. We also used JavaChart to display tabular data.

JR: Did you have any problems with the ICE Browser or JavaChart components? Did the vendor fix the problems?
We were mainly concerned about the 100% certification of these components. Both the ICE Browser and JavaChart have been certified since.

JR: Is Quiz Studio internationalized?
Yes. As we are a Franco-American company, this feature was part of the design from the beginning. We have implemented a very effective way to translate the interface into any language without any programming skills.

JR: How did the team get "Java" trained? What were the best training books you used?
We learned Java by ourselves. Everyone on the team had already worked with C++, Smalltalk, and Object development methods. The first book we used was actually a French book, but we ultimately used the famous Java in a Nutshell (Flanagan, D. and M. Loukides, O'Reilly & Associates, 1997), which has proven to be an invaluable source of information. We also relied a lot on the original JDK docs.
JR: What would you do differently on your next effort based on lessons learned from Quiz Studio?
We underestimated the coding time by more than 30% due, in part, to the delay in the availability of development tools (VisualAge, JDK, Swing, Java Plug-in, etc).

The Java Promise

CEOs and high-level managers are recognizing the benefits of Java. Quiz Studio's CEO, Theirry Levy, discussed his company's introduction to Java and the ensuing benefits. One of the many idiosyncrasies of Quiz Studio is that its founder is an MBA graduate (instead of being the typical geek).

I must mention, however, that I had worked several years for major IT companies as a salesperson and had always passed for very well-versed in the technicalities of what I sold (probably due to my scientific education in France).

Making the Java decision in November 1996 was like a leap of faith, as I did not have all the data necessary to make a truly rational decision. Back in late 1996, Java was little more than a skillfully touted marketing concept with no real-life references.

On the other hand, I knew perfectly what I did not want anymore: Elti (Quiz Studio's parent company) had been developing software using C++ for 4 years. Although I was not directly involved in the programming, these were 4 years in Hell for me, too. C++ was very demanding, fool-prone, and nerve-racking. It was also very expensive to maintain.

So when we first heard about Java, this concept took on the appearance of a messiah bound to save a C++-plagued Windows community. Promises were high: a more robust language (originally designed to run on washing machines or toasters—imagine the consequences of a bug), totally portable through many platforms and easier to program than C++. On the other hand, it also included standard features useful for interacting with the Internet (a primary requirement for Quiz Studio).

Maybe it was too good to be true, and Java has not yet fully delivered on all these promises but, on the whole, this leap of faith has been very successful. Java is really the closest thing to a portable language in the history of IT, and although it is still young, we have encountered comparatively fewer glitches than I had expected at the inception of the project. An ancillary problem was that at the time we chose Java, there was no tool available to develop the visual interface that was part of our specifications.

Our bet was that by the time we would begin coding, "somebody out there" would come out with the right tool for the job. This was like surfing on the edge of technical feasibility. And so it was: by early spring of 1997, several software vendors seemed to offer "the miracle cure" to our woes. We actually tested five packages before picking VisualAge. We all knew that the beta version was grossly flawed. It was like throwing a leaking buoy to a drowning man.

It amazed me that VisualAge was made by IBM. Until that time, I had always identified Big Blue with "big brother" and "big trouble." I have since changed my mind. Not only has VisualAge been a good choice despite its many glitches, but IBM clearly appears to be a Java champion. What really tipped the scale in favor of Java versus ugly C++ or smart Delphi, was the glow the sheer word "Java" brought about in Dan Serfaty's eyes.

Despite its shortcomings, Java is actually every object-oriented developer's dream come true, a worthy successor to the much beloved "Smalltalk" language. Choosing Java had the considerable advantage of bolstering morale among our development team, not only because it was a much-hyped concept but also because it was a sleek, intellectually-pleasing language irresistibly appealing to any young engineer's mind.

Java has not established its reign over the Internet world yet, but I know one thing for sure: If techies were the only ones to make strategic IT decisions, the Wintel supremacy would be doomed.