* Rather than saying to hit 'R' to reset have a button (keyboard can work too, but only allowing the keyboard goes against the rest of the game which is mouse/touch driven).

* On the right have the words "Goal" on top of the image, maybe put a box around it or something to separate it from the other images that appear.

* For the first level you need a "pit of success". Limit the available functions to only the one that works.

* The first few levels need to introduce and teach the user how to use each and every function separately. Say for 12 levels the first three teach/introduce a concept, the next 6 are actual simple/medium levels and the final 3 are the more difficult (but not impossible) levels before repeating and introducing a new concept.

* When you solve it don't put the message up top in little text, but next to the program and bigger bolder so the user knows. Ideally with some sort of css transition.

* When you solve it put a link to "Play next level" or automatically go to the next level after a short animation or something

* Only expose levels after you have beat them.

* After doing a function rather than instantly showing the next cube put a .5 second opacity transition (or something) so the user will notice what they did.

Lastly, but most importantly play test in person. Show someone your game, but don't say a single word. Write down everything they do wrong and debate how you can improve it and try again. Do not give them advice on what to do. If they can't figure it out neither will a ton of random people on the internet (I didn't the first time I saw the game and just closed it as I didn't realize I had to drag it over and I was on a tablet and saw the 'R' command and figure there was other keyboard only commands.)

Remember it is not fun to lose. Hard is fun, but you want to guild the user to have fun, be challenged, and build on the game concepts you have taught them. It isn't fun to give up because you have no clue what to do.

If you build in a way that users can create puzzles and share them (say by putting the user generated level in the url) the game would have more life as users spread the word by showing off their creations.

Wow! Thank you so much for the detailed feedback. This will be very helpful for the future development. Most of these are 'small/easy' changes but I definitely see how they will improve the user experience. I think I agree with all of your points and will try to use it as a roadmap :-). The 'play test in person' tip is also very helpful. I will try this!

> After doing a function rather than instantly showing the next cube put a .5 second opacity transition

Please, no animation. Instantaneous feedback is perfect as it is. My 2cts.

Yeah .5 seconds is way to long, the reason for the animation is that in this game you are looking at the list of functions and only after you are done does your eyes have time to register changes elsewhere. If it has already changed your brain has to try to figure out what has changed when the system can provide hints.

Because you would rapidly move them around changing it to be 0.05 or something just slow enough so that your brain would notice movement above, but not slow enough to impede in trying new things.

The block function diagrams would be clearer if they were stacked like they work instead of being turned on their side. That is,

    ▥ ↦ ▥ ▧

could instead be:

         ▧ 
    ▥ ↦ ▥

I hope that makes sense!

Also, the dropdown menu for levels could be replaced by something more informational (perhaps a tree control?), that indicated e.g. by color which levels have already been solved.

Yes, that makes sense! I've put it on my (now long) list of UI improvements. Thank you very much for the feedback!

Like others I would like to second the visualization of block sizes better. And a brief explanation of commands like stackEqual (is there some sort of normalization going on to unit size?). push(X) would probably be better read as layer(X) or stack(X).

Is there a way to normalize the program into a text string and also convert text string back into the program. This would allow for easy cut/paste sharing between users (including HN comments).

This feedback is based on having completed up to 1.2 only.

Thank you for the valuable feedback!

There is no import/export available right now, but you can take a look at the developer console for an output line like

Program: ["rejectO","replaceYbyBY","replaceBbyOO"]

I definitely like the idea, however. It should be quite simple to implement it. Basically, the 'code' right now is just the compositions of different 'transformers'. In pseudo-PureScript:

rejectO >>> replaceYbyBY >>> replaceBbyOO

Poseidon was very tough for me, but I got it just now! Had to go back to it after finishing the rest. If you rotated the entire block display 90 degree vertically then the commands would match the display (as in R -> R R shows two red blocks adjacently instead of vertically), without having to make the commands too tall. (Just a possibility, maybe not a great way to do it.)

Thank you for your feedback! Poseidon is actually quite hard, true. I just promoted it to 'hard' :-).

I think I will first try to display the two R blocks on top of each other in the name of the functions. I will keep your suggestion in mind, though.

When you try to apply all functions, the space becomes limited and you cannot see the resulting piece, especially when it gets tall.

An intro would've been nice for people like me who know nothing about functional programming.

It would be better if we could see the adjacent cubes with same color clearly. Especially on objective part, it is hard to determine how long a line segment is if it is same color.

Thank you for the feedback. I have been thinking about this earlier (https://github.com/sharkdp/cube-composer/issues/7). I will definitely try to improve it.

How about truncate the cube a little bit ( http://en.wikipedia.org/wiki/Truncated_cube )?

I will try this out in Isomer.js and see how it looks like. Thanks for the idea!

Yeah, thin black borders between all the cubes would be a world of help.

[white] as a catchall is a bit misleading. Perhaps a different border color or an asterisk inside the square to clearly mark that it's not an actual white block?

Good idea! I will try both and see what works best. Thank you!

I would suggest just white (or whatever the background color happens to be), with a dashed border.

Now that I've seen the update, I think just make it transparent, so it is the color of the button on which it is placed. The dashed border is nice though.

Thanks for the feedback! The dashed border was a really good suggestion. I like white better than 'transparent', though.

How about an in-row voxelperson or checkered flag, or something which indicates solved?

I love this idea! I'll try to implement it..