janpaul123 / jsdares Goto Github PK

Learn and explore JavaScript, and create your own dares!

License: MIT License

JavaScript 40.51% CSS 44.47% CoffeeScript 0.89% PHP 0.02% HTML 1.60% Makefile 0.04% Yacc 0.64% Less 11.83%

jsdares's Introduction

jsdares

jsdares is an experimental learning environment, created by Jan Paul Posma for a masters dissertation at the University of Oxford. The code is available under the MIT license.

Features

Collaborative platform for anyone to create and solve programming puzzles: "dares".
Custom parser for a subset of Javascript: "js--".
Runtime that saves everything, and allows moving through the program execution with ease, inspired by Omniscient Debugger.
Advanced interface for making games that allows going back in time, visualises how the code maps to the output, and makes it easy to tinker with the code, inspired by Bret Victor.
Robot environment for learning the basics of programming, based on the Logo turtle and Karel the Robot.
Canvas and console environments based on the standard browser components.
Extensive set of code examples.
Basic set of dares which challenge learners to make shorter programs using the concepts they are learning, inspired by Code Golf.
Cohesively designed experience.

Installation

Install dependencies: npm install.
Run grunt: node_modules/.bin/grunt.
Done! Serve using some webserver, on the root domain.

To load the default dares, register a user with username janpaul123 and restart the server. Automatically dares will be created for this user, and the user will get admin rights.

Spinoff projects

Clayer, a direct interaction library based on BVlayer.
Robot, a robot applet based on the robot environment.

Contributing

PRs and bug reports are always welcome! :)

jsdares's People

Contributors

Stargazers

Watchers

jsdares's Issues

Sharing solutions

Users must be able to share solutions with others, e.g. using Facebook and Twitter, or just by copying a URL. Those who view the dare must be able to immediately try out different things, or play the dare themselves.

No completion of top level / global variables

JSDares is the only JS I've used, so my terminology is probably wrong!

I like the code completion, but there's no completion for top level names as far as I can see. So, robot. needs to be written in each case, and when you start to use functions functionName( needs to be written.

Syntax too strict

The #1 thing people just starting out ask me is if it matters exactly where the ; and { and ( are placed.

In reality it doesn't. But in jsdares If I say

function foo()
{
stuff;
}

instead of

function foo() {
stuff;
}

it fails to run.

That is too strict in my opinion.

Also it doesn't seem to allow for loops inside of functions:

function automate (command) {

for( var i=0; i<command.length; i++) {
robot.drive( command[i] );
}
}

and doesn't seem to accept any kind of array syntax:
automate( [1,6] );

Is there a list of what is and isn't allowed?

And it would be nice if people could register with an existing account:
Google
Facebook
Twitter
BrowserID
OpenID
Other

line count confused even more than expected by simple golfing technique

In “Zoo”, this solution gets 0 points for being 10 lines, the maximum allowed:

var context = canvas.getContext("2d");

function animal(x, y) {
context.fillRect(x+150, y+50, 50, 50);
context.fillRect(x+50, y+100, 100, 50);
context.fillRect(x+50, y+150, 30, 50);
context.fillRect(x+120, y+150, 30, 50);
}

animal(0, 0);
animal(250, 0);
animal(0, 250);
animal(250, 250);

However, this solutions gets 200 points - an additional 100 for being 0 (?) lines, 10 for each line below 100:

var context = canvas.getContext("2d");

function animal(x, y) {
context.fillRect(x+150, y+50, 50, 50);
context.fillRect(x+50, y+100, 100, 50);
context.fillRect(x+50, y+150, 30, 50);
context.fillRect(x+120, y+150, 30, 50);
}

animal(0, 0); animal(250, 0); animal(0, 250); animal(250, 250);

"Programming contest" dares

Add a dare type in which the program should contain a function which is called multiple times with different parameters, and should give the right output in each case. Optionally, the right output can be hidden from the user, to make it more difficult.

Twitter icon broken

Twitter icon in dares is ugly..

Configure maximum run time per dare

Because now it is impossible to make dares with long run times, even though these may be slower on some machines.

Zooming in/out breaks

When zooming in or out using the browser, there are a couple of things that break:

Spacing between tabs and the modal window
Toolbar buttons move
No horizontal scrolling when zooming in
Rounding errors in the robot output

No rule to make target `cli-assets-dev.js'

How do you build and run this code? There's a Makefile, but 'make' complains:

 $ make
make: *** No rule to make target `cli-assets-dev.js', needed by `browser.js'.  Stop.

Once that's fixed, it's not obvious to me right away how to run this: point my browser at one of the HTML files, I presume, but there are a bunch of them, and the first I looked at, home/index.html, is not it. assets-dev/index.html looks more promising, but is mostly blank before the 'make' succeeds, at least.

Introspection

It would be very cool if much of the interface and code for the editor and outputs could be viewed and modified within jsdares. This is probably a big project, but very rewarding nonetheless. If we do this, we should probably think about integration with github or something.

Crowd fund project costs

Scratch did it for Scratch JR.

JSDares may not have the user base for that yet, but in a while, it could be a great way to get funding for development, assets, teacher's materials, evangelism, etc.

Add string functions

At the very least add properties like str.length, but potentially also others.

A variables browser

I'm looking at the bat and ball example. Variables / global state, unlike drawn canvas entities, are something that is not "visible":

*You can't see them (as a list).

You can't mouse over them and see where they're defined in the program or touched.
You can't see a timeline of their values.

… I don't remember B.V. addressing this, but it seems like it would make sense to stop them being hidden state?

I'd like to note this isn't something I noticed while my Son was using JSDares, so it's just me speculating.

Use consistent font sizes and styles

It looks way too chaotic now.

Discoverability of "Victorian" interactions

I was enjoying JSdares with my son last night. I'm very impressed, thanks! I started reading your short essay about it today, and realised there's lots of amazing stuff we missed in the UI while using it for about an hour!

Mousing over the canvas and seeing the code highlight is amazing! We didn't know about it :-(
Mousing on the code and seeing the canvas is amazing! We didn't know about that either :-(

Could this be made more discoverable, or be explicitly explained? Or, how about: have a dare that introduces the concept! This is an approach often used in games to teach you the interface. Something like:

"Mouse over the robot's tracks to find the line of code that goes through the green square, then add a comment to it."

Rethink error/step message positioning

Right now messages are placed under the text, which hides the text underneath. Perhaps position to the side if possible.

Large number editables don't work properly

Try adding 10000000000 and then dragging it.

Colours in Canvas dares

Not sure, but I think colours do not matter at the moment for canvas dares. Find a good colour matching metric and use it in canvas dares as an optional feature.

No way to "start again"?

I'm not sure if there is a way to start again? With the first function example, we accidentally trashed the code and couldn't work out how to get it back. I think in the end I guessed what the function syntax would probably be and wrote it.

I'd suggest a prominent "Restart" button, and on first use, explain that you can "Undo" the "Restart" if you wish.

Discoverability of code completion by cursor keys

I've used a few IDEs before, so I got the hang of the code completion pop up. My son didn't learn that he could use the cursors to select a completion until I showed him, and then he preferred it.

Finishing a dare doesn't take you to the dare menu

When we finished a dare, we had to navigate the system to the menu of dares to pick the next.

I somewhat like this, because it can be fun to continue playing. However JSDares feels like a puzzle game, and puzzle games take you to the next level when you complete one. They let you get back to previous levels to earn more stars if you want to, but that's a secondary action.

Use consistent color hierarchy

It now looks to bloody boring. 'Nuff said.

More dares introducing abstraction (functions)

I was working on the dares last night with my son (8). He made good progress but struggled most with functions. I think the learning curve here is quite a bit steeper than earlier on. Could it be more gentle?

Perhaps add more dares that bring it up in stages? It seems like you get functions in, and then start asking darees to find an abstraction and also build a function to implement it.

I'd suggest:

Maybe more examples using pre-written functions, so you start off just using calls to the pre-written functions (and see that this is like growing new pieces of language, similar to robot.drive() and robot.turnLeft(). This might include just adding extra calls of the existing function.
A further departure could be adding other code between existing calls to an existing function.
Then perhaps an example where you change what is in the function.
Then an example of passing a parameter, perhaps to a square drawing function, and seeing how varying the parameter helps.
Then examples where you build your own functions.

Better error message for "new Array"

Long programs become effectively un-editable

I have my keyboard repeat up fairly high. My son accidentally pasted perhaps a hundred copies of a few code lines in to the program area. It became nearly impossible to edit the code, and deleting single lines was taking seconds each. We managed to select all the pasted code and cut it in a single operation, but it took a while to get back to a nice state again.

Can the environment continue to be "happy" with a long program?

Should there be a limit on program length to prevent this?

Show error message only when hovering

For more consistent behaviour with the arrows, show the error message when hovering over the icon.

Simpler homepage game

Right now the game on the home page is rather complicated. We need a simple game that yet shows the power of the editor.

Click name to go to definition

This might be in there? It'd be nice to be able to option click a function invocation and go to the function, or something.

Grouping solutions by tree edit distance

We can give an overview of typical student solutions by using the tree edit distance to group them.

Preview might be confused with actual output

Right now people may confuse the output in the preview window with the output of the program. We can solve this by showing "preview". Or perhaps it'd be better to restructure the way dares are shown.

Sound effects

I think sound, even if subtle, could be pretty helpful with making the whole experience (even) more tangible.

*Sounds for the bot driving and turning would be good. Picking up a square. Hitting a wall.

Sounds for mousing over the canvas lines, or over code lines, might help to cement the idea that each highlights the other.
Sounds for the scoring of dares.
Sounds for starting a dare.

Etc.

"Highlighting" and "manipulation" buttons should not be necessary

Right now you have to use the "highlighting" and "manipulation" buttons, or use a keyboard command. But it would be much better if this would just work: when you hover a line it should just highlight it, and if you drag a number it should always use manipulation.

No way to retrieve or reset account password

As a user, I've created an account but forgot my password. There's no way to reset my account password on the site. There's no link to click or form to use. The welcome email mentions resetting your password, but the site does not provide a way to do this. Please fix this, so I can log into my account.

Saving programs / history of submissions / reset to initial program

Right now there is no way to go back to an old program (or the initial program). We should add saving each submission, perhaps along with manual saving (but this may be redundant if you also save upon submission).

Q&A / comments

Users must be able to ask community members questions about a dare. We might also add comments for those who've completed a dare.

Oddities when editing a dare's config program

For example:

config.outputs.canvas.enabled = true;

Now when looking at the "config" tab it still shows that the canvas is not enabled. Also when clicking on "true", turning it into "false", and then switching to the "Target program" and back, it shows "true" again.

logging out while on Create page -> inconsistent state

If you are on the Create page and click the Logout button, you are left on the Create page, but showing none of your dares, but the New button is still active.

Refactor thing names by just renaming them

I so often want this in IDEs.

The compiler knows that all these different uses of myDudeX are the same thing. So if I change any of them to mySuperDudesX, they could all update.

There's probably more to this than I expect, such as disconnecting a particular name to fix a bug or make a change, or what happens if you change a name to an existing name, or the empty string…

Support touch based UIs

It didn't seem to work on iPad (of iPhone). I'm not sure if its the same for other touch UIs?

Banging in to walls makes it hard to see how your program works

I think my son (and me, to be fair) sometimes had trouble with understanding (particularly with functions) because our bot was banging in to walls. This is effectively breaking / changing what the abstraction does, which is something else to keep a hold of when you're trying to grok abstraction.

Perhaps the early dares using functions could remove the walls and use an arena you're unlikely to drive out of. They could be more about adjusting the program to see how changing the abstraction changes all instances, or changing the code between calls just effects that code.

The Time Line Is Amazing, But…

It really is amazing. I hadn't realised the bat and ball thing really runs and you can see the time line or values and stuff…

But, it's … really confusing to look at, sorry. It's obviously extremely cleaver, and doing some really impressive heavy lifting, and recording a lot of stuff. But the visualisation isn't helping me to see what is happening much…

… I've come back to this and used it more. I'll leave my original comments in because that was how I initially felt. I'm learning more about it and I'm finding it more useful now. But I've got some suggestions for it.

… and I'm back again! I only now realised as well as as the "current tick's timeline" at the bottom of the screen (which I was talking about in the notes below), there is also a slider for moving around through ticks. I didn't pick up on that until just now!

Current Tick's Time Line & Code Area

Use hysteresis on the code area to stop it jumping about unnecessarily as I move on the timeline selecting near by time points. Only move it if necessary to show the selected execution point, and then, only by enough.
You highlight the executing expression at that time step (great), and show its arguments substituted and its result in a popover (cool). However, it's a pity that the popover information doesn't visually align to the code so that it's easy to see the substitutions being made. Would this be possible? Also, instead of totally covering other lines, just dim them?
The way the code jumps when moving in and out of functions while panning on the time line is disconcerting. Can much be done about this? If the implementation could be seen in place at call point, instead of shown in another place, this might help? That seems like a lot of work though and could have its own issues!

Current Tick's Time Line Itself (at the bottom)

Bring the time line to the bottom of the screen so that I can't inadvertently mouse off it and lose the highlighting of the current step.
Allow the time line at the bottom to be wider than the screen, and to be scrollable:
- Mousing on to the time line should "show" that time point (as now).
- Clicking and holding should scroll the timeline but continue to show the same place.
- (For touch devices make it handle more like a scrubber / scroll wheel).
Ideally, allow the time line to be zoomeable.
Possibly drop the step number labels from the timeline, or just number every tenth and simply dot the rest.
Instead of step numbers show a "graph" of call depth on the time line – this would make it clear where functions begin and end.
Possibly the timeline could be colour coded by the kinds of functions being called. This would reveal drawing, updates, loops, io, etc.

Current Tick's Time Line & Canvas

When a point in time is selected, somewhat dim out canvas stuff that's yet to be drawn. I notice the current time step is highlighted on the canvas – this is cool. Some kind of onion skin effect might work well here. It's great that you can see stuff being drawn as you scrub, but you can't see this if you have selected a function in the code area that draws it (I think?), which I didn't originally realise.

The Granular Time Slider

I much later realised that there is a slider for moving between ticks, as well as the time line for within ticks.

Could these two ways of moving through time (fine and coarse) to be integrated?

Although, in a way, they do have differences: it is almost like two variables as the current UI suggests. But could they be displayed more closely to make their relationship clear?