I love decker. Recently I helped my 6yo build an automated score card for her favourite board game in it. The blend of visual and code is about right for her to be able to see results right away. Especially with the storing results in widgets like is talked about here that makes debugging easier by seeing the bad state with your eyes.
I read this last night, and it really helped me change my thinking around building UIs in Decker. I’m planning on writing a Boggle game for DeckMonth and will use a bunch of this to improve my code.
I’m glad this had some helpful ideas, and I’m looking forward to seeing your Boggle implementation!
The sync/async styles of writing scripts for animation, the concept of reifying persistent state in widgets, and the importance of choosing representations for data and parameters which support “direct manipulation” as much as possible are all ideas I consider important, but often struggle to convey to beginners outside specific concrete examples.
I love decker. Recently I helped my 6yo build an automated score card for her favourite board game in it. The blend of visual and code is about right for her to be able to see results right away. Especially with the storing results in widgets like is talked about here that makes debugging easier by seeing the bad state with your eyes.
I read this last night, and it really helped me change my thinking around building UIs in Decker. I’m planning on writing a Boggle game for DeckMonth and will use a bunch of this to improve my code.
I’m glad this had some helpful ideas, and I’m looking forward to seeing your Boggle implementation!
The sync/async styles of writing scripts for animation, the concept of reifying persistent state in widgets, and the importance of choosing representations for data and parameters which support “direct manipulation” as much as possible are all ideas I consider important, but often struggle to convey to beginners outside specific concrete examples.
For anyone interested there is an episode in Arraycast