Week 27

April 19

Adolph Loos. Glassware. 1929.

Reading discussion

We’ll start with Natalia Cecire’s essay, Apple’s Modernism, Google’s Modernism:

We’re going to start as we have the last couple times, with you first discussing your response/reaction with your table. We’ll have 10–15 minutes for this, then will pick up together.

We will take our break here, after our group reading discussion.

Project check-in

In lieu of meeting in groups/with us today, we want to talk briefly about your projects overall:

Some other stuff we havent talked about yet but want you to have at least heard of before the end of the semester

Git/GitHub and collaboration

Besides our second project, we’ve been using Git (via GitHub) primarily for solo, linear software development—but that is rarely how you work, especially at scale. One of Git’s core concepts is a branch (think tree metaphors). These are new/separate versions of your entire repository—which you create (people say branch, as a verb) off the main  trunk. When you do this to a separate repo it is called forking.

Figma has started to adopt this concept, too!

You might use these to develop a new feature, or to fix a bug, before you merge these back into main. Sometimes, someone else will have edited the same lines of code you were working on, in the meantime, and you’ll have to resolve a merge conflict—deciding whose work to take. (It can get messy.)
PRs (Pull Requests)
When you are working on big software projects/repos with multiple people—and when you don’t want to break main with hasty merges—you push your code up to GitHub and open a pull request (everyone says PR). This shows all your combined commits together, and allows your team to review and approve your work.

Working with devs

A popular way to structure software project management. Many product teams will use Agile as a way of prioritizing tasks—working in so called sprints (often two weeks) to deliver features incrementally rather than all at once.

One way that Agile is practiced is with a kanban board (from Japanese), a visual way of organizing tasks into discrete phases of work so that team members understand where different stories (or tickets/tasks) are in the queue. Many tools are built around this methodology.

Often a completed design in Figma isn’t enough for handoff to a developer for implementation. There can be ambiguities in your design that you may have thought through, but need more explanation than the visual on its own. This could be how you expect an element to behave responsively, or maybe you have a specific dimension in mind—some of this is handled by the Inspect panel.

Redlining (not to be confused with its other meaning) is the term for when you mark up or annotate your designs with information—key measurements or other important behaviors/traits. This forms the spec that a dev should implement.

Bus factor / bus count
On small product teams, certain individuals may be the only ones who understand how a certain feature works, or is implemented. The phrase bus factor (or bus count) is used in the lens of risk management—to make sure the product/team can continue if anyone gets “hit by a bus.”

Always try to avoid a bus count of one! Not just because of busses, but to distribute knowledge and understanding (and stress) among your team.

Technical (and design) debt
Very often, products have to make trade-offs between design or code quality to meet deadlines, or to handle scope creep. These decisions sometimes come at the expense of either side—sacrificing the most nuanced design, or giving up on the most pristine, sturdy code.

Technical debt (or the analogous design debt) are the accumulation of these short-term decisions—where you have postponed doing it the right way. Like other forms of debt, these often compound over time—if you don’t pay them down/address them as you move forward.

Often the best way—or at least the first way—to make sure your product is up to snuff is by using and testing it yourself. This term is called dogfooding, or eating your own dog food. (There are debates on the etymology). An example is Apple, pushing desktop publishing in 1980, outlawing typewriters internally.


A11y is a catch-all term for accessibility. Like i18n (for internationalization), the abbreviation a11y is shorthand for ensuring that your product is as inclusive as possible.
ARIA labels
While the best and most-basic way of writing accessible websites is to start with semantic DOM elements, sometimes there isn’t an appropriate one—this is where ARIA (Accessible Rich Internet Applications) labels come in. These are additional attributes you can add to an HTML element which help a screenreader to convey the meaning of your content.
VoiceOver / TalkBack / Narrator
Commonly-used assistive technologies: Apple’s VoiceOver, Google’s (Android) TalkBack and Microsoft’s Narrator. Some disabled folks use other screen-readers, but these are a good, built-in start.

Frameworks and approaches

The framework du jour for a long time—Bootstrap was created by Twitter as a way of quickly creating web apps. Because frameworks have to have opinions to work (think back to The Web’s Grain) the downside is that many websites created using this have a certain “made with Bootstrap” vibe. In a small environment you’ll likely be working with an existing (legacy) framework or component library, so understanding these trade-offs is important.
As you may have noticed, writing CSS can be repetitive and tiresome. Back in 2006, some (very opinionated) folks developed SASS (Syntactically Awesome Style Sheets)—which is a CSS preprocessor. It is its own language/syntax (mostly based on CSS) which gets compiled (processed) into normal CSS, which your browser understands. SCSS is a slightly different—but much more popular—variant of SASS. (When people say SASS, they usually mean SCSS!)

More recently, some of the utility/need for SASS has been obviated by CSS adopting similar features, like custom properties (variables) and soon, CSS nesting.

You might have also noticed that coming up with CSS class names can be difficult, as well—and only gets worse as your projects get larger. BEM (Block, Element, Modifier) is a commonly-used nomenclature methodology/practice to deal with this (and also avoid specificity problems).

It follows the pattern .block__element--modifier in classnames—and these double separators (__ and --) are sometimes seen even in non-BEM-y contexts.

Tailwinds / Atomic / utility CSS
An alternative approach to CSS naming—following a utility class methodology. This uses many small, descriptive or directly-property-mapped names (like .red or .flex) across any elements. This approach is sometimes kleenexed as atomic CSS or Tailwinds.

Your instructors wrote our own atomic CSS library, baking-in/formalizing MoMA’s brand, that we called Sol.

For next week

That’s it. We’ll end saying we are really looking forward to these, and are proud of how far you have all come. Show us what you can do here—for us, but also for yourselves and for each other.

Session recording