Beach design crit


#1

Hello friends! I have been actively at work designing Beach but recently I’ve hit a bit of a wall. I’m stuck designing a fundamental part of the app and I was curious if anyone would be interested in doing a sort of design critique of what I’ve got so far? What follows might be a bit long, but I’m trying to give as much information / context as possible so you know we’re I’m coming from.

Some context

As mentioned elsewhere, Beach is a computing environment for kids. For the sake of the discussion here, you can think of Beach as a vector drawing tool (like Sketch), but where you can also give your graphical objects (shapes / drawings / etc) some behaviours (I’m currently referring to these behaviours as “scripts”).

Beach is currently being made for the desktop (Mac), which means a person using it has a mouse and a keyboard, but no touch interface.

The main UI is a zooming and infinitely scrollable canvas (again, kinda like Sketch). This was chosen to allow you to arrange your projects spatially (something I quite love doing in Sketch) and to drive home a sense of interconnectedness between your various objects and projects. Where a traditional programming environment has programs in discrete files (and thus windows / tabs), in Beach everything is in a continuous, scrolling expanse. Want an overview of your project? Zoom out! Want to see things that are related? Zoom out, scroll over a bit to a related area, and zoom back in to it.

So far in my prototypes, just about everything lives in this zoomable / scrollable space. That means, when you create a new place for your objects (I’m currently calling this a “stage” and it’s similar to an artboard in Sketch) it exists in the space; when you double click an object to see its properties / methods (currently calling this an “inspector”), or when you make a new script, all of these things open in the same scrollable area (they’re kinda like windows, and currently they aren’t meant to overlap). Here’s a rough picture to illustrate:

(top left: a stage with a car object on it; bottom left: a bit of an untitled script; right: a bit of the inspector for the car object)

A “script” in Beach is where the programming happens. As you might guess, a script is similar to a function in a plain text language — a reusable unit that can be invoked elsewhere. In my current design, my scripts are kind of text heavy (I’d love to change this, but my thinking is quite trapped by years of text programming languages! open to suggestions on this!). Here’s a rough example of what one might look like:

(At the top of the script is its name, followed by a description of what it does, followed by the “instructions.” I don’t love the look of this yet (the yellow pills are far too attention grabbing and there’s not a coherent overall style, but you hopefully get the gist))

That’s the overall environment of Beach as it stands today.

Where I’d love design help

With that context in mind, what I’m trying to design now is “how do you make a script?” (or more accurately, how do you get instructions into a script?). This is a major part of the programming aspect in Beach, and it includes adding and editing instructions.

It’s probably not obvious from the pictures, but scripts in Beach are meant to have no syntax errors (so if it helps, you can think of instructions as “blocks” like you’d have in Scratch / Hopscotch; I don’t like the visual style of blocks, but I am a big fan of how the disallow syntax errors). So, instructions in Beach have the constraint that they should always “compile” and should not allow you to have a syntax error (this means that instructions can’t end up in the program in an “incomplete” / half-written state, unless the language has some kind of “this instruction exists, but is currently not connected to the rest of the program because it’s not yet valid” state, but I’m not sure about this).

Some things I have so far explored:

  • Something like Scratch / Hopscotch. In those apps, you have a sidebar / “library” that lists all the blocks available to you. This has the benefit of recognition over recall (that is, you see what you can program with, instead of needing to remember what exists) and things are grouped together by theme (geometry, pen drawing, sounds, control structures, etc).

    But this style has some drawbacks, too. Blocks are cumbersome, especially dragging and dropping them with a mouse. It’s hard for me, even as a proficient adult, to drag them with a mouse (and Beach is designed for kids!). Building any kind of complex statement (say, with math), involves a lot of dragging and dropping of blocks. What bothers me about this isn’t that it’s slow, but that it’s tedious enough to discourage you from thinking with blocks (compare this to typing in a text editor: personally, I’ll often figure out an algorithm by typing out a crappy idea, reacting to it, and refining it; I’m not sure blocks in something like Scratch support this way of thinking).

    (A good paper I came across recently discusses some aspects of blocks.)

  • Something like Bret Victor’s Stop Drawing Dead Fish programming UI that watches what you do on the canvas and records “steps” as you do things (and you can later edit / abstract the steps). I’ve played around with this briefly but found it kind of stressful: almost every change you make gets recorded, which kind of made me less certain whether I should make them. It felt harder to have messy fun when every step was going to be recorded.

So, having a library to choose from is good (especially if it can handle thousands of objects you might want to access), but drag and drop kind of stinks (and is made worse by having a large scrollable canvas). I like the idea of typing but the way typing works in typical languages allows for syntax errors (:no_entry_sign:) and typing is hard for kids (and learning to type is not a goal of Beach).

My current design tries to mix and match both worlds (here’s a very rough wireframe):

Here’s what’s happening in the picture:

  1. There’s a “test if” instruction that needs a condition, and I’ve clicked in the empty box for the condition. This shows me a dropdown window that lets me type. I’ve typed bal so far. The things shown below the search box are things I can use to make my instruction, like “ball overlaps a certain object” or “ball’s position…” I’ve chosen “ball’s left edge…” and pressed enter.

  2. The “…” on “ball’s left edge…” means that I need to add more to this statement (because “test if ball’s left edge” isn’t a complete / valid instruction). So in the second image, you see the first part of my instruction has appeared above my search window and is floating there. Now I search for and select “is greater than a certain object” and press enter on that.

  3. In the 3rd image, I search for and select “the stage’s left edge” and press enter.

  4. In the 4th image, the parts I have selected are now enough to create a valid instruction: “test if ball’s left edge is greater than the stage’s left edge” and I press the “Done” button to insert this instruction.

  5. The 5th image is just the final, completed instruction.

The idea is roughly: search for what you want by typing, and build your instructions that way. It’s kind of like autocomplete, but doesn’t let you “commit” half-made instructions to the program.

Now, I really don’t like this design :sweat_smile: but it’s kind of what I’ve got so far. It hits a lot of what I’m after but it’s obviously quite strange / all over the place and I’m kind of stuck here. Here’s some feedback I’m specifically looking for (but I’ll be happy with any kind of feedback, really!):

  1. Ideas for how “scripts” should work, broadly. What I’ve built is quite text-ish, even though it’s not made of plain text (I’d like to have special notation for writing out math equations, and in another design not shown here, I’ve incorporated data viz tools directly into the script — but even then, the script itself is still quite wordy). Is there a better way I should think about scripts?

  2. Are my constraints (eg no syntax errors) sensible?

  3. General thoughts on how to build instructions? What are good alternatives here? Am I correct in feeling drag and drop is not a good way of building programs?

  4. Does my current design make any sense? How should I better approach this (both in terms of things I can change, and also like, a meta approach to getting better at figuring these things out)? I am pretty new at design!

Phew! OK I think that’s about it. Sorry for the humongous wall of text here!! I’m really interested in getting feedback about this, but I realized I haven’t explained very much of what Beach is all about, and I thought the context would be helpful in explaining what I’m trying to accomplish. Please let me know if there’s anything I can clarify!


#2

One thought: can you have multiple ways to input? So you can drag and drop, or you could do a typeahead search, maybe even use the mouse arrows to select a function then press enter to confirm?
I think different people and different situations might require different inputs. In a more exploratory mode, or for a beginner/younger kid you might want drag and drop, if you’re not using a lot of different functions drag and drop is fine. As you get more advanced you want to use keyboard shortcuts to move faster, especially when you already know what you want to do. This is basically how it works with sketch I think.

Another thing to consider is that many of the most interesting and important things you’ll want to do might not involve a lot of functions but rather manipulating a small number of functions in interesting ways. I’d encourage you to notice when your beach code starts to feel tedious and think about whether there’s another way to express what you’re trying to express. The bumping code in beach, for example, looks a little bit unwieldy. Maybe there are language features that could make it easier to express this.
One tip: I find it useful to ask non-programmers how they would do something and try and see if I can make the language work in that way.
I once asked liza how she’d make a grid and she told me she’d draw three vertical lines then three horizontal to make squares. That was a completely different than anything I’d been thinking of before and it led to some really intereating ideas.


#3

Hey Sam, thanks for writing this thoughtful reply and sorry for taking so long to respond to it! (been travelling this week :sweat_smile:)

This is a great point, and something I’ve been thinking but hadn’t quite articulated in my design so far (roughly: you can type to narrow down the list of suggestions, but you can also just scroll and click / select+enter on a thing in the list). But I’d love to explore this more. Are you suggesting something like “library of all parts in a sidebar, but also the “type-ahead” thingy I’ve shown here “at the cursor”?

This is intriguing, could you elaborate more on what you mean here?

This has definitely been on my mind a lot. The example I showed above is totally unwieldy and probably not the best example I could have shown. It could be better expressed maybe either as some kind of property (like “reverses velocity on bump”) or maybe a “when” (like “run this script when I bump the wall”), or maybe even just put in its own script — distinct from the “scale the velocity down every instant” script (at these point, they’re less like scripts and more like processes).

I love this suggestion and am definitely going to do that!


#4

I agree Stop Drawing Dead Fish can be stressful, but maybe there’s a better approach: what if Beach used gesture recognition and transcribed the actions into code? The kid could move the car, rotate it etc. and the code instructions would appear in real time as text. Then the kid can just edit the text to make adjustments. Now, the cursor position determines the state of the preview – since the code is a linear sequence of instructions it can be treated like a timeline, of which the cursor is the playhead. Previewing the different states of the code, skimming through it, would be as easy as moving the cursor up or down.
If the kid wants to inline another move, it just moves the cursor to that position and starts moving the car or typing code. Either way, since the cursor moves with the text, the kid will always see the impact of it’s most recent action. When the code is to be run, a play button can jump the cursor to the end of each instruction in order of their appearance.

What I like about this is the simple UI the end-user faces. It’s a graphics app on one side, and code on the other. No blocks, no menu’s, no drag-and-drop. You do graphics in one and code in the other.


#5

I think you’d greatly simplify this issue if you re-evaluated whether disallowing errors from partial input or syntax errors is actually a good thing. For sure, if you can never go wrong then that could be comforting.

However,

  1. Never being able to go wrong puts a ceiling on potential expressiveness
  2. And syntax errors aren’t the frustrating part of coding - shitty and unfriendly debugging tools and obscure errors are
  3. Taking a cue from videogames, errors/failure states can actually be a great teaching opportunity, of course assuming you know what went wrong and why. (I actually have an old blog post about this)
  4. Failing/succeeding immediately on input, with no latency, is an effective way to interactively teach

Even though it’s a very diff product we explored a lot of these issues while making HyperDev/Glitch, my conclusion was that the real root of frustration that turns people off of anything is when the system feels unfair or randomly capricious.


#6

I definitely agree with your goal of avoiding a system that feels unfair or randomly capricious, but I think you can achieve that without having syntax errors.

A program is a document format (just like the Photoshop format, or the Word format, etc), but unlike basically every other document format out there, program source code can be in a busted state at any given time. I think that’s kind of backwards (imagine how unacceptable it’d be if a Word doc could be in a format such that it wouldn’t even render!), and I think it impedes programmers, especially kids.

Now, as far as accomplishing how to do the “no error” UI, that’s the big question! Because as you say, if you’re not careful, it could put a damper on expressiveness (it’s one of my explicit goals to not do this). And if you have a system where you can only input something if all your bits are juuuuuust so, then that’s going to be infuriating. So a better way around it (/me waves hands) is to have a UI that allows for unfinished / scrap thoughts. The problem with so many Blocks-based UIs is they sort of implicitly act as though you know exactly what your program is going to be and let you assemble it. But that’s not really how I program at all: I usually start with a shitty version of things, half typed lines, algorithms that are wrong / don’t handle edge cases, etc. and then I gradually massage it into something more solid. Every programming UI should support that, and it’s one thing that text programming does an OK job of today.

I would argue that especially for young programmers, syntax errors are indeed a major source of frustration (in addition to shitty debugging tools and obscure error messages! we can have it all!). I think the point I’m trying to get at is I view the “no syntax errors” thing as a starting point, necessary-but-not-sufficient, a bare minimum. But I can’t just say “no syntax errors” and call it a day, because that could impede creativity / expressiveness, as you say.


#7

I think that makes sense, and is a good principle to stick to.

At a high level, I can think of a couple ways to do ‘no errors’:

  • allow users to input partially complete or incorrect input but only compile when it’s valid. This would ensure the document is never broken. With this approach I think you’d be leaning on a linter style approach that hints users in the right direction when their input can’t be compiled yet. This (and comments) also supports the use case of iteratively refining a rough draft.

  • a sandbox for scrap thoughts. Having one place for some types of expression and one for another, feels like it might be a chore tho imo. Maybe an alternate analogy for this is comments? Where you define ‘safe’ areas inline with your script that you can just think things through?

  • I agree with you on the problem with blocks based UIs. The other consideration I’d hold against blocks that text is super easy to copy/paste and share with other people in a way that custom GUI things just aren’t on computers today.


#8

Hey @Jason, I come across this discuss site recently.
This post is interesting ! Are you still working on Beach ?

Me, as a visual learner, I would like images of a ball and arrows signaling the top, left, bottom of right edges to make the code visual. Could also be with the stage.
Maybe even have both representations: textual and visual. I just thought about it because you said that you would like to really on text less.

Anyway Beach looks really cool, I would like to give it a try, or see the code if it’s open source.
Best.


#9

Hi Daniel,

Sorry for the tremendously slow reply. Beach is still in slow, ongoing spare-time development. As it has a tendency to do, life has gotten in the way a bit.

I hope to have Beach out some time this millennium :slight_smile: