Reading discussion
We’ll start with Natalia Cecire’s essay, Apple’s Modernism, Google’s Modernism:
Unit 5 reading synthesis (Modernism)
We’re going to start as we have the last couple times, with you first discussing your response/
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:
-
We would like to remind everyone that these are due next week.
-
And also add that they account for 40% of your grade.
-
Both of these things have been true since the start of this semester, and should not be a surprise to anyone here. This isn’t to scare you, but we want to re-emphasize the importance of these projects (and your presentations of them).
-
We’re saying this because many of you (as of writing) are significantly behind where we’d expect you to be on these. This isn’t everyone, but if only practically, it bears repeating to the whole group.
-
Our read of this is that (again, for some of you) it isn’t a difficulty thing, it is a time thing. We think we can tell the difference, and we can’t help you when it is the latter.
-
We also want to say that we’ve seen a lot of a… copy/paste approach in your code. We will also remind you of our policy on code plagiarism. Consider yourself warned.
-
So, all this to say, we think some of you have a long week ahead of you. That’s fine; that is (sometimes) part of this work. But now you have to show us your engagement, if you haven’t already!
Some other stuff we haven’t talked about yet but want you to have at least heard of before the end of the semester
Git/GitHub and collaboration
- Branches
- 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
maintrunk. When you do this to a separate repo it is called forking. -
Figma has started to adopt this concept, too!
- Merges
- 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
mainwith 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
- Agile
- 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.
- Redlining
- 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.
- Dogfooding
- 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.
Accessibility
- A11y
- 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
- Bootstrap
- 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.
- SASS / SCSS
- 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.
- BEM
- 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--modifierin 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
.redor.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
-
You will be finishing your projects and their presentations!
Another reminder, everyone’s projects are due next week.
-
As always, submit your (final) links to the submission form:
Double check that your links work—that your repos are set to public and we have permission to view your decks! This has been all over the place.
Last reminder, we will not accept additional work on these after the start of class next week. This is to be fair to the folks who go first. We have timestamps. Don’t put us in that position.
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.