%
%  $Description: Active Essay on the Web
%
%  $Author$
%  $Date$
%  $Revision$
%

\documentclass[times, 10pt,twocolumn]{article}
\usepackage{latex8}
\usepackage{times}
\usepackage{graphics}
\usepackage{url}

%\documentstyle[times,art10,twocolumn,latex8]{article}

%-------------------------------------------------------------------------
\pagestyle{empty}

%-------------------------------------------------------------------------
\begin{document}

\title{Active Essays on the Web}

\author{
   \begin{tabular}{c}
     \begin{tabular}{ccc}
       Takashi Yamamiya & Alessandro Warth & Ted Kaehler\\
       takashi@vpri.org & alex@vpri.org & ted@vpri.org
     \end{tabular}\\
     \\
     Viewpoints Research Institute\\
     1209 Grand Central Ave., Glendale, CA 91201
   \end{tabular}
}

\maketitle
\thispagestyle{empty}

\renewcommand{\thefootnote}{\fnsymbol{footnote}}
\footnote[0]{This material is based upon work supported by the National Science
Foundation under Grant No. 0639876.
Any opinions, findings, and conclusions or recommendations expressed
in this material are those of the author(s) and do not necessarily
reflect the views of the National Science Foundation.}

\begin{abstract}
   This paper describes ``Active Essays'' and their
   implementation with Internet technology.  An Active Essay
   combines a written essay, program fragments, and the resulting live 
simulations into a single cohesive narrative~\cite{activeessays}.  We 
believe the integration of programming and natural
   language makes a superior teaching medium for expressing mathematical, 
scientific,
   and even literary ideas.  It is especially effective when it can be 
read, run,
and authored in a web browser.  We review our previous 
implementations of Active Essays on the Web. 
Chalkboard~\cite{chalkboard} is our latest Active Essay framework. 
We discuss Chalkboard's features, examples, design
   decisions, and unresolved issues.
\end{abstract}

%-------------------------------------------------------------------------
\Section{Introduction}

Programming languages were made for giving orders to machines.
They have evolved to be somewhat more human-friendly and modular, which makes programs easier
to maintain. Now we understand that the single most important aspect of
a program is readability, not efficiency. An important additional goal is for a
programming language to be a good medium for learning and
communication between humans.

A programming language has the notable feature that its meaning is strict and
ideas expressed in it actually run on a machine. This property has a 
great benefit:  when combined with a written essay, it allows the reader to see an animated and interactive 
expression of what is being taught.
Neither natural language nor mathematical formulas are as alive or 
expressive. The
best way to rigorously learn a complex idea is to program it. While the 
program you write
may not run well at first---often, it will not run at all---%iteration 
%of modifying and
the process of debugging will lead to an elegant expression of the idea that 
actually runs. The result is often good material
for another learner to read.

On the other hand, natural language is better than a programming 
language to show an overview.
Written language works well to express the ``Why''
and ``What'' knowledge that are hard to describe in a program. The
combination of a natural and a programming language in an Active 
Essay has all of the
advantages. It can be an excellent substitute for a textbook.

The Internet gives people large opportunities to access massive
amounts of knowledge. But information on the web tends to keep the 
form of old media like
newspapers, TV, and articles.  These do not yet use the real ability 
of the computer.
Our project aims to re-introduce programming languages as
a way to teach powerful ideas on the web.  We want to harmonize 
literature and programming into a new medium that is more expressive than each alone.

%-------------------------------------------------------------------------
\Section{Background} % and Related Work}

%-------------------------------------------------------------------------
\SubSection{Active Essays}

An ``Active Essay'' is a written essay mixed with a computer program. The
term was coined by Alan Kay. The goal was to provide students with a hands-on
experience of mathematical and scientific ideas via
dynamic simulations. The same concept, but without the essay is used 
to create and teach dynamic content
in the Etoys authoring environment~\cite{etoys-site, etoys-kim, steinmetz}.

Think of a math book that includes several paragraphs and
formulas on each page.  The reader follows the author's idea not
only by reading the text but also trying formulas. In the case of Active
Essays, programs are embedded in the page instead of formulas. The
biggest advantage of an Active Essays is that the program actually 
runs and animates the example.  This is more dynamic
than a formula. It is really fun to see a few lines of code generating little
surprises on the screen. Another advantage would be that you
don't have to calculate the numbers yourself -- the computer does a
faster and better job of ``fiddling variables''.

%Some examples of active essays include \textbf{MENTION SOME 3rd PARTY EXAMPLES HERE}

%-------------------------------------------------------------------------
\SubSection{World Wide Web}

The Internet has made finding and publishing information incredibly
easier, but it's content still tends to mimic traditional media.  Even
though it is highly dependent on computer technology, the web makes
little use of programming languages as communication media.

A programming language is the primary tool for talking between man and
machine.  It could also be a good way to exchange ideas among humans.
If there were enough support tools, it would be natural to write a
blog post using a programming language, to chat with source code, and
even to write a novel that runs as a program.  Especially when the
topic is science or mathematics, a programming language is often the
most accurate way to present an idea.

It is ironic that you can't play
with a LOGO program while you read the Wikipedia article about LOGO.

\begin{quotation}
However, e.g. while the article on Logo has some good information and
examples, none on them can be run, dynamically changed and tried,
etc. To me this is outrageous given that the browser was done some
years after HyperCard, longer after the Apple ][, and long long after
     the prior art of the 60s and 70s. -- Alan Kay~\cite{logowiki}.
\end{quotation}

What kind of tool could support running examples in an article? The abundant
introductory material for science written in Etoys is a good
place to start. The history of Literate Programming shows
another interesting aspect of the topic. These were our starting
points.

%-------------------------------------------------------------------------
\SubSection{Literate Programming}

Active Essays share ideas in common with Don Knuth's Literate
Programming. Active Essays emphasize dynamic experimentation,
while Literate Programming focuses on the readability of system-level
programs. But, both of these media try to combine literature and programming.
Advantages of Literate Programming can also be applied to Active
Essays.

Don Knuth said that even though more time is required for writing, the
total time including writing and debugging in Literate Programming is
not greater than normal programming.  This is because it takes less time to
debug a well-understood program~\cite{literateprogramming}. Although 
it is possible that his
words arise from too much enthusiasm, integrated documentation makes 
it very much easier for a third person to understand a program.

The original idea of Literate Programming was implemented as the WEB
system for Pascal. The WEB generates program source code and
documentation from single WEB source file.  But, to be compatible with
the inflexible nature of Pascal, the syntax of WEB is rather
complicated.  Attempts using the Smalltalk language~\cite{reenskaug}
reduced this difficulty.

%------------------------------------------------------------------------
%% \SubSection{Etoys and Microworld}

%% Target user of the project is older than Etoys and LOGO. Papert's idea
%% of Microworld~\cite{mindstorms} is that a carefully restricted
%% environment maximizes kid's imagination.

%-------------------------------------------------------------------------
\Section{Previous attempts}

In 1994 Ted Kaehler built an active essay in HyperCard that explained
and ran Richard Dawkins' example of evolving the sentence ``methinks
it is like a weasel''~\cite{weasel}.  The HyperTalk scripts for the
example were in fields on cards, and could be modified by users.  The
stack kept old versions of scripts, so that the user could revert
after trying out a change to a script.

In 1995, Kaehler built two active essays in web pages using Glyphic
Codeworks as plugin to run the code~\cite{codeworks}.  Each of
Kaehler's essays were awkward; the first was not on the web, and the
others required a plugin that was difficult to install.  These efforts
were tantalizing, and caused us to search for an easy and capable
active essay format in a web page.

Because there are many design choices when designing an Active Essay
framework on the web, we introduce our recent attempts in historical
order. These are helpful in examining possible designs and
understanding our latest decisions.  We have made five experimental
implementations over the last few years. Those projects are described
with their features, server and client platforms, screen layouts, and
data formats. All projects use HTTP for sharing content.

%-------------------------------------------------------------------------
\SubSection{Scamper Workspace}

\begin{figure}[tb]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{ScamperWorkspace.png}}
   \caption{Scamper Workspace.}
   \label{fig:scamperworkspace}
\end{figure}

A Scamper Workspace (2004)~\cite{scamperworkspace} by Takashi 
Yamamiya was an extension
of Scamper, a web browser written in Squeak. Scamper
Workspace allows the reader to execute any Smalltalk code that is 
present on a web page.  An author can include illustrative examples 
in Smalltalk on a web page.

People often write a small amount of source code in a blog. And it is natural
that a reader may want to run this code without any effort. In the case
of Squeak, you have to copy and paste from a web browser to
Squeak. However, Squeak contains a web browser named ``Scamper'', and a web
page is just text the same as other Squeak text objects.  Scamper is 
very limited as a
web browser, but it has enough power to let the user read blogs.

``No Application'' is Squeak's motto. Squeak consists as a number of
objects that each have different tiny functions, and those are
connected together in a single world of objects. In that sense, there 
is no need for an
``Application'' because an application is just an artificial
boundary. So, it seemed natural to allow Scamper to have the commands 
that execute text as code.

%% Because all the necessary functions were already available in the Squeak image,
%% the implementation was very easy, and the result was surprisingly
%% attractive.  

Thoru Yamamoto created a lot of content for the Scamper Workspace.
Figure~\ref{fig:scamperworkspace} explains how to draw a robot by
Squeak functions. This is a typical one which consists of a short
story and a couple of lines of code. A reader would execute the code
while reading a story.

%% This format was very
%% effective when the story was integrated with Squeak's graphics
%% facilities. %% [[Please have an example!]]

%-------------------------------------------------------------------------
\SubSection{StackWiki}

\begin{figure}[tb]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{StackWiki.png}}
   \caption{A screen shot of the StackWiki.}
   \label{fig:stackwiki}
\end{figure}

StackWiki (2005) by Takashi Yamamiya was a WYSIWYG authoring tool 
written in Squeak. A
document was saved in original binary format onto a Swiki (Squeak Wiki) server.

StackWiki was inspired by Zest and Marmalade~\cite{zest} by Benjamin 
Schroeder and John Pierce. Although Zest
only used a local disk for saving data, the idea was similar to a
Wiki. You could easily make a link to another page, and make a new page
just by specifying a nonexistent name. Additionally, Zest could
include multimedia content written in a Smalltalk-like language.

Compared to Zest, StackWiki was closer to the original idea of
HyperCard.  A StackWiki project consisted of one or more ordered
pages, and relationships among pages were defined by the page order
and hyperlinks.

%% In a web site, normally relationships among pages are maintained only
%% by hyperlinks, but there is no structure like hierarchy or
%% order. Some web sites attempt to impose linear structure by using standard
%% navigation buttons. While the structure helps the user to know a position
%% within the context, it often makes the UI complicated. In addition to 
%% page turning,
%% historical forward and backward navigation are needed if
%% the pages have an order. Above all, if there is hierarchy then three
%% dimensional navigation becomes necessary. StackWiki had only ordered 
%% structure and links.

By using a background, selected objects can appear on all pages. 
StackWiki only allows one background, though
HyperCard could handle many. The background was implemented as a special
``background'' page. If you add something to that page,
it is shown in the same place behind other elements on all
pages.

A background can be seen as a special version of macro or
template. A macro is a technique to share a common structure in
documents. It is useful to reduce redundancy and to improve
maintainability. However, it is easy to make a macro be too 
complicated by including another macro in it.  The background is a 
better
compromise for the end-user.

Each StackWiki page is stored in binary format in the Swiki
server. The Swiki is used only
as a file uploading server and web page server. StackWiki does not 
use any web standard except HTTP to transport saved data. StackWiki 
can only read pages from a Swiki server. StackWiki is simple and uses 
many built-in Squeak features.  It took only three days to implement 
StackWiki.

%-------------------------------------------------------------------------
\SubSection{Tinlizzie WysiWiki}

\begin{figure}[tb]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{driveacar.png}}
   \caption{TinLizzie WysiWiki.}
   \label{fig:tinlizzie}
\end{figure}

Tinlizzie WysiWiki (2006)~\cite{tinlizzie} by Takashi Yamamiya et al.\ was a 
wiki written in Tweak~\cite{tweak}. It uses OpenDocument Format 
(ODF)~\cite{odf} as its data
format, and WebDAV as the server.

While the data format in StackWiki was a Squeak-specific binary, in the
Tinlizzie WysiWiki, an existing standard format is used. The reason 
is to make the
user's data available in other applications besides Tinlizzie WysiWiki.  A user
can confidently put large amounts of important data into this system, knowing
that it can be viewed and used in other OpenDocument application programs.

%% The project was also an
%% exploration to find a possible format for exchanging Etoy content among different
%% platforms. We wanted to be platform-independent and
%% transparent. ODF was quite close to what we needed. It was a) text-based
%% b) able to embed graphics c) able to support internal and external
%% links.

An ODF file is just a zip archive which includes XML text and
multimedia binary files. It is easy to extract one of the multimedia binary
files from the archive using an external tool. Both internal and external
resources can be referenced using normal URLs. And if
necessary, a new XML tag for a Tweak-specific object can be defined. For
example, a project which includes fully dynamic behavior written as
Tweak objects can be viewed by an OpenOffice application, although
any dynamic features in it would be disabled.

%% Special care was needed to export a Tweak object to ODF as naturally
%% as possible. It is not a good idea to define a new tag for a
%% Tweak specific object, even though it is possible.  A better way is to
%% use an existing tag in the ODF specification.  For example, if a Book
%% object in Tweak is stored as a presentation with a frame in ODF, the
%% project looks somewhat normal when viewed by other applications.

Sometimes the entire state of an object does not need to be save.  For example,
when text is saved during editing, should the position of the
cursor should be saved or not? There are two strategies.
One is to save everything with a few things excepted
(deep copy), and the other is to save only the specified
object types. Tinlizzie WysiWiki took the latter course, although Tweak's
native mechanisms were the former.

Saving only a specific state has two disadvantages. a) A user might
expect to save everything including minor state because combining
arbitrary objects in any peculiar way is possible in Tweak. b)
Each new widget needs to be implemented with its own custom exporter. 
But the ``saving everything by default'' strategy has a
compatibility problem with future version of the system.  Changing 
the name of just one instance variable
can make reading an older project impossible. This strategy was not taken by
the project.

%% WebDAV was used as the server. Both StackWiki and Tinlizzie WysiWiki
%% do not need server side logic.  Only simple storage is
%% required. WebDAV is the best option. A version
%% control system, such as Subversion, can be used on the server.

%-------------------------------------------------------------------------
\SubSection{JavaScript Workspace}

\begin{figure}[tb]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{JavascriptWorkspace.png}}
   \caption{JavaScript Workspace}
   \label{fig:javascriptworkspace}
\end{figure}

The JavaScript Workspace (2007)~\cite{javascriptworkspace} by Takashi 
Yamamiya is a simple
web application. It uses a normal web browser and JavaScript on the
client side, and Ruby CGI on the server side. It behaves like a
Smalltalk Workspace, and content is managed in the same manner as a
Wiki.

Let us review the workspace again. A workspace is a text editor with
two additional commands, ``do it'' and ``print it''. The ``do it'' command
executes the source code selected by the user, and ``print it''
inserts the result in text after the cursor position. It is similar to a
Read Eval Print Loop (REPL) in a dynamic language, but the use is slightly different. A
typical usage of a workspace is as documentation for the program. An
author often writes example source code inside the workspace, so that
a user can try the actual functions while reading the text. A REPL is 
a two-way dialog between machine and human, while a workspace is a 
three way
conversation among machine, author, and user. %% [[ What is a REPL shell??]]

The workspace is an indispensable tool in Smalltalk, so it makes 
sense that it would be useful in other systems. It would be nice if 
there were a
workspace for JavaScript. This was the initial motivation for
JavaScript Workspace. And then it was a natural consequence to use a
Wiki to save the content.

During development, however, we realized that it was more than
just a workspace.  It was an entire web application. JavaScript
Workspace has a simple user interface, which includes a couple of
buttons and one big text area. The text area does not allow 
hyperlinks or emphasized text. But, a variety of things can be made 
from such minimal
configuration. It is possible to make hyperlinks by
assigning into the {\tt location} property of the {\tt window} object 
and rich text could be shown by modifying the DOM
tree.  Even games could be created by setting up an event hander
and a timer (Figure \ref{fig:javascriptworkspace}). A piece of source 
code can do
almost anything.

Just one text box on a web page is a radical idea. It is in the
complete opposite direction of the current trend toward rich Internet
application pages. Web applications consist of a number of hidden functions
these days, but JavaScript Workspace does not have any invisible
information. Everything on the screen can be seen as source code. 
JavaScript Workspace may appear dangerous since
it can run any JavaScript code, but in fact, it is quite a safe
system.

The user interface of the JavaScript Workspace was adopted by OMeta/JS Workspace (see Section~\ref{sec:ometa-js}).

%-------------------------------------------------------------------------
\SubSection{TileScript}
\label{sec:tilescript}

\begin{figure}[tb]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{TileScript.png}}
   \caption{TileScript}
   \label{fig:tilescript}
\end{figure}

TileScript (2008)~\cite{tilescript} by Takashi Yamamiya et al.\ uses 
Scriptaculous~\cite{scriptaculous} as its GUI library and WebDAV for 
server
storage. Its data format was JSON.

A TileScript document consists of one or more paragraphs, and a
paragraph is either JavaScript code, a ``tile script'', or an HTML
expression. A tile script is a set of draggable tile object, where each tile
represents a syntactic element in the programming language. You can
combine tiles to construct a program using drag and drop. This is an
easy way to make a program and avoid all syntax errors. JavaScript 
can represent more complex programs than TileScript. HTML is used for 
annotation and explanation. TileScript is a richer version of 
JavaScript Workspace.

The motivation of TileScript was to investigate remaking Etoys as a web
application. The initial idea was to make tiles available in a web
browser.  After tiles worked, the next step was to hook up the Etoys
environment itself, which includes event handling, scheduling and
bitmap animation. But those issues seemed too difficult for the
current nature of a web document.

Flow layout, in which the actual positions of the elements on a page are 
dynamically determined
by the reader's browser, is a significant feature of a web
document. You don't have to specify the concrete position of elements,
but rather just the logical structure.

On the other hand, Etoys allows free layout, where the size and position
of elements are fixed by the author.  It assumes a particular screen
size. Free layout works well for graphical application like Etoys, but  if
the reader's screen size is smaller than the original,
clumsy operations like zooming and horizontal scrolling are required.

Because the goal of TileScript was not simply reproducing Etoys, but
investigating new possibilities, flow layout was adopted in
TileScript. Position was supported in the form
of objects embedded HTML. TileScript provided for
variable watchers like Etoys, but those widgets were also laid out with
text flow.  %%[[Ted does not understand how this was done.]]

%------------------------------------------------------------------------
\SubSection{OMeta/JS Workspace}
\label{sec:ometa-js}

\begin{figure}[tb]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{ometajs-workspace.png}}
   \caption{The OMeta/JS Workspace}
\end{figure}

The OMeta/JS Workspace (2007)~\cite{ometajs} by Alex Warth extends 
its predecessor, the JavaScript Workspace, with support for arbitrary 
programming languages.
This is done via a user-defined function called {\tt translateCode}, 
which is implicitly called by the Workspace in order to translate the 
code that the user wishes to execute into JavaScript, ``the assembly 
language of the Internet''~\cite{ingalls}.

The benefits of this almost trivial extension are twofold.
First, it makes it possible for the user to express his ideas in the 
language that is best suited for the job, which is especially 
important for active essays.
For example, when discussing differential geometry, it makes much 
more sense to write programs in a language like Logo than in 
JavaScript.
In this case, the user can define {\tt translateCode} to be a 
function that translates Logo to JavaScript.\footnote{See 
\url{http://jarrett.cs.ucla.edu/ometa-js/#Logo}}
(Such translators are fairly straightforward to implement using OMeta~\cite{ometa}.)
This enables the user to get out from under the limitations of 
JavaScript, effectively putting him in charge of his own software 
destiny.

Second, the flexibility provided by {\tt translateCode} turns the web 
browser into a convenient platform in which to experiment with new 
programming language ideas.
In the past year, the OMeta/JS Workspace has been used as the user 
interface of a number of experimental programming languages, 
e.g., Etude (a language for describing music)\footnote{See \url{http://jarrett.cs.ucla.edu/ometa-js/#Etude}}, Worlds/JS (a language that enables programmers to control the scope of side effects)~\cite{worlds}, and even OMeta/JS itself.
Users are able experiment with these new languages inside the web browser, without 
having to download any additional software, which makes our research 
much more accessible.



%------------------------------------------------------------------------
\Section{Chalkboard}

\begin{figure}[h]
   \centering
   \resizebox{6cm}{!}{
     \includegraphics{chalkboard.png}}
   \caption{Chalkboard}
   \label{fig:chalkboard}

\end{figure}

Chalkboard by Takashi Yamamiya is the latest attempt of an authoring
tool for Active Essays on the Web.  In this project, some design
decisions were based on past work, these decisions are described at
section \ref{sec:platform}, \ref{sec:layout} and \ref{sec:format}.  In
short, because the aim of Chalkboard is to provide a simple and robust
platform for Active Essays, the simpler way was always chosen.

%------------------------------------------------------------------------
\SubSection{Document structure}

\begin{figure}[!h]
   \centering
   \resizebox{8cm}{!}{
     \includegraphics{chalkboardText.png}}
   \caption{Chalkboard Document}
   \label{fig:chalkboardText}
\end{figure}

Figure \ref{fig:chalkboardText} shows a typical Chalkboard
project. You can use standard HTML formats like normal paragraph,
header, list, hyper text and source code ({\tt <pre>} element). Source
code is shown in a fixed pitch font and gray background.

You can execute any text in the document, but the run command and {\tt
  include} function only work with code inside a {\tt <pre>} element.

To make a new project, you simply access a nonexistent URL on the
Chalkboard, or make a new link as {\tt ./\#NewProject} with the link
command. When the project is saved, a new project is created.

There are two ways of running a program in a project. The primary case
is using a ``do it'' or ``print it'' command on each fragment of code 
in order. A reader invokes this
command on program text, and experiments with the content step by
step. Another way is to use the ``run'' command to execute all of the code.

The {\tt include} function provides a way to use a project as a
library. When as the {\tt include} is called, the specified project
its executed in the same way as the ``run'' command, except there are
no visual effects. It allows an author to hide unessential parts of
the program.

%------------------------------------------------------------------------
\SubSection{Chalkboard's user interface}

The screen of Chalkboard is made up of the following parts:

\begin{itemize}
\item
   Tools: There are command buttons in the top-most area. Every
   function of Chalkboard can be invoked from this tool bar.
   \begin{description}
     \item [home] Link to the home page.
     \item [save] Save the page to the server.
     \item [run] Evaluate all JavaScript expressions within the source code
       areas. Each result is printed in the transcript area. If an
       error happens, the border surrounding the source code becomes
       red and the editor area is scrolled to show it. Once the error is
       fixed, the border becomes black.
     \item [do it] Evaluate the selected expression or the selected line
       if there is no selection. The resulting value is shown in the
       transcript.
     \item [print it] The same as do it, but print the result just to 
the right of
       the expression.
     \item [h1, h2, h3] Make selected lines into a header. These
       generate {\tt <h1>, <h2>, <h3>} HTML elements respectively.
     \item [pre] Make the selected lines into a source code area.
     \item [p] Make selected lines into a paragraph.
     \item [list] Toggle to a list item or normal paragraph.
     \item [link] Assumes selected string is a URL, and it makes it 
       into a hyperlink.
     \item [edit] Toggle browse and edit mode. This is unnecessary in
       most browsers. But, some web browsers disable the event handler in
       editor mode, and hyperlinks work only in browse mode.
   \end{description}
\item
   Editor: The largest area on screen is a text editor where you
   can write descriptive text and JavaScript code.
\item
   Play Area: The top right area is referenced from the global variable
   PlayArea. It is typically used to show a graphical object with
   a Canvas element.  The source code in the editor draws on this Canvas.
\item
   Transcript: Results of ``do it'' and ``run'' commands are printed on
   the right bottom area. It is also used to show general output
   via the {\tt display} function.
\end{itemize}

%------------------------------------------------------------------------
\SubSection{Client and Server platform}
\label{sec:platform}

A web application requires both client and server programs. To keep
the development process simple, the Apache web server and WebDAV
protocols are used as the server logic of TileScript, OMeta/JS, and
Chalkboard.  With WebDAV, the remote server can be used in the same
manner as local storage. In addition, version control is provided by a
Subversion module.

Each project is specified by a URL with the name of the project after
a hash mark (\#). Normally, a hash element is used to point to a place
within a document, but we treat it as a project name. An advantage of
this trick is that a web browser doesn't wipe and reload the
JavaScript when you change projects. A disadvantage is that Internet
Explorer doesn't handle these URLs properly in the history list.  This
method is derived from the way GMail~\cite{gmail} works.

%------------------------------------------------------------------------
\SubSection{Screen layout}
\label{sec:layout}

There are two options for screen layout. One is free layout,
which allows the user to place an object in any position on the
screen. Squeak-based projects, Etoys, StackWiki and Tinlizzie WysiWiki
are designed in this style.  Another option is flow layout, in which
objects in a page are aligned in paragraphs, and the position on the
screen is adjusted based on the screen width. TileScript is designed
with this style.  Flow layout was chosen for Chalkboard because of
usability on the web, as explained in section \ref{sec:tilescript}.

%% The goal of Chalkboard is to be a
%% simple mechanism for experimentation with real world content for Active
%% Essays. For this purpose, only basic HTML elements are used.  It 
%% works in all browsers and has very good performance.

%% Another reason is to reduce degrees of freedom and to adjust for
%% various user environments. Free layout has a problem that the content
%% depends on screen width. When a reader's screen size is
%% different from the author's, zooming, or a two dimensional scroll bar
%% are required. The author needs to use special care to get a
%% layout design that works for different screen sizes. Restriction of 
%% freedom can relieve such burdens
%% and help to focus on the text and program content.

%------------------------------------------------------------------------
\SubSection{Data format}
\label{sec:format}

Powerful file formats and interoperability are in a trade off
relationship. Squeak exports the internal memory as a project
file. This is powerful and easy for rapid development. However, it is
difficult to maintain compatibility because it depends on all of
Squeak. Chalkboard uses HTML as its data format. The main part of the
file is the explanatory text, and the program is extracted from the
PRE elements.

There is a special simplicity in Chalkboard's UI. Only logical format
commands for a paragraph are supported.  There are no emphasis or font
size commands. This can help an author avoid strange looking layouts
depending on the web browser.

\Section{Related Work}

%% Two paragraphs: (1) talks about other active essay systems, and (2)
%% talks about programming languages on the web. (Not necessarily in that
%% order.)

%Mitch Resnick and Brian Silverman's
Emergence~\cite{resnick-gol} is an active essay based on Conway's Game of Life.
It is implemented as a series of web pages that, using a combination of text and Java applets, explain the rules of the system and enable the reader to interact with a live simulation. %, respectively.
Unfortunately, the system is exposed as a black box that cannot be inspected or modified by the reader.

The LogoWiki~\cite{bryant} was a Javascript-based implementation of the Logo programming language that enabled users to run, modify, and share programs in the web browser.

SophieScript~\cite{sophiescript}
is a scripting language that makes it possible for active assays to be built on top of the Sophie multimedia editing environment.

The Lively Kernel~\cite{lively} is a Smalltalk-like programming environment that operates inside the web browser.
Its mechanism for enabling users to share their projects was inspired by our JavaScript Workspace implementation.

%------------------------------------------------------------------------
%\Section{Future work}

%------------------------------------------------------------------------
\Section{Conclusion and Future Work}

We have briefly discussed the concept of Active Essays, and their
implementation as Internet applications. Quite a few prototypes have been
developed over the past years. Based on our experiments, we have 
developed Chalkboard as an Active Essay web application using a 
normal web browser and a
WebDAV server.

To allow collaboration between users, we are considering more sophisticated
extensions to Chalkboard:

\begin{itemize}
%------------------------------------------------------------------------
\item \textbf{Versioning}

%% For a Wiki, it is natural to allow anyone to edit the text. But this
%% can be a problem for both authors and readers.

The most effective way to learn from content in Chalkboard is not only
following the author's intention, but also modifying minor parts of
the project to see how it effects the result. Sometimes a reader might
want to save for future use a project that is halfway modified, but not
want to break the original project.  In this case, keeping on the 
server versions for each user
independently is useful.

%% To realize this feature, integration with a version control system
%% (such as Subversion) is needed.

%------------------------------------------------------------------------
\item \textbf{Guidance}

Some projects in Chalkboard offer the reader a chance to follow step by step
instruction, as a in tutorial. In this case, it is desirable to keep
track of the reader's behavior and record an error when some problem
occurs.  

%% The current version of Chalkboard checks only for JavaScript
%% errors, but we would also like to detect user-defined semantic
%% errors.
\end{itemize}

\Section{Acknowledgments}

We owe Alan Kay thanks for his encouragement. The layout design of
Chalkboard is based on his idea of how to teach students
the basic ideas of computer science. Scott Wallace and Yoshiki Ohshima
often have joined our discussions. And we would like to express thanks
for the valuable insights that Kim Rose, Ian Piumarta, Bert
Freudenberg, Hesam Samimi, and other colleagues have given us.

%-------------------------------------------------------------------------


\bibliographystyle{latex8}
\bibliography{chalkboard}

\end{document}