Display Page Design

[scottgarner]

Dead simple at this point, it just displays the Gist referenced in the URL:

http://hoc.j38.net/display/#6974963

I think keeping this page pretty barebones is a good idea, though we'll want branding and some kind of call to action to get visitors to try out the site.

[scottgarner]

Things this page needs to do:

• Display the Gist in the URL, which it does.
• Have "branding" for Hello Processing.
• Have a CTA so visitors can try the lesson
• Show the code
• Offer a .pde download (maybe)

Most of these are small functional things, but we need to have some concrete copy.

[scotthmurray]

1) To confirm, we're not prompting people for their names, are we? It would be nice to have a name and title for each piece, as in "Rotating Triangles" by "Scott". But adding that may be too much complexity. We could encourage people who want to be credited to leave a title and name in a comment at the start of their code.

2) What do you mean by CTA?

3) Assuming we don't have a title or name for each piece, how about something like the following?

[scottgarner]

1) Good point, though I feel like identity is covered on the social end. The code will be linked from a given person's Twitter or Facebook feed with text like "Look what I made", so I don't think we should add complexity on our side. We also didn't teach them how to comment. ;-)

Inserting fields for name and title would also be slightly tricky since the Gist is created in the background before the share pane even comes up. This is necessary so that the links to Twitter, etc., are instantly ready to go. We'd have to introduce another step in the process.

2) Hah, sorry. Too much time on conference calls with advertising people. "Call to Action." What you have in the screenshot is more or less what I had in mind.

3) I like the simplicity of this. I think I might prefer a toggle so you only show the code sometimes, but maybe for these purposes it really is best to show the code and result right off the bat.

Actually, now that we've given the user free reign over "size", we can't necessarily count on showing the code in a fixed window as seen here. We may just have to center it with an option to overlay the code because it could be any size they dream up.

[scotthmurray]

1) Great, good points. Let's keep it simple.

Also good point about size(). Let's try a single column design, where the width of the sketch determines the width of the entire column, e.g.:

Suggestions on proper copy welcome. :)

[scottgarner]

We don't scroll anywhere else in the site, so it seems weird to do it here. I think branding should also go on top.

I can build a fluid layout where the branding is always on top, in the upper left and will sit over the sketch if it is a crazy size. I'd prefer not to scroll. @REAS and @shiffman, thoughts on always showing the code?

We probably also want an option to download the .pde and information on downloading Processing, etc.

[shiffman]

I personally like the idea of showing the code since that is part of the story of empowering users to feel comfortable with code. . . along with a feeling of pride for their code? I also think we can assume that folks will likely not change the size very often? However, keeping things simple is a top priority and if it overcomplicates things I am fine with leaving it out. Curious to hear what @REAS thinks.

[scottgarner]

Just to clarify, I definitely think we need a way to view the code here. It's really a question of whether you click a button or scroll to see it. 

Scrolling feels less elegant to me, but it does mean that the code is there and available from the start. 

— Sent from Mailbox for iPhone

On Sun, Nov 10, 2013 at 9:59 PM, Daniel Shiffman notifications@github.com wrote:

I personally like the idea of showing the code since that is part of the story of empowering users to feel comfortable with code. . . along with a feeling of pride for their code? I also think we can assume that folks will likely not change the size very often? However, keeping things simple is a top priority and if it overcomplicates things I am fine with leaving it out. Curious to hear what @REAS thinks.

Reply to this email directly or view it on GitHub: https://github.com/scottgarner/Processing-Hour-Of-Code/issues/9#issuecomment-28169987

[scotthmurray]

(I think the comment above this one was intended for the landing page design thread.)

I'm OK with scrolling. I just want to make sure the sketch/output is the first thing on the page, hopefully to entice people. Then #2 is, "hey, I made this with code, wow!" Then #3 is "whoa, I want to do that, too! How can I do that?"

[scottgarner]

Whoops, you're right. Late night commenting!

I'm building out the display page right now with all of the necessary content and functionality, which can be shuffled later. Since we're not showing rulers here, we also have the option to scale the sketch to fit if it's too big.

I'm going to make the code view part of a popup with a download button. I'm anti-scrolling since it breaks with the application-type interface of the rest of the site, but will defer to the group.

[scotthmurray]

Sounds great; looking forward to seeing this.

[scottgarner]

I took a stab at this just to get the components and functionality in place. We definitely don't have to show code and text in a Bootstrap modal window, that was just an easy way to get things up and running. The only thing I might add from a functionality standpoint is something to constrain the size in case the sketch is huge.

Beyond that, it should just be copy and layout. I'd like to have the copy nailed down by the draft milestone this weekend if possible.

Downloading without a server-side component is supported to various degrees at this point. Chrome will actually download the file, for example, but Safari will just open it in a new window to be manually saved.

[shiffman]

Looks great so far. If it sometimes opens in a new window, I don't think that is so terrible and wouldn't spend a lot of time worrying about it for now.

[scotthmurray]

Agreed. This looks great. @REAS would love your input on the copy and mockups above, as I think you're most familiar with the "Processing style."

If the side-by-side and/or vertical layouts above aren't optimal, @scottgarner your modal window has me thinking we could take the canvas and "flip" it around, e.g. with a CSS 3D transition, to reveal the code on the "back". In terms of visual metaphor, it could work, although it's my preference for people to be able to see the code and image at the same time. (I'm just proposing this as another option.)

[shiffman]

making a note here that the source code on the display page has fill(), stroke(), etc. as clickable links. They probably should not be in this context since the code is not editable.

[scotthmurray]

Yes, I noticed clicking them doesn't do anything, although they do appear underlined.

[scottgarner]

I'm very open to different arrangements for both this and the splash page, but feel like my plate is already (over) full with functional concerns to spend a lot of time experimenting. Whatever we do, I'd like to have the presentation settled for the draft milestone this weekend.

Good catch, I made the CSS selector for the color options only work in the editor on the lesson page.

[scottgarner]

I took another stab at the display page design. Something a little closer to Scott's original two-pane layout, but with copy instead of code on the left. I kept the modal code window for now.

[REAS]

How do I see the page that Scott is working on? In general @alignedleft I like both, they both work.

[scottgarner]

http://hello.processing.org/display/#7361107

Now the sketch is scaled down to be 400 pixels high with the width scaled in proportion in case someone uses crazy sizes. The rest of the layout will adjust itself based on that size. I'm currently working on some fluid layout issues throughout the site.

[scottgarner]

Closing this issue as functionally complete. Style refinements will continue as part of #1.