Big Ideas

In working on Waterbear, several ideas have been raised that are too large to be tackled at the moment, but which are worth considering as a possible avenue of work for the project.

One key issue is how to support the goal of having Waterbear accessible to non-programmers while still having the functionality included which allows for complex programs. This basically requires a degree of abstraction, where features deemed 'advanced' can be hidden until needed. There are several ideas of how to accomplish this:

1. Tagging blocks and implementing a system to hide and show blocks based on these tags. This would allow us to tag advanced blocks and hide them by default, making it clearer which basic tools the users would need to learn to be able to start creating programs. This is being investigated as an issue at the moment.

2. For objects, hide the parameters by default and have them accessible via context menu. Taking the Sprite object as an example, the way it currently works is that when you drag in a new Sprite object it requires a size, point location, and colour. There are default values provided, but they must all be accounted for. To take further action with the Sprite other properties such as speed, turning, and facing. The mechanisms of turning and facing in particular are quite complicated and involve several blocks with multiple options. One proposal of how to simplify this would be to change it so that when you drop in a new Sprite it contains nothing but the name. Internally it would assign default values for all parameters, say making it a random coloured square 32x32 in the middle of the screen), so the user could start working with it immediately. Should they wish to change a property, perhaps changing it from a square to a rectangle, they would right click the sprite to bring up a context menu which has a list "Parameters" which expands into Size, Colour, Location, Speed, Turning, Facing, etc. If they then selected Size, it would automatically either expand the sprite constructor to include the size parameter, or would automatically generate a set size block for the specific sprite. This would serve to reduce unnecessary horizontal clutter and make getting into simple programs easier.

3. In what is some ways a simplified version of (2), parameters could be expandable and collapsable in the same fashion as control blocks, to reduce horizontal stretch and hide unnecessary functionality. By default the parameters could be collapsed when the block was dragged in, so it may be a way to fulfil much of the same functionality as (2) while staying simpler and not interfering with the other work being done on context menus.

A second area of concern is how to make Waterbear a good tool for learning programming. One opportunity may be in the script view, which is useful in allowing a user to see what the block looks like in actual code. But what would be of possibly great use and would be more unique, would be a way of going the other direction and editing the script to see the change reflected in the blocks. Ideally Waterbear would be smart enough to recognize code which is mapped to a block and place that block, and then in places where non-block code has been written a kind of "black-box" block would be placed to reflect this unknown code. This would make Waterbear a more unique option and serve to distinguish it from other visual programming options, and would be very useful in fulfilling a side goal of Waterbear, which is to be able to make and share new blocks easily. If someone was able to create a black-box block by editing the script and could then play with this block in their code, they could effectively test and design a new block and then it would simply be a matter of adding the option to submit that black-box for acceptance as a proper block to be able to add your new code to the project as a whole, or share it with other people.