[Squeakland] Squeak 'non-starter' in U.K. schools?

Wed Jul 9 15:50:51 PDT 2003

Hi Darius --

Two things worth checking out here.

First, is "The Analyst" done in the early 80s by Xerox EOS in 
Pasadena in Smalltalk (originally for the CIA) but then sold as a 
product. Its main feature is just as you suggest: a spreadsheet 
composed of views of Smalltalk objects - it was quite nice and very 
powerful (and probably still exists somewhere).

Second, is "Agentsheets" done at the U of Colorado over the last few 
years. This is a pluggable cell spreadsheet system with complete 
objects as cells done for children.

There are strengths and weaknesses with this view of enduser 
computing. Some of the strengths are obvious, but can you spot the 
weaknesses?

Cheers,

Alan

-----

At 11:07 AM -0700 7/9/03, Darius Clarke wrote:
>Hi Ned,
>
>Thanks for your interest.
>
>I have been contemplating Squeak as a "programming system for
>non-experts" for the past year for use in after-school Computer
>Clubhouse or classroom environments. (I don't know what Andreas has done
>with "Tweak" in this direction or what the "Scratch" project is doing.)
>
>It strikes me that an eToy or Fabrik tile-based approach can be
>substantially improved by superimposing on it a spreadsheet-like
>framework, something like an editable grid where the columns are not
>fixed. The spreadsheet framework represents in the interface itself the
>Smalltalk principle of "everything visible, searchable, and reference by
>its name" to the non-expert while simultaneously presenting an order,
>and an assumption of multiple views off a common data store.
>
>My suggestion draws from the cognitive psychology principles found in
>Jef Raskin's "The Humane Interface" and my experience as an undergrad
>conducting experiments exploring the linear thinking that most people
>exhibit vs. network systems thinking (based on Piaget's psychological
>models). Considering the difference in an programming environment can
>help the non-expert grow from liner thinking into network thinking using
>the GUI framework as a crutch.
>
>Cells are known to have properties just as classes. The cell/class
>properties can be pivoted into view when the non-expert needs them and
>are otherwise collapsed from the view when not needed. This also implies
>the importance of the Outliner as a view of the same data.
>
>Just as the natural Smalltalk data structure for collecting data the
>collection class hierarchy of list classes, the natural display
>structure of the spreadsheet is the list. This also shows how lists help
>preview the debugging with Unit Tests.
>
>HttpUnit http://httpunit.sourceforge.net/doc/cookbook.html
>Cactus http://jakarta.apache.org/cactus/index.html
>
>The visual grid for data entry can allow the non-expert to create a
>visual list of content before assigning the list to a specific class
>thereby delaying until ready the inheriting of the methods to work on
>the list.
>
>A spreadsheet can syntactically parse and highlight source code just
>like Squeak's "tile" view in the System Browser. Each tile now being a
>cell in the spreadsheet. Notice how Squeak's "tile" view in the System
>Browser preserves the hierarchical nature of the data. The grid format
>would need to preserve the same.
>
>I suggest that users of PC GUI's functionality suggest three distinct
>modes or planes of display use. An ideal user interface could have two
>or more full screen planes to represent the difference between
>text-only-plane information and the exploring/feedback-graphical-plane
>(similar to how Squeak projects are each a full screen plane). I'd allow
>the two plane to interact with each other, including having a whole in
>one plane to reveal specific content in the other, alpha blending, and
>sharing links to the same content. The insertion point would be unique
>to either one plane or the other while command keys apply to both. One
>can have pre-defined templates that reveal part of a text plane grid
>superimposed over the graphical plane such as how game developers make a
>heads-up-display (HUD) superimposed over the 2D or 3D graphical scene.
>They would share the same keyboard input. This takes advantage of TeX
>type functionality.
>
>Text doesn't shrink very well on an CRT, and even worse on LCD, for
>rapid visual recognition due to fixed pixel size. Also bright colors and
>complex patterns have a detrimental effect. Therefore, almost all text
>should be kept on the plane displayed on the surface of the display.
>This should have no z-buffer. Use grid placement such as web pages to
>separate and group content. Since the keyboard is the quickest content
>creation device, this first, display-surface plane would mostly function
>for searching, grouping, prioritizing, content creation and some
>establishing relationships between content.
>
>The second plane would make use of all the graphic manipulation that
>Morphic provides.
>
>This could be extended by adding a third 3D plane for simulations and
>storytelling about a process.
>
>I'd abandon the common row/column ($AC$12) naming convention of
>spreadsheets for a new one similar to Excel's named cell ranges which
>can address specific cells based on offset addressing.
>
>The advantages such a grid format has over the window layers that
>Morphic provides is
>* the reduction of occlusion
>* the sense that whatever one needs to find is either above or below the
>current focus
>* less distraction of one's attention to manage the windows/icons in the
>interface
>* one doesn't need to bother about where a value appears and what it
>looks like if that degree of fiddling is not needed, it's in the grid
>_somewhere_ and can always be found by searching
>* outlining and indention can easily be added to the grid model
>* like outlines, grids can be collapsed to only show a row with just the
>view's name or collection's name or other summary representation,
>Morphs are more sensitive to where the minimized title bar can be found
>and what will be covered when brought into view
>* as more fields are created rows can be added or filters applied by
>"filling in the blank" or inserting a column/row; contrasting the
>exponentially increasing time to adjust
>eToy-tiles/connected-graphs/connectors or add more pages to make more
>white space
>* tool bar buttons can just be cells in the grid too
>
>Graphics are always aligned by a grid of Cartesian coordinates as well.
>Hiding links of grid to remove "bars of a jail" feeling.
>Music scales on grid. How would one represent music theory?
>Midi composition & Video editing is done on grids.
>New rows below appended below all prior content build on and easily link
>to and reference back up to prior content cells above.
>Goals of the environment should be included as a part of the
>environment.
>
>Cheers,
>Darius
>
>
>
>
>
>-----Original Message-----
>From: Ned Konz [mailto:ned at bike-nomad.com]
>Sent: Wednesday, July 09, 2003 08:03 AM
>To: Darius Clarke; Alan Kay; Squeakland; Jim Ford
>Cc: Kim Rose
>Subject: Re: [Squeakland] Squeak 'non-starter' in U.K. schools?
>
>
>On Wednesday 09 July 2003 12:57 am, Darius Clarke wrote:
>
>>  I believe that Squeak/eToys UI severely underutilize lists and
>>  outlines as essential tools for Watching
>
>[snip]
>
>>  But this could be easily rectified. ( I just need a little more
>time.)
>
>This is an interesting topic to me. I've written a (text) outliner
>that I use all the time <http://bike-nomad.com/vim/vimoutliner.html>
>and have found it really useful.
>
>And I'm also working with the Tablet PC and Squeak, in conjunction
>with my Connectors framework for Squeak.
>
>One of the "sample apps" I'm doing is a quick
>brainstorming/concept-mapping tool using ink (and/or recognized or
>keyboarded text) and Connectors.
>
>Once you have a bunch of items and can indicate some structure between
>them (with Connectors, we draw lines between the items), you can
>present that structure in different ways.
>
>For instance, it can be turned into an outline (though of course a
>typical outline (without aliases) is a tree structure rather than a
>general graph like you can draw.
>
>And an outline can be turned back into a shapes-and-lines graph
>representation easily.
>
>I'm curious as to what you think we could (or should) do with outlines
>(and connected graphs, and ink, and gestures) in Squeak.
>
>Thanks,
>--
>Ned Konz
>http://bike-nomad.com
>GPG key ID: BEEA7EFE
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>***********************************************************************************
>This transmission contains information which may be legally 
>privileged, proprietary in nature, or otherwise protected by law 
>from disclosure, and is intended only for the use of the 
>addressee(s) named above. If you are not the addressee, or the 
>person responsible for delivering this to the addressee(s), you are 
>hereby notified that reading, copying, or distributing this 
>transmission is prohibited. If you have received this transmission 
>in error, please telephone us immediately at 818-407-1400 and mail 
>the transmission back to us at the above address.
>
>This footnote also confirms that this email message has been swept by
>MIMEsweeper for the presence of computer viruses.
>***********************************************************************************
>
>
>_______________________________________________
>Squeakland mailing list
>Squeakland at squeakland.org
>http://squeakland.org/mailman/listinfo/squeakland

-- 