Default costumes should be visible in costume editor

[marwahaha]

I think it's really important to have the default costumes be very accessible.

Alternatively, we have a "Costume Library" button next to the "Paint New Sprite" button underneath the stage, similar to Scratch.

Thoughts?

[studej]

And maybe button can be under the stage too (as in Scratch) :-) just sayin

[cycomachead]

Do you mean other than the turtle costume?

The costumes and sounds in the file menu shouldn't really be there to begin with. We need a proper browser style UI to pick these costumes. Yes, they should be under the costumes tab, and maybe even within the corral bar as well.

[marwahaha]

Should be like Scratch. See button with monkey icon, we should have another button. http://scratch.mit.edu/projects/editor/?tip_bar=getStarted

The same button should exist next to the paint button in the Costumes tab.

[marwahaha]

I made some initial progress here - I would like to see a thumbnail image before I select the costume.

Thoughts? @brianharvey https://github.com/marwahaha/Snap--Build-Your-Own-Blocks/tree/costume

[brianharvey]

I don't see how a one-line text input dialog does any good in this context. It has to be a well-designed graphical browser. That's more important than where the button is; I would use the existing file menu item to bring up the graphical browser as the first step, /then/ worry about buttons in different places.

[marwahaha]

Most of it is implemented, but not refactored. For quick testing, you can visit this link: http://ses.berkeley.edu/snap/snap/Snap--Build-Your-Own-Blocks/snap.html

@jmoenig @brianharvey what are your thoughts on the display itself? If you expand the dialog box, should the preview or the list expand? Spacing concerns?

My code is here https://github.com/marwahaha/Snap--Build-Your-Own-Blocks/tree/costume

[nathan]

You should be able to see thumbnails of all of the images as you scroll through them. Like Scratch.

Also, Snap! users don't really care about file extensions. You can get rid of them.

[marwahaha]

@nathan Any speed concerns? Clicking one at a time would save the overhead of loading all thumbnails...

[nathan]

Speed concerns should not drive user interface design. You can always generate the thumbnails and cache them or make the list virtual, but I really don't think it would be that slow.

[studej]

@nathan What I miss in Scratch's sprite library is search functionality :-( It can be handy to have this...

[brianharvey]

I agree with @nathan: it should basically look like the Scratch one. It should be fast if we just cache thumbnails. If you search bar fans want a search bar in there too, that wouldn't kill me, but mostly people browse the actual pictures.

[cycomachead]

speed is a part of design, but I do think it's simple enough to solve the problem here and we should show thumbnails. I also agree that we don't need file extensions.

We will definitely want to create thumbnails (especially for backgrounds) because otherwise it's quite a lot of data to pull and store.

Not that it will make the biggest of differences, but we could also use CDN to serve the files if we wanted.

Michael Ball http://www.michaelballphoto.com Photos & iPhone Apps

On Fri, May 30, 2014 at 5:06 PM, brianharvey notifications@github.com wrote:

I agree with @nathan https://github.com/nathan: it should basically look like the Scratch one. It should be fast if we just cache thumbnails. If you search bar fans want a search bar in there too, that wouldn't kill me, but mostly people browse the actual pictures.

— Reply to this email directly or view it on GitHub https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/420#issuecomment-44711951 .

[jmoenig]

I think we don't need this at all. Snap doesn't have to have a dialog box for costumes with thumbnails, because we can simply pop open a web page (in new browser windw or in a new tab) and let people drag & drop the costumes directly into Snap. Scratch cannot do this for some strange reason (maybe something to do with using Flash?), so they have to come up with a fancy dialog. Snap is a much better team player in this respect, and - come on - drag & drop is pretty cool, and also pretty user-friendly (but oh, now everybody is going to inform me that unless you have a button, a menu or a dialog box users arent't going to find out that they can simply drag and drop stuff into Snap, right?)

[marwahaha]

drag & drop is cool - but I think that access to a few costumes at a really low barrier to entry helps the beginning user get excited and interested. After playing with a few images, the beginner might realize that zhe could drop an image right into Snap. I think many users fail to even realize that Snap supports image files of any type - they must either use the turtle or paint their own costume...

I'm in favor of a simple dialog that is accessible immediately next to the paint button - it feels right to choose between making a costume or selecting a pre-loaded costume. I don't think we need many pictures, but just a few to get people interested. I wonder if there aren't enough handholds towards the bottom, when people are getting started. After some time, we can let them play and find the feature gems - but let them use a few pretty pictures when they're making their first "move 10 steps".

@jmoenig thoughts? You do own this project ;-)

[brianharvey]

On 5/31/14 3:36 AM, Jens Mönig wrote:

I think we don't need this at all. Snap doesn't have to have a dialog box for costumes with thumbnails, because we can simply pop open a web page (in new browser windw or in a new tab) and let people drag & drop the costumes directly into Snap.

Jens, when you said this to me before, I tried it, and opening the directory in a web page didn't show pictures, just names. Or do you mean we construct a specific web page with pictures, not just open the directory?

Also, don't I vaguely remember that that dragging from one tab to another doesn't work in every browser?

[nathan]

Scratch cannot do this for some strange reason (maybe something to do with using Flash?), so they have to come up with a fancy dialog.

I'm pretty sure they have a "fancy dialog" because it's a better user interface, not because they can't support drag-and-drop.

[jmoenig]

Hmm... I remember John telling he wished they could import costumes via drag & drop in Scratch...

So, I'm not saying don't show a dialog, but it doesn't have to be a morphic dialog box. Instead we can just pop up a browser window with the acual costumes or thumbnails with links to the actual costumes and that webpage is probably a lot easier to "design" for most students. And in that costume library, which is just a plain old html thing we can tell our users to drag what they want into snap. Of course, we can also put DOM based buttons and widgets onto that window that do the dragging and dropping for you, if - as I anticipated - this is regarded as a "better" user interface than drag & drop in 2014.

(Of course, I don't mind a morphic dialog box at all, but I feel strongly that we don't have to include everything in Snap itself that can readily be found elsewhere, even a paint editor is already questionable).

[brianharvey]

Probably not "plain old HTML" because we want to be able to add a costume to the library and have it automatically appear on the page. And we want a way to assign costumes to categories... So I think it's going to involve some programming whether in Morphic or in a separate page.

I guess it depends on how much you want it to feel as if the costume library is "built in." For example, @jmoenig, you've always resisted using a browser-native file dialog for loading/saving projects, because you wanted local load/save to feel just like cloud load/save. Isn't this a similar design issue?

I'm not taking a position either way. I think the programming involved will be the same either way. I just want to understand the criteria.

[marwahaha]

I'm confused.

1. Should we have any default images within Snap? (Costumes & Backgrounds)
2. Should we let the user know that you can drag and drop images or should we let them figure it out?
3. If yes to (1), how do we allow the user to find the default images?

I'm a fan of Morphic dialog boxes because it feels like Snap. I'm also a fan of a dialog to show default images, if we have any.

@jmoenig @brianharvey what do you all want?

[brianharvey]

On 6/21/14 3:59 PM, Kunal Marwaha wrote:

1. Should we have any default images within Snap? (Costumes & Backgrounds)

We should load Alonzo on startup. (2D Alonzo!) I'm not sure we are in full agreement as to which should be the default costume, but I think probably the turtle.

1. Should we let the user know that you can drag and drop images or should we let them figure it out?

The manual will tell them, and the curriculum can too. Users can also use the "Import..." menu item to import costumes from a file browser.

1. If yes to (1), how do we allow the user to find the default images?

Ideally, ultimately there will be an Import button on the Costumes tab that brings up a dialog in which over on the left are Library and Filesystem option buttons.

[brianharvey]

I think making a web page with costume thumbnails, as Jens suggests, would be a great student project. Then we can have a menu item or button or whatever that launches it. But first we have to invent it.

P.S. Eventually people will be able to store their own costumes in the cloud.