By:  Benjamin Brunk
August 8, 2000
 

Introduction

The Generalized Relation Browser is a tool for creating a preview of a collection of online documents or web sites.  It could also be used to view the relationships among attributes of a database, independent of the web.  The GRB is similar in concept to query previews, but unlike a query previews system, its goal is not to aid people in narrowing a search but rather to help them understand what information is available so that they can make better use of independent search tools and viewers.

The generalized version of the Relation Browser is a descendant of a prototype created for the United States Bureau of Labor Statistics.  It only worked with a predefined set of data describing numerous websites hosted by the federal government that contain statistical information.  These sites are accesses through the Fedstats portal, www.fedstats.gov.  The original Relation Browser used the sitemap from the Fedstats web site to create a listing of 14 topic areas.  Each of these topics had numerous web sites associated with them.  Each web site contained various kinds of statistical data as well as other information.  The Relation Browser accessed a simple flat-file database that associated web sites with various topics and maintained information about each site such as what datatypes were available, where the data was collected, and when the data was collected.  The relation browser applet then displayed this information in its user interface.  One goal of the interface was for it to be more engaging and interactive than a typical web sitemap.  Guided by the philosophy of “A click is a terrible thing to waste,” we decided to use a mouse-over style interface rather than a click-style interface.  The major difference is that the data being displayed in the various interface components updates as the user moves the mouse over various objects within it without having to click to make something happen.  In this case, user interface buttons were given special functionality so that when the mouse is positioned over them, they change color and fire off events to other objects in the interface.  This style of interface design opens up new possibilities for speed and dynamic interaction.  It augments the click-style interface rather than eliminating or superseding it.  The prototype still relies on mouse click events to initiate certain actions.  In this case, when a topic button is rolled over, the data displays change to show the attributes of that topic.  If the button is clicked, the display is “locked” so that the user can then examine the various attributes.  This locking behavior also makes it possible for the user to quickly select a list of attributes and then examine the entire “result set” more closely.
 
 
 

Setting It Up For Your Data

This section describes how to set up and use the Generalized Relation Browser on your own collection of data.

The Database

Any database can be used with the GRB since the applet tag contains a parameter specifying a JDBC connection url with a site URL (must be the same host as the web server), database name, username and password in the query string.  The current prototype uses a MySQL database and queries a single table.  The schema was created using Microsoft Access 97.  Data was entered via a form in Access. Once data entry was completed, the table was copied to the MySQL database via an ODBC connection.  We did this because Access 97 has a superior user interface for schema creation and data entry and MySQL is a much more robust server that is capable of handling many simultaneous table queries with little performance degradation.
 

The Applet Files

You need to have the file grb.jar (or grb.zip if the archive is compressed) in a directory that is world readable via your web server.  In this same directory, you must also have an HTML file containing an applet tag with the parameters filled out correctly (this will be discussed in the following section).  If you have more than one database you want to preview, multiple copies of the HTML file with different parameters in the applet tag can be generated.  There is no need to duplicate the jar archive, however, as long as the files are all in the same subdirectory.

The jar file contains all the class files associated with the applet, including those needed to connect to the MySQL database via JDBC.  This applet makes use of the Java Swing widget library.  Most web browsers have built-in Java virtual machines, but unfortunately, they do not support the latest release of the Java libraries including Swing.  This being the case, Sun Microsystems has released a VM upgrade for Netscape and Internet Explorer that will bring the browser up to the appropriate version.  This is done through the installation of a browser plug-in.  The HTML has some Javascript code in it that checks for the appropriate version of the VM.  If it is not found, the plugin is automatically downloaded from Sun’s web site.  The user is asked to authorize the install procedure via dialog menus and certificate authorizations.  The plugin installs in a fashion similar to most other software programs.  It does not require a reboot of the computer, however.  The plugin download occurs only once.  After that, the test conducted by the Javascript succeeds and the Relation Browser starts up immediately.  Based on experiements done on machines in the Interaction  Design Lab, the downloading and installation of the plug-in goes pretty smoothly and does not impose too much waiting or interference on the user.  This may be a problem for those users who have less bandwidth (i.e. dialup modems at 56K or less).  The plug-in is fairly small and installs pretty quickly once it is downloaded.  After the install process concludes, the Relation Browser applet should start automatically.

The Applet Tag

The most difficult part of setting up the GRB is editing the parameters in the applet tag.  These parameters control several important features of the GRB.  Errors in the applet tag will probably cause the applet to fail to load and display the correct data.

The following code shows the original applet tag for the GRB before the javascript was added by a program that converts the file for use with the plug-in virtual machine.  This tag is embedded in an HTML file.  The CODE, ARCHIVE, WIDTH and HEIGHT tags should be left alone, they should never have to be changed unless the name of the jar file changes (to a .zip for example).

<APPLET CODE = "GRB.class" ARCHIVE = "grb.jar" WIDTH = 504 HEIGHT = 531>
<PARAM NAME = dburl VALUE ="jdbc:mysql://squash.ils.unc.edu/RB?user=brunkb&password=brunkb432" >
<PARAM NAME = maintitle VALUE ="Relation Browser Mark III Using Fedstats Data">
<PARAM NAME = primaryquery VALUE ="select distinct Topic from fulltable" >
<PARAM NAME = bottomattributes VALUE ="Site Name|Site URL">
<PARAM NAME = attributesquery VALUE ="select SiteName, SiteURL from fulltable where Topic=">
<PARAM NAME = tabtitles VALUE ="Data Types|Regions|Dates">
<PARAM NAME = tab1 VALUE ="SELECT SUM(Reports), SUM(Tabs), SUM(downloadabledatasets), SUM(searchabledatasets), SUM(GraphsCharts), SUM(Maps), SUM(PhotosVideos) from fulltable where Topic=">
<PARAM NAME = barnames1 VALUE ="Reports|Tables|Downloadable Datasets|Searchable Datasets|Graphs/Charts|Maps|Photos/Videos">
<PARAM NAME = tab2 VALUE ="SELECT SUM(International), SUM(National), SUM(Regional), SUM(State), SUM(Sub_State) from fulltable where Topic=">
<PARAM NAME = barnames2 VALUE ="International|National|Regional|State|Sub-State">
<PARAM NAME = tab3 VALUE ="SELECT SUM(_Pre_1960s), SUM(_1960s), SUM(_1970s), SUM(_1980s), SUM(_1990_1995), SUM(_1996_2000) from fulltable where Topic=">
<PARAM NAME = barnames3 VALUE ="Pre-1960s|1960s|1970s|1980s|1990-1995|1996-2000">
</APPLET>

Parameters

The first parameter you will have to edit is the dburl.  This parameter tells the applet where to find the database (server and port), what protocol is being used (jdbc:mysql), the name of the database, and supplies a valid username and password in the query string in order to access the database.  This parameter is case-sensitive and must be included or the applet will terminate and not display any information.

The maintitle parameter sets the title at the top of the GRB to whatever text title you want displayed.  The example above informs the user that they are running the “Relation Browser Mark III using Fedstats Data.”  This parameter must be filled out, but the GRB will run if the field is null (emtpy quotes “ “).

primaryquery  is the next field you will have to change.  It is the query that creates the list of topic buttons on the left-hand side of the interface.  It is also a very important parameter, the GRB will not run if there is an error in it or it is missing.
The next two parameters go together.   bottomattributes and attributesquery control what gets displayed in the table at the bottom of the interface.  bottomattributes is a list of column names for the table.  Each column title is separated by the vertical bar “|” character.  The attributesquery is the query used to populate this table for each topic object.  Notice that the query is missing a literal in the comparison “topic=” at the end of the string.  This is intentional because the GRB changes the name of the topic dynamically as each topic object is loaded into memory.  If your query is significantly different than this due to your schema design, the query may fail and cause the GRB to terminate.  While not exactly a bug, it does point to an area where future work needs to be done on the GRB code in order to support more complex database schemas.  Once again, both of the parameters are critical to the functionality of the applet and cannot be left blank or null.  The number of columns in the table derives directly from the number of titles in the bottomattributes list.

The balance of the parameters in the applet tag are all associated with the tabbed panel of graphbars on the right-hand side of the interface.  tabtitles tells the applet the title of each tab.  Similar to the bottomattributes parameter, the number of tabs is derived from how many items are on the list separated by vertical bar characters.  For each tab, there is both a query parameter, tabX (where X is a number starting with 1) and a list of graphbar names, barnamesX (where X is the same number for each tab).  Each tabX query selects the attributes to be displayed as graphbars.  Since these attributes are all integer values in the database, and since there are many associated with each individual topic, what is needed is a sum of each one, as can be noted from the example queries above.  The ordering of parameters in the query is important because this is how the GRB fills up the graphbars on the tabs.  The order of graphbar titles for barnames must correspond to the order in the query or the results shown on the graphbars will be incorrect at runtime.  Each barnames parameter is just like the bottomattributes parameter, a list of titles separated by the vertical bar character.  The number of titles controls how many bars appear on each tab.  Only six graphbars will fit on a tab, however.  There is currently no mechanism for scrolling to view more than six on each tab.  This was an interface design decision based on usability, not a bug.  More tabs can be added to accommodate additional graphbars.
 

Final Notes

Although the Relation Browser is now in its third iteration and has undergone substantial usability testing, it is still a prototype.  We hope to get more feedback about it and continue to improve upon the interface and make it accessible for even more generalized applications.  It is quite possible that new bugs will surface as it is begins to be applied to new datasets, so please let us know so we can fix them.