@jason wrote:
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 (
) 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:
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
balso 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.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.
In the 3rd image, I search for and select “the stage’s left edge” and press enter.
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.
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
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!):
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?
Are my constraints (eg no syntax errors) sensible?
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?
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!
) and typing is hard for kids (and learning to type is not a goal of Beach).
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!):Posts: 9
Participants: 5