How we created our Christmas Wordsearch program

How we created our Christmas Wordsearch program

We have become greatly interested in the rise in interest in computing lessons in schools, and as software developers we wanted to let you know how we created our Wordsearch activity.

1. Reason for creating

Why make the program? To support some of our existing activities, we wanted to offer a wordsearch containing some of the keywords for the main activity. To get it started, we thought that we would create a Christmas version for children to use, and to see how popular such an activity might be online.

2. Design

We had previously created a wordsearch program for our “Smudge Spells” program. That was written in Java – we use Javascript these days, a different language despite the similarity in names – so we could not make use of any of the code. But the way in which it worked and the screen layout defined how this wordsearch should work.

3. Starting Point

We were not starting from scratch. As we have created several activities written in Javascript before, we could use these as a basis for the wordserach activity. We had an established “framework” which contained routines that allowed the software to work within a range of screen sizes, display images, handle mouse clicks etc.

4. Plan of Action

The list of tasks that we needed to do included:
a. Draw the screen containing a Grid and Letters
b. Be able to handle mouse clicks
c. Generate grids containing words
d. Add some graphics and animation

5. Draw the screen containing a Grid and Letters

In an ideal world, we would have the skeleton of our “framework”, and we could add code to make into a new activity. In the real world, we took the last activity (Property of Materials), and bolted on the code, initially for displaying the Grid.

This brought up the key questions about whereabouts on the screen we would place the grid (and we use global variables so that we only have to set the position of things like the left margin , the top and the cell width and height once). And how we would store data about the grid – we decided on one two dimensional array storing the letter to go into each square, and another two dimensional array storing whether a square would be shown as highlighted.

Once the grid was looking ok, we could them cut out the old bits of code (and directories containing data) that would not be needed. We are always careful when doing this, in case we delete something that means the code won’t work (and it takes a long time to sort out), so we go one small (reversible step at a time)

6. Be able to handle mouse clicks

This was the trickiest part of the development. For this, we wrote some ‘pseudo code’, a half way stage between English and computer code of the form:

Writing pseudo code involves some crossings out, and rethinks, which is great, and to be encouraged. Sometimes your first idea isn’t the best, but it needs to be put down, as it lets you have a better idea – and it’s a mistake to try to stick with the original idea. The great thing about writing pseudo code, is that mistakes made at this stage can be corrected more quickly than when it’s entered into the computer. Ideally, you would dry run the code (or have someone else do that), but I must admit we didn’t do that on wordsearch.

So we were able to write this code, and test it with a basic word in the grid.

7. Generate grids containing words

This was a potentially harder piece of code to write, and involved more pseudo code. We used a simple system (maybe too simple as the grids don’t have many words that cross with each other). We were aware that the code could potentially lock-up, if it could not fit all the words into a grid, so we let the program try a word in several positions, and then give up and go onto the next word. Cheating maybe, but it worked!

A further complication was that this code needed to be re-run once all the words had been found, where the variables needed to be re-initialised.

8. Testing, testing, testing

Having broken the coding down into stages, we did test each part as we went along. But once it was finished (and we added some graphics, but the animation has been missed off for now), we started to test it.

This showed up a few things we’d forgotten (like we hadn’t got the re-initialising part right when it needed to regenerate a new grid). Once they were done, we normally write a test check list – to ensure that when we make a small change, either now, or in the future, we check everything. Then we test with some representative users (in this case with a 7 and a 9 year old), and hey presto, it was ready to go!

I hope this has shown some of the steps involved in writing a small software program, and if you have any questions, please ask me. In the meantime, the final program is here: