At 6:07 PM +0100 2/13/99, Stefan Matthias Aust wrote:
>>Agreed that stand-alone applications require some doing, particularly
>>if they have to interact in a "traditional" manner.  That will come
>>in time -- when there is meaningful and actual demand or need.
>>That's the beauty of open source.
>
>And that's exactly the only reason I started to respond to this thread: to
>determine what would be needed and to find out how we can add this to Squeak.


I'm not sure I agree.  I'm currently considering creating two "standalone"
applications with Squeak in the next few months:
- A SqueakPages (or MuSwiki) browser: An image with Scamper open, a button
(or maybe the Parts Bin) for creating new SqueakPages, maybe a FileList for
finding/importing JPEGs/GIFs, and some tools relevant to the audience I'm
aiming at (e.g., for EE's, the RecordingControls and WaveEditor, and maybe
even MathMorphs).
- A JukeBox Tool: For our cooperative radio, the JukeBoxMorph for
controlling the playlist selection, a RecordingControls (tweaked to upload
sounds to the JukeBox site), and maybe a FileList for trying/exploring
sounds/MIDI-files.

In both of these cases, I plan to set up an image and release it (detached
from source/changes) with appropriate VMs available.  I don't think lack of
windows is a problem.  Rather, I'd like to explore the Morphic-style,
few-windows interface, and that's a plus.  I don't think windows make a
usable interface.  I firmly believe that a good Morphic interface is just
as usable.  People are willing to try an innovative interface.  In my
opinion, the weakest part of my Palm Pilot's interface is the scrollbar and
menubar.

The problem I'm more interested in is what it means to have "multiple
applications" in a Morphic world.  How do I support people who want to run
BOTH the JukeBox, and the SqueakPages browser?  My current thinking is to
distribute the SAME image, just with different morphs open.  Then, when
they ask, I teach them how to open up new morphs, and use that as a lead-in
to programming their own space.

At 12:13 PM +0100 2/13/99, Stefan Matthias Aust wrote:
>And this is what I call a toy.  This term isn't meant negative or to value
>it against other terms like tools.  A toy is just a device you'll use to
>play or explore.  It's self-centric and exist only for this purpose.   A
>tool on the other hand is created with a special goal in mind, it's a
>helper-device to achieve this goal.

"Toy" does have negative connotations, but I do agree that Squeak has the
positive characteristics of a good "toy": It's "hard fun," it stretches
one's thinking, and it encourages play.  We've been having a battle in our
department about the value of "toy problems" in CS, and I recently sent out
the below message to the faculty on the undergraduate curriculum committee
that relates Squeak and the issue of toy problems.  I think it's relevant
to this discussion.

Date: Wed, 20 Jan 1999 10:02:39 -0500 (EST)
From: Mark Guzdial <guzdial at cc.gatech.edu>
Subject: A Vote for "Toy" Problems

Last year, when we were reworking the semester curriculum, we had a long
discussion about whether to focus the entire curriculum on
industry-sponsored projects: Junior-level students doing the coding,
senior-level students leading the teams and designing the systems.  We
debated the value of "toy" problems versus "real" problems, where real
problems have a real customer, real requirements, and a real timeline. The
argument was that only "real" problems motivate students to learn, where
"toy" problems are, well, just toys.

Yesterday, I had an experience that put more firmly in the camp of those
who see the value of "toy" problems.

In CS2390, where we're using Squeak, I occasionally demonstrate interesting
research projects in Squeak, both from Tech and elsewhere.  Yesterday, I
demonstrated a really amazing new UI from Argentina.
The folks at UBA are re-doing their whole math curriculum to
use Squeak, and they've developed a new look-and-feel that is very
innovative.  (I've demoed it to a few of you, and I'd be happy to show it
to others.)  No windows, direct representation for all computational and
mathematical objects, drag-and-drop to create new expressions.

The result?  Enormous laughter.  Students were literally rolling out of
their seats, they were laughing so hard.  I was surprised.  I asked out
loud, "Why is this funny?" but no one answered.  I finished the demo and
the class. Afterwards, a few students came up to explain it to me.  "Nobody
would use this seriously, would they?  I mean it's so cute.  It's a toy!"

Which is amazingly similar to what people said when the first windowing
systems came out.

That's when I realized one of our other jobs as University faculty.  We're
supposed to be the ones pointing out alternative ways of doing things,
options not yet explored, and even critiquing current tools and practices.
Having our students work on real problems for real corporations will help
them to learn the current tools and practices. But that's not going to help
them get the radical and outrageous ideas that will give them insight into
what computing might yet do.  That's part of our job, too -- to be
questioning and suggesting, and encouraging our students to do the same.
This isn't an issue of "preparing them for Industry" vs. "preparing them
for Grad School."  Rather, it's an issue of preparing them to be
worker-bees vs. preparing them to be leaders who are looking for and
creating the next great thing.

Mark


--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html