coding owl

public class Problem1 { public static void main(String [] args) { int sum3 = 0; int sum5 = 0; int sum15 = 0; for (int i = 3; i < 1000; i += 3) { sum3 += i; } for (int i = 5; i < 1000; i += 5) { sum5 += i; } for (int i = 15; i < 1000; i += 15) { sum15 += i; } System.out.print(sum3 + sum5 - sum15); } }

Yeah, I don’t know.

It gets better (or worse) when I look at my old solution to the second problem:

By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.

public class Problem2 { public static void main(String[] args) { int sum = 0; for (int index = 1; fibonacci(index) < 4000000; index++) { if (fibonacci(index) % 2 == 0) { sum += fibonacci(index); } } System.out.print(sum); } // Find the nth Fibonacci term. public static int fibonacci(int n) { if (n == 1) return 1; if (n == 2) return 2; return (fibonacci(n - 1) + (fibonacci(n - 2))); } }

I used a recursive solution to find the nth Fibonacci number, which isn’t too surprising since I’m pretty sure I had just learned about recursion at that time. But then I called that recursive method three times in that for loop?

Here’s my iterative JavaScript solution:

They looked to GOV.UK for inspiration

“Be consistent, not uniform” (GOV.UK design principles)

18F pitched the style guide idea and got 4 months to make an MVP

First they talked to people who work for USDS

Flexible design

A consistent look and feel with common design elements will feel familiar, trustworthy, and secure

What components are important?

Brought in various departments and did an inventory of websites

They tested typography pairings on actual government websites

Settled on a font, but noted that it’s not required, so agencies can retain their brand identity if they want

3 ways to use the standards

Our design and our code

Our design and different code

Different design and our code

Flexible code

Just HTML, CSS, and JS

Sass preprocessor + Bourbon and Neat

Component-based design

Modified BEM syntax

For a healthy open source community…

Respond to GitHub issues within 24 hours

Respond to pull requests within 48 hours

You don’t have to have the answers, just acknowledge them

Be kind

Example

Name: naming

Context: a way to identify

Problem: we need to identify things so everyone knows what we’re talking about

Solution: work with stakeholders to establish a name

Related patterns: documentation

Why do we need a pattern language for front-end development?

The web is a complex system with moving parts

A pattern language for front-end web systems (four types)

I. Global patterns

Community guidelines

Temporary autonomous zones (meetups/conferences)

Independent disciplines

Web guidelines (W3C)

Open borders

Accessibility

II. Process patterns

Purpose

Planning/management

Code reviews

Cross functional teams

Single origin of truth

Documentation

Naming

Design systems

III. Workspace patterns

Editors

CLI

Syntax highlighting

Shortcuts

git/GitHub

Version and dependency management

Configuration/settings

IV. Project patterns

Build tools

Bundling dependencies

Directory structure

Linters

Composable

HTML templating

CSS methodologies

JS

Content strategy

Shareable data

Identifiers

At Casper, they created something called Ando that uses many of these patterns

Open borders = working with people across different disciplines

Problem: provide a way for everyone to work on the same codebase and contribute their skills

Solution: use a system that has minimal dependencies

Static, no DB, no migrations, back to basics

Related: cross functional teams, build tools

Documentation = a way to record decisions

Problem: code is not self-documenting. Decisions need to be captured. Captured decisions need to be easily referenced by people who did not write the doc

Solution: use community-vetted code documentation solutions. Pick a place to store documentation

SassDoc

JSDoc

HTML templating = a way to create sound structures, a way to componentize

Problem: HTML is verbose and at scale it becomes difficult to maintain

Solution: use a templating language

Nunjucks, Jade, Swig, Handlebars

Related: naming, documentation, directory structure

Directory structure = organizing/grouping project files

Problem: need a way to organize files that is easy to comprehend

Solution: traditional vs. component

Traditional

Files spread all around the app

Cruft often remains in the codebase

Component

Group files by component

Everything in one place

Works for organizing components and views

Use traditional director structure within component directories

Common accessible code techniques

Use semantic HTML

Use h1 for headings, not a span that is styled to look like a heading

This is for screen readers!

Use the button tag for buttons!

Input fields: use visible, explicit labels

Current trend is to put the label inside the input field as a placeholder

This is bad because of low contrast, and once you start typing it goes away

Also need to associate label with form field using for

Give ALL images alt text

If the image is redundant (example: home icon next to home label), use empty alt text or aria-hidden=“true” for SVGs

decorative images: use discretion, often empty alt tags

ARIA = accessible rich internet applications = communicate element’s role, state, and properties to assistive technology

Use it only when you need it

Modals, menus, accordions, tabs, alerts, trees

WCAG 2.0, @heydonworks’s practical ARIA examples, web-a11y.slack.com

Accessibility in design

Make keyboard interactions as rich as mouse interactions

A lot of people don’t use the mouse

Example: Facebook reactions animations still work when navigating with keyboard

Don’t forget about focus styles (the blue halo)

Don’t get rid of it! People navigating with keyboard rely on these

You can style the focus to look better than the blue halo (branding comes into play here)

Tooltips should appear on hover AND focus

Color

Rule #1: reasonable contrast for text

4.5:1 for regular text

3:1 for large text

Lea Verou’s contrast ratio tool

wave.webaim.org

colorsafe.co

Use vibrant colors! Use light colors! Just make sure the text has high contrast

Use those fun colors for borders, icons, etc.

Rule #2: use more than just color for meaning

Test: put website in grayscale mode and see if you can still use it

Example: input field border turns red when wrong = not enough

Add an icon and a message

Sharing your accessible code/documentation

Include accessibility notes in your documentation

See Dropbox’s Scooter framework, Salesforce Lightning, Bootstrap

Component-level documentation

Discourages accidental removal of accessible aspects

Encourages constant attention to accessibility

Spreads best practices

General documentation

Might get overlooked (so shouldn’t exist by itself)

Encourages holistic thinking about inclusive design

Designers want:

Thematic

Theory

Educational

Guidance

Developers need:

Granular (how to implement)

Components

Instructional

Maintainablity

How they compliment each other:

Documentation = what’s there and why

Defaults = building blocks and rules for spinning up new things

Unity and overlying choreography with language (?)

Guide and empower future contributors to make decisions

Deliverables: two types

Unicorns = designers who can code

Developers are given prototypes with code

Some designers argue that designing with code is inherently limiting

Throw-over-the-wall

When developers are only given gifs/movies, this is frustrating

Developers need numbers! Easing, timing, and properties

Easing = rate of change

Acceleration = ease-in —> system-initiated animations

Deceleration = ease-out —> human interactions

Bounce = increase animacy and add an element of fun

Fade and color changes look best with more linear subtle curves

Timing/duration

modularscale.com

Limitations

70-700ms

200-300ms is a sweet spot

Shorter duration for fades and color changes

Longer duration for large movements

Use ms instead of s to prevent decimal hell

Properties

What to animate

Opacity and transform are the most performant properties to animate on the web

But don’t be afraid to push the envelope! “The art challenges the technology, and the technology inspires the art” (John Lasseter)

Easing + timing + properties = deliverables = animation vocabulary

Patterns

Notification and dismissal: when something pops/fades in and then slides out

Storyboards (verbal)

Use orange to indicate behavior/animation, use blue to indicate user action

Blank story boards

boords.com

Animatics (visual)

Sometimes you need a video/stop motion/rough sketch that moves

But it is NOT a deliverable on its own

Keynote, Adobe After Effects, Principle app, Stop Motion app

Prototypes (visual)

Need interaction to be able to test an animation on users

Native-oriented: Principle, Pixate

Web-oriented: Invision + gifs, UX Pin

Code required: Foundation, Framer

Combine all three for great deliverables!

Generating buy-in (how to get people to care about animation documentation)

Group writing

Get index cards and ask people to draw the in-between stage between stage A and B (i.e., the animation)

Cultivate and champion: you need someone to be a champion!

Have a co-conspirator

Empathy

Who am I talking to?

What emotional state are they in?

What is the context (frequency, placement)?

What do I want them to take away from this?

Courtesy

Get out of people’s way = say what you need to say, then let them go do their work

Am I providing all the info that people need?

What can I do to simplify this message?

How does this help the user?

Is this actually intuitive? Do I need to speak at all?

Craftsmanship

Care about details, work with transparency, give up the ego, be prepared to explain reasoning behind decisions, be better together

Is this as good as I can make it?

Could someone else make it better?

What are the options?

Playfulness

Go beyond expectations

(I missed the actual bullet points; hopefully she posts her slides at some point)

Honesty

Is this really what I want to say?

Is this really how I would say it?

How human does it sound if I read it out loud?

Learning to crawl

Design audit and inventory of all components in designer’s comps

Standardized values became design tokens and were abstracted

Font sizes, color, etc.

theo: a tool to turn tokens stored in JSON to Sass or whatever

Break components down to their smallest patterns and objects

Clarity and understandability in class names

BEM

Keep specificity low

Naming is hard!

Learning to walk

Enterprise apps have unique traits

They demand content and data-rich interfaces

Lack vertical rhythm

Heading levels may vary and our components should be agnostic

So they equalized all headings to a base font size of 1rem

Then made utility classes to get the heading styles they needed

Baked accessibility in

Semantics matter

ARIA roles

rem unit sizing

Play well with others

Namespacing! They put slds in front of every class

Learning to run

How do we lower the bar for adoption? Very important for a company as large as Salesforce

How do we maintain consistency across a massive organization?

How do we keep our design system agnostic? Internal and external developers

One thing they knew…minimize dependencies

You don’t know what you don’t know

What makes up your ecosystem?

Who are your customers?

Try to understand your potential footprints

Did not include JavaScript

At Salesforce, developers use React, Angular, jQuery, etc. so leaving out JS makes it easier for any stack to use the design system

Design team has to support 3 versions simultaneously

Production release, previous production release, future release

As a developer

How to keep track of changes?

When is right time to deprecate?

As a consumer

How do I know what is deprecated?

What kind of guidance do I get?

How long do I have to upgrade?

Solution: sass-deprecate

@include deprecate('3.0.0', 'some stuff here')

Basics of web architecture

Separation of concerns (data, logic, structure, presentation)

Specificity is your guide (prefer the shallow end)

Don’t repeat yourself but don’t stretch for patterns

“These elements share a border style” is not enough for a pattern but “these elements share a purpose that is represented by a border style” is good

Naming conventions consistent across entire team

Use separate JS hooks like js-something instead of a random CSS class

No right answer but no answer at all is wrong

In Sass: extends works well when representing is-a relationships

Look up ITCSS

Sass maps are cool!

Better than using variables when defining a color palette, for example

Problem with maps: cannot self-reference

Solution: define now, calculate later

See the accoutrement-color project

You need documentation! See SassDoc

Toolkits are a byproduct

Test your Sass using true

Lint your code

Once you know what components and parts to work on…

Framing a Design System’s Roadmap

Take what we could do and decide on what we will do by when

When you get asked to create a design system for a large organization (sorry for the question marks; I either didn’t write it down correctly or forgot to clarify it for myself)

Choose flagships that’ll commit to you too

Choose between 3 and 5 (?)

Use their launch dates or make your own

What’s your get (?)

Avoid distractions

Like the home page: build one-offs because it’s always going to be changing and controlled by people you can’t argue with

Not everything needs to go into the system

Hook system access via code they’ll use first

Radiate influence from web apps

Where the important metrics are

Demo value across the journey

More helpful articles

Stitching Prototypes

Team Models for Scaling a Design System

The Salesforce Team Model for Scaling a Design System

Also a video: Leah Buley: The Modern UX Organization

When making decisions, use The Sliding Scale of Giving a Fuck

Step one: discover

Who will use the style guide?

Users = designers, engineers, PM’s, QA’s, sales/marketing, doc writers

Builders = designers, engineers, doc writers

Stakeholders = CEO, department heads, project leads

Also consider current projects, future projects, product-specific needs

Step two: interview

What questions to ask?

Users

Uncover problems: what are your biggest pain points?

Uncover goals: what would a style guide enable you to achieve

Uncover usability: what info do you need from a style guide? How do you want this info presented?

Builders

Uncover goals: what would make a successful style guide

Uncover requirements: what are important factors to consider? What constraints?

Stakeholders

Uncover problems: what problems to solve?

Uncover goals: what impact do you hope for this style guide?

Face-to-face is best, pull out “nuggets,” use sticky notes, divide and conquer if you have a lot of people to talk to

Step three: understand

Cluster nuggets to discover problem statements

Example

Nuggets

Designer: redlining takes a lot of time

Developer: I have to go through every redline, many of which are repetitive

Problem statement: people wasting time on repetitive tasks

Step four: define

Principles: something to strive for

People wasting time on repetitive tasks —> efficiency

Information not readily distributed to all teams —> transparency

Unwieldy and unsustainable codebase —> consistency

User stories

As a designer, I need to quickly communicate basic elements of a page to an engineer

As an engineer, I need clear instructions detailing how components will be used

Metrics: how you will measure success

As a designer, efficiency means decrease in JIRA story size/QA tickets

As an engineer, efficiency means shorter code reviews and a decrease in GitHub changes

Potential issues of Bootstrap-like frameworks

One size fits all

Lookalike

Bloat

Compatibility

Quote from Dave Rupert: “Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs” (more context here)

Benefits of pattern libraries

Promotes UI consistency and cohesion = more conversions and $$$

Users are already familiar with the experience (what a button looks like) so they can get through the process faster

Faster production = more features faster

Shared vocabulary = more time collaborating, less in meetings

Easier to test = more responsive, performant, accessible experiences

Useful reference = an essential resource and hub for best practices

Future-friendly foundation = modify, extend, improve upon over time

How to convince your boss/client (“make them cry”)

Interface inventory = an exercise where you go through every web page and find every type of button, form input, icon, block, etc.

Should point out inconsistencies

Also establishes scope of work

Groundwork for future pattern library

Atomic design

Atoms

Buttons, labels, input fields

Molecules

Button + label + input field = search molecule

Organisms

Search molecule + nav molecule = header organism

Templates

Combine organisms to make a content skeleton

Pages

Put real content into a template

You should also test variations here

Establish direction

Style tiles, element collages —> get an idea of what client wants

Developer plays role of prep chef —> do upfront work by starting on the pattern library (code from day one of the project)

Check out Pattern Lab

Build up fidelity

Danger: as soon as pattern library stops reflecting the website, it becomes obsolete and fades away

Now for some clarity on the difference between a style guide and a design system

“A style guide is an artifact of the design process. A design system is a living, funded product with a roadmap and backlog, serving the ecosystem”

A great looking style guide reflects an organization’s commitment to making a great design system

Maintainable design system = the holy grail

Lonely Planet

Yelp

U.S. Web Design Standards

Rule One: Default Binding

most common case

standalone function invocation

default catch-all rule

applies when a function is called with a plain, undecorated function reference

var counter = 0; function incrementCounter() { this.counter++; } incrementCounter(); console.log(counter); // 1 - got incremented

Note: if the function is in strict mode, the global object is not eligible for the default binding, so this.counter in the above code would throw an error.

Rule Two: Implicit Binding

consider whether the call-site has a context object (i.e., owning/containing object)

var counter = 0; function incrementCounter() { this.counter++; } var object = { counter: 10, incrementCounter: incrementCounter, }; object.incrementCounter(); console.log(counter); // 0 - did not get incremented console.log(object.counter); // 11 - got incremented

But wait! There’s more. In some situations, the implicit binding can be lost.

var counter = 0; function incrementCounter() { this.counter++; } var object = { counter: 10, incrementCounter: incrementCounter, }; var copyOfIncrementCounter = object.incrementCounter; copyOfIncrementCounter(); console.log(counter); // 1 - got incremented console.log(object.counter); // 10 - did not get incremented

Here, copyOfIncrementCounter looks like it’s a reference to object.incrementCounter, but it’s actually a reference to the global incrementCounter. So we fall back to the default binding rule and the global counter variable gets incremented.

Another example of this situation:

var counter = 0; function incrementCounter() { this.counter++; } var object = { counter: 10, incrementCounter: incrementCounter }; function doSomething(callback) { callback(); } doSomething(object.incrementCounter); console.log(counter); // 1 - got incremented console.log(object.counter); // 10 - did not get incremented

Why?

Parameter passing is just an implicit assignment, and since we’re passing a function, it’s an implicit reference assignment, so the end result is the same as the previous snippet.

Rule Three: Explicit Binding

force a function call to use a particular object as this

use call and apply, which are available to all functions

call and apply are methods that take an object to use for this as their first argument

call and apply are identical with respect to this; we won’t worry about their differences for now

var counter = 0; function incrementCounter() { this.counter++; } var object = { counter: 10 }; incrementCounter.call(object); console.log(counter); // 0 - did not get incremented console.log(object.counter); // 11 - got incremented

Note that if a primitive is passed instead of an object, it gets wrapped in its object-form (String, Boolean, or Number). This is called boxing.

Unfortunately, explicit binding alone still doesn’t offer any solution to the issue mentioned previously, of a function “losing” its intended this binding…

…but hard binding, a variation pattern around explicit binding, will work.

var counter = 0; function incrementCounter() { this.counter++; } var object = { counter: 10 }; var incrementCounterWrapper = function() { incrementCounter.call(object); } incrementCounterWrapper(); console.log(counter); // 0 - did not get incremented console.log(object.counter); // 11 - got incremented incrementCounterWrapper.call(window); // will it use the global counter? nope! console.log(counter); // 0 - did not get incremented console.log(object.counter); // 12 - got incremented

What’s happening here is incrementCounterWrapper internally calls incrementCounter with object as this. No matter how incrementCounterWrapper is called, it will always manually invoke incrementCounter with object.

Since hard binding is such a common pattern, it’s provided with a built-in utility as of ES5, Function.prototype.bind

bind(..) returns a new function that is hardcoded to call the original function with the this context set as you specified.

var counter = 0; function incrementCounter() { this.counter++; } var object = { counter: 10 }; var incrementCounterWrapper = incrementCounter.bind(object); incrementCounterWrapper(); console.log(counter); // 0 - did not get incremented console.log(object.counter); // 11 - got incremented

Rule Four: new Binding

Ah, the new keyword. Another confusing one that I often see but am never sure when to use myself.

JavaScript has a new operator, and the code pattern to use it looks basically identical to what we see in those class-oriented languages; most developers assume that JavaScript’s mechanism is doing something similar. However, there really is no connection to class-oriented functionality implied by new usage in JS.

Okay, what else?

First, let’s re-define what a “constructor” in JavaScript is. In JS, constructors are just functions that happen to be called with the new operator in front of them. They are not attached to classes, nor are they instantiating a class. They are not even special types of functions. They’re just regular functions that are, in essence, hijacked by the use of new in their invocation.

How is new relevant to this, then?

Well, when a function is invoked with new, a brand new object is created. That object is set as the this binding for that function call. And that function call will return the new object (unless the function returns its own alternate object).

var counter = 0; function incrementCounter(counter) { this.counter = counter; this.counter++; } var newIncrementCounter = new incrementCounter(10); console.log(counter); // 0 - did not get incremented console.log(newIncrementCounter.counter); // 11 - got incremented

Rule Precedence

new binding

explicit binding

implicit binding

default binding

More detailed:

Is the function called with new (new binding)? If so, this is the newly constructed object. var bar = new foo()

Is the function called with call or apply (explicit binding), even hidden inside a bind hard binding? If so, this is the explicitly specified object. var bar = foo.call( obj2 )

Is the function called with a context (implicit binding), otherwise known as an owning or containing object? If so, this is that context object. var bar = obj1.foo()

Otherwise, default the this (default binding). If in strict mode, pick undefined, otherwise pick the global object. var bar = foo()

For a discussion on why this is the case, read the original material here.

When I ran the code in the console, calling testList(), I got 'item2 undefined' in an alert three times. But according to the explanation, I should have seen 'item3 undefined'.

Note that when you run the example, 'item3 undefined' is alerted three times! This is because just like previous examples, there is only one closure for the local variables for buildList. When the anonymous functions are called on the line fnlist[j](); they all use the same single closure, and they use the current value for i and item within that one closure (where i has a value of 3 because the loop had completed, and item has a value of 'item3').

Unless there’s something wrong with my browser, I don’t think that’s completely correct. Let’s look at the buildList function in depth.

function buildList(list) {

Passing in a variable called list to the function.

var result = [];

Just initiating an empty array.

for (var i = 0; i < list.length; i++) {

Here we have a standard for loop. But in JavaScript, you have to remember that the variable i gets hoisted to the top of the current scope (which in this case is the scope of the buildList function). So once this loop is done, we’ll still have access to i.

var item = 'item' + i;

Creating a string using the word ‘item’ and the current value of i. I think this is where my confusion is coming from. More on that later.

result.push(function() { alert(item + ' ' + list[i]) });

Here’s where the fun closure stuff happens. We’re creating new functions and pushing them onto the result array. These functions are special because they have access to the enclosing function’s variables, like list and i. And they will still have access after buildList is done running—the variables are saved in a closure.

} return result; }

The array of functions is returned.

Calling buildList([1, 2, 3]) and then each of the functions in result always yields 'item2 undefined'. The undefined part makes sense, because at the end of the for loop, i increments one last time to 3. So i = 3 at the point in time when we call the functions in result. Since the input array [1, 2, 3] only has three elements, trying to access the fourth element at index 3 results in undefined.

As for why I’m seeing 'item2' and not 'item3', I think that’s because the item string is set in this line:

var item = 'item' + i;

Since the last time the code inside the loop is run is when i = 2, the item string is set to 'item2', not 'item' + i. In other words, the i is evaluated at that point in time, and not later, when i = 3.