Week 4

We’ve gone through your Figma sketches (everyone should have feedback there now) and want to discuss some trends:

• Many folks really only had one direction. (Maaaybe 1¹/​₂, being generous.)

  A lot of the work landed much closer to “explorations on one theme” rather than “three distinct directions.” Changing the type alone does not make a new direction, nor does a different layout with the same type.

  In addition to not satisfying our expectations for the assignment, this can also only limit your horizons for the project. Sketching is meant to initially broaden these, from which we can later narrow. But you can’t refine (and we can’t respond/​give feedback to) what we don’t see. We want to see much more varied exploration, here!

• It also wasn’t very… sketchy.

  Lots of “here are my only three frames.” We want to see more in-progress and more iteration/​experimentation. These don’t have to be complete thoughts. Sketches are not presentations. Be looser. Show us how you got there. Don’t “tidy up” prematurely. Remember, we’re working in the open!

• Multi-column, print layouts.

  We left many notes for folks about their multi-column layouts. Columns are a powerful, structural design tool⁠—but are complicated in digital, where the audience only ever sees a portion of your page while scrolling.

  We can’t expect people to scroll down one column, then zigzag back up another. You probably wouldn’t! So don’t expect your reader to, either. Again, put yourself in their mind/​eyes.

• Again, we aren’t designing posters.

  Relatedly, there were still a lot of Frame-centric layouts. Keep in mind that on the web, your reader never sees “the whole canvas” as we do in Figma⁠—this is a limitation/​weak point of the tool.

  Always think about how your audience will flow (scroll) through your page⁠—especially when the primary purpose is reading, as it is with this project.

  Going further, we didn’t see much in the way of “frameless” work! Remember that with all of our tools, their form and limitations can become our own.

• Lots of (way) too-small or too-large type.

  To some extent, scale/​zoom doesn’t matter⁠—it is all about the relationships. But we doubt everyone was drawing at 13% or 200% zoom⁠—so the type sizes were pretty tough to parse for their intent.

  Start working at 100% in Figma ( ⌘/​Ctrl+0 )! Be mindful of us⁠—and in the future, your boss⁠—reviewing your work.

• Build up from the base (paragraph).

  Overall, we want to see more of an emphasis on basic readability. This is true in any project, but particular one about text and reading! Readability is our “table stakes;” this requirement precedes all others.

  We’re all designers⁠—everyone here wants to start with their Bigass Type Moment, above the fold. But instead⁠—try starting with your most basic, simple, base paragraph. Land that⁠—and it is your typographic “floor”/​“foundation” to build up from. Think of your larger type moments in relation to that base⁠—as increments of its size, or in contrast to its weight.

• Read your work in its design!

  To cap the last few points: much of our feedback would’ve been addressed before we looked at the sketches if you tried actually reading your work, as designed.

  Text is is never just a formal, visual element. Always put yourself in the mind and eyes of your reader! Practice distancing yourself from your work, in this way.

• More deliberate, intentional design choices⁠—the why.

  Ideally our work should always be bespoke to our content⁠—especially here, where you have chosen it and written in response. Your design should deeply reflect this. Many folks were landing in “default” or “template” territory⁠—as in you could plop any text into the design. Consider that an anti-goal, here⁠—and really, in your career.

  If the intent (or anything) isn’t clear⁠—especially when working asynchronously⁠—you can leave annotations/​marginalia to help explain. But the strongest designs stand on their own, of course!

• More engagement (time).

  Many of these points probably came out of the same root cause: it doesn’t seem to us like a lot of folks spent very long on this! (And Figma timestamped version histories confirm.)

  This is not an “half-hour before class” course⁠—we need to see more. Let’s course-correct!

  _{If folks are ever unclear on assignments or our expectations, they should ask! We didn’t get any questions.}

TL;DR: always mind your medium! And let’s see more engagement, going forward!

</stern-teacher>

Our main topic for today is CSS. We’ll start to make things look good:

An Intro to CSS

And depending on how we’re doing on time⁠—a rare, second topic: examining our work in the browser:

DevTools /​ Web Inspector

Again today our back half will be a demo, picking up from last week:

1. Open your repo from last week⁠—either from GitHub Desktop or VS Code. We’ll be using the template repo⁠—now with some dummy HTML⁠—which you can reference:

   manuscript Template

   _{This example is indicative of the kind of structuring we’re looking for in your projects. Don’t mimic this exactly/​directly, but interpret its hierarchy and level of detail within your design’s needs. Your project should be as nested.}

2. Let’s take a look at our example index.html file!

   • We’ve got a clear document base semantic structure: <header>, <main>, <footer>
   • The document has an overall <h1> that matches its <title>
   • Inside <main> there are two discrete <article>, one for the text and our response
   • You can see there are nested <header> within each <article>⁠—these are semantically now their <header> , and hierarchical <h2> for their own titles
   • Each text has lots of structure within: broken up into <section>, some <blockquote>, plenty of links and appropriate inline elements
   • Document was getting long, so we added a <nav> to move around, using their #id attributes
   • Beyond semantics/​accessibility⁠—these will all also give us thinks to “hook” our styles onto!

3. Some more IDE tips:

   • Refresher on last week’s
   • Adjust indentation: ⌘/​Ctrl+[ /​ ]
   • Move lines with: ⌥/​Alt+↑ /​ ↓
   • Jump selection by word: ⌥/​Alt+← /​ →
   • Code folding to make things less cluttered: click sidebar ▾
   • Invert/​fold everything else: ⌥/​Alt-click

4. We’ll switch gears to CSS! Create a style.css in the same folder as your index.html .

   • You can click File → New File… , or click the little + icon that hovers over the Explorer pane
   • Recall that CSS can also live in a <style> tag, or even inline⁠—but these don’t scale very well!
   • So we’ll be using this separate, external file (not in our HTML) for our stylesheet
   • Great time to talk about VS Code’s side-by-side editing!

5. In the <head> of your HTML file, link to your style.css :

   						<!doctype html>
   <html>
   	<head>
   		<title>Your page title</title>
   		<link href="style.css" rel="stylesheet">
   	</head>
   	<body>
   		<!-- Your HTML content. -->
   	</body>
   </html>
   
   		
   		

6. It’s always good to add something obvious in, to make sure it is all connected. Add this to your style.css :

   						body { color: tomato; }
   
   		
   		

   If you hop back to your page in the browser, you should see the color change! If not, your HTML isn’t seeing your CSS. Retrace your steps until you see the color⁠—this means we’re “plugged in.”

7. Let’s also try adding in a reset to start with a clean slate:

   						<link href="https://typography-interaction-2627.github.io/assets/reset.css" rel="stylesheet">
   
   		
   		

   Try commenting ( ⌘/​Ctrl+/​ ) this line in and out, then looking again in the browser! Note the differences, as the user-agent styles are reset.

8. We’ll bring this file in locally, to avoid a dependency.

   Create a reset.css in your repo, as we did with style.css . You can go to the course reset in your browser, and copy the code into your local file. Then update the <link> in your <head> :

   						<link href="reset.css" rel="stylesheet">
   
   		
   		

9. Finally, let’s change up our type!

   • Set a font-family and font-size on our <html> element
   • You can also target “the whole document” with :root { }
   • Font properties inherit, but we can set/​change/​override this at any level/​place with different selectors
   • Ahead of next week’s topic, let’s put some space between things with a couple simple rules:

   						body { padding: 3rem; }
   *:where(:not(:first-child)) { margin-block-start: 1em; }
   
   		
   		

10. Let’s add something nice from Google Fonts.

    On the specimen page (the page for a specific font family), click the Get font button⁠—this will add them to a sort of “shopping bag” up top.

    We’ll start by linking to it. Click <> Get embed code to see our options, choose <link> . Select your weights, if necessary (only bring in what you will use), and copy the code there into your <head> :

    						<link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link href="https://fonts.googleapis.com/css2?family=EB+Garamond:ital,wght@0,400..800;1,400..800&display=swap" rel="stylesheet">
    
    		
    		

    And then we’ll apply it⁠—in this case, to everything:

    						:root { font-family: 'EB Garamond', serif; }
    
    		
    		

    You can also @import right into the top of your stylesheet, if you prefer:

    						@import url('https://fonts.googleapis.com/css2?family=EB+Garamond:ital,wght@0,400..800;1,400..800&display=swap');
    
    /* The rest of your CSS… */
    
    		
    		

    The page should now be set in the font!

    _{The process for Adobe Fonts is somewhat similar, but involves setting up a “project” there first. And know that these fonts (and your design) will go away without a subscription!}

11. And with any remaining time:

    • Adjust some font sizes, with element selectors
    • Differentiate color on some paragraphs, with a class
    • Adjust some of those snazzy inline elements
    • Add a local (meaning “in this repo”) font, maybe something flavorful from FontShare

Phew.

1. Spend some time with the CSS topic! There is a lot in there, and we know we flew through it:

   An Intro to CSS

   Also better familiarize yourself with the DevTools, which we’ll be using heavily:

   DevTools /​ Web Inspector

2. You’ll be completing the next phase of your Manuscript projects:

   Project 1: Styled Markup

   As in our demo today, you will be adding a style.css to your project. You will use this stylesheet to begin to layer your design onto your semantic document, from last week⁠—adjusting the font(s), their sizing/​hierarchy, color, spacing, and so on⁠—making use of the CSS lecture and referencing the demo repo, above.

   _{Watch the recording, revisit the lecture, and talk to each other! You’ve got this.}

3. When you are done, submit a link to your URL⁠s, as before:

   Submission Form

   _{We’ll be reviewing these async, using GitHub Issues. We’ll try to get through everything in the next few days!}