Making Sushi Cards

1. One card, one concept
A card should teach one important concept. What is an important concept? That's the tricky bit – and that's for the card designer to decide. There is no scientific way of defining this!

Ideally a Sushi Card should show example code that illustrates the principle as simply and clearly as possible. Don't be tempted to add in 'side' lessons which show something else. Instead, make these into separate cards. Sushi cards are divided into 3 series, beginner, intermediate and advanced with each series containing multiple Sushi cards.

2. Laminate the cards
The medium is the message – the fact that Sushi cards are two-sided laminated cards is important because they don't look intimidating; learners can move at their own pace and there is never the suggestion that a massive HTML Made Terrifying 300-page tome needs to be digested before the newbie can do exciting things.

Also … laminated cards work because they don’t eat up screen estate when learners are working on small laptops. For instance, if they’re learning HTML, they’ll probably have three or four windows open – so having another open to show the class notes is contributing to serious window management problems.

Finally – lamination will save you time and money. Our laminator cost around €30. The individual laminating pouches are less than 10 cents each. Once you’ve produced your laminated sheet it will last for many weeks of Dojo sessions, in contrast to paper handouts which are usually discarded after one or two Dojos.

3. Practice-led, not theory-led
The approach is practice-led rather than theory-led so that learners see results as fast as possible. We think this mirrors the way most programmers learn anyway. (First take some existing code and hack it, read up the theory only if you can’t figure out what’s going on …)

4. Keep examples short and sweet
Any example code should be as short as possible (to minimise mistyping) and should be as easy to understand as possible – make examples as concrete as you can. Using self-descriptive variable and parameter names is helpful (good programming anyway).

5. Don’t feel you have to explain everything
Don't feel you have to explain everything – it's often better to show some self-descriptive code and then ask the learner the question 'can you figure out what this is doing?' or 'how would you change this to do X'. You’re pointing learners in the right direction, but you're not watching over them for the whole journey.

Also … improvision should be encouraged. Learning examples should be presented in such a way that the learner can riff on the examples and quickly produce new materials which showcase their own interests.

6. Cards should be self-contained
Although the lessons should be built on one another, individual cards should still be fairly self-contained. In the HTML example it's necessary to do the first two or three cards in order, but after the learner has created a basic site cards could be picked up in any order. (Although to make this work, you may need to revisit earlier cards after you add in a later card).

7. Pictures are good
Having the materials look inviting is important. We try to show an end-result that looks exciting and makes learners want to dive in. In the example shown above we use a crossword to demonstrate table layout techniques (rowspan and CSS formatting) mainly because the crossword and suduko puzzles look interesting.

Illustrations also provide valuable feedback that a learner is 'doing the right thing' – in particular illustrations which tie the coding inputs to the expected outputs. They form a reference point which allows learners to verify that what they’re doing is OK.

Try to avoid having English in your pictures due to hassle made when translating

8. The cards will never be perfect – don’t worry!
Whenever you work with learners and use the cards you’ll quickly come across all sorts of errors, imperfections and barriers to comprehension. But don’t worry about it. It’s normal. Just go home and modify them. Each change you make will make the cards easier to use.

9. Follow these beginner headings if in doubt.

 * 1) Setup: How to install or access all necessary software or hardware
 * 2) Output: "Hello World"
 * 3) Input & String
 * 4) Conditional:  If, When, else etc.
 * 5) While loop
 * 6) Game: Number guessing game etc.

These headings are for a beginner series.

10. Remember the core principles of a sushi card.
CoderDojo Sushi is delivered on double-sided laminated cards known as Sushi Cards. One card = one concept. Dojo Sushi is a method of communicating programming concepts which is suited to the CoderDojo environment. Concepts are communicated in Easy-to-digest, bite-sited chunks (hence Sushi).

11. Use colors and paragraphs to prevent a wall of text
Large blocks of text can be intimidating to young Ninja's and tough to read for all. Look at the examples for reference of a good sushi card in term of text readability.

12. Design aims.
Visit http://dojo.soy/style for guidelines to aim for.

More tips

 * You can remind them to ask for a mentor if installing something is too hard
 * Add important Terms in colored boxes
 * Historic tips are welcome, fun facts too
 * Bold terms like copy, paste, click, keyboard buttons etc. (any words that's used a lot and has either been defined or is common computing terms)
 * Instructions should work for both PC and Mac
 * Appropriately colored boxes break the wall of texts and make the text less daunting. There should be at least one yellow box or screenshot on each page. Use this to explain key concepts in simple language.
 * Always try end a series for the Ninja's to play around with i.e. making music with a Raspberry Pi,  a game in Python, a webpage in HTML/CSS. Encourage them to tweak and explore what they've done.
 * Needless to say a child will not understand a lot of big words, use basic language and don't make a comparison to something they wouldn't understand like a bank or job.