New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

long text input #740

Closed
jcaldw737 opened this Issue Mar 11, 2015 · 21 comments

Comments

Projects
None yet
7 participants
@jcaldw737
Copy link

jcaldw737 commented Mar 11, 2015

Is there a way to input long amounts of text? I know this question may sound out of place in such a visual world, but we used to do this in LOGO and some of my students really got into writing long adventure stories that presented their own readers the opportunity to make choices and get different results. The only solution I have so far is to write the text in a text editor and paste it into a "say" block.

@jmoenig

This comment has been minimized.

Copy link
Owner

jmoenig commented Mar 11, 2015

Good question! You've already found out about pasting (which currently works for Chrome). There are two other ways:

  • make a variable, right click on the watcher and chose "import" to read a text file. Once you've got it you can parse it into a list or transform it so something else inside Snap.
  • use the HTTP reporter block (in the sensing category) to dynamically query a web page or - better - data from a web service. The service/website you're querying the data from must have their cross-origin-resource-sharing option enabled (CORS) - this isn't Snap specific, though. That way you can interact with databases etc.

Do you have any other suggestion? Which would be a good way to input data for the kind of projects you're having in mind?

@jcaldw737

This comment has been minimized.

Copy link
Author

jcaldw737 commented Mar 11, 2015

Thank you so much for the rapid response! I know what you said will be useful in many situations, but here is my problem. There are students, many not tech savvy, who are going to write,and no doubt edit as they go along, an interactive story. It seems to me that two things would really help,

  1. be able to put a carriage return in their input
  2. for the input box to allow them to a few lines of their input and scroll to see the rest
@jcaldw737

This comment has been minimized.

Copy link
Author

jcaldw737 commented Mar 11, 2015

FYI, I know there's work to be done in presenting the long text, but I can handle that through blocks that break up the text and spoon feed it to a "say" block.

I just need a way to get the long input input into a block.

@cycomachead

This comment has been minimized.

Copy link
Collaborator

cycomachead commented Mar 11, 2015

  1. be able to put a carriage return in their input

I think this would be nice as well, w/o having to work around it. AFAIK, the input type is supported for built in blocks, right? (Code mapping and JSFunction use it, I think.)

@jcaldw737

This comment has been minimized.

Copy link
Author

jcaldw737 commented Mar 12, 2015

for a "say" block, if I enter its input box and hit these keys

a [enter key] b

only the "a" shows up in the input box and when I click that "say" block only the "a" shows up in the resulting output on the stage ???

@jmoenig

This comment has been minimized.

Copy link
Owner

jmoenig commented Mar 12, 2015

Snap (as well as Scratch, too) currently only supports single-line user input in the stage prompter (ask-block). I'm pretty sure that this is in the best interest of beginners, and that mulit-line input would actually freak out a lot of students (and teachers). That said, we do want to improve working with text drastically in the future. For this we want some kind of first-class text boxes (similar to sprites) that support finegrained programmatic interaction and - of course - multi-line edits.

@brianharvey

This comment has been minimized.

Copy link
Collaborator

brianharvey commented Mar 12, 2015

I'm not suggesting that this be high priority or anything, but we could echo as ↩ (LEFTWARDS ARROW WITH HOOK, Unicode: U+21A9, UTF-8: E2 86 A9) in the input box and then display it multiline on output.

@jmoenig

This comment has been minimized.

Copy link
Owner

jmoenig commented Mar 12, 2015

Good idea!

@cycomachead

This comment has been minimized.

Copy link
Collaborator

cycomachead commented Mar 12, 2015

I'm not suggesting that this be high priority or anything, but we could echo as ↩ (LEFTWARDS ARROW WITH HOOK, Unicode: U+21A9, UTF-8: E2 86 A9) in the input box and then display it multiline on output.

How does a user enter this key or know it exists? I don't know why a simple \n won't work? They currently display fine in Snap! there's just so easy way to enter them... The say block doesn't have to by default support multiline text, but if we have an input option then people can use it for their own blocks when necessary.

@jmoenig

This comment has been minimized.

Copy link
Owner

jmoenig commented Mar 12, 2015

well, we could just do what everybody else does and treat cmd-enter as special thing and make it produce that character. But anyway, this isn't anywhere close on my near-term agenda, because it could totally creep users out. Also, I'd start with only allowing it in the stage prompter. But, again, not in 4.0 anymore.

@cycomachead

This comment has been minimized.

Copy link
Collaborator

cycomachead commented Mar 12, 2015

well, we could just do what everybody else does and treat cmd-enter as special thing and make it produce that character.

Why not expose the multiline input morph for custom blocks? And, since so many apps (including Google, Facebook, and most twitter clients) use some form of the +enter combo, I don't think it'd creep users out.

@jmoenig

This comment has been minimized.

Copy link
Owner

jmoenig commented Mar 12, 2015

no power user features. Well, next to none, anyway. That's paramount for designing a friendly system. I'd much rather leave out many, many features, than overwhelm newbies. We're in the business of flirting with people who might never become power-users, ever :-)

@brianharvey

This comment has been minimized.

Copy link
Collaborator

brianharvey commented Mar 12, 2015

@cycomachead: I think you missed the word "echo" in my comment. My idea is that users type plain old enter, no bucky bits, and they see a visual representation of a newline, without any text disappearing.
@jmoenig: Since users type the plain old enter key, and since nothing disappears when they do so, there's nothing to freak them out. And certainly multiline SAY won't bother anyone -- they already get that, in effect, for long text strings.

@jcaldw737

This comment has been minimized.

Copy link
Author

jcaldw737 commented Mar 13, 2015

As we all know there is an effort to reach groups of people who are underrepresented in the software world, and that one of those groups is the female population. I can tell you from experience there are a number of them who really get into writing stories and having their users make choices. This they could do easily in LOGO, but not yet in SNAP. If you could give us some way to put in some new line character in the input box of SAY or "SAY LONG" OR "SAY A LOT", that would be wonderful. BTW, I really appreciate the attention and thought that you have given this discussion.

@jcaldw737

This comment has been minimized.

Copy link
Author

jcaldw737 commented Mar 15, 2015

Thanks so very much - things went very well!
From: Brian Harvey notifications@github.com
To: jmoenig/Snap--Build-Your-Own-Blocks Snap--Build-Your-Own-Blocks@noreply.github.com
Cc: jcaldw737 jcaldwell@2kn2kn.com
Sent: Saturday, March 14, 2015 12:28 PM
Subject: Re: [Snap--Build-Your-Own-Blocks] long text input (#740)

It seems to be working again -- fingers crossed.—
Reply to this email directly or view it on GitHub.

@deader69

This comment has been minimized.

Copy link

deader69 commented Apr 13, 2015

I sort of wish the (http:// [ ]) reporter block allowed the 'file://' specifier... and why not other specifiers to?

Equivalently, you could add a separate (file:// []) reporter block, but that'd add more blocks, and be inextensible.

So what if (http://) could just secretly recognize any ':' prefix, maybe even support the 'javascript:' prefix, etc?

Are there technical or security reasons that would make this a bad idea?

I would LOVE to be able to slurp in data from a 'file://' URI, and be editing that local text file with my favorite text editor.

@cycomachead

This comment has been minimized.

Copy link
Collaborator

cycomachead commented Apr 13, 2015

File:// URL's wouldn't work when Snap! Is accessed from a web server, which is really how most people access Snap!. Plus, this would render projects to be dependent on user's personal OS / file systems which makes it hard to share projects.

You could do this with the current JS Function block and make your own most extensible request methods.

I do think some way to have file system access would be nice, but to do it right, someone would need to build a small desktop companion app that exposes certain methods to access the file system.

@jmoenig

This comment has been minimized.

Copy link
Owner

jmoenig commented Apr 13, 2015

Last time I checked XHR2 (XMLHttpRequest) did not work with "file:" addresses.

@RedMikePumpkin

This comment has been minimized.

Copy link

RedMikePumpkin commented Oct 13, 2016

Multiple line text would be epic, for now you can use the "multiline" block in the "allow multiline text input" library

@jcaldw737

This comment has been minimized.

Copy link
Author

jcaldw737 commented Oct 13, 2016

This is just what I needed. Thank you so much. There is a subset of my students who really get into writing adventures. That task was easy in Logo, but has been difficult in SNAP - until now that it!

THANK YOU AGAIN VERY MUCH,.

@jcaldw737 jcaldw737 closed this Oct 13, 2016

@Jonathan50

This comment has been minimized.

Copy link

Jonathan50 commented Oct 13, 2016

You could edit the MULTILINE block and change it to something different (like SAY A LOT) but without changing the type of the TEXT input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment