LearningForward

Kent Chesnut's technology in education blog.

Wow!  It’s been almost exactly a year 2 years since I posted on my adventures with Scratch on Linux (see post here). 

Well, the Scratch team at MIT has made the use of Scratch 1.4 (the latest version) on Ubuntu Linux (versions 9.04 and 9.10) much less of an adventure.  I’ve successfully followed the installation procedure on 5 Ubuntu 9.04 computers.  I have not done extensive testing on Ubuntu, but everything I’ve tried works fine.

Installer notes:

• The instructions for installing Scratch on Ubuntu are posted here.
• I did NOT use the link https://launchpad.net/+help/soyuz/ppa-sources-list.html (this is a link in the intructions).
• Open the Software Sources panel via System -> Administration -> Software Sources to access the “3rd party software sources” list.
• Although instructed to do so by the instructions, I was not able to “paste” the line
  sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 4EA7974E
  into the console.  I had to type the line in.
• When you go to the System -> Administration -> Symantec list to find Scratch to select it for install, you’ll find a formidable list to look through.  If you look through there and really can’t find Scratch or scratch (I’m sure that happened to me a couple of times), reboot the computer and then look through the list again.  Either Scratch miraculously showed up or resting for a couple of minutes while the computer rebooted improved my search capability.

Comparing Scratch on Ubuntu to my original post:

• An installer for Scratch 1.4 is available for Ubuntu 9.04 and 9.10.  This alleviates the need to install Squeak and then the WinScratch.zip file… just follow the instructions!
• A launch icon is automatically added to the Applications menu under Programming.  No need to open the terminal to start the program.
• Presentation mode works.
• Sound works (although I didn’t explicitly try the midi, so I’m not sure about that).
• The Scratch website works fine with Java installed.

Other notes:

• Edubuntu is no longer published with Ubuntu as part of the same image.  First install the standard Ubuntu package, the install the Edubuntu add-on.  Link to Ubuntu is here.  Link to Edubuntu is here.

Have a great week!

In this second post about the Scratch Balance Board, I’ll be looking at an extremely simple project - and the process of creating projects for use with the balance board.  Earlier posts that referenced the purpose of the balance board are here and here.

One of the first ideas about a project using the balance board was a virtual segway.  The first step was to build a simple project that uses the 4 arrow keys to control a virtual segway.  Run the project here.  Download the project here.  The key is to control the project by polling the keyboard (instead of looking at keypresses) and using “broadcast” to communicate the state of the keys to the segway sprite. 

The segway sprite uses “When I receive” to act upon the keypresses.  A screenshot of the Segway sprite scripts is shown.

• sorry
• I’ll
• use
• these
• bullets
• to
• spread
• stuff
• out
• again
• k
• k
• k
• k
• k
• k
• k
• k
• k
• k

 The next step is to use the board control script to send those same messages.

Scratch will not let you save off a script by itself.  So I created a sprite that contains the board control script.  I then exported that sprite.  When I want to add balance board control to a program, I simply drag the sprite file into the Scratch window.

Here’s a screenshot of the board control script.  There’s a short explanation of this script in last weeks post.

• k
• k
• k
• k
• k
• k

 So how does it work?  I’ve linked in a short narrated video of me trying to drive the segway around the track here .  I used RenderSoft’s CamStudio OpenSource version 2.00 to capture the video and compress it to a .swf file. 

Results from this first simple project:

• Sometimes I have a little trouble getting the PicoBoard to communicate.  I think it may have to do with plugging other stuff into the USB when it is plugged in - or possibly loading other software.  I’m not sure.  I did have to reload the PicoBoard driver to get the board operational again.
• The Balance Board is usable - but I found it very useful to have a chair to hold onto when I was trying to drive the segway. 

For the next post, I’ll try to make a little more complex project.  Any comments would be appreciated.

In my last post, I discussed building input devices for Scratch (see here).  My goal was to create a peripheral that could help get more kids interested in Scratch, programming, and educational endeavors in general (by providing more intrinsic motivation).

My first peripheral - a Scratch Balance Board.  The idea was to allow some neat activities like the Wii balance board.

 Remember that you will NEED the PicoBoard interface discussed in the previous post.  The cost is $50 plus $10 shipping to Oklahoma.

Background

I started this project wanting to build a practical Wii clone.  The tough part of the balance board is pressure sensing.  Load cells are very expensive!  And Force Sensing Resistors are only good for very small loads.  So I changed my goal - to build a very simple balance board using parts that can be easily and cheaply acquired (or hopefully scrounged).

Design

Note that I’m a software engineer and am a real klutz when it comes to mechanical things.  This design is not meant for production - it’s meant so that an adult and kid can put this together and play with writing Scratch programs using the balance board as an input device.

Here’s a picture of the outside.

It’s basically a simple box comprised of the following:

• 2 1″x12″ boards cut 22″ long for the top and bottom.
• A frame around the boards made of 1″x4″ boards.
• The bottom 1×12 is screwed in place.
• The top 1×12 sits on top of an elaborate force management system (more on that later).
• Note that the top 1×12 must slide easily within the frame.
• k
• Sorry about the extra lines
• but needed to keep pics from
• getting screwed up.
• If the pics aren’t lined up on
• the right side, try making your
• window narrower or wider.
• k

Here’s a picture of the inside with the “elaborate force management system”.  This elaborate system is composed of 4 tennis balls which are just placed at the 4 corners of the box.

Switches are placed at the center of each side to detect where the user is standing / leaning.

Note that the switches are mounted to scraps of 2″x4″ boards.   The 2×4’s are glued in place with standard school glue.

• k
• k
• k
• k
• k
• k
• k
• k
• k

As you can see from the closeup, each switch is comprised of 2 small screws.  These screws are parallel to the side of the box frame and 3/4″ away from the frame.  The screws are 1/2″ apart.

The wires are held in place by the screw being tightly screwed into the board.

• k
• k
• k
• k
• k
• k
• k
• k
• k
• k
• k
• k

The switch is activated when the top is pressed down.  This picture shows the other half of a switch mounted to the upper 1×12.

The washer is about 1″ in diameter and held in place with scotch tape.

Note that the objects under the washer are rubber tubing (about 1/4″).  These tubes serve 2 very important purposes:

• Allow washer to flex when contacting the screws.  This flexibility is needed to allow the switches to work even if the screws are not exactly the same height.  This also allows the switches to stay made even when the board is tilted on the perpendicular axis (i.e. you can lean forward and make the up contact even while leaning left and right.
•  Using the tennis balls as the suspension system is easy, but leaves no adjustment.  Adjusting the height of the washer off of the top 1×12 changes the force needed to activate the switch.
• k
• k
• k
• k

The screenshot at right shows a script I have attached to the background.  Notice that the script will work in either of the following 2 conditions:

• The force required to activate the switch is high compared to the weight of the user.  The user must lean toward a switch to activate it.
• The force required to activate the switch is low compared to the weight of the user.  When the user stands on the board without leaning, all the switches (or at least a pair of them - right/left or up/down) are activated.  When the user leans toward a switch, the opposite switch opens.

Note that no message is sent if opposite switches are both met.

The biggest shortcoming in the design is the force adjustment described above.  A system that allows the washer to be flexible but also allows for adjustment toward and away from the top 1×12 would be very helpful.

 I’ll look at 2 or 3 simple programs to use with the board in my next post.  I’d love to hear any comments or suggestions.

I’ve been thinking about some input devices for Scratch that might make the program more interesting to kids who aren’t particularly interested in programming - but are interested in video games.  Several input devices come to mind; a gun (for games like Duck Hunt), a balance board (like the wii balance board), and a direction sensor (so the program could know which way you are looking).  Now I’m not trying to recreate a Wii, just provide some interesting input devices to capture the imagination of a few more kids (especially my youngest).

Scratch can support these sensors because of its internal interface to the PicoBoard.  The board supports:

• 4 x 10-bit A/D converters (configured to read resistance)
• 1 x switch
• 1 x Sound Sensor
• 1 x Light Sensor
• 1 x Slider (another A/D input on-board)

What kinds of components would such input devices require?  Not quite sure, but I’ll take a shot at it. 

Balance board:

This was discussed on the Scratch forums (here) but I didn’t see any indication that anyone was actually trying to build one.

• 4 x Force Sensing Resistors or Load Cells
• Conditioning circuit to adapt sensor output to the Pico Board
• Wood for the balance board and base

Gun: 

I would try to make the gun operate like the old Nintendo Entertainment System Zapper (see here).  I’m not sure it would work, but it’d be worth a try.

• Gun looking device
• Sensitive light sensor mounted fairly deep in the barrel
• Trigger activated switch
• Circuitry to detect if the target had been hit (to detect the dark / light transition shortly after the trigger is pressed)

Direction input - I’m not sure how to do this, but the ultimate output would be a resistance based on the direction the user is pointing.

I’ll do some research to see if such sensors are economically feasible over the next week or 2.  If they look do-able, I may try to prototype one or more of them.

Any comments?  Would such input devices increase Scratch’s appeal? 

My youngest son’s 7th grade Science class just finished a chapter on cell division and DNA.  DNA Replication is a key concept in cell division.  Each strand of DNA divides into 2 half-strands (which are not identical).  Then each half reconnects with free bases within the cell to for 2 new strands of DNA which are identical to the original strand.

Key Concepts:

• There are 4 bases the are used to make the rung of the DNA double helix “ladder”.
• 2 bases combine to form each rung.
• The 4 bases are Adenine (A), Thymine (T), Guanine (G), and Cytosine (C).
• Adenine binds only with Thymine (A-T or T-A) to form a rung.
• Guanine binds only with Cytosine (G-C or C-G) to form a rung in the DNA ladder.

 My goal with this project was to consider what type of a constructivist / constructionist project a 7th grade student could generate to help them understand the concept of DNA replication.  I utterly failed at this - instead ended up investigating the capabilities of Scratch to build a game like activity to illustrate DNA replication.

A screenshot of the project is shown at the right.  Run the project by clicking here.  Download the project file here.

OK, so the project does make an activity that students could use to practice DNA replication and, hopefully, understand how the DNA strand can replicate itself.  But why was the project a failure?  Because it’s way too difficult for a 7th grader!

I believe the following parts of the program to be much too difficult for a typical 7th grader:

• Checking to see if the strand is reconstructed correctly.  Have a look at the “when I receive Checkit” block in each of the Rightx sprites.
• The concept of constructing the bases as generic left and right, each one having a state (essentially the base type T,A,C,G) controlled by a variable.
• Randomizing the DNA strand each time the program is run requires the state concept above and is beyond the reach of most 7th graders.

Suppose a 7th grader actually wanted to create a project like this?  What could (s)he make?  I’m speculating here - but I suggest that such a project created by a 7th grade Science student in a reasonable time (say 2 hours) could have the following attributes:

• Starts with a full DNA strand that looks something like the one in my project.
• Rips the DNA strand apart leaving the right side as 9 separate sprites that retain their type (T,A,C,G).
• Allow the user to drag the right sprites onto the left strand.
• Provide instructions for the user to follow to check to see if the DNA strand has be replicated properly.

I want to consider here the great constructivist / instructivist debate.  Which is more valuable for the student when trying to learn the basics of DNA replication?

A. Practice DNA replication a few times by running a more automated activity like I created  (Instructivist approach).

• Very efficient in terms of time… student can practice the process many times in the 2 hours that it would take build the simpler project himself.
• The puzzle nature of the activity will be engaging to some students.
• There’s no guarantee that running the program even a large number of times will result in the student attaching biological meaning to what he is doing.
• Probably the better approach if the instructional objective is for the student to be able to fill in a DNA chain on a test.

B. Create the less capable project… essentially having to learn the DNA replication process to be able to build the project (Constructivist approach) and having the project available as an artifact to discuss / explain DNA replication (Constructionist approach).

• Students may get too bound up in the Scratch implementation to really think about what is happening biologically.
• Will take longer than simply running the activity.
• Students who complete the project will probably have a better understanding of DNA replication than those who ran the program.  I believe this is true and that the main cause of the better understanding would be the thinking and planning that go into building an interaction to illustrate DNA replication.
• Probably the better approach if the instructional objective is for the student to be able to describe to others how DNA replication works.

I’d be really interested in any reader response to this analysis.  What do you think?  And if you’re a teacher, which would you rather have (the instructivist activity or the constructivist project) and why.

Oops!  I apologize for the misspellings in the project file… I think I fixed them in the post.

For the 3rd post on using Scratch as a Simulation Engine, I’ll be moving back to a High School classroom example.  The following is a problem from my daughter’s Physics class:

“Crazy Joe Clayton parks his 57 Chevy close to a cliff overlooking the ocean.  The land leading up to the cliff is on an incline of 37 degrees below the horizontal.  Joe runs to meet his sweetheart Thelma, but leaves the Chevy in neutral.  The car begins to roll down the incline with a constant acceleration of 4.0 m/s2 and travels 50.0 m to the edge of the cliff.  The cliff’s edge is 30.0 m above the ocean.

a. Find the time the car is in the air.
b. Find the position of Joe’s car relative to the base of the cliff when it lands in the ocean.”
 

The problem is  a simple 2 dimensional trajectory problem… but with a twist.  Brittany does not have enough of a math background to comfortably view this as a single problem!  For most High School students, the best way to solve the problem is to break it down into 2 pieces; the car accelerating down the slope to the edge of the cliff and the trajectory problem of the car careening into the ocean.  (Actually, maybe everyone would solve the problem as 2 separate steps.  If one were trying to impress someone, however, one could solve for the velocity at the end of the first part of the problem as an equation and substitute the equation into the 2nd part of the problem.  But would anyone really solve the problem this way?  I wonder.)

 A screenshot from the Scratch simulation I created for this problem is shown below.  The project can be run here.  The project file can be downloaded here. 

Reset the simulation by clicking on the green flag.  Run the first part of the problem by clicking on the car.  Run the final part of the simulation by clicking on the car again.

 What’s hard about this problem and simulation?

• As in most of the simulations I’ve looked at, the actual math is not too complicated.  However, the scaling of the movements of the sprites to match a graphic can be fairly challenging.
• With the problem broken down into 2 parts that can be readily solved, it is necessary to realize the the starting x and y velocities of the 2nd part of the problem are equal to the ending x and y velocities of the first part of the problem.  This was not intuitive for Brittany.  In fact, she argued pretty forcefully that the starting y velocity of the 2nd part of the problem should equal the ending x velocity of the first part. 

Could a simulation like this be used to help students understand Physics in a High School Physics classroom?  I’ll consider a few possibilities, and my thoughts on them…

• Assign students to develop a simulation of the problem? - Probably Not!
  Although this would be a very constructivist (or constructionist) activity, I believe that assigning the students to develop a simulation of the problem would probably be too tough for all but the most advanced students.  And the time it took to build the simulation of this one problem would probably be better spent practicing several more problems.
• Use the simulation as an in-class demonstration?  - I think so!
  The simulation could be used in-class to demonstrate how the problem can be broken down into the 2 separate problems.  Further, it could be used to explain the relationships of the x and y velocities as the 2nd part of the simulation begins.  These relationships may be easier to explain / understand given the simulation.
• Use the simulation as an in-class demonstration of debugging? - Hm, I’m not sure!
  If you compare the results of the simulation with the results of working the problem by hand, you’ll find that the answers provided by the simulation are not quite right.  These inaccuracies are caused by what I would refer to as quantization limits.  The simulation moves based on a clock tick and the accuracy of the simulation is limited due to this.  An understanding of this phenomenon might be within the scope of a High School Physics class.  However, If I used the simulation as an in-class demonstration as discussed above, I wouldn’t include a discussion of the quantization problem because I think it might interfere with the point of the problem - which is to set up and properly solve the problem.  I might consider discussing quantization and accuracy, however, whenever discussing the accuracy of experiments carried out in class (or in the real world).  In such a discussion, the simulation might make a useful demonstration.

As always, I’d love to hear what readers think of these ideas.  Is the use of Scratch for simulations a useful school activity?

In this post I’ll be considering a fairly complex simulation with Scratch.

Control systems commonly use a control algorithm called the PID Control loop.  The PID stands for Proportional - Integral - Differential.  You can find more information about the PID algorithm here.

A few months ago at work we were putting together a control system that would control the level of fluid in a tank.  Fluid was coming into the tank from various systems, with rates that could change over time.  Fluid was to be pumped from the tank using a pump driven by a Variable Speed Drive (see here if you’re really interested).  As we did not have access to the actual system, but wanted to try to test the control, a colleague had built a simulation of the tank level into our device.  We weren’t really understanding what we were seeing (turned out there was an undesirable feature in the PID algorithm in the software - what most folks refer to as a bug).  In an effort to understand what was going on, I decided to model the overall system.  And I decided to see if Scratch could get the job done.

A screenshot of the project stage is shown on the right.  The blue in the upper left illustrates the fluid level in the tank and is reflected by the TankLevel variable.  The IntakeRate is the rate at which fluid is entering the tank.  The PID MaxOutputRate is the rate fluid is being pumped from the tank when the VSD is running at full speed (100%).

Run the project here.   Click on the green flag and then on the big green dot to start the simulatin.  Note that the fish labeled Ft graphs the tank level and the fish labeled Hz graphs the VSD speed.  Download the project here.

It’s beyond the scope of this post to explain the innards of the simulation.  Suffice it to say that you adjust various start values in the PID sprite to try to match the system you wish to simulate and then run the simulation.  Repeat as necessary to optimize the PID response.  The purpose of the post is to describe what I learned in using Scratch to create a fairly complex simulation.

• As you can see from the image at right, the actual PI algorithm is not too complicated.  (I didn’t simulate the D term as we seldom use it and the anomaly we were seeing was evident even when we only had a P term.)
• The stage size was somewhat limiting.  In a simulation of this nature, you’d typically display a bunch of data.  All the stuff I really needed fit, but didn’t leave much room for any graphics or animations (often referred to as “eye candy” at work).
• Often one wants to save the simulated data to a file as the simulation progresses.  Scratch doesn’t have this capability.  However, one of the things you typically do with the saved data is to graph it to observe the control response (in this case, Drive Speed) with respect to the feedback variable (in this case, tank level).  Scratch can do the graph.
• I really liked the little fish building the graph.
• My coworkers and boss seemed either impressed or somewhat amused that I was using a kids’ program to do a “work” simulation.
• The speed of the simulation was fine on a 3 year old laptop (1.6GHz Centrino Duo processor).

As always, I appreciate any feedback.  In the next post, we’ll look at another example of a simulation - but this time back to a school problem.

Wow!  It’s been 7 weeks since I posted.  That’s a long gap, even by my lax standards.

 For the next few posts, I’ll be looking at Scratch as a tool for simulating events.  Since my interest in this is mainly education, most of these will be simulating a school problem.

The problem for this simulation came to me as a text message from my daughter Brittany… something like this…

“2 bicycles start 20 km apart and move toward each other at 10 km / hour.  A fly flies  between the bicycles at 30 km/hour until they crash together smashing the fly.  How far does the fly fly?”

The statement of the problem leads one to start drawing lines back and forth between the converging bicycles.  This is the hard way to work the problem.  I responded to Brit’s text with a question… “How long until the bicycles crash together?”  Thinking of the problem this way leads to a very simple solution.

I wondered, however, if there is educational merit to actually seeing the problem unfold in a simulation.  I believe building this simulation would be possible for someone at Brit’s level (High School Senior, good programming skills, taking Physics).  I decided to simulate the problem in Scratch in order to investigate the educational opportunities for a student faced with such a problem. 

A screenshot of the program is shown to the right.  I substituted cats for the bicycles and a butterfly for the fly for ease (as Scratch came preloaded with those graphics).

Run the project by clicking here (click on the green flag to start the animation).  The project is available here.  Note that Scratch 1.4 or later is needed to open the project.

So what’s difficult about this simulation? 

• Setting up scaling.
  The cats start 20 KM apart and the Scratch screen has 480 horizontal pixels.  Therefore, I chose to let each KM be 20 pixels. 
• Setting relative velocities.
  I don’t really care how fast the cats and the butterfly move, but their relative velocities must match those of the problem statement.  I chose to let the cats move toward each other at the variable “Speed” pixels per simulation iteration.  So “Speed” was defined as the speed of the cats.  Since the butterfly moves 3 times as fast as the cats, the butterfly moves 3x”Speed” pixels each iteration.
• Calculating the actual distance moved.
  The velocities are in pixels / iteration, but the problem needs an answer in kilometers.  The distance moved is simply the butterfly velocity / the number of pixels per KM.

So the simulation is probably doable, but challenging for a High School Physics student with some Scratch experience and reasonable programming skills.  But would the exercise of creating the simulation be a worthwhile educational endeavor?  Reasons I believe the exercise might be worthwhile include:

•  The simulation provides an method for a student who doesn’t see the easy solution to still solve the problem.  If the simulation included the flight time as a displayed variable, the student may make the connection between the butterfly speed and the time to the collision.  I believe such ”aha!” moments are powerful learning times for students. 
• The activity certainly falls under the Constructivist category.  As such, student learning may prove deeper and more transferrable than just working the problem.

I’d appreciate reader feedback…

• Would such a simulation be a worthwhile educational effort? 
• If so, what benefits to the student do you see from such an effort?

Next time… we’ll look at a fairly complex simulation in Scratch.

In my post on March 14 called ¿Puedes hablar con su computadora? (good grief, it’s been 5 and a half months!), I discussed an One Laptop Per Child XO program called Hablar Con Sara and how I thought one could add context to such a program and make if more effective.  The objective is to put together a program that allows a foreign language student to practice conversation with their computer.

In March, I predicted I’d have a proto in 2 - 3 weeks.  Ha!  With everything else to do, the project got shoved to the bottom of the list.  As I now have a little breathing room in my schedule, I realize I still want to do this project and think it has merit (see the original post for more details).

My original program idea was straightforward, if not simple.  Put together a context - such as going to eat at a restaurant - and have the student move through the different phases with simulated conversations with the greeter, waitress, …  Limit the vocabulary and provide a vocab list for the student to preview / review.  I still think this is a great idea, but it’s quite a chunk to bite off all at once.  So I’ve put together several simpler ideas to consider:

• Supply a context like a restaurant, but don’t try to sequence the events.  Although this is somewhat simpler (no state machine for what part of the scenario is going on), it is very similar to the previous idea.
• Use a picture as context and try to provide a discussion / conversation with the student about the picture.  In this program, a picture is supplied and the student is encouraged to discuss it with a picture of a kid on the screen.  The student types in phrases to the program.  The program parses the phrases for keywords and uses the results to speak back to the student.  I think this program could be easily expanded to the programs above by using a sequence of pictures that represent eating at a restaurant, …
•  Use a picture for context and try to provide a discussion / conversation with the student about the picture.  Instead of allowing the student to construct phrases and type them into the computer, allow the student to pick from phrases that have been provided as buttons.  This is really simple - but not allowing the student to construct his responses and comments really restricts the program from allowing any resemblance of real conversation.

Based on the included comments, you can probably tell that I’ve decided to start with the middle option.  A simple task flow would be:

• Select a picture
• Put together 15 - 20 phrases about the picture
• Identify trigger words and tie them to the phrases
• Record the phrases

Interaction with the student is pretty simple 

• Allow the student to enter a sentence
• Parse the sentence for trigger words
• Select a phrase that is triggered by the trigger word
• Play the audio file of the selected phrase
• Additionally, one might add a button that says “You start” or something similar to get the program to pick a conversation starter phrase.

So what would be a good development environment?

• Authorware - although I have Authorware (and like it a lot), I’m not using it because it requires a player that is not commonly found on most computers.
• Flash - Flash is a good development environment for such a program as this.  And Flash is easily deployed on the internet.  However, I prefer to use Open Source tools and think this program would actually be easier in Xerte as it doesn’t need animation.
• Scratch - I’d like to use Scratch for this… but how could you get user input.  Then I found that in version 1.4 Scratch allows for users to enter a string.  However, writing the Scratch code necessary to parse the string for key words turned out to be pretty hard… and it appeared to be pretty slow.
• Xerte - Xerte is similar to Authorware with Flash Actionscript as the scripting language.  And it compiles to a standard Flash swf file for easy deployment on the internet.  And it’s open source.  See my earlier post on Xerte Xerte - eLearning Development Tool for more details.   So Xerte it is!

So what’s the current status?  (so am I going to take another 5 months before getting anything done ;-)… No, I should have something to post in a couple of weeks (yea, we’ve heard that before).

The logic of handling the user input is really pretty simple.  I’ll post an early version of the code here for comments…

“Triggers = [
   new Array(”rock”, 3, 5),                                  // Trigger words and phrase indexes
   …

Unsolicited = new Array(4, 6);                        // Phrase indexes for unsolicited / unrecognized input

Phrases = [
     “This picture was taken in southern Oklahoma.”,                  // 0 Phrases - need to be recorded
     …

triggerphrase = RSTextEntry.text;

selected = -1;
for(i=0; i<Triggers.length; i++)
{
   if(triggerphrase.indexOf(Triggers[i][0]) > -1)
   {
      selected = Triggers[i][1];
   }
}

if(selected == -1)
{
   selected = Unsolicited[0];
}
IDFeedback.setText(Phrases[selected]);”

There’s still some things to do, but code complexity certainly won’t be the constraining factor.

Any comments or suggestions would be appreciated.  I guess I should quit writing about this project and get to work!

The ability to run programs directly from a USB Flash Drive - without installing them on a computer - is useful in a number of circumstances.  I’ve got several programs installed and running on my flash drive.

I have a U3 style flash drive - but most of the programs I’m describing here are not loaded as U3 programs.

Why would this be useful?

• Some time back I was looking for a venue for a Scratch class for kids.  A local library expressed interest… but they couldn’t install software on their computers.  I’ve now found that Scratch can be installed and run from a USB Flash drive.  I can’t find a link describing how to put Scratch on the flash drive at the moment - but if I remember correctly I downloaded the .zip version of Scratch and unzipped it.  Then I just copied the whole Scratch folder onto the flash drive (I actually put the folder into a folder named Programs on the flash drive to keep the root level from getting so cluttered) and then put a Shortcut to the program onto the root level.  Note that you have to start Scratch and then open your projects.  If Scratch is not installed on the computer you are using, it won’t recognize the file extension.  Maybe that Scratch class at the library is possible now.
• When using someone else’s computer (or a public computer), you may need access to a wide variety of utilities.  I’ve found that IrfanView (photo editing), Audacity (audio recording and editing), and jZip (a compression / decompression utility) all work fine from the flash drive.
• So, maybe your into teaching kids a programming environment but don’t like Scratch (I can’t imagine that!).  I’ve found Squeak and NetLogo also run fine from a flash drive.
• If you’d like to do a little multimedia authoring, I’ve found that Xerte will also run from my flash drive.
• U3 programs I’ve installed include Skype (communications), Gimp (another photo editor - I really haven’t tried this but it did install correctly), and WinSCP (ftp utility).
• Do you think you’d like to investigate the Sugar user interface (the shell that runs on the OLPC XO laptop)?  You can even get Sugar on a flash disk.  One note - to get Sugar to run you actually reboot your computer into Fedora linux (which is also installed on the flash disk).  This could also be very useful if you have small children and are looking for a good user environment for them.  One more note - as best as I can tell, when I boot into Fedora / Sugar, my hard drive is NOT mounted.  If I’m correct, this would mean that nothing a child (or anyone else) could do from Sugar could affect the data stored on your hard disk!

Well, that’s just a few programs that I’ve found to work on a USB Flash drive.  There are many others.  While access to other Authoring environments, etc, on a flash drive may be useful, many of these programs are licensed in such a way that (in my reading) would preclude such use.

My philosophy at this time is; if it’s licensed such that it’s not a violation to run it on multiple computers (Open Source, for example), and I think it might be a useful tool to have with me at all times, then I put in on the flash drive and see if it works.