Introduction to the ScienceWare Classifier

Eric M. Carter

Anthony J. Hornof+

The University of Michigan, Artificial Intelligence Laboratory, 1101 Beal Avenue,

Ann Arbor, Michigan 48109-2122, (313) 763-1043,



1.0 Introduction

This paper is intended to serve as an introduction to the Classifier for both the observer and the programmer. The pedagogical goal of the Classifier is “to deliver content about the objects and content about the process of classifying.” That is, the idea behind the Classifier is that the user builds a hierarchical tree based on an ordering of the questions that the user selects.

1.1 What is the need? [1]

As part of learning biology, high school students study classification keys that resemble Linnaeus's taxonomic system (kingdom/phylum/etc.). Studying these classification keys, students learn about objects (such as insects, minerals, cloud formations, etc.), relationships among the objects, and the scientific process of classification. While building them, students exercise and develop cognitive skills: observing and describing individual objects, identifying similarities and differences among objects, and grouping objects into hierarchies of concepts.

Most students study classification keys on paper and if the student builds a classification tree on their own, it is built on paper. The problem with building classification keys on paper is that it does not encourage students to change previously asked questions, to try different ordering of questions, or to link multimedia data (video, computer images, etc.) collected by the students themselves to the classification tree. Further, paper classification trees do not keep the student informed of the process of what they have already accomplished and what remains to be done. Not only does the paper and pencil method fall short, but currently available educational software fails to fulfill the needed functionality for classifying objects.

1.2 What does the Classifier do?

In the ScienceWare classroom, the Classifier will enable students to build computer-based classification keys to classify objects depicted in multiple media, including computer images, text, video clippings, sounds, etc. Students will be able to organize and view the objects to help themselves think about the objects while they decide what questions to ask and what answer to give for each question. They will be able to view an interactive depiction of the fully or partially-constructed classification key at any time, return to and change a question asked earlier in the key and view the new key structure instantly. Students will be able to load and modify previously saved classification keys as well as create new keys.

But the Classifier will do more than enable students to quickly design, build, reconstruct, and reference keys of their own — it will reinforce the fundamentally important concepts about classification as a scientific tool. We are designing and building the software so that it is easy to use and will therefore keep students focused on the cognitive tasks required to build a classification key rather than computer-related tasks. Doing so, we hope to best support the teaching goals of a project-based science curriculum.


+ Anthony J. Hornof was a member of the Hi-C Research Group during the design and implementation of both the SuperCard and the original SmallTalk versions.

[1] The information in this section is primarily from the file “necc 94 blurb”


2.0 History of the Classifier

The Classifier was originally prototyped in Apple's HyperCard. After further evaluation, SuperCard was believed to have more functionality than HyperCard. The original design phase started in the fall of 1993. By the end of spring 1994, the Classifier had been introduced into the classroom. Then, during the summer of 1994, the Classifier was moved over into the SmallTalk Agents (STA) environment and has since been updated into its current state.

2.1 SuperCard Classifier [1]

The idea behind the Classifier is that the user builds a hierarchical tree based on an ordering of the questions that the user selects. For now, we have the user entering their questions and answers about some things into a chart and then building the “tree” from that chart.

The original SuperCard version of the Classifier was introduced into the classroom at Community High School at the end of March 1994. For some introduction suggestions, see Appendix B.

Two students were originally studied, and here are some comments on the introduction.

“Our student observations on March 23rd with Peter and March 25th with Brenna indicate that the Classifier effectively supports students building classification keys. The students grasped how the information in the different views related to the task. The students understood the functionality contained within each button and how this functionality is coupled to the important steps in building a classification key. Both students completed a key of seven objects in about twenty minutes with minimal assistance after receiving a five-minute tutorial.

Our observations suggest that the design of the software supports the task of building a key. ...

We also have reason to believe that the software will support teachers teaching students about classification in that 1) the software reinforces the fundamentally important steps and concept in classifying objects (for example, the sets of objects to compare contain successively fewer objects) and 2) the software correctly carries their previous questions and answers forward through the process. (The second point may seem trivial, but it is important. Information re-appears in different screens. Since it is consistent with the previous view, the student can say `yes, i see why it looks like this' and even start to anticipate what the next view will look like.)”

Here are a couple of comments made by the students:

“It was pretty easy to use.... One of the hardest things, it's not as much the software as just thinking up the good questions to use to make it easy to classify the stuff.” Peter

When asked, “What is classifying?”, Brenna responded:

“Breaking them down so that they each have their own individual characteristic, instead of referring to all of them as `creatures.' they each have their own individual characteristic that makes them separate from the other ones.”

The original version had several major shortcomings. The first and most important was the inability of the Classifier to classify more than seven objects. Even in the early stages of the program, we realize one of our future bottlenecks — To classify more than seven objects, the students will have to scroll to see questions, answers or objects. Further, We will need to determine what side-by-side information is required for students to make important classification decisions every step of the way.

Some other interesting points on the initial deployment into the classroom were comments the students made:

• Peter wrestled out-loud with what constitutes a good question.

• Students are talking about their cognitive processes and the technology together and the data group should find that useful.

• How we introduce the software (whether or not we take them through building a miniature key or not) makes a difference as to whether or not people understand how the software is organizing the process of classification.

• People referred to the “Key View” screen as “the key” but not to the “Chart View” as the chart. We need a better name for the “Chart View.”

• Without us pointing it out, Peter grasped the generality of the tool: “It's kind of neat the way you can classify just anything.... We just did these pictures and then we did the bugs but I mean really you can classify just any object or any thing.”

• We asked Peter “Do you think you could have done it as easily without the software?” He replied “I don't think so because it, like, has the chart that helps a lot. Because then you take all of them and you ask one question and then you say yes or no to that question on all the things. You need something to say that. If you had just come in and said `make a classification key' I probably wouldn't know how to do that very well.”

• We get a lot of mileage out of making our interface as Macintosh-like as possible but the

little inconsistencies do show up (such as not bolding the object buttons or using the Chicago font in the chart view).

At the end of the school year, it was decided that rather than trying to improve the SuperCard version it was more important to totally overhaul the current version. This belief comes from several different reasons:

1. Any software modifications that we propose as a result of our usability testing would be modifications to the existing SuperCard code. SuperCard has a very limited tool kit, so if we continue modifying the SuperCard code, we would be limited by the widgets available. Any major modification to the existing SuperCard code would only make it slower and the usability modifications less usable. Though a new version of SuperCard would eventually be released, these features were not on the list of features.

2. Problems with the introduction in the classroom limits the usefulness of the data we have already collected. Detailed analysis of the existing software would require additional user testing but a) there are already enough big and obvious shortcomings with the software that we can attack without detailed analysis and b) the currently available test subjects are already familiar with the software so we won't have the chance to test the software in a live classroom with curriculum until the fall.

3. In addition to the existing functionality, we will attempt to address the three major, obvious shortcomings of the software that we observed in the classroom and heard from the teachers: 1) that the classroom version was limited to seven objects, 2) that the key view is very difficult to understand, and 3) that there are no thumbnails to keep the student informed of and interested in the objects they are comparing.

At the beginning of the summer of 1994, the design of the STA Classifier began. The main goal was to ”Keep what worked.” The main features that worked in the classroom version:

The Chart View

Students immediately understood the concept of rows for questions and columns for objects and the intersection of a row and column as being the answer to a specific question for a specific object. Students used the Chart View very effectively:

• to compose, compare and keep track of questions,

• to track their progress in the classification task (more on this later),

• as a lab notebook.

Graying Out

Graying out objects that the students did not need to consider at the moment served well to keep the students focused on a subset of objects, but it only served marginally well at helping students monitor their progress because the graying out served two purposes: hiding objects that are not part of a particular branch of a tree as well as objects that are fully classified. Several times, students asked for clarification between these two and it was not always given clearly by the teachers and researchers (including myself). We will keep the graying out but in two shades, a lighter shade for objects on another branch of the tree and a darker shade for objects fully classified. This way, the student only has to consider the objects with no shading and can use the darker shading as feedback along the way of fully classifying all of the objects.

Other features that worked:

• Navigating with the "Tab" Key

• Reinforcing the steps required for classification.

• The simplicity of the chart view is a plus.

• That the students could ask and answer questions one at a time or en Mac.

• Highlighting the current cell kept the student informed of which object and question they were focusing on at the time.

• The software does guide the student through the process of building a key.

The other half of the goal was “Replace what did not work.” Aspects of the software that fell short in the classroom included, as mentioned above:



Key View

The Key View did not succeed as an artifact should at furnishing the students with a representation of their classification scheme. The Key View does not communicate what is relevant and hide what is irrelevant. Shari has shown me a tree viewer object that comes with Smalltalk Agents that, if we can modify to our needs, could vastly improve the current Key View. Shari also believes that it would be possible, with some hacking, to incorporate thumbnails into the existing tree viewer object.

Proposed new Key View

7-Object Limitation

The teachers first protested, then adapted to this limitation. It not only affected but limited the curriculum that they developed around the software.

Needs Thumbnails

The motivational limitations of not having a visually informative and striking interface cannot be measured. But when we tried out the software on the teachers, Liz protested quite strongly about having to continually click on buttons to look at objects and that she could not even look at tiny pictures side-by-side. During our initial user observations with the students, students had to click many times on the objects to view them to make their comparisons.

Proposed new Chart View with thumbnails

We discussed many different options for displaying thumbnails in the Chart View and

decided that this arrangement would provide

the clearest delivery of the information. We could try others later, but believe this would the best to try first. Shari points out that Smalltalk Agents has built in thumb-nailing capabilities that would make such a layout reasonably straightforward to implement.

Other features that didn't work:

• Having to click each time to look at pictures.

• The students did not seem to understand the concept that all of the "yes objects" were behind one "Further Classify" button and all of the "no objects" behind another.

• The current cell can end up in the grayed- out area.

• Numbers on chart view corresponding to key line number where question was used.


[1] See the file, ”report - 3/29/94”, for more information



2.2 Original SmallTalk Classifier [1] [2]

The version of the Classifier at the end of March 1994 had three major shortcomings:

• the classroom version was limited to seven objects

• the key view is very difficult to understand

• there are no thumbnails to keep the student informed of and interested in the objects they are comparing

It was decided that the only way to overcome these shortcoming was to change to a different programming language. The logical language was SmallTalk. The reason for this is that ScienceWare is intended to be a suite of tools. As such, they will need to interact with each other — the easiest way to do this is by having the separate parts written in the same language. SmallTalk Agents was that language. STA also, upon initial review, would allow the Classifier to be elevated to a new level. The original STA version put most of the basic functionality that was in the SuperCard version in place and also addressed the second shortcoming above by introducing a Tree View.

The main features in the SuperCard version that were not originally brought over were: The graying out of objects that are classified, Easy-to-use buttons such as the “use” buttons next to the questions (though the new Tree View opens the door for many creative button and selection options).

For the records, the STA environment version used to develop the initial STA version was QKS's version 1.1. The SuperCard/SuperEdit environment was Aldus SuperCard version 1.6.

For a more in depth explanation as to how to use the original version of the Classifier see the document “Programmer's Documentation.”

Here are some technical details of the original STA version. Here are the global variables:

theModule: SWClassifierModule, the STA "module" that you are running.

theTreeWindow: Instance of SWCTreeView, the window that contains the hierarchical tree

theTree: Instance of SWCTreeView, perhaps identical to theTreeWindow. Probably redundant.

theRoot: Instance of SWCNode, used by the tree-drawing methods of the super-classes CETreeView and HTree.

theChartView: Instance of SWClassifierWindow, the window that holds the chart.

theThings: List of instances of SWCThing's, the order of which dictates the order in the Chart View.

theQuestions: List of instances of SWCQuestion's, the order of which dictates the order in the Chart View.

theSelectedChartCell: Instance of SWCThing if the selected cell is a thing, instance of SWCQuestion if the selected cell is a question, and a 2-item list of an instance of a SWCThing and SWCQuestion if the selected cell is an answer.

Here are the class instance variables:

SWCNode variables:

YorN: the character (now "Y" or "N") that is written to the left of the node in the Chart view.

pretext: text that appears before the text in the node, currently only used to put "Classify:" in the top node the first time.

yesNode, noNode, and parentNode: instances of SWCNode that define the structure of the tree.

SWCQuestion variables:

blankThings, yesThings, noThings: Lists of instances of SWCThing's, depending on the answer each thing has for this question.

SWCThing variables:

yesQs, noQs: Lists of instances of SWCQuestion's, depending on the answer that this thing has for each question. (If the thing has a blank for a question, that question would be in neither list.)

On the next page is a graphical view of the class structure for the Classifier.


[1] See the file, ”STA Proposal”, for more information

[2] See the file, ”Programmer's Document”, for more information



2.3 Current STA version

As soon as I was able to make a Stand-Alone version of the Classifier, I registered our Creator types with Apple. Here are some answers to frequently asked registration questions. [1]

Q What does it mean to register a Macintosh Creator or File type with Apple?

A Registering a Creator type with Apple ensures that it is unique, meaning it is not in use by more than one software application.

Q Must Creator and File types be unique?

A Creator types must be unique. File types need not be unique; nor must Resource types. And although we do not register Resource or File types, we do list them in our files for reference.

Q Who registers Macintosh and Apple // Creator types?

A Both Macintosh and Apple // Creator file types are registered by Apple's Developer Support Center.

Q Must a developer be a member of the Associate or Partner program to be eligible for this service?

A No. Apple encourages all developers, even those not in our programs, to register unique Creator and File types with us. This is a service that helps everyone!

Q Are there any Creator types developers can't use?

A Apple reserves all Creator and File types consisting of entirely lower case letters. And of course, any Creator type already in use cannot be used by another developer. First come, first served.

Q How can changes and updates be made to previously-registered products?

A If you need to make a change to a product we've already registered for you, please don't use the Registrations stack. Instead, please simply send an AppleLink message to DEVSUPORT providing your name, your full company name, daytime phone number, and the name of the product whose registered information you want to revise. Include any changes you want made to that record. A revised confirmation will be sent to you within 2 business days.


[1] See the file, ”Read Me - C/F Registrations”, for more information



Here is the response to my request for a Creator type [1]:

From DEVSUPPORT@AppleLink.Apple.COM

Date: 21 Mar 95 00:21 GMT

From: Developer Support Center <DEVSUPPORT@AppleLink.Apple.COM>


Subject: Registration Confirmation

Date of Original Request: Monday, March 20, 1995

Dear Eric,

Thank you for using the HyperCard stack to register your unique creator and file type IDs. We appreciate your continued product development and support of Apple Computer!

The Developer Support Center has reviewed your Creator identification request, and has registered the following unique product information:


Technical Contact: Eric Carter

Application Name: ScienceWare Classifier

Application Signature: SWCL

File Type: SWCF

This letter serves as your confirmation and proof of registration. Please keep it on file. Additionally, you should review the information for accuracy. If

you locate discrepancies in our data, please contact Developer Support with your corrections.

Thanks for supporting Apple!

Sincerely yours,

Jill Dinnebier

Registrations Administrator

Apple Computer, Inc.

Developer Support Center

Another major improvement after registering was to move to using picture buttons rather than cells for the user to enter answers to questions. This removes the need for the student to type in `y' or `n' and also makes the software more intuitive.

Here are the pictures [2]:

The reason for the different style is that the when the pictures are scaled, the circumscribed circles and strikes come outside of the box, like above. With the circles and strikes drawn over the box, scaling looks natural.

Other improvements to the Classifier:

• Easy-to-use buttons, such as the “use” button next to questions — this was solved by allowing the user to select and remove questions through pull down menus associated with the nodes in the Tree View.

• Allow user to move around the Chart View with the Tab key

• Get the chart to scroll such that the thing and question headings stay on screen at all times

Currently, this is unnecessary since we are only allowing the user a total of 24 objects — which will fit on the screen of a PowerBook.

• Make SWClassifier a stand-alone

• Allow the users to start anew

• After discovering an unnamed object let the students type in name and have tree update

• Upon changing an object's or a question's text, the information is automatically updated in the Tree View.

• Create icon for the Classifier

• When the user selects a node in the Tree View, the respective objects or question should become Hilighted.

2.4 Further Improvements to STA Version

There are many ideas for improvement of the current Classifier. Here is a list of suggested changes in order of importance [3].

• The questions that are currently in use should be grayed out in the pull-down menu

This would keep the students from wasting valuable time and energy. It also helps the user keep track of where they are in a bigger chart.

• Allow the user to Save and load both the Chart and Tree View

Currently, we only save the chart information.

• Make windows always open/easy of switching (Make Tree View a window so the user can switch between the Tree View and Chart View using the menu — remove resizable on chart view)[The windows are not closeable.]

When working correctly, to switch between windows, you can either click on the window you would like in front or you can select the window's name in the Views menu to bring it to the front.

• When the user changes an answer, the Tree View should dynamically update


[1] The information in this section is primarily from the file “Registration - Classifier“

[2] These pictures are contained in “YandN Pictures”

[3]The information in this section primarily comes from the file ”classifier rebuttal”



This helps keep the user aware of updates.

• After changing no to blank box, prompt user “Do you want to change this box to: cancel/remove questions/change to yes?”

This is necessary since changing to a blank could screw up the entire tree.

• Allow the user to add and remove both objects and questions

This is nice for adding an object after the fact.

• When adding a new object, put up a dialog box for all questions that are in use (traverse down the tree)

This simply requires adding a variable to SWQuestion called inUse and using it to traverse with.

• Make sure to highlight new selected node before creating pull-down menu

So that the pull-down menu (pm) is always attached to the correct node.

• Correctly place pull-down menu — so that it is on top of the “Tree View”

It's confusing when the pm is way on the other side of the screen.

• Do not allow objects of the same name

Simple, but a nice feature.

• Move first Question Cell down one pixel (make it one pixel bigger)

Jonathan thinks it would look better.

• If cancel in first window, quit application

It seems the right way to go.

• Allow the user to double-click on a node to collapse or expand it.

This would be VERY intuitive.

• Offer the user a choice of rows and columns on start up

After the add row/column works, this would be nice.

• Put `Object a and Object b' don't have an answer to `Question b'

It helps tell the user what they are doing wrong without a manual.

• Yes/No's of different color?

Might be nice if the Y's were Green and the N's red.

• Allow user to move around the Chart View with arrow keys

The next step after the tab key.

• Look in to feasibility of movable rows/columns

Make this as Excel-like as possible

• Handle Option-title bar

So the user can't press option and mouse key on the title-bar.

• Gray out objects that are uniquely classified (they are leaf nodes). Possibly adding sound effects upon doing this (something to make it flashy).

I'm not sure if this is absolutely necessary.

• Vertical text - enter horizontal

Makes it cleaner.

• Put thumbnails of objects into Chart View (or Tree View)

Something we've always wanted

• Input user data/thumbnails

The teachers want it all.

• Undo button

Mike suggested it.

7.0 Past bottlenecks with the software

The biggest problem to date with creating the STA version was trying to make it stand alone. Our main problem was that while we making the software stand-alone, we did not realize that STA produced an output error log. This log contains vital information during compilation. One very important note. The QKS people are very responsive and very courteous. If you are in need of serious help, send them e-mail at

8.0 Potential Bottlenecks with the software

I feel that attempting to make the “Tree View” and actual window could pose to be as much as a problem as was had with making the project a stand-alone. To this date, there have been attempts at switching the superclass of the “Tree View,” reworking the current class, and switching the classes category — all to no avail. Maybe the next thing to do is request help from QKS.

The other potential bottleneck is displaying more than X objects. This is limited by the size of a PowerBook screen. The teachers suggested looking at a program called Grade Book for ideas. I would ask them for a copy of that program — as an initial starting point for this problem.

9.0 Conclusion

The Classifier is a tool to help students learn about objects through finding ways in which to separate them. As a computer tool, the Classifier has come a long way — it is by far done, but has made a step in the right direction. This is the ScienceWare Classifier. I hope you like it. If you have any question for me, feel free to call Eric Carter at

612-884-0121 or e-mail at


Appendix A - Classifier Hand-out

Introduction: In this activity you will study and compare some of the characteristics of common stream insects and crustaceans using a software tool called the Classifier. You will be asking yourself questions about the different creatures on the Stream Insects & Crustaceans sheet. Your goal is to divide them into categories until each one is uniquely identified from the rest by its distinguishing characteristics. This process is called classifying.

1. Open the Classifier. When the dialog box appears, asking “How many objects are you classifying?”, type 9. The Chart View will appear on the screen. In the columns for “Objects”, enter the names of all the creatures on the first page of the Stream Insects & Crustaceans sheet.

2. Read through the information on the Stream Insects & Crustaceans sheet. You are looking for a way to separate the creatures on this list into two categories. What characteristics come to mind? One possibility is size. The question, “Can it be longer than one inch?” would be a good way of classifying these creatures. Enter “> 1 inch?” into the space labeled “Question 1”. To enter the appropriate answer in the corresponding box for each creature, click on the box once for “Yes” (a green circle will appear) or twice for “No” (a red x will appear) [If you make a mistake, clicking a third time will clear the box].

3. Now, let's apply this question. Go to the Tree View screen of the Classifier. While holding down the Command (open-apple) key, click on the list of object names in the Tree View window. A pull-down menu will appear with a list of your questions. Select “> 1 inch?” Your tree should now look like the one below.

4. Continue looking for other ways to separate the different creatures. Another possibility is the presence or absence of gills (gill tufts). Enter the question, “Gills?” into the space for Question 2. Now, enter the appropriate answers in the corresponding boxes based on the information on the sheet.

5. Some creatures have many legs while others have none. Enter the question, “> 6 legs?” into the space for Question 3. Then, enter the appropriate answers.


6. Continue asking questions to separate the creatures. Questions such as: “Does it have a tail?” or “Does it live in a shell?”, would help to further sort the creatures. Enter your questions and answers in the chart.

7. Return to the Tree View and apply the questions that you have entered.

8. Have the creatures all been sorted out? If not, then you must return to the chart view to create a question that will separate the remaining creatures. Take a look at the Chart View, to the right. You'll notice that from the questions, the Water Penny and the Riffle Beetle have identical answers. So, you need a question which will uniquely identify each of them. For example, you could use the question, “Does it have antennae?”

9. Compare your tree to the tree on the left. This is just one of many possible ways to classify these organisms.

10. Now try to classify the creatures on the back of the Stream Insects & Crustaceans sheet using the techniques which you have just learned.

11. You will now use the key that you have made to identify three unknown bugs. Go to the next page for descriptions of the unknown bugs.

12. Now, pick a total of fifteen of your classmates. Come up with identifying characteristics of each person.

13. Here are the descriptions of three bugs. You do not have a picture of them, and you do not know their names. Use the classification key that you just created in the Classifier (from page 2 of the Stream Insects & Crustaceans sheet) to identify them based on the characteristics described below.

a. This creature has small antennae and is about the same size as its six legs. It does not grow to be bigger than one inch.

Bug 1 is a .

b. This creature has many legs and can be longer than 1 inch long. It does not have gills.

Bug 2 is a .

c. This creature does not have legs. It is not greater than one inch. It does not have antennae or a shell.

Bug 3 is a .


Appendix B - Introduction into Classroom [1]

Suggested classroom protocol:

• Introduce yourself and explain the purpose of the observation. Learn the names of the students in your group. Talk about the equipment in the room.

• Make it clear that we are evaluating the software and not the students and that if they have trouble with the software it is the software's fault not the students' fault.

• We will not ask the students to think out loud since we are hoping working in pairs will keep them talking to each other. But if the conversation lags, ask non-leading questions like "What are you doing now?" or "What are you going to next?" or "Why did you do that?"

• During the class time, the students' focus should be each other, the three CHS teachers, and their task, not on us. We should not be the center of attention (as if that will be possible with all the equipment, but try).

• If the students get stuck, prompt them to figure it out on their own before giving them a direct plan (unless it is a clear shortcoming of the software or a clear cognitive breakdown).

What to Video Try for the keyboard. The screen will be difficult to read, so it is not a priority. Try to get the students interacting with each other and with the objects.

•• If the software crashes or gives a funny or unexpected error, try to understand as clearly and exactly as possible what had caused the error. Then, narrate the whole episode so that the microphone and camera capture it and so the student can try to confirm that you correctly restated the problem. This will be invaluable for debugging and redesigning.

• Make sure to get the students' Classifier files ON A FLOPPY DISK at the end of the session besides however the teachers want them collected.

• If the students ever decide to clear a key and start over, ask them to save their work first. Watch for this!

Appendix 3. Helpful hints for STA [2] [3]

First are some intro. examples...

“Example - Simple Message Passing”

2 squareRoot

2 * 4

2 raisedTo: 3

1 / 3

5 i

2 - 2 i

2 + 3 * 6

2 + (3 * 6)

“Example - Checking a class”

2 class

2.0 class

(1/3) class

(2 - 2 i) class

“Example - Lists”

{10. 13. 14. 17. 18. 20} add: 44

{10. 13. 14. 17. 18. 20} includes: 13

{10. 13. 14. 17. 18. 20} includes: 15

{10. 13. 14. 17. 18. 20} at: 3

{10. 13. 14. 17. 18. 20} at: 3 put: 15

{10. 13. 14. 17. 18. 20} at: 3 insert: 15

{10. 13. 14. 17. 18. 20} collect: [:x | x * 2]

{10. 13. 14. 17. 18. 20} select: [:x | x isEven]

{10. 13. 14. 17. 18. 20} reject: [:x | x isEven]

{10. 13. 14. 17. 18. 20} detect: [:x | x >= 15]

{'January'. 'February'. 'March'. 'April'} do: [:x | Notifier prompt: x]

'Hello' includes: $o

'Hello' at: 2

'Hello' select: [:x | x isLowercase]

'Hello' detect: [:x | x >= $k]

'united states of america' asCapitalized

'united states of america' asListOfSubstrings

'united states\of\america' asListOfSubstringsDelimitedBy: $\

“Example - Blocks”

5 timesRepeat: [Speakers beep]

(10 < 20) ifTrue: [Speakers beep]

(10 < 20) ifFalse: [MenuBar flash]

(10 > 20) ifTrue: [Speakers beep] ifFalse: [MenuBar flash]

myFileName ifNil: [Speakers beep]

'Washington' ifNotNil: [Notifier prompt: 'Argument was not nil.']


[1] The information in this section primarily comes from the following files “Classroom Notes - day of” and “Classroom protocol”

[2] The information in this section is primarily from the file “Eric's STA Notes”

[3] The information in this section is primarily from the file “Smalltalk Examples.txt”

“Example - the Inspector”

1066 inspect


(1/3) inspect

Q inspect

`Hello, world!!' inspect

Q class inspect

String inspect

Now, more intense examples...

“Memory operations”

Gestalt gcMemory. 1460812

Gestalt optimalExternalHeapSize: 2000000. 2000000

“Example - code to recompile methods for both STA 1.1.4 and 1.2”

(SWClassifier values select: [:i | i isKindOf: Constructor]) do: [:c | c recompileMethods. c metaclass recompileMethods.].

(SWClassifier values select: [:i | i isKindOf: Instantiator]) do: [:c | c recompileMethods. c metaclass recompileMethods.].

“Setting a superclass of a class”

SWCTreeView metaclass setSuperclassTo: SWCCETreeView metaclass. SWCTreeView metaclass

“Removing instances (of windows)”

SWCTreeView instancesDo: [:i | i become: nil]. SWCTreeView

“Example - a way to find open windows”

SWClassifierWindow instances select: [:x | x isOpen]

“Example - creating a list”

Q := {40. currentXPosition. 80. currentXPosition + colWidth + 1.}.

“Example - creating and moving a new window”

Q := (UIWindow new bounds: {10. 10. 50. 100}) open.

Q moveTo: (0@0).

((Q closeable: true) resizeable: false) zoomable: false.

“Example - use of notifier”

Q := (Notifier prompt: 5 class).

“Example - getting data using prompt”

Q := Prompter prompt: 'How many objects are you classifying?'. 8

'sd' isLiteral. true

8 isLiteral. true

4.5 isLiteral. true

'23' asNumber. 23

'sd' asNumber. 0

“Example - using pictbutton”

Q := UIWindow new addComponent: ( (SWCPictButton new) bounds: {10. 10. 70. 70}; identifier: 'btn'); open.

“Example - who knows”

Q := (SWCTreeView new rootClass: 'Fred') renderTree.

“Example - a debugging device”

Console show: NewLine, 'Before: ', state.

“Example - Order in list”

{'ab'. 20. 30.} readLimit.

“Example - Is it the same?”

$c = 'c'

“Example - Comparison”

'Object 1' startsWith: 'Object'. true

“Example - Dictionary stuff”

Q := Dictionary new

Q at: #michigan put: 83

Q at: #indiana put: 'Unknown'

Q at: #ohio put: 195.5

Q at: #michigan

Q at: #wisconsin

Q at: #wisconsin ifAbsent: [Notifier prompt: 'Key missing.']

| pictureDictionary |

pictureDictionary := Dictionary new.

pictureDictionary at: #yes put: yesPicture.

pictureDictionary at: #no put: noPicture.

pictureDictionary at: #blank put: blankPicture.

pictureDictionary keys. {#yes. #blank. #no.}

pictureDictionary values. {"Picture" (-16838 asObjectFromWeakID). "Picture" (-2216 asObjectFromWeakID). "Picture" (-5468 asObjectFromWeakID).}

pictureDictionary at: #chris ifAbsent: [Speakers beep]. pictureDictionary at: #yes ifAbsent: [Speakers beep]. "Picture" (-16838 asObjectFromWeakID)

pictureDictionary any.

pictureDictionary associationAt: #yes. #yes ==> `"Picture" (-16838 asObjectFromWeakID)'

pictureDictionary at: #yes. "Picture" (-16838 asObjectFromWeakID)

pictureDictionary includes: #yes. false

pictureDictionary includes: -2216 asObjectFromWeakID. true

pictureDictionary includesKey: #yes. true

pictureDictionary includesKey: -2216 asObjectFromWeakID. false

pictureDictionary keyAtValue: -2216 asObjectFromWeakID. blank

pictureDictionary keyAtValue: #yes ifAbsent: [Speakers beep]. Speakers

“Example - How to make a project (sub)library”

LibraryInspector openOn: SWClassifier "LibraryInspector" (-12443 asObjectFromWeakID)

Pictures at: #stoneFly put: (-14369 asObjectFromWeakID)

(SWClassifier at: #Pictures) class Library

(SWClassifier at: #Pictures) at: #stoneFly

“Example - Pointer to module”

SWClassifierModule soleInstance

“Example - Menu item stuff”

Q := MenuBar menuAt: 'File'.

Q1 := Q at: 'New Listener'

Q1 enable: true. NMI New Listener

“Example - Lists”

Q := {'Object 1'. 'Object 5'. 'Object 4'. 'Object 3'. 'Object 2'. 'Object 10'}. {'Object 1'. 'Object 5'. 'Object 4'. 'Object 3'. 'Object 2'. 'Object 10'.}

Q asSortedList. {'Object 1'. 'Object 10'. 'Object 2'. 'Object 3'. 'Object 4'. 'Object 5'.}

Notifier prompt: 'Hello, World!'

To start up a module from a PIPO:

• Load a fresh copy of the STA v1.2 environment.

• “File In.../PIPO” the Classifier STA file.

• From the project window, set the library to “SWClassifier”.

• Evaluate “SWClassifierModule launch” in the Console window.

• Try to position the two windows so that you can see everything in both at the same time. (To do this automatically will be a future programming challenge).


+ Anthony J. Hornof was a member of the Hi-C Research Group during the design and implementation of both the SuperCard and the original SmallTalk versions.


[1] The information in this section is primarily from the file “necc 94 blurb”

[2] See the file, ”report - 3/29/94”, for more information

[3] See the file, ”STA Proposal”, for more information

[4] See the file, ”Programmer's Document”, for more information

[5] See the file, ”Read Me - C/F Registrations”, for more information

[6] The information in this section is primarily from the file “Registration - Classifier“

[7] These pictures are contained in “YandN Pictures”

[8]The information in this section primarily comes from the file ”classifier rebuttal”

[9] The information in this section primarily comes from the following files “Classroom Notes - day of” and “Classroom protocol”

[10] The information in this section is primarily from the file “Eric's STA Notes”

[11] The information in this section is primarily from the file “Smalltalk Examples.txt”

Back to hi-ce Office