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 Studioone 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 yearone of the best examples is
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?
QS: 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
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?
QS: 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?
QS: 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
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?
QS: 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
QS: 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?
QS: 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?
QS: 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?
QS: 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.
QS: There were approximately 450 classes.
JR: How many components were custom and/or third-party?
QS: 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
QS: 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?
QS: 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
JR: How did the team get "Java" trained? What were the best training books you used?
QS: 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?
QS: 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).
POINT OF VIEW OF A CEO: |
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 toastersimagine 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
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.