Blog Post

More bug developments

So weve been pretty crazy here over the last few weeks working on Ecobugs.  I went into school to test out the game design using a paper prototype, to get feedback on the bug designs and website wireframes.  We had students from years 3,4,5 and 6, (7-11 year olds) the target audience of the game, and their teachers.  The big news is that they loved it, (phew!) and that even the younger students reacted well to the game design (we were wondering whether the processes would be too complex for them).

We also got their feedback on the bugs which is crucial, not just for the visual attractiveness of the game, but also for the technical learning the game supports.   Thankfully they all were able to pick out the classification features on the bugs, e.g. whether they have jaws, number of wings and legs (that saves our genius designer Steve a lot of time and painful reworking!) In fact, they were better than the teachers at adapting and seeing continuities between the bugs. For example, seeing which bugs had hidden wings which were intimated by a line down the back of the bug (if you look closely on the image you might be able to see it). It was also interesting unpicking the students feedback and discerning whether they didnt like the bugs because of the style, or, as was actually the case, because they found them a bit scary!

Also to report the teacher pack is full steam ahead and were lucky enough to be working with 2 great teachers who are creating lesson plans for subjects across the curriculum.  Theyll be 12 in total.

We're continually working to achieve a balance with this game how can you make it as easy as possible for teachers to use, while still maintaining the premium functionality?  So, for example, we had some big chats about the player website that is created when you set up a game.  (Players can go here after the game to view data about the bugs they caught, who the best catcher was and the types of habitats etc)  Is the best way to handle access to this site to create a unique URL for each game, (so this can just be given to the students and they dont have to navigate a teacher facing main site)? Or is it best to have a log in screen on the home page and a unique code generated when the game is made (more codes to hang on to but just one website to go to)?  The response for the teachers was to have just one home page with a log in box.  This means that they dont have to worry about dealing with new URLs.  This type of challenge is constant when building education resources where were balancing the possibilities of exciting functionality with the need to keep interfaces effective and accessible.  Mr Einstein reminds us to keep things as simple as possible, but not simpler but as simple is a relative term for the diverse teaching community, actually doing that in development isnt always as easy as it sounds!


One more thought on developing the Ecobugs website is that competing for teachers attention on the web is as tricky as for any audience.  You only have those few crucial seconds to grab their attention when they visit your site.  For the teachers were working with, the question is will this work for my kids?  If you dont communicate the age and subject relevance of the resource really, really quickly, theyll move on, really, really fast.



No comments