Web Unit Post-Workshop Studio
Work to have done: asynchronous peer-review; optional forum post about possible consolidation-unit projects
Plan for the day:
- Planting seeds
- Gathering questions
- Studio time!
- Check for new feedback
- Set an intention
- Work time
- Exit note
Planting seeds
As a reminder of past advice, please:
- Call your homepage index.html, probably in the docs folder. (Other html files can be called whatever you want… but will probably work best in lowercase and without spaces.) Note that it doesn’t need to be in a subfolder: directly inside docs is fine!
- Be sure to include some basic spacing to limit the length of lines and let your content breathe.
In addition, after reading through the drafts and comments, I hope you can…
Have alt text for all your images.
Text-alternatives, which you add to images using <img alt="text description here" src="path/to/source.jpg">, are a required element in validated html. They're also really helpful, and not only to blind users: they make the html file more readable on its own, and thus more semantic, and they help you troubleshoot layout when image paths are broken by showing you where each image is trying to appear.
For more guidance on how to write useful alt text, see https://webaim.org/techniques/alttext/.
Level up your HTML.
There are a few patterns that I notice often as people learn HTML and search for models online:
Use div for grouping, semantic HTML for basic structure
When you have divs inside divs inside divs, they all start to flow and meld and it's hard to see what role each thing is actually playing. Sometimes we call this "div soup." To help with that, see whether you can replace some with a more semantic tag:
- Is that div with one line of text acting like an
<h2>(or vice versa)? - Are those divs wrapping up each of several items, each with a recurring structure like photo / name / description? Maybe they're actually
<article>s. - Is the whole display of articles really a
<section>? - etc
Avoid hard-coded spacing
When I say "hard-coded spacing," I mean especially spacing that uses <br/>. That tag is not really for spacing, but rather for creating manual but meaningful line breaks. Think poetry, or maybe a two-part heading where you want to enforce a particular phrasing (e.g. a line break after a colon). A real <br/> should itself be part of your content, a piece of punctuation as much as a comma or period.
Instead of hard-coding space after your paragraphs or headers, a better practice is to give them some margin-bottom, which you can also adjust using @media queries if need be. A margin of 1em or slightly more (depending on your line-height) should do the trick.
When I say don't skip heading levels...
Headings like h1, h2, and h3 are essentially the outline of your site's content. You should be able to read them to get a stripped-down sense of what the page is about. For screen-readers that read sites out loud to blind or vision-impaired visitors, this outline of headings can be literally the first way the page is presented.
For that reason, your headings should follow a nested sequence that respects their numbers: the top-level heading on any given page should be an h1, and you shouldn't have any h3's unless you first proceed through h2. If you like the look of a smaller header, but that would "require" you to skip a level, instead use your browser's inspector to find the current CSS – font size, color, spacing, etc – and copy/paste that into a new rule for the heading level you're actually up to.
(See the CSS Diner for tips on limiting the scope of these changes through classes and descendent selectors.)
Remember to proofread for tag nesting.
The <body> should be at the top of the page, but I also know it's often confusing for newcomers to html: many of you are naturally inclined to put your navigation up above the body tag, sometimes in the head and sometimes even above the html tag. I get it: in many contexts, the "body of the page" doesn't include things like headings and menus. And many browsers will be flexible enough to figure out what you mean.
But properly speaking, the entire rendered content of the page should fall between <body> and </body>, and </html> should be the last line in the file with any content. (A blank line after that is fine.)
An html element that you can use instead of <body> to designate the main area of the page is, appropriately enough, <main>.
Remember to credit your sources somewhere on the site.
If you're using resources you didn't make yourself, be sure to include enough information to recover where it came from: a direct link to the image and to the specific license (if there is one) is ideal. Creative Commons sources often provide that html for you!
Where to put this information? Ideally, somewhere small near the image itself. (There's a semantic html way of doing this with <figure> and <figcaption>, which you may remember from the Semantic HTML section of the tutorial. See also this extended discussion of figures, figcaptions, and alt text.)
Alternately, you can have a rights page somewhere, or use the site footer – or have a live hyperlink from your site to an external credits.md file in your repo.
Call your homepage index.html
When you make your site live through GitHub Pages, the default URL you'll get is https://{username}.github.io/{reponame}. If you open that address, it will display one of two things: index.html or README.md.
If your index.html file is directly inside your docs folder, you're good to go! But if it's inside a subdirectory, you're going to see the README at that address – which will consist, if you haven't seen this yet, of instructions for how to host your site on GitHub Pages. You can add a subdirectory or alternate filename to the end of the URL, like https://{username}/github.io/{reponame}/website/home.html, but it's a little less convenient.
So if you haven't yet done so, you probably want to move your files into the docs folder (not a subdirectory), and make sure your home page is called index.html, not home or mysite or welcome.
Gathering questions
As you finish taking in the advice of your peers (and going over my suggestions above), I’d like to know what questions you have that I might be able to help with – especially if it’s about something you’ve seen in assigned readings or revision suggestions, but you’re not sure how to implement.
I’ll float and respond to in-person questions, as usual, but when I have some down time I’ll also come back to these questions in the gdoc and write up responses.
Studio Time!
Check for new feedback
Please open up your website repo, head into the history, and see if you have any unread comments there.
Hopefully everyone has by now received at least 2 (ideally 3) comments from members of your workshop groups! If you have not, please let me know, so I can make sure you’ve got a diverse set of perspectives on your work in progress.
Set an intention
As usual, before you start, go to the next section of the google doc and write a quick line about what you hope to accomplish with your remaining time. e.g. Will you…
- Work on responsive layout?
- Work on replacing placeholder content with real content?
- Work on one of the suggestions above? (Which?)
- Work on one of your stretch goals? (Which?)
- etc etc
Just a sentence or two as a guidepost will give you something to come back to, to reorient, if you find yourself walking in circles or caught in a thicket.
- as an html / css / js file
- as a git commit, saying what you've just achieved
- as a screenshot
Work Time
Please ask questions as they come up. Otherwise, I’ll try to work through the questions from the doc.
Exit Note
Before you leave, as a way for me to check in, I’d like to hear more about what happened today: did you find images? Level up on a particular CSS skill? Decide something about your project? Raise a question in a new way that you’d like some help with?
Homework for next time
-
To access the class Zoom, start on Canvas: look for the password and link in the blue box.
-
In Tuesday’s class, which will mostly be studio / Q&A, I’ll also make sure everyone knows how to take your site live, so you can show it off to friends and family without requiring them to navigate GitHub. ;¬)
- Continue revising forward on your website. The website project and prose reflection will be due by next Friday (4/7), incorporating (as usual) images from your feedback and screenshots of your work in progress.
- The main goal of this deadline is to free you up to begin reflecting on the semester as a whole in our Consolidation/Integration unit. That said, one of your possible projects for that unit is to continue working on a previous project.
- If you anticipate that you’ll want to just carry on with the website, that’s fine! Please try to confirm that with me by Tuesday (4/4).
- Don’t forget to save, commit, and push as you go.