Skip to main content

Writer/Designer’s studio: web unit

Work to have done:

Plan for the day:

  1. General advice on moving from proposal to product
  2. Brief intro to the browser inspector (Firefox, Chrome)
  3. Set goals and go forth!
  4. Update your goals

1. General advice on moving from proposal to product

Start by thinking about structure (i.e. HTML before CSS)

Remember from last time that though you probably have a vision for how your site should look, it makes sense to begin by thinking about the structure of your content. That will give you the material you need to support multiple views, depending on screen size and/or what begins to feel most important.

So I recommend starting by listing and grouping:

  1. What are the content sections your site will include?
  2. How might you group those things hierarchically? That is, what's the most important for a viewer to encounter first? Which things are (or could be) parts of others, and which things have to be at the same level?
  3. If you can make a nested list of your content areas, that could serve you as a navigation... and probably also a list of headers (<h1>, <h2>, etc).

Beware of scope creep; plan for phased releases

Bear in mind that you only have a couple more weeks on this project. If you've just given yourself an ambitious agenda, think about "minimum deliverable product" and "stretch goals." You have version control; you can iterate. In other words: you can always come back and add more, but it's good to start with what's really at the core of your website idea.

Let appearances reflect the structure, not vice-versa

This one's related to the first, but applies when you're starting to think about appearances. Visuals are volatile; structure should be steady. It can be very tempting to just accept your browser's default styles as a given, e.g. to jump from a large <h1> page title to an <h5> subtitle because it "looks about right." But this would mis-represent the actual structure of the document – and would seriously confuse screen-reader software trying to present the page to a blind visitor. Instead, take note of the CSS rules defining that <h5>, and apply them to <h2> in your stylesheet.

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 giving it a parent container – or a class. 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.

When you're ready to work on appearances, test CSS rules directly in the browser

Chrome and especially Firefox have great built-in developer tools to "inspect" elements of the page. It's already available: just right-click anywhere and choose "inspect element" to see the local html, the full cascade of CSS rules that apply to it, and a few other features beside. (Safari can do this, too, but you'll need to activate it first... and then "show the details sidebar.")

Crucially, you can also add CSS rules and immediately see what effect they would have on the page. (Safari users, note that the button to add a new rule is on the bottom left, not the top right as in the other two browsers.) Color pickers are an especially nice feature – and perhaps the one thing that Chrome's inspector does better than Firefox's at the moment, in that Chrome lets you change from hex color to RGBA or HSL, and directly adjust saturation / luminosity, e.g. to improve contrast.

screencast of the firefox in-browser inspector
Just be sure to copy your changes to a file for safe keeping, or they'll disappear when you refresh! To make copy/paste easier, click on the source your browser created for your new rules: in Firefox it's called "inline", in Chrome "inspector-stylesheet", in Safari "Inspector Stylesheet."

Stuck for what to do, CSS-wise? Start with some basic spacing

Work your way through Web Design in 4 Minutes, and borrow some of the most essential rules... e.g.

  • set a maximum width for text
  • add padding on main content and headers
  • change font-family away from the default "Times"

For more advanced layout (sidebars, columns, grids, etc), see the links in the homework assignment.

3. Go forth!

In the shared google doc, set a goal for today: what do you need to do to level up on HTML and CSS in the direction of your specific project? Note that a Website Preview is due Tuesday.

If you haven't yet, please do expand and read my notes above. Also remember that you have many Resources on our website; for today, might I especially point out the design advantages of placeholder text and/or images?

EXT: Want more practice with CSS selectors? Try flukeout.github.io, a lovely little learning game.

As usual, to get credit for asynchronous participation, please add your intentions and exit notes to the google doc when you start and stop working – and aim to work for at least two 20-minute pomodoros. (In class, we had about 50 minutes of straight-up studio time.)
Did you know? If you're building a website in GitHub (and you are), you can publish it for free, using GitHub Pages! You don't need to create a new repository: Just
  1. have a folder in your repo called "docs," [DONE]
  2. put your website's files in there (additional subfolders are fine), and
  3. change the settings for the repo to "use master branch /docs folder" as your source.
Then your site will build at https://your-username.github.io/your-repo. There are more options you can read about, but that's it in a nutshell! If you're worried about showing up in search results before your site is ready, you can always add a noindex meta tag.

Save about five minutes at the end to write me a brief exit note about what you’ve been working on.

4. 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? Reply to your note in the google doc.

Homework for next time

  • Do more of the tutorial, including at least Flexbox (8) and Responsive Design (10), if you haven’t yet.
  • Separately, also read about Grid Layout on Medium (and optionally the followup post on responsive grid). Author Rafaela Ferro includes screencasts, and also pictures of cute dogs!
  • Compose and push a website preview: a beginning. As detailed in the assignment, this should include:
  • A multifile project folder (probably named "docs," for ease of use with GitHub Pages), containing a combination of html and css and image assets, even if the whole thing is not yet 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).
    • (Optionally, take a screenshot of your Atom project setup, too.)
  • A plain text (.txt) or markdown (.md) file, explaining in at least 300 words what you're showing us in this preview. Feel free also to ask questions or lay out next steps for yourself!
  • An updated ASSETS.md file, now with any files or fonts you've actually obtained. As you go, add source documentation for any outside sources – and your permission to use them (e.g. licenses, fair use; see Writer/Designer p. 160-165).