Research Log of Web Science Students

Computer Science is not simply programming

design issues

leave a comment »

For the next demo, we have had to confront a number of design issues. The most troubling one so far has been the overall layout of the program.

Overall Layout

First, here are the overall layouts for related programs.




The major difference is that Alice and Scratch mostly deal with one object at a time, and Greenfoot with more complex code, whereas we need to deal with multiple objects on a simple grid. Another difference is that we are functioning with limited screen real estate as we are viewed from within a browser. We must then examine the major areas we are arranging.

A. Ojbect Choices – This will provide the user with a list of object types that are available
B. Grid – This is where objects are placed for manipulation
C. Command Choices – This will provide the user with a list of commands that are available
D. Command Sequence – This is where the sequence of commands for an object are laid out.

From the above it can be seen that
* A and C are providers of choice while B and D are receivers of said choice,
* B must be visible when A is made use of, and,
* D must be visible when C is made use of.

If all areas are visible at the same time, the space taken up becomes prohibitively large, especially given the current upsurge in the popularity of netbooks. This suggests that some of the areas must overlap, similar to tabbed browsing.

From the above it can be understood that
* A may overlap with C and/or D
* B may overlap with C and/or D
* C may overlap with A and/or B
* D may overlap with A and/or B

It is thus our proposed solution that there be two layers such that A and C overlap, B and D overlap, with A and B being the default layer, with the C and D layer being displayed upon an object’s selection.


Object Selection

If the above solution is acceptable, then it must be determined how an object is selected for editing of its commands.

The options we see are
A. Double Click
B. Right Click
C. Seperate Button

Of the above, option A seems to be the most intuitive choice.

Choice Selection

It must also be determined how an object/command is chosen and placed on the grid/command sequence.

The options we see are
A. Click + Click, Click the choice then click where you want it to be placed
B. Click + Appear, Click the choice and it will appear at some predetermined location
C. Drag + Drop, Drag the choice and drag it to where you want it to be placed

Of the above, option B seems complex as there must be a predetermined location at which newly selected choices will appear. Options A and C both seem viable, with option C being the more typical form of interaction but also a slightly more difficult one as the mouse must be held down while dragging.

Color Scheme

The mockups and the demo so far has been done in black and white. The colors and/or graphics to be displayed has not been selected although it would actually be more ideal if the interface were somewhat skinnable. Color schemes for younger children’s games should be brighter and livelier so as to catch and sustain their attention. Looking at popular games from different websites proved informative and will be discussed in a separate post since the colors are not as essential and are simpler to change.


Written by cathy

August 14, 2009 at 5:16 pm

Posted in We PEG

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: