Week Nº 4

Session Recording

Notes on Sketches

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. (Maaaaybe 1 ¹/₂, being generous.)

A lot of the work landed much closer to “explorations on one theme” rather than “three distinct directions.” (A font or color change alone does not always make new direction.)

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.

If your “boss” asked you for three directions, specifically calling out “distinct” and “more than font/color changes”⁠—would you turn in three of the same thing?
It also wasn’t very… sketchy.

Lots of “here are my only three frames.” We want to see more in-progress and more 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.
Lots of too-small type.

We did say that to some extent, scale/zoom doesn’t matter⁠—it is about the relationships. But we doubt everyone was drawing at 200% zoom, so the type was often too small. Put yourself in the mind/eyes of your reader! And also folks reviewing your Figma.
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.
Multi-column, print layouts.

We left lots of 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.
We aren’t designing posters.

Relatedly, there were a lot of Frame-centric layouts. Keep in mind that your reader never sees “the whole canvas” as we do in Figma⁠—this is a 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.
In the Semantic DOM we’ve seen so far, not enough structure.

There are lots of “text fragments” (no <p> or <h#> tags around), very flat hierarchy, little overall organization. We probably shouldn’t see <br> unless you’re writing poetry. We definitely shouldn’t see div ! This is about finding our semantic meaning first.

You will need more groupings/containers around your text elements to work towards your designs. We want to see a lot more semantic structuring of your document. Boxes within boxes! Dolls within dolls! Nesting.

Our second-half demo repo is indicative of what we want to see, here.

TL;DR: Always Mind your medium!

Alright, alright, CSS

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

An Intro to CSS

Let’s Try This Together

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

Open your repo from last week⁠—either from GitHub Desktop or VS Code. We’ll be using a demo repo, which you can reference:

manuscript

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.

Related tip: Wrap with Abbreviation !
Let‘s start with some general ergonomic settings ⌘ , to get comfortable:
- User vs. Workspace (and even syncing)
- Enable Auto Save
- Toggle Render Whitespace
- Tabs vs. spaces 😬
- Convert between them and adjust our defaults
- Syntax highlighting and themes
- Make it look like GitHub for consistency
And we’ll improve our turnaround on seeing changes with the Live Server extension.
- Note file:///Users… vs. http://127.0.0.1/… vs. https://username.github.io/… URL⁠s in your browser⁠—only the last are online!
- No more ⌘ R⁠—make a change and see the live reload !
Okay, for real, let’s 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 live also live in a <style> tag, or even inline⁠—but these don’t scale very well!
- So we’ll be using an external (not in our HTML) stylesheet
- Great time to talk about VS Code’s side-by-side editing!

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>

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.”
Let’s also try adding in a reset to start with a clean slate:
```
						<link href="https://typography-interaction-2526.github.io/assets/reset.css" rel="stylesheet">

			
	
```
Try commenting ⌘ / this line in and out, then looking again in the browser! Note the differences, as the user-agent styles are reset.
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">

			
	
```
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; }

			
	
```
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=National+Park:wght@200..800&display=swap" rel="stylesheet">

			
	
```
And then we’ll apply it⁠—in this case, to everything:
```
						:root { font-family: 'National Park', serif; }

			
	
```
You can also @import right into the top of your stylesheet, if you prefer:
```
						@import url('https://fonts.googleapis.com/css2?family=National+Park:wght@200..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!
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.

For Next Week

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

Project Nº 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 demo repo, above.

Watch the recording, revisit the lecture, and talk to each other! You’ve got this.
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!