Using snap for prototyping/wireframing


I'd like to use snap for creating prototypes of User interfaces. I'd need to have a kind of "textbox" widget. I think I could mimick the radiobutton using several sprites...

Any idea about how to implement this ?

Yes. This has been on my list since forever.

A text box should be a kind of costume that can be worn by a sprite. If I were implementing it just for myself, it'd use a monospace font such as Courier, but I'm sure other people will want to be able to specify a font. (I don't think it's necessary to support font changes within the box, but it should support italics etc.) It will have a flag saying whether or not the user can type into it. It will have a selection (two character positions within the text). There will be functions to convert between character position and row-and-column position. The program can read the text, with or without style settings. (Character codes 1-6 can be used for italics on, italics off, bold on, bold off, underscore on, underscore off.)

It would be useful, but tricky, for a sprite to have both text and picture in its costume. But we can solve that problem with nested sprites. So text boxes will just be text.

On clones of one sprite:

when 7 clicked
switch to costume [off v]
set [last clicked v] to []

when this sprite [clicked v]
tell (last clicked) to ({switch to costume [off v]}>)>
switch to costume [on v]
set [last clicked v] to (my [self v])

thanks for all the hints.

I have just shared my 'wireframe' project, that shows how to create a simple but working text box, I don't know if you can have a look, since I have no idea where the 'share' button does.

this is the code in case you can't see what I shared

After you share a project, the URL up in the browser's URL box can be sent to your friends and they can use it to open the project. In fact, if you look at the top of the picture you posted, you can see (most of) that sharable URL.

Oh, I see, you're using a variable watcher to hold the actual text! That's clever. If you right-click on the watcher and choose "large" from the menu, you'll get just the value without the grey-background label.

this ?

I guess that 'unsharing' it makes it impossible to be changed by a third party.

Nobody can change your copy of your project. Sharing lets people read your project, and then of course they can make their own copy and change that.

I've just made the checkbutton code, trying to place as much code as possible on the "controller" rather than in the individual checks (or radio)buttons.

Now, how can I wrap (and parametrize) those three components ( two checkbuttons and a controller, which mean three different sprites and its code) into a single "sprite" ( object) so I can place them everywhere ?

Look of the checkbutton:


Code of one of the buttons:


Code of the "controller":


You can use the nested-sprite feature, if the point is for them to move as a unit. Grab the sprite corral icon of a checkbox and drag it onto the controller on the stage. Let go when it's in the position you want, relative to the controller sprite.

If the problem is creating them all at once, have a "when I start as a clone" script on the controller that clones the checkbox sprite twice.

But I think your biggest issue is that you can't use BROADCAST that way, if you have more than one of these controller/button combinations. With BROADCAST, clicking a button will unclick all the other buttons, not just the one in the same controller.

So what you need to do is have two "for this sprite only" variables in the controller to hold the two buttons associated with that controller, and a "for this sprite only" variable in each button that points to its controller, and then instead of broadcasting to the world, use TELL to tell the specific sprite you're signaling what to do.

Wow, that's nifty and very cool indeed. Not so easy/evident to see if you are accostumed to textual specifications , instead of handling things...

I've been thinking about this. And you are right. Under an object orientation perspective, this is just saying
my_controller.unclick_button_2() , and you have the objects "radiobutton" and controller, and an attribute (of the radiobutton) that associates both. It's clean,... it's 'imperative'.
BROADCAST is wayyyy too loose and poses the problem of "personalization", of having several different radiobuttons.

I've been thinking in "twisting" the "message" mechanism, by concatenating the 'id' of the object and the message. BROADCASTing allows to have a kind of subscriber-dispatcher model, but , in the long run, it's equivalent to a "straight imperative OOP" call.


I think, the best 'theoretical' ( perhaps not feasible) way would be to "recreate" the entire wireframe from a list, using a 'pic' (, even 'some' adjusting could be computed by "actually letting the block crash and adjust themselves".

An example of data structure (list) describing an wireframe:
'( (textbox textboxname1 labelofit nameofvariable ) ( radiobutton flavour ( vanilla chocolate strawberry ) placed (to-the-right-of textboxname1))

Then that list would be interpreted and the sprites would be created on the fly ( using "reflection" or "dynamic" snap code).

Yeah, that's what you have to do in Scratch, where it's broadcast or nothing. :slight_smile:

I'd love to create new variables programmatically, so that I could create pairs ( textbox, variable_holding value_of_the_textbox). Ideally, I'd read a list such as ( ( textbox nametextbox1 posx1 posy1 variabletexbox1 )
( textbox nametextbox2 posx2 posy2 variabletexbox2 ) ... )

Today's your lucky day. Look in the Libraries list for "create variables in program."

1 Like

Many thanks... That is a big small step forward.