Editor Page Design

[scottgarner]

Here's a rough stab at the editor page with most of the components in place:

http://hoc.j38.net/editor/

Thoughts:

1. I swapped the positions of the editor and canvas as represented in the wireframe. The main reason is that drawing a canvas at a size other than that specified in the sketch looks pretty bad with the way Safari resamples, though Chrome is a bit better. I think it works because the code is so short that the editor doesn't need to be very big.

2. Right now, everything is fixed at what the smallest size would be, but I can create a more fluid layout for larger browsers with a couple of catches: The video would ideally maintain its aspect ratio and the size of the actual canvas would ideally stay the size defined by size() in the code, though it could live in a fluid container with a colored background or something.

3. The video is pretty small for the above reasons. If the sketch were 512x512, it could have more horizontal room, but that would expand it vertically into the editor's space if the same aspect ratio is kept. Tricky stuff. I do plan to expand and contract the video view as seen in the wireframes once we start building out the lesson sequencing.

4. The timeline isn't a timeline yet, obviously, just a row of buttons to jump lessons. This can be fleshed out as we continue the design conversation.

5. Popcorn.js is in place, but isn't do anything yet but loading the video.

6. No branding or small print yet. We can get specific on this.

[REAS]

This is so promising! Shall we make the examples 500 x 500 px to give more room for the video and the branding and timeline stuff on the bottom, maybe below the canvas space? I'm worried about 512 being a strange number for people who don't think in base 2.

[scottgarner]

Hah, it's probably telling that my first instinct was "512" rather than "500" and of course you're right.

Upon further investigation, the tablet world makes things even more complicated, unfortunately. The usable height on a Nexus 7 appears to be something like 582 in Chrome and is probably something different in other browsers. On the iPad, the height varies from version to version of iOS but doesn't seem to get lower than 672.

The good new is that I can now pass a global scale to the Processing.js instance, which should let us draw the sketch at any size without distortion. I'm going to take a stab at a fluid layout that keeps the canvas square and maintains the proper aspect ratio for the video, which could get a little tricky.

[scotthmurray]

A fluid layout is ideal, but of course a little tricky to implement. (I wasn't aware that PJS instances could be scaled like that.)

I'd suggest doing what you can, and testing on an iPad and maybe one other tablet, then cross our fingers on the rest, as there's no way to test every device out there.

[shiffman]

Yes, I also think that, given our limited time and resources, we shouldn't let tablets be too much of a distraction. we can test and make tweaks, but I wouldn't go overboard.

[scottgarner]

Fluid layout with broken sketch scaling:

http://hello.processing.org/editor/

The catches:

I can resize and scale a running sketch, but only if it is looping. In other words, it has to have a setup and draw because the size/scale calls only happen for subsequent draws. Possible solutions:

1. Always have a setup and draw, which probably makes the code more intimidating for beginners.

2. Choose a fixed sketch size and live with it or live with the artifacts of browser scaling. Picking the perfect size for all possible scenarios will be tricky.

3. Rewrite the code on the fly to modify the size command and add a scale if there's no setup and draw. The biggest downside here is that there's significant overhead to compiling new Processing code into javascript and this hit would happen not only on page load, but anytime a user resized the browser.

A possible variation of this would involve trying to intelligently wrap the code in a setup and draw, but this could get very broken very quickly depending on the input.

[shiffman]

Some quick reactions:

1. I think we need to start without setup and draw for the purposes of this tutorial.
2. If it makes our lives much easier, I think that living with a fixed sketch size is totally fine for this tutorial and these very basic examples.

[REAS]

I've gone back and fourth on this in my head since I started to comment. This won't "solve" the issue, but I think it might help. Let's try a nav bar at the top of the window like Tributary (http://tributary.io/inlet/6666089) that can house the branding and timeline. With this, we don't need to overlay the timeline on top of the canvas. If it helps with the spacing, the canvas can be 600 x 400.

Did you say the video can't be at the bottom of the screen?

I wonder if we can learn anything from the DBN layout: http://dbn.media.mit.edu/dbn/

For example, it would be nice to be able to turn on an off the grid over the entire canvas, or to have the grid rulers on the outside as in DBN. We should probably also have Processing-like play and stop buttons for running the code. I'm worried they are currently buried in the lower-right.

[REAS]

Another reason to not live scale the canvas is because Processing doesn't behave like that. It sets up the wrong expectation if they start to use Processing.

[scottgarner]

New solution!

Processing.js uses some browser-specific css magic to implement smooth() and noSmooth() and noSmooth() was the default. It is implemented in such a way that calling smooth() later didn't undo the noSmooth() damage (which is an active state as opposed to the passive way you'd normally think of no anti-aliasing).

Long story short, I modified Processing.js to default to smooth() and can now scale the canvas independent of the sketch without much distortion. This seems to be the best solution for now so I'll consider it done unless we need to revisit later.

[scottgarner]

Casey, with this new layout, adding a fixed header and/or footer is no problem. We can certainly have branding on the top and a timeline on the bottom if that's your preference, or marry them both to the top.

The video, canvas and editor can be arranged in any way we see fit. I guess my point was just that given that we want the canvas to be square and the video to be 16x9 at all times, this layout seemed most appropriate, but I'm open to other options.

I also agree that grabbing the button styling from Processing is the correct choice. I'm not exactly clear on the grid comments, though, if you wouldn't mind elaborating.

[scottgarner]

Editor page with header: http:/hello.processing.org/editor/

[REAS]

Please discuss. In making this mockup, a few things changed.

[REAS]

It's still very rough, but I wanted to clean it up a little bit. This layout gives us a little bit of space above the canvas window to have timing information and for potential next/back arrows to provide a 2nd way to navigate between the lessons

[scotthmurray]

This is great. Casey, glad to see the pixel units marked around the output area. Agreed that the output area should be a fixed size (not scaled). Given that, perhaps the video and editor areas should also be fixed width. (Maybe the editor can have a dynamic height, so it grows taller in a large window.)

Love the "hello" --> "goodbye" progression as well.

The only minor annoyance to me is the right --> left workflow. That could be because I tend to work with my code on the left, and output on the right, as though it's "flowing" that direction. But this could just be a personal thing for me.

Also, to me, the "run" and "share" buttons should be tied to the code editor, not the canvas. I'm envisioning it similar to the regular IDE in which "play" and "stop" buttons are part of the editor window.

[scotthmurray]

For example (excuse the roughness)…

[REAS]

I do like the left/right orientation better like this because of the video placement. I'm still unsure about the run and share button location. Are you putting them in the blue in this drawing? We can probably fit all of the way finding into the top area.

[scotthmurray]

Sorry, that poor mockup with hand-drawn arrows was just to indicate workflow (left to right), not actual button placement.

This is a touch more refined. What about this button placement? (Ignore the actual button style for now.) "Run" could be at the top right, closest to the output panel. "Save" on the left (triggers local save). "Share" would only appear at the end.

[scottgarner]

I'm a bit swamped at the moment, but wanted to get some of these changes in place to continue the conversation.

http://hello.processing.org/editor/

No styling on the header yet, no new buttons and the sketch will definitely need to be smaller if we're going for a fixed size and rulers.

[scottgarner]

New version:

http://hello.processing.org/editor/

Most of the work here was coming up with a scheme to script each video with Popcorn events. Currently, there is a script loader for each of the videos in scripts.js. This definitely isn't the most elegant solution, but it didn't seem useful to create an overly flexible system for only six videos.

So far, I've only done events for the second video (I kept the previous test events associated with video one). Click "Shapes" and jump to around 6:15 to see the events start happening. Looking at scripts.js, you can see that most of what's going on is dealing with interface state, both forwards and backwards. I'm not sure if we want a scrubbable timeline in the final version, but it definitely adds a lot of complexity because you have to account for state when someone scrubs to an earlier point in the video. In other words, if Dan shows the canvas at 1:00, you have to hide the canvas if you scrub back to 0:59 or things get confusing.

Some other things:

1. I'm a little worried about 600x600. The current minimum viewport height that will show the whole canvas and the rulers is around 730px. This is definitely a problem for smaller displays, like an iPad, which normally maxes out closer to 675 depending on the version of iOS. Popular Android tablets are even worse.

I agree that sticking to real pixels is the right choice, but we may need to go to 500x500 or even 400x400 if targeting tablets and other small displays at true pixel values is important.

2. I added a very rough version of the post-video "hints" box. What goes here? Is it just some helpful info about syntax? Are there buttons to jump to the next video when you're ready? Is there some kind of automatic jump to the next video?

3. Should we look for ways to hide size()?

[REAS]

I look forward to digging into the work, but quickly I'll way the 600 x 600 pixel dimension isn't important, we can go 600 x 400 or 500 x 400 etc. It should be as large as it can, in units of 100 that allows us to reach the most platforms.

[shiffman]

Fantastic, this is very exciting to see all this work. I will offer some quick thoughts here and @scottgarner let's catch up at ITP sometime this week.

1. Any size() is fine 600x600 was arbitrary. We should just decide before I shoot the final videos (as of now Nov 9 or 10th). I might pick something that is not a square as this might have educational value in terms of distinguishing width/height dimensions, but this is a small detail not not particularly important.

2. I think the post-video hints box should have:

• A sentence or two remiding student what their "assignment is"
• syntax reminders
• buttons for resetting code (to example code, to previous "working" version, etc. etc.
• some sort of timing information, it doesn't need to be a scary countdown clock, but we could have the tutorial auto-sequence to the next video after X amount of time (giving the student option to pause of course). Or maybe simplest to say "Take about 10 minutes for this exercise" + "advance to next tutorial when ready" button.

3. I made my videos off the cuff and it just didn't feel right to start explaining size() and I just jumped into ellipse() and rect(). But I could so easily explain size() when I talk about the dimensions. @REAS, what do you think?

[scottgarner]

I have a break between classes on Tuesday between 12:00 and 3:30 if that works for you.

Regarding size(), I wonder if it makes sense to introduce the canvas and editor in the introduction along with size() instead of the first video?

[shiffman]

I have a break 3-3:30 on Tuesday, let's try to catch up then.

I also forgot to mention that I think removing the "scrubbing" functionality is fine. This videos are short enough. Sure it would be nice, but it seems like that creates a ton of complexity for us that we may not have time to solve. As long as we have pause and return to the beginning or skip to end I think we'll be ok?

[scottgarner]

Some quick updates:

1. Switched to 400x400 just to be on the safe side, but this can be tweaked.
2. Graphical play button.
3. "Run cache", which will store the code after a successful run so it can be restored if the user gets stuck.
4. A bunch of poorly placed buttons:

• Restart video
• Pause/Play Video
• Next lesson
• Reset code (to last successful run)

My next focus will be on the hint screens that pop up between videos. The current idea is to have a reminder of the "assignment", some syntax reminders and a button to jump to the next lesson when ready. After that, I'll move on to better error handling.

Dan and I talked a bit about buttons today. We have this issue where some buttons are video related, some buttons are lesson related and some buttons are code related. Do they all go in one place? Are they split up on the screen?

[REAS]

Do we have potential size issues with 500 x 400? I think it might be easier for people to understand the difference between width and height if they are different numbers.

[scottgarner]

Dan and I weren't sure which was simpler, but I think a rectangle drives home the width/height difference. I'll swap it now and we can tweak it later if needed.

-S

[scottgarner]

I just pushed some new code. The biggest change is with error handling, which is outlined in issue #12.

I also built out the after-video hint display. There currently isn't any content, but anything added under hints should be displayed properly at the end of a video.

Without the Vimeo timeline visible, it's a little tricky to jump around while working. I recommend opening your browser's error console and typing something like this: helloEditor.popcorn.play("11:18");

Or, Dan, maybe we should just turn the timeline on during development even if we don't plan to keep it.

Finally, I went through main.js and script.js and tried to comment pretty heavily. Right now, only the second video is fleshed out in script.js, but it should be fairly straightforward to finish the other videos.

[shiffman]

FYI I turned the player on for the "shapes" video.

[scottgarner]

I just pushed a lot of updates that have the UI looking a little crazy as I rework the buttons, so pardon the mess. The main thing I wanted to get up is the ability to link directly to lessons and times within lessons, which should make things easier on us.

http://hello.processing.org/editor/#shapes
http://hello.processing.org/editor/#shapes-11:16

[scotthmurray]

I think this looks super. I even like the buttons, although you mentioned they are still in process. The white text labels on the rulers could be a bit more clear — perhaps this could use the same typeface as either the code editor or the nav at top?

[scottgarner]

I think I may try a solid treatment for the rulers. In other words, a filled background with darker text. I think it might make them more legible and anchor them a bit more. I'll experiment with the typeface, too.

[scottgarner]

Just pushed a new new ruler treatment along with some initial work on nice UI animations when they're toggled. I'm undecided on this look, but they're just SVG files and very easy to tweak.

[scottgarner]

I think everything here has been split into other issues, so I'm going to close it. If I missed something, please file another issue.