Scratch

nXIII · 2012-11-26 16:38:03

Jens wrote:
Just ask those who are really using them to build systems and not just shiny web pages.

I made an IDE out of DOM elements. It was easy, it works fine, and it has all of the features, speed, and platform integration I expect from a native app.

So, some buttons in Snap! don't always have keyboard control because keyboard input is directed to somewhere else, e.g. the stage!

Buttons in Snap! never have keyboard control because they can't have focus. At all.

Claiming that widgets respond to mouse input "incorrectly" just because it differs from what your OS does disappoints me.

When you press the mouse to scroll in a pane, move it, and release it over a button, it clicks the button. Is that correct? When you press the mouse on a button, move the mouse off, move it back on, and release it, it clicks the button even though it doesn't have its active state. Is that correct? When you click a button in the dialog and try to cancel your action by moving the mouse outside of its bounds, it drags the dialog. Is that correct? No. It's not. It doesn't have to be "what my OS does." It has to be what the user expects. Snap! fails to do what the user expects.

I am keeping Snap! small, snazzy and so easy to understand, that even hobbyist kids are able to play with its source.

I don't believe that sacrificing quality for simplicity is appropriate.

@bharvey you can solve your problem with DOM, it's just that the current implementation doesn't. We're already dealing with the multiple-OS problem, and changing to DOM controls isn't going to change that.

bharvey · 2012-11-26 17:11:07

nXIII wrote:
you can solve your problem with DOM, it's just that the current implementation doesn't.

Ah, time for the Iron UI Chef bake-off! Next time I'm in your neck of the woods I'll bring the tablet along... tongue

shadow_7283 · 2012-11-26 17:43:43

nXIII wrote:
I don't believe that sacrificing quality for simplicity is appropriate.

Then why are you using a Mac in the first place? tongue

@Jens: I'm in complete agreement. As a web design enthusiast, it's difficult enough to be compatible in one web browser- much less the wide range that users employ. I agree with your decision to keep Snap's GUI platform independent.

But honestly, I think this entire issue isn't that important anyway.

Last edited by shadow_7283 (2012-11-26 17:44:14)

nXIII · 2012-11-26 18:37:23

shadow_7283 wrote:
nXIII wrote:
I don't believe that sacrificing quality for simplicity is appropriate.
Then why are you using a Mac in the first place?

I'm using a Mac because it has a user interface a hundred times superior to Windows, and achieves quality through its simplicity of interface rather than losing quality in the interest of simplicity of code.

@Jens: I'm in complete agreement. As a web design enthusiast, it's difficult enough to be compatible in one web browser- much less the wide range that users employ. I agree with your decision to keep Snap's GUI platform independent.

Platform independence is a hard concept to define, but it's certainly not having your application look exactly the same in every browser and operating system. Platform independence is providing your users with the functionality they expect in a browser- and operating-system-agnostic way. Users expect different things from an application, but almost every user agrees that an application should behave more or less in the same way as all of the others on his/her computer. When it doesn't, it can be very confusing and hard to use, because it disregards many of the concepts and conventions with which the user is familiar.

As a web-based application, it's hard for Snap! to act exactly like native applications on a user's computer. However, browsers provide implementations of DOM elements for each operating system which closely mimic or actually have the behavior of their native counterparts. They do this so that web applications don't need to worry about reproducing the behavior a user is accustomed to on his/her platform: the browser takes care of that, and all web applications have to do is use the cross-operating-system, cross-browser components that HTML provides. It might not look exactly like a native app, but it looks and feels close enough that it's not confusing or hard to use.

Snap! doesn't use any of the DOM elements the browser supplies. Instead, it provides bare reimplementations of some common controls, which ignore the user's browser and platform. These controls look sort of like the native ones, so when users encounter them they expect them to behave in the same way native controls do. They don't, and this makes it very hard for users to use Snap! as fluently and easily as they use native applications on their computer.

Snap! doesn't need to support Firefox on Windows, Firefox on OS X, Firefox on some Linux distribution, Chrome on OS X, Chrome on Windows, Chrome on some other Linux distribution, IE6, IE7, IE8, IE9, IE10, Safari on Windows, Safari on OS X, Opera on Windows, Opera on OS X, and every other browser on every other platform.

Snap! just needs to support web browsers. The web browsers will take care of the rest, and will make Snap! behave just like each user expects.

Last edited by nXIII (2012-11-26 18:37:57)

xly · 2012-11-26 18:56:29

@Jens &bharvey
To say it simply, but in latin "De minimis non curat praetor".
While some are splitting hairs with keyboard controls, you are going to achieve a real "masterpiece" by combining 3 quasi-revolutionary inventions Scratch, Javascript (*) and First-Class concept.
Keep steady, my grandson is fully supporting you !

(*) at the beginning just a way to write small Html scripts, and consider it now !!!

shadow_7283 · 2012-11-26 19:03:06

Not going to rehash the old Mac v. PC argument, I've already made my argument multiple times concerning that topic.

nXIII wrote:
Platform independence is a hard concept to define, but it's certainly not having your application look exactly the same in every browser and operating system.

Now you're just nit-picking... from Stack Exchange

Software that is platform independent does not rely on any special features of any single platform...

I've cited Blender earlier, but I'll be more clear about why I think platform independence is a very viable option.

Blender works exactly the same on a PC as a Mac, the same on Linux and FreeBSD. Its inputs are thoughtfully designed, with practical aesthetics and usability. With a very small learning curve, Blender's developers can effectively organize the plethora of options that are present with unparalleled control over their functionality.

I'm not suggesting that Snap! should replicate this particular design by any means, but simply showing a quality example of GUI platform independence.

No one is suggesting that Snap! should have sub-par inputs. Quite the opposite in fact. I think Jens has done a remarkable job recreating the universal DOM elements we're familiar with. Despite minor differences, he struck a balance appealing to the fundamental usability of each element, regardless of the operating system or browser one uses. You can pick up a completely unfamiliar computing device and use Snap! successfully. Users have the comfort of knowing that when they open Snap! again, even from another location, it'll still work exactly the same.

Last edited by shadow_7283 (2012-11-26 19:25:47)

nXIII · 2012-11-26 19:08:02

shadow_7283 wrote:
nXIII wrote:
Software that is platform independent does not rely on any special features of any single platform...

Um…I didn't write that…
EDIT: I figured out where that's from. It's from Wikipedia, and the full definition reads:

Software that is platform independent does not rely on any special features of any single platform, or, if it does, handles those special features such that it can deal with multiple platforms.[citation needed]

I want Snap! to rely on browsers' cross-platform nature to provide the platform-specific features Snap! users expect while remaining platform- and browser-agnostic.

EDIT:

I think Jens has done a remarkable job recreating the universal DOM elements we're familiar with. Despite minor differences, he struck a balance appealing to the fundamental usability of each element, regardless of the operating system or browser one uses.

You can't even enter non-ASCII characters without the help of a tiny invisible DOM input, and all the other features I cited above still don't work.

Last edited by nXIII (2012-11-26 19:31:30)

shadow_7283 · 2012-11-26 19:31:21

I know you're committed to the quality of Snap! but frankly, Scratch's "poor" implementation of a platform independent GUI didn't drive you or any of its other users away. Clearly we're at an impasse as far as what constitutes quality design.

Snap's usability issues are minor and hardly noticeable, and your lack of appreciation for Snap's current state of being (at least as far as its GUI is concerned) is a little harsh.

My posts may indicate otherwise, but:

shadow_7283 wrote:
I think this entire issue isn't that important anyway.

Last edited by shadow_7283 (2012-11-26 19:33:03)

nXIII · 2012-11-26 19:37:17

shadow_7283 wrote:
I know you're committed to the quality of Snap! but frankly, Scratch's "poor" implementation of a platform independent GUI didn't drive you or any of its other users away.

I constantly wish Scratch would have text fields and buttons and menus that work like all my other OS X ones. I just use Scratch because it's the best option which currently exists.

Snap's usability issues are minor and hardly noticeable

They may be minor to you, but accessibility and usability are hugely important to me. I notice these things every time I use Snap!.

your lack of appreciation for Snap's current state of being is a little harsh.

I'm offering constructive criticism. If nobody pointed out or cared about the things Snap! doesn't do well, there'd be little reason for anyone to fix them.

EDIT: You edited your post.

EDIT: Almost off-topic, but:

Not going to rehash the old Mac v. PC argument, I've already made my argument multiple times concerning that topic.

Macs are personal computers, too!

Last edited by nXIII (2012-11-26 19:45:14)

shadow_7283 · 2012-11-26 19:48:52

nXIII wrote:
Macs are personal computers, too!

Better tell Apple that so they can fix their Mac v. PC commercials. Oh, and the thousands of journalists who use my particular usage in their articles.

EDIT: You edited your post.

EDIT: What of it? wink
EDIT2: That quote WAS from Stack Exchange, looks like a Wikipedia author thought they would be smart and copy paste.

Last edited by shadow_7283 (2012-11-26 23:06:13)

bharvey · 2012-11-26 20:32:19

nXIII wrote:
Macs are personal computers, too!

Personal computers, but not PCs; "PC" is, or at least
used to be, a trademark of IBM. For a long time other
manufacturers were careful to say that they made
"PC-compatible" computers, rather than PCs.

[/offtopic]

nXIII · 2012-11-26 21:15:14

bharvey wrote:
nXIII wrote:
Macs are personal computers, too!
Personal computers, but not PCs; "PC" is, or at least
used to be, a trademark of IBM. For a long time other
manufacturers were careful to say that they made
"PC-compatible" computers, rather than PCs.

[/offtopic]

Oh, good to know. smile

PS: Why the line wrapping?

bharvey · 2012-11-27 00:44:27

nXIII wrote:
PS: Why the line wrapping?

Oops. Because I'm old, and until quite recently read my mail in /usr/bin/mail, which is to say, without fancy auto line wrap, and I'm still in the habit of ending my lines with the return key, just like on a real typewriter. Every time I post on a modern computer system I have to struggle to remind myself not to do that.

Hardmath123 · 2012-11-27 08:15:10

@Jens: "Polluting" with DOM? Really? With all due respect, people have made some pretty great things using DOM, some of them (almost) better than Snap!

Take Waterbear. It's a simple language, lets you drag and drop blocks like Scratch, but is written using JS, HTML, and DOM. All the controls are easy to learn and everything works very well. If only they had lambda...

Another example is ThreeNodes. It uses Three.js for the 3D rendering and SVG for some additional stuff, but is mainly made up of plain ol' vanilla DOM. And the results are impressive.

So DOM isn't exactly a pollutant, it depends on what you make of it. smile

Jens · 2012-11-27 08:42:28

Of course the DOM isn't a pollutant, but I don't want any of it in Snap! because it would pollute Morphic.js. Incidentally your examples are great reasons why. ThreeNodes doesn't run in any of my numerous browsers except FF, and Waterbear..., well, if you really think lambda is the only thing that's missing there, what are you waiting for? It's all open source and they're looking for contributors!

Thing is: Everybody is using the DOM to make web stuff. Some of it is very cool, some of it isn't. I've designed Snap! to be Morphic and I don't want it to look like anything else except maybe a lot like BYOB 3 and Scratch 1.4. That's what I'm aiming for, and - with all due respect smile - I believe Morphic delivers just that, and it does so quite elegantly.

Most of the stuff that's bothering platform fanatics is also "missing" in Scratch 1.4 / BYOB 3.

Again: There are zillions of projects out there which are not using Morphic.js as a kernel. Some of them even look a lot like Scratch (e.g. Waterbear). If you're looking for a project to which you can contribute with DOM know-how, join any of them or start your own project.

Mine's Morphic.

Last edited by Jens (2012-11-27 08:44:15)

iTweak0r · 2012-11-27 15:07:15

jji7skyline wrote:
Where is the make list button?

It used to be there, but now everythings more "codey."

How to do it: Make a variable, then set it to an empty (list >) block.

iTweak0r · 2012-11-28 14:51:44

It's cool that "Snap!" runs on my iPad! Then I can program BYOB/Scratch stuff on the go.

Thanks Jens for making Snap! smile

joefarebrother · 2012-11-28 16:07:03

Can't the invisible DOM element simply copy it's text straight into the text box whenever it changes? Like:

Code:

WhateverMorphItIs.prototype.init = function(whateverArgsTherIs){
  ...
  self = this;
  DOM_Element = document.createElement("input");
  DOM_Element.onchange = function(){
    self.text = DOM_Element.value;
  };
  ...
}

That way there can be copy, paste, undo, redo, speech to text, virtual keyboard, all without "polluting" the platform-independent GUI.

blob8108 · 2012-11-28 17:17:20

bharvey wrote:
blob8108 wrote:
I think I've done it!
Yay! That's terrific.

[...]

So, finish it up and send Jens a diff!

Okay, so here's a screenshot of how I'm getting on. Following the instructions here, I've copied my changes into a separate changeset file.

I've certainly fixed the crashes caused by the infinite recursion; I still haven't quite made a nice UI to replace it. I'm working on the license plate idea, but I've just hijacked the list's length label for now. List watchers still don't expand to fit their contents (not sure how to do that).

So, some questions in response to your post...

I don't understand how this first example is circular — as subsequently updates to foo do not affect "item 4 of foo". "All but first of" seems to have copied the list object.

I do get the circularity here. I'd forgotten about improper lists... tongue Is this one worth fixing, though? It's not causing Snap! to crash, or anything... Is there a significant advantage to being able to identify the lists as related?

Why isn't the "license plate" placeholder in the head of the list, referring to the "body" below? Just wondering... smile

What do you think?

Brian — can I also (cheekily) ask if you know where I could find some good algorithm-y-type problems? I have a CS university interview next week, and they suggested I try some "algorithmic problem-solving tasks, perhaps from first-year university courses"... Thanks! smile

bharvey · 2012-11-28 21:19:55

blob8108 wrote:
List watchers still don't expand to fit their contents (not sure how to do that).

Ah, luckily, Jens has just fixed this, so all list watchers (even in speech balloons etc) are expandable by dragging the corner.

I don't understand how this first example is circular — as subsequently updates to foo do not affect "item 4 of foo". "All but first of" seems to have copied the list object.

Oh dear, you're right, I wasn't thinking through the implications of the way we implemented lists. Try this example:

EDIT: Wait, no, this isn't circular either! Jens, why not? It should be!

Is this one worth fixing, though? It's not causing Snap! to crash, or anything... Is there a significant advantage to being able to identify the lists as related?

Oh, yes, aside from the fact that we should do things right, given that we know what "right" is, you need to know if a list is circular because if so, modifying it in one place will also change what you see in other places. And also, circular lists don't exactly have lengths. (Neither do improper lists btw.)

Why isn't the "license plate" placeholder in the head of the list, referring to the "body" below? Just wondering...

Because (see above corrected example) the circularity may not refer all the way back to the front of the list. Yes, ideally I should put the license plate above a particular element rather than next to it, I guess.

can I also (cheekily) ask if you know where I could find some good algorithm-y-type problems? I have a CS university interview next week, and they suggested I try some "algorithmic problem-solving tasks, perhaps from first-year university courses"... Thanks!

Oh, you know, do a dictionary search of a sorted array; implement Quicksort or mergesort; find the median item in an unsorted array in linear time.

Or find whether a list is circular in time linear in the number of unique elements. smile

Count the number of ways of counting out a given amount of money using pennies, nickles, dimes, and quarters (or the equivalent wherever you live -- not the US, I'm guessing, since you have "cheekily" in your speaking vocabulary and since they actually interview undergraduate applicants where you're applying).

PS Nothing cheeky about it. I'm a teacher; you're a student; this is what I do! "Could you lend me some money," that would be cheeky. smile

Last edited by bharvey (2012-11-28 22:08:00)

technoboy10 · 2012-11-28 21:53:37

Hey all! I've been playing with Snap! on the iPad mini, and it works pretty well except for a few things. The text inputs default to caps lock, and the iOS touch-and-hold to move the text cursor. Any way to fix this?

Hardmath123 · 2012-11-29 05:25:48

bharvey wrote:
Count the number of ways of counting out a given amount of money using pennies, nickles, dimes, and quarters (or the equivalent wherever you live -- not the US, I'm guessing, since you have "cheekily" in your speaking vocabulary and since they actually interview undergraduate applicants where you're applying).

That's from Structure and Interpretation of Computer Programs, isn't it? I've had that book for months now, with no time to dig in. sad

blob8108 · 2012-11-29 10:23:02

bharvey wrote:
blob8108 wrote:
List watchers still don't expand to fit their contents (not sure how to do that).
Ah, luckily, Jens has just fixed this, so all list watchers (even in speech balloons etc) are expandable by dragging the corner.

I mean that they don't automatically grow so you can see all of their contents. I get some odd layout issues sometimes, too (but I think that's just my code).

Why isn't the "license plate" placeholder in the head of the list, referring to the "body" below? Just wondering...
Because (see above corrected example) the circularity may not refer all the way back to the front of the list. Yes, ideally I should put the license plate above a particular element rather than next to it, I guess.

Okay, this is getting complicated. Are you thinking something like "set x to (1 in front of (2 in front of x))"?

Showing the LP (shorter name?) next to it makes sense, I think. I just need to figure out how to implement that.

Or find whether a list is circular in time linear in the number of unique elements.

I don't understand this one. (Which is probably ironic... tongue ) If it's not nested, you can just do:

for item in list:
if item is list:
return item

If it is nested, I don't see how it can be linear time. How can you not use a recursive algorithm to iterate over a tree-like structure?

Hardmath123 wrote:
bharvey wrote:
Count the number of ways of counting out a given amount of money using pennies, nickles, dimes, and quarters
That's from Structure and Interpretation of Computer Programs, isn't it?

I thought the same — I've been reading the first chapter of SICP over the past few days. (The new Kindles have this awful feature that predicts how long it will take you to finish, and for SICP it claims about 16 hours...) Maybe I should try some of the other exercises from that? Though I thought it was more about language theory...

bharvey wrote:
or the equivalent wherever you live -- not the US, I'm guessing, since you have "cheekily" in your speaking vocabulary and since they actually interview undergraduate applicants where you're applying.

Yes, yes — I'm in the UK. That's very observant of you!

PS Nothing cheeky about it. I'm a teacher; you're a student; this is what I do! "Could you lend me some money," that would be cheeky.

Heh, okay tongue Thanks anyhow!

joefarebrother · 2012-11-29 11:04:52

bharvey wrote:
And also, circular lists don't exactly have lengths. (Neither do improper lists btw.)

wouldn't that be only if the circularity is on a cdr? So like if it was scheme,

Code:

(set-cdr! pair pair)

but the length would still be defined it you did

Code:

(set-car! pair pair)

Am i right?

bharvey · 2012-11-29 12:07:09

Hardmath123 wrote:
That's from Structure and Interpretation of Computer Programs, isn't it? I've had that book for months now, with no time to dig in.

When you finally get around to it, you will look back on whatever now seems more urgent to you than reading SICP and think, "ah, in my naive, callow youth, before SICP, I didn't understand the true meaning of life."

No smiley. This is seriously profound stuff.

Scratch

archived forums

#6326 2012-11-26 16:38:03

Re: BYOB 3 - Discussion Thread

Jens wrote:

#6327 2012-11-26 17:11:07

Re: BYOB 3 - Discussion Thread

nXIII wrote:

#6328 2012-11-26 17:43:43

Re: BYOB 3 - Discussion Thread

nXIII wrote:

#6329 2012-11-26 18:37:23

Re: BYOB 3 - Discussion Thread

shadow_7283 wrote:

nXIII wrote:

#6330 2012-11-26 18:56:29

Re: BYOB 3 - Discussion Thread

#6331 2012-11-26 19:03:06

Re: BYOB 3 - Discussion Thread

nXIII wrote:

#6332 2012-11-26 19:08:02

Re: BYOB 3 - Discussion Thread

shadow_7283 wrote:

nXIII wrote:

#6333 2012-11-26 19:31:21

Re: BYOB 3 - Discussion Thread

shadow_7283 wrote:

#6334 2012-11-26 19:37:17

Re: BYOB 3 - Discussion Thread

shadow_7283 wrote:

#6335 2012-11-26 19:48:52

Re: BYOB 3 - Discussion Thread

nXIII wrote:

#6336 2012-11-26 20:32:19

Re: BYOB 3 - Discussion Thread

nXIII wrote:

#6337 2012-11-26 21:15:14

Re: BYOB 3 - Discussion Thread

bharvey wrote:

nXIII wrote:

#6338 2012-11-27 00:44:27

Re: BYOB 3 - Discussion Thread

nXIII wrote:

#6339 2012-11-27 08:15:10

Re: BYOB 3 - Discussion Thread

#6340 2012-11-27 08:42:28

Re: BYOB 3 - Discussion Thread

#6341 2012-11-27 15:07:15

Re: BYOB 3 - Discussion Thread

jji7skyline wrote:

#6342 2012-11-28 14:51:44

Re: BYOB 3 - Discussion Thread

#6343 2012-11-28 16:07:03

Re: BYOB 3 - Discussion Thread

Code:

#6344 2012-11-28 17:17:20

Re: BYOB 3 - Discussion Thread

bharvey wrote:

blob8108 wrote:

#6345 2012-11-28 21:19:55

Re: BYOB 3 - Discussion Thread

blob8108 wrote:

#6346 2012-11-28 21:53:37

Re: BYOB 3 - Discussion Thread

#6347 2012-11-29 05:25:48

Re: BYOB 3 - Discussion Thread

bharvey wrote:

#6348 2012-11-29 10:23:02

Re: BYOB 3 - Discussion Thread

bharvey wrote:

blob8108 wrote:

Hardmath123 wrote:

bharvey wrote:

bharvey wrote:

#6349 2012-11-29 11:04:52

Re: BYOB 3 - Discussion Thread

bharvey wrote:

Code:

Code:

#6350 2012-11-29 12:07:09