Michael Swaine

But I believe that the significance of the MessagePad's handwriting deficiencies has been inflated. In my humble opinion, the main technical problems with the original Newton MessagePad, in decreasing order of importance, were:

1. There was no built-in modem. Isn't that a rather serious flaw in a so-called communication device?
2. It didn't fit in the average pocket. It just missed, but that was a big miss for a so-called portable device. Maybe everybody at Apple carries a bag, but some of us out here grew up in the Midwest and rely on our pockets.
3. It was buggy. This was less serious. Okay, it was unacceptable, but it was also predictable. This is a very new technology. This was version 1.0. There's a ROM upgrade.
4. The handwriting recognition failed to recognize handwriting often enough to make the device unusable as a meeting note-taker, which is just what any computer journalist would try to use it for if given the slightest encouragement.

Which brings me back to the question that motivated my writing a Newton app: What is a Newton good for?

Apparently not for implementing the game of Life. DDJ contributing editor David Betz described his efforts in this direction in the March 1994 issue of BYTE. He found NewtonScript grindingly slow for this application. Okay, scratch that.

For what it's worth, I'd say that the current Newton devices are well adapted to three kinds of applications:

1. Personal Information Manager (PIM) stuff. Electronic to-do lists, appointment calendars, name-and-address databases. Small apps you'd like to carry around in your pocket. (Oops. The pocket problem again.)
2. Communications. A built-in modem is still lacking, but the pager on a PCMCIA card is amazing, and the two-way cellular communication from a Newton device redefines portable computing.
3. What I think of as "tap apps"--applications that don't require much typing or writing. These apps just ask the user to tap a few buttons or menu choices, then return some brief text or illustration. Mobile kiosks, you might call them. This is not a real category, of course; it could include anything from a calculator to an expert system for medical diagnosis. But it seems like a reasonable way of thinking about the question of how to make the Newton useful, a question that would be heavy on your mind, too, if you had these receipts in front of you.

Why expert systems?

The interface seems right. Expert systems, at least those I've come across, typically take input from users in small chunks and return brief textual opinions (possibly augmented by lengthy explanations). Sounds good for a device with a small black-and-white screen.

Expert systems need not be compute-heavy apps that require heavy iron. Even a Newton ought to have the horsepower for a simple expert system. That suggests a subtle third point.

Devices like Newton could spur interest in truly simple expert systems. AI lite. Users might have quite different expectations of an expert system that can be carried in the pocket (oops, the pocket problem again) and that boots (machine and app) in four seconds or so.

Imagine using an expert system in the field on your conventional portable computer. If you have to turn on the portable, wait through its boot cycle, load the app, and take an occasional hike in the middle of using it to get an answer to a question (portable or not, you don't want to move a computer while it's running), you probably aren't going to be satisfied with a response of "Gee, I dunno."

Now picture using a handheld device that is carried in your pocket (let's imagine that Apple can crack the pocket problem) and can be consulted in a few seconds. You might shrug off a "Gee, I dunno" response more philosophically.

For some situations, it seems to me, the place where you need that expert advice is in the field, and the time when you need it is ASAP, and pretty good right now is better than excellent some time later. Small expert systems might be ideal in such situations. (You'll notice that I don't actually name any such situations, but take it on faith that there are some.)

Anyway, whether there's a market or not, I'm writing a small expert system for Newton. This month you'll see the application shell and the user interface. Next month, I'll present the inference engine and the knowledge-base structure.

A two-part presentation actually makes sense. The project as I've conceived it breaks down nicely into the front-end and back-end components: the UI and the smarts. Since the Newton Toolkit (NTK) provides an abundance of templates for user-interface development, this first part of the project is mainly an exercise in using the NTK and its templates. On the other hand, the NTK doesn't provide any templates or classes for what I'll be doing in the second half, so that'll be more an exercise in writing NewtonScript code. Just so you know, I mean an exercise for the author, not the reader. You'll be watching me learn here. Scary for all concerned.

I wanted a tool I could take with me into the woods when I go hunting for mushrooms. It didn't have to give authoritative advice on mushroom species, but it should help me decide whether it was worth throwing the latest find in the basket to take home and look up in my mushroom books. A fallible but helpful advisor.

That sounded like a good candidate for a tap app. Tap to select mushroom features like color and cap shape, tap a button to start the identification, and read off the identification in a text field.

Some mushrooms can be identified from a few features, some require more. The program should accept partial data. It should also allow refinement of the feature list: Hmm, that identification doesn't look right; let's try calling this thing red rather than brown. Or: Here's another mushroom like that last one I identified, but it has a scaly stem; I'll change just that feature and ask for another identification. And, so that I can learn which features matter in identifying different kinds of mushrooms, it should give feedback on what features it used in making its decision, but this information should be shown only on request.

It was clear that the program would need to display a hierarchy of mushroom features, since over 100 features might be relevant for some identifications. For the current version, though, I restricted it to a single screen of feature choices.

<b>(a)</b>
viewBounds.top := b.appAreaTop + 2

<b>(b)</b>
myFrame := {
  slot1 : 1000,
  frameSlot : {
    name : "David",
    game : "Life"
  },
  methodSlot : 
    fun()
      begin
        // method body;
      end
}

<b>(c)</b>
observations := {
  cap := {
    cap_surface : "",
    cap_color : "",
    cap_shape : "" },
  gills := {
    ... }
}

// Fungus -- A Mushroom Identification Program for Newton by Mike Swaine
// Fungus presents a single screen of mushroom attributes, lets the user set
// values for some or all of them, and tries to identify the mushroom based
// on these values. NB: This is a demo of NewtonScript, not a useful app.
// Its "advice" is NOT to be relied upon! The base view of the application is
// a frame named Mushrooms. It's based on the protoapp proto.
Mushrooms :=
  { viewSetupFormScript: /* executed during view creation */
      func()
      begin
        // Set view bounds relative to screen dimensions.
        local b := GetAppParams();
        self.viewBounds.top := b.appAreaTop + 2;
        self.viewBounds.left := b.appAreaLeft + 2;
        self.viewBounds.bottom := self.viewBounds.top+b.appAreaHeight-4;
        self.viewBounds.right := self.viewBounds.left+b.appAreaWidth-4;
      end,
    title: "Mushroom Field Guide",
    viewflags: 5, /* visible, clickable, etc. */
    viewFormat: 328017, /* pen, frame, etc. */
    declareSelf: 'base, /* required for base view */

    observations: /* attributes of mushroom to be identified */
      {color : "", /* all initialized to emptiness */
        size : 0,
        cap_shape : "",
        cap_surface : "",
        gill_type : "",
        gill_attachment : "",
        stem_position : "",
        stem_surface : "",
        veils : ""},

    advisor: /* the mushroom identification engine */
      func()
      begin
        // Dummy code. Could be extended to a humungous list of IF-THEN tests,
        // but plan is to replace with a simple expert system. Note: in
        // NewtonScript, all = tests on structured objects compare pointers,
        // while < and > tests compare contents. Hence variations in syntax.
        if strEqual(base.observations.color,"brown")
          AND base.observations.size > 3
          AND strEqual(base.observations.gill_type,"absent")
        then base : advise("a Bolete",1);
        else if strEqual(base.observations.color,"brown")
          AND base.observations.size <= 3
        then base : advise("an LBM (little brown mushroom)",1);
        else base : advise("too little data for a conclusion",0);
      end,

    advise: /* outputs the identification */
      func(m,c)
      begin
        setValue(MessageBox,'text,"It looks like you have" && m & ".
        \n Confidence level:" && c & ".");
      end,

    showSize: /* updates Size display to current SizeSlider value */
      func(n)
      begin
        setValue(Size,'text,n && "cm"); /* value shown as centimeters */
      end,

    _proto: protoapp, /* proto inheritance link */
  };

// Cap Shape, based on the protolabelinputline proto, is a child view of
// base view. It displays a label and an input line. Tapping the label
// shows a list of values. Tapping a value puts it in the input line.
Cap Shape :=
  { viewSetupFormScript: /* executed during view creation */
      func()
      begin
        // This should set base-relative view bounds.
        // The protolabelinputline proto that this view is based on
        // has a child view, entryLine, responsible for the input line.
        // This is how its slots are accessed:
        entryLine.viewFont := userFont10;
        entryLine.text := "";
        prevText := entryLine.text; /* save for undo */
      end,
    label: "Cap Shape", /* the label */
    labelCommands:      /* the values displayed */
      ["cylindrical", "conical", "bell", "convex", "flat", "concave"],

    textChanged: /* invoked when text in input line is changed */
      func()
      begin
        // Store user selection in slot in observations frame.
        base.observations.cap_shape := entryline.text;
        // Register this method's undo method with the system
        // so the Undo button will know what to do.
        AddUndoAction('undoTextChange,[prevText]);
      end,

    labelClick: /* invoked when user taps the label */
      func(unit)

      begin
        prevText := entryLine.text; /* save for undo */
        return nil; /* otherwise method is not passed */
      end,
    undoTextChange: /* the undo method for this method */
      func(t)
      begin
        entryLine.text := t;
        base.observations.cap_shape := entryline.text;
      end,
    _proto: protolabelinputline, /* proto inheritance link */
  };
// ...and so on. There are also frames for user input of Cap Surface, Gill
// Type, etc., but they look like this frame for Cap Shape.
// The frame(s) for input of Size, though, are a little different:
// SizeSlider, SizeLabel, and Size are views that implement a kind of slider,
// an alternative to the protolabelinputline used in Cap Shape.
// SizeSlider is based on the protoslider proto.
SizeSlider :=
  { viewSetupFormScript: /* executed during view creation */
      func()
      begin
        viewValue := 5; /* initial setting */
        / Display initial slider setting in Size view.
        base : showSize(self.viewValue);
        prevValue := viewValue; /* save for undo */
      end,

    // Slider settings are interpreted by interpolating between
    // minValue and maxValue. This app treats the result as centimeters.
    minValue: 0,
    maxValue: 24,
    changedSlider: /* invoked when slider is moved to a new position */
      func()
      begin
        // Store user selection in slot in observations frame.
        base.observations.size := viewValue;
        // Register this method's undo method with the system
        // so the Undo button will know what to do.
        AddUndoAction('undoValueChange,[prevValue]);
      end,
    trackSlider: /* invoked as slider is moved */
      func()
      begin
        // Display slider setting in Size view.
        base : showSize(self.viewValue);
      end,
    viewClickScript: /* invoked when user touches slider */
      func(unit)
      begin
        prevValue := viewValue; /* save for undo */
        return nil; /* otherwise method is not passed */
      end,
    undoValueChange: /* the undo method for this method */
      func(v)
      begin
        viewValue := v;
        base.observations.size := viewValue;
      end,
    _proto: protoslider, /* proto inheritance link */
  };
// SizeLabel, based on the protostatictext proto, labels SizeSlider.
SizeLabel :=
  { text: "Size",
    _proto: protostatictext, /* proto inheritance link */
  };
// Size displays the setting of SizeSlider numerically.
// It's based on the protostatictext proto.
Size :=
  { text: "",
    _proto: protostatictext, /* proto inheritance link */
  };
// View Size is accessible from Mushrooms.

// Advise is the button pressed to start the identification.
// It's based on the protopicturebutton proto.
Advise :=
  { icon: GetPictAsBits("Mushrooms", 1),
    buttonClickScript: /* invoked when button clicked */
      func()
      begin
        base : advisor(); /* fire up the identification engine */
      end,
    _proto: protopicturebutton, /* proto inheritance link */
  };
// Messagebox displays messages to user. Based on clParagraphView view class.
MessageBox :=
  { text: /* initial value */
      "Select the characteristics that best describe your find
      and tap the picture of the mushroom.",
    viewclass: 81,
  };
// View MessageBox is accessible from Mushrooms.

Copyright © 1994, Dr. Dobb's Journal