Skip to main content

Web Unit Criteria and Stretch Goals / Studio

Texts to have read / watched
Work to have achieved
  • Compose and push a second preview draft of your website portfolio project, starting to add layout for wider screens. Like last time, this should include:
    • A multifile project folder – probably the pre-built folder named docs, for ease of use with GitHub Pages – containing a combination of HTML and CSS, even if it's not well-developed.
    • A static screenshot (.png or .jpg) of your website-in-progress, as rendered in a local web browser (for comparison later to subsequent drafts: this is your "flat" export).
    • A screenshot of your text editor setup, too, with the navigation pane showing: this can sometimes help me give feedback more quickly.)
    • At least an initial update to your README.md file, introducing your site (as opposed to this assignment). Feel free also to ask questions or lay out next steps for yourself!
    • An updated list of assets, now with any files or fonts you've actually obtained. As you go, add TASL documentation for any outside sources – title, author, source (e.g. url), and license (e.g. Creative Commons, fair use rationale).

Plan for the day:

  1. Reflective writing on your current project (5 min)
  2. Reflective writing on audience and design (5 min)
  3. Talk to each other! (20-30 min)
    • about your goals, excitements, questions
    • about the shared criteria and inspirations
  4. Studio: from structure toward layout (30-45 min)
    • Reminder about scoping (and screenshots)
    • Set Goals
    • Go forth!
    • Exit note
  5. Homework: workshop-ready draft

1. Reflective writing on current projects (5 min)

In your own space – you won't have to share this unless you want to – do a little writing about your website portfolio in progress.
  • What's exciting about it?
  • What's challenging about it?
  • What are you unsure of, or wondering about?

2. Reflective writing on audience (5 min)

Shift now in your writing to think about audiences:

  • Who do you imagine would get the most out of the website you’re designing? Who’s your primary audience?
  • What will they be looking for? How will you make that easy to find?
  • Can you think of any secondary audiences for your project? Who else might come look at this site?
  • Where might they be seeking something different? How might you steer them toward what they’ll need?

Jot down some notes.

EXT: Think about websites you want to visit frequently. What seems to make them easy to get through, to find what you need? Now think about websites you’re forced to visit, but find hard to use. What causes the frustration?

3. Talk to each other! (20-30 min)

Primed now by that writing and thinking, I’m going to ask you to get in groups and brainstorm in pursuit of inspirations for this unit.

Share some of your questions and excitements, your goals and ideas about how to achieve them. Take advantage of being together to go beyond where you could on your own!

After a few minutes talking about your individual projects, move onto the next section to brainstorm about the collective implications.

3a. Review, comment, and suggest (10 min)

You’re used to this process by now, yes?

Criteria from previous semesters are posted in our shared google doc as a starting point.

In groups at your tables, take 10ish minutes to talk amongst yourselves about these criteria: what's working, what's missing, and what you'd like to move or modify.

As you reach consensus in your group, add comments or use the "suggestions" feature (click the pencil icon in the top right) to propose modifications or additions. Or ask questions, if you have them! If you prefer, you can also just upvote.

Remember that aspirational criteria are not required, but baseline criteria are. Given the goals of the unit, what should we set as our minimum criteria for full credit? What must everyone achieve?

What are some ways we might push beyond that minimum – not merely in terms of quantity, but in terms of quality or challenge level? I really want you to see these aspirational goals as opportunities to stretch yourselves and your skills, not just to do more of the same.

EXT: If your group feels finished, skip ahead: read through other groups’ notes, respond to their questions on yours, or start discussing thoughts and questions on how to achieve your personal preferred aspirational goals.

3b. Comment and Discuss in the Doc (10-15 min)

As you finish up, read through the other groups’ notes and post collegial replies to their comments in the margins to upvote, ask questions, or propose modifications.

Make sure to loop back to your own comments to see if you’ve picked up anything to respond to.

ALT: If you're joining us asynchronously, please also leave comments, especially with questions or suggestions. You will be held to these criteria, too, so make your voice heard! We won't finalize them until after workshop next week.

EXT: If you finish early, move on to the next section.

I’ll work solo to write up a clean list that reflects your consensus in the comments, while you all work solo (with groupmates on-hand for questions or other feedback) on your projects and any needed tutorials.

4. Studio / Q & A

Questions your group couldn’t answer, but I’m too occupied elsewhere? Post them to the google doc, and I’ll work on posting answers there. You’re probably not the only one wondering!

Reminders, tips, and ways to level up

I've said all of this before, but it bears repeating.
  • Beware of scope creep; plan for phased releases, starting with a minimal deliverable product and adding stretch goals from there.
  • Use relative file paths where possible: this will ensure your files work on GitHub, or (especially) when a classmate clones your repo from GitHub for workshop.
  • To the best of your ability, keep the HTML about content (or grouping); keep the display in the CSS.
  • Don't forget accessibility: every img should have alt, and headings (h1, h2, etc) shouldn't skip levels.
  • When you're ready to work on appearances, you can play with CSS rules using the browser's Inspector.
Take on the lowest line-count challenge.

If you repeat the same CSS rules across multiple selectors, ask yourself: do those need to be separated? Could they be combined into a shared class that you reuse in several places?

If you're using a div, ask yourself: what is this grouping? If there's only one element inside of it, does it need to be there? (Sometimes, yes, for layout – but most of the time, no, despite what the old tutorial might suggest.) See my brief screencast updating their Flexbox tutorial.

Take advantage of parent selectors and classes to limit the scope of CSS rules

If you're worried a rule will spread too broadly, e.g. affecting inner page <h2>'s when you only meant it to apply on the front page, just limit the scope of the css rule by specifying a class, or a parent container, or both. For example, the following code will only apply to <h2>'s inside a <body class="front">: 


  body.front h2 {
    font-size: 18px;
  }
(Setting a class on the <body> is a good way to set up page-wide contexts, e.g. for background or the position of a navigation bar.)

Or here's code that only applies to an <h2> when it appears inside an element (a <div>, say, or a <header>) with class "title-block": 


  .title-block h2 {
    font-size: 18px;
  }
This solution probably makes the most sense if you want to do some styling on the containing element, like changing its background or centering a bunch of things.

Or – probably the simplest solution of all – you could just set the class directly on the element, calling it something like "subtitle" (or whatever you want to call it): 

<h2 class="subtitle">

  h2.subtitle {
    font-size: 18px;
  }
This has the extra advantage that you can set a lot of other rules for all <h2>'s, and just add the tweaks you need for the subtitle in this additional ruleset. In other words: the Cascading Style Sheet will cascade!

Do search for tutorials! Just... be mindful of when they're from.

You don't have to reinvent the wheel. Sometimes programming is like plumbing: you can find the pieces you need and just hook them together, turning them around until things flow.

But please be aware that there's still stuff out there from the early web that's now deprecated, for all sorts of good reasons, including accessibility: you should not be using <table> or <frameset> for layout. Nine times out of ten, you shouldn't be using float, either. (The tenth is if you're wrapping a text paragraph around an image; in that specific use-case, go ahead and float the image.) Grid is more accessible, more powerful, and, frankly, makes more sense!

Set Goals

After reading the notes above, set a goal for today: what do you need to do to level up on HTML, CSS, and resource gathering to move toward your specific project? Note that we’ll have a Web Unit workshop on Monday, so I’ll ask you to bring in some kind of peer-reviewable draft.

Go forth! And Don’t forget to document your process

Save periodically as you go:
  • as a project file
  • as a screenshot, showing your process
  • as a git commit, saying what you've just achieved

Exit note

Before you leave, just as a way for me to check in, I’d like to hear more about what happened today: Did you decide on your navigation? Block out the html? Make some progress on a stylesheet? Work through a tutorial or two (and which)?

Reply to your note in the google doc.

Homework for next time

  • Aim to push a full draft to GitHub by 10:00pm Eastern Time on Sunday: a solid attempt at a complete website, ideally meeting baseline criteria. Rough edges are still welcome.
    • If you’re including other people’s images or other media assets, don’t forget to update your source credits and permissions / license to use them. You can include these right on the website, or link from the website to a file (credits.md, or even README.md) in your repo.
    • If you’re doing something advanced (Jekyll, React, etc) that will require a server and not just a browser, be sure to explain in your repo’s README.md file how to load your files.
  • If you’re pretty sure by Sunday dinnertime that you won’t be ready to turn in a draft, please let me know ASAP so that I can responsibly rearrange peer-review groups.
    • That said, remember that pretty much any start, however rough, will count here. Even placeholder content with navigation lets us see the parts you’re thinking about, maybe we can help you move forward from there. If you need some minimum styling, check out my “basic spacing” bullet in lesson 18.

To double-check that your partners will see the files as you intended, please download a .zip from your GitHub.com repository to a second location on your computer. Does your site open in a browser? Did the images come along, or did your paths break? Use the alt text and the inspector to figure out where it went wrong, and update. And don't forget to save, commit, and push the latest changes...

(You should then also delete that extra copy, before you get confused as to where you're revising and pushing from.)