Amanda Olsen

Front End Developer User Experience Enthusiast


Thoughts on the industry

Best Practices for Automated Communication

Ordered from most-important to least-important

Macro: Groups of documents, processes

Make documentation part of every story.
a. This is how we keep docs up to date.

Build a hierarchy
a. It does not matter how good your content is if no one can find it.
b. Do not rely on search. Your navigation should be good enough to find things.

Remove everything that is not contributing
a. Anything that is not contributing is in the way.
i. Speed matters.
b. An old doc is worse than no doc because it reinforces the belief that docs are worthless.

When someone asks something already documented, send them the link to that doc.
a. Don’t answer their question.
b. This reinforces the Best Practice that users should read docs first and ask questions second.
c. And your document will likely say it better than you can say it anyway.

Do not store valuable information in wiki comments.
a. Comments, at the bottom of a wiki page, are meant for conversation only not for storing valuable information.
b. Once you learn something valuable, find the spot on the page where that content goes and add it.

Micro: Words, sentences, paragraphs

Don’t Repeat Yourself (DRY)
a. Just like we keep our code dry, we keep our docs dry.
b. Say what you need to say in one place only and then link to it as needed.

Be concise
a. Speed matters. Don’t slow me down. I don’t want to be reading your document to begin with.
b. Remove all unnecessary words. Less is more.

Be as specific as possible. Always.
a. Speed matters. If you’re not as specific as you could be, I have more thinking to do, which slows me down.

Be consistent
a. Don’t talk about “API devs” and later “server side devs”. Pick one! And use it! Every single time.
b. The text in a link should exactly match the page header on the next page.
i. Example: If I click “Tools & Access”, the page header of the next page should be “Tools & Access” not “Required & Recommended Tools”

Prefer lists
a. Prefer lists over paragraphs.
b. These are scan-able which increases speed of reading. And it’s all about speed.

Chunk content
a. Each new chunk requires a header, of course.
b. This also increases the scan-ability of your content. Brilliant!

Avoid nominalizations
a. “Use and Contribute” instead of “Using and Contributing”
b. “Include GC on your page” instead of “Including GC on your page”

Start most phrases with a verb
a. Usually applies to headers and list items.
b. “Setup Lodging spinner” instead of “Lodging spinner setup”
c. “Format a Pull Request” instead of “Pull Request Format”

Use active voice
a. “We use Yarn to install and manage…” instead of “Yarn is used to install and manage…”
b. “We configured Gulp to…” instead of “Gulp has been used to…”

Prefer simple language

Don’t be polite
a. If you ever see the word “Please”, delete it! Now!
b. If you ever see “you can”, delete it! Now!
c. “Install nvm and then use it to…” instead of “Please install nvm and then you can use it to…”

Avoid noun strings
a. “NASA is still developing the module that will provide living quarters for the astronauts aboard the International Space Station” instead of “NASA continues to work on the
International Space Station astronaut living-quarters module development project”.

Avoid formality
a. Write the way people talk. This decreases the reader’s processing time; it’s all about speed.
b. “You must” instead of “One must”.


These Best Practices come directly from the ideas below.

Know Your Audience

  • Readers don’t read, they “satsfice” (satisfy + suffice).
  • The reader is trying to get something done; your document is only a means to an end; in fact, your document is in the way.
  • Nobody wants to be reading your document.
  • Nobody wants to update your document.
  • If the reader loses faith, he will not come back.
  • If it’s too much work, the reader will quit and not come back.


  • An old doc is worse than no doc because it reinforces the belief that
  • docs are kinda worthless.
  • Anything that is not contributing is in the way.
  • It doesn’t matter how good your content is if no one can find it.
  • Build your hierarchy. Maintain your hierarchy. Honor your hierarchy.
  • Love your hierarchy. Cherish your hierarchy. Take vacations with
  • your hierarchy.
  • Remember the Golden Rule: how you treat your hierarchy is
  • how it will treat you.


Notes from DevNexus 2019

Enjoy/use/peruse at your own risk.

Some of these notes were taken rather quickly and may be wrong or contain typos. Human stuff like that. Overall, should be helpful content.

JavaScript Cage Match between Map, Filter, Reduce, and Find

  1. Scott McAllister:
  2. Review of methods
    1. Map
      1. Runs a function against each element of an array and places each result into a single new array
    2. Filter
      1. Same as map, but removes array items which do not match criteria
    3. Reduce
      1. Just like map, except that it accumulates the values (however you specify) creating a single new value
    4. Find
      1. Like filter, but only returns one value, when the test critera is first met
  3. Performance
    1. Tool he recommends:
    2. This was run against an array of 1 million values, comparing the method to a for loop
      1. map – much slower than for loop
        1. Much slower in Chrome than Firefox
      2. filter – also slower
      3. reduce – much faster
        1. super fast – the best one
      4. find – about the same
    3. Most methods don’t run against arrays this large (in the browser), so the significance of these findings is unclear.
      1. Maybe this applies more in node.js where it might be more likely to use massive arrays? Even then, though, a million? Seems like a massive edge case.

Getting Started with Service Workers

  1. Jennifer Bland:
  2. Service worker: script your browser runs in the background separate from the page itself
    1. (Kind of like a browser extension!)
  3. Does offline and background functions, such as:
    1. Display an offline page
    2. Stores pages offline
    3. Store content in the cache
    4. Push notifications
    5. Background sync
  4. Browser support
    1. All good except for IE11 and below
    2. Probably just need some graceful degradation for IE11 and below
  5. Requirements, etc
    1. Https ONLY (and localhost)
    2. Controlled scope (can apply to some pages but not others)
    3. Can only run one service worker active at a time
      1. Per domain, right? The user can run 2 web sites at once which both have them, I assume?
  6. It “installs” then “activates”. After that it listens for “fetch” and “message”.
    1. That’s all! There are no other events.
  7. View her deck here:

Don’t Be Afraid of the JavaScript Stack Trace

  1. Jennifer Bland:
    1. – Jennifer’s training videos
  2. Terminology
    1. Javascript
      1. Single threaded programming language – it can only do one piece of code at a time
    2. Call stack
      1. First, it creates a call stack – a series of functions it will call in a particular order
      2. Last in first out method
    3. Heap
      1. Mostly unstructured region of memory
      2. Memory allocation to variables and objects happen here
    4. Queue
      1. List of messages to be processed and the associated callback function to execute
      2. Messages executed by call stack
      3. Message processing ends with stack is empty
    5. Concurrency model
  3. Stack trace (this is what you see in the console when an error happens)
    1. What functions were called
    2. In what order
    3. From which line and file
    4. With what arguments
  4. 5 levels of logging using console
    1. .debug
      1. By default is hidden in most browsers. Will need to change the setting to see it.
      2. Finds and locates the code for a particulr function
        1. Will open up the elements pane in dev tools when needed
      3. She highly recommends this one.
      4. Example
        1. If you know the problem function, in the console, run the function
        2. Then in the console, run debug(nameOfFunction)
    2. .info
    3. .log
    4. .warn
    5. .error
  5. console.table() – pretttttty awesome
    1. Displays objects as a table
    2. Click on headers to sort
    3. Works with objects of objects
    4. Can pass it an argument which states which fields/names you want if you don’t want all
  6. console.trace
    1. Very cool
    2. “(anonymous)” is always the bottom line in the stack trace because it’s in the global scope
    3. She recommends console.trace instead of using .log or any other consoles, so that you can see exactly what the code is doing.
    4. Why use it?
      1. Easer than writing a series of console.log
      2. Only have to remember to remove one line for production
      3. Shows file where it was called
      4. Shows line number where it was called
  7. Why do errors occur?
    1. EvalError
    2. InternalError
    3. RangeError
    4. ReferenceError
    5. SyntaxError
    6. TypeError
    7. URIError
    8. MyCustomError
  8. window.onerror()
    1. window.onerror = function(message, file, line, col, error) {
      // send crash information back to your servers
    2. Add this to your production code
    3. Because the users will have a different environment than mine, I want to know what errors they experience with the stack track. This is what window.onerror() does.
    4. Otherwise, we don’t know what error trace the user experienced.
    5. Loggong in the error on the server for future reference.
    6. window.addEventListener… could do this instead the window.onerror
  9. View her deck here:

A Practical-ish Guide to Data Science

  1. Mark West:
  2. software development + machine learning + traditional research = interdisciplinary part of data science
  3. The skill of story telling
  4. Roles in a data science project
    1. data scientist
    2. data engineer
    3. visual storyteller
    4. process owner
  5. Isn’t data science just a rebranding of business intelligence?
    1. No. It’s more of an evolution of BI.
  6. You’re giving the job of programming to the machine itself.
  7. The three main types of machine learning
    1. Supervised Learning
      1. Linear regression
      2. Decision tree (an if statement, or series of them)
    2. Unsupervised Learning
    3. Reinforcement Learning
      1. The output of the first process is rules for the next process to use. This is AI, I believe.
  8. You want to keep your model somewhat generic.
    1. Otherwise you have “overfitted” it.
  9. Python, very popular. He recommends this.
  10. This deck:

Notes from DevNexus 2018

Attended my first DevNexus today (and yesterday). It was great! While it’s put on by the Atlanta Java Users Group (I believe), DevNexus is meant for all developers. It has good content for UI folks.

Below are notes from 3 of the 6 sessions I attended. These three were fantastic! Of the other three, two were pretty poor, and the third was too far outside my knowledge to be valuable to me, so I’m not posting notes from those. But the three below were absolutely worth my time. These notes are written with my mind in view, i.e. for me to review/understand later. If things don’t make sense to you, that’s why! And there’s likely typos, not my normal post.

Don’t Over React: Use Vue


  • Recommends just using a scrip tag to include Vue
    • as opposed to npm install, etc


  • must define/locate a place in the DOM before you can begin work
  • (Why do so many developers like cats? WHAT is the relationship?)
  • HTML supports validation baked in… so I guess you don’t need JS for this? Very interesting.
  • supports components
  • Routing
  • Can just use Vue to replace basic jQuery interactivity in a page
    • so cool! It looked much easier.
    • Would need to run some comparisons about how much time is used to make certain functions.
  • What is VueX?
    • The store thing?
    • A litlte confused about what is a store is


A Skeptics Guide to Functional Style JavaScript

  • Jonathan Mills
  • “Practical Design Patterns in JavaScript”
    • his Pluralsite class
    • I think he considers this more important than Functional JS
    • I SHOULD go through this class
  • He went to Wikipedia to find out what “Functional JavaScript” is
    • It is a “programming paradigm” (a way of writing JS)
    • There is no such thing as “Functional JavaScript”
      • Instead what exists is “Functional Style Javascript”
    • Functional JavaScript says: side effects are evil!
    • “Tail Recursion is its own reward”
      • what is that?
  • But, he says
    • In JS you can’t avoid side effects
    • Not all functions can be pure
    • And not all things will be immutable. That’s how things work.
  • Functional Style JS is about using less brain power and making things easier.
    • It’s about making your life easier.
  • His proposed subtitle to this talk: Never write a for loop again
    • Can use a .map function instead
  • A function is pure if:
    • it returns the same value for the same input value all the time
    • and doesn’t do anything else
  • Should research the methods which run against array
    • ’cause there’s a whole bunch of them and they’re needed so often
    • Find ALL these methods: he HIGHLY recommended it
    • Your code will be so much more efficient
  • Currying
    • a series of functions?
  • Functions are just things
    • you can pass them around
  • Monads
    • Mondas are things that get around the “no side effects” rule.
    • He says “screw monads” because he DOES NOT CARE about the “no side effects” rule.
  • Functional Style JS
    • as you write a line a code, ask yourself “is this the simplest way of getting this done?
    • And at the same time, keep an eye on the big picture
    • FEEL FREE to have side effects. That’s kind of the point…
    • And to use less brainpower.

Write Better JavaScript with TDD

  • James Bender
  • Loves TDD
  • Tests usually get cut because they’re at the end
    • because usually at the end you’re pushed for time, so something has to go
  • The workflow should be
    • specifications -> tests -> code
  • Tests turn the specifications into a living/breathing piece of code
    • He usually has someone from the business verify his tests
    • The other benefit is: you become the first consumer/user of your code (i.e. does it meet the tests?)
  • Unit tests
    • should be isolated/independent
      • I don’t know what order the tester will run them in
      • So they should all be independent
    • Each test should test one thing at a time, not multiple
    • They need to be repeatedable
  • “I like to keep my code DRY but my tests kind of damp.”
    • There’s a time to repeat things
    • You don’t want to change your code to fit your test; you want the reverse
  • Red, Green, Refactor
    • Red – Start by writing a failing test.
    • Green – Write just enough code to make the test pass.
      • Code is ugly at this point.
      • I know the code works.
      • We’ve passed the worst-case scenario
    • Refactor – Optimize your code for readability, maintainability, and quality.
  • You want to be able to refactor as you go – things change over time! – this is normal and good
    • That’s why you want tests.
    • So that as you refactor you don’t worry about breaking previously-written stuff.
    • And so that as time passes, and you get further and further away from remembering what you were thinking when you first wrote the code, your tests will do the thinking for you.
  • Testing frameworks
    • Jasmine – set the bar for testing, and/or was the original one
      • Karma
    • Jest
      • Developed by Facebook React team
  • As you’re writing the tests, you write just enough code to make the test pass.
  • I really like BDD better than TDD
    • Would be GREAT for confirming I understand all specs in full AND for ensuring the business person does too AND for testing my code
      • Awesome
      • 3 great goals achieved in 1 step
    • Can embed “describe” blocks inside “describe” blocks
    • So… BDD is a set of best practices for writing tests (could be TDD)
  • Test each scenario AND its opposite
    • I.e. the condition and the negative condition
  • JavaScript is like the child in kitchen who is helping you but then makes a mess of the kitchen.
    • Or something like that…
    • He was referencing the fact that JavaScript is extremely flexible (and helpful!) but won’t stop you from doing dumb things.
  • Mocking
    • Mocking is hard (I think)
    • Sooooooo glad not to be using Angular – looks like a bit of a mess
      • React is way simpler
      • Qunit, on my app, is way easier than what he was showing.

Forward JS: San Francisco, 2016

I was lucky enough to attend the Forward JS conference in San Francisco in late July. It was fantastic!

The conference occurs twice a year: in the earlier part of the year it is your standard in-person conference, in the later part of the year it is an online conference.

I attended the in-person conference, and did two workshops and one conference day: “Advanced JavaScript Fundamentals” with Kyle Simpson (workshop 1) and “Four Semesters of Computer Science in Six Hours” with Brian Holt (workshop 2).

While the content on the conference day was nice, I attended this conference because of the workshops. In fact, if I could have skipped the conference day, I would have. Why? I wanted hands-on, stick-in-my-mind, non-fluff non-excited-for-the-sake-of-being-excited (i.e. the way I assume most conferences are) kind of information.

Their workshops did not disappoint! Kyle Simpson is an incredible instructor and JavaScript master. Brian’s content was perfect for UI Engineers like me who feel like we may have missed something important in not getting a computer science degree. (I was actually surprised to see how little I was missing, i.e. what I already knew, but now I know what to focus on to make up for the rest!)

At a later point, I hope to post specific information from both of these workshops. For now: I could not recommend Forward JS more! (Or the city of San Francisco!)

Edit (Feb 2017): presentation I made of my Learnings from Forward JS Conference (PDF)

Regular Expression Basics

Note: I prepared the following notes for a presentation/workshop that I recently gave at work to the UI Engineer community.


  1. Regular Expression – a pattern describing a certain amount of text
    1. It is case sensitive.
  2. Literal character – a character we want to find
  3. Metacharacter – a character which does the finding


  1. All Metacharacters: . | () [] ^ $ ? * + {} \
  2. Descriptions
    1. .
      1. Official Name: period or dot or wild.
      2. Shorthand: period
      3. Matches: any character except newline
      4. Example: .
    2. |
      1. Official Name: alternator
      2. Shorthand: Pipe
      3. Matches: the lefthand or righthand value
        1. If the lefthand side is found, it will skip the righthand side.
        2. Example:
          1. find e or m
          2. e|m
    3. ()
      1. Official Name: capture group
        1. A slightly more official name might be “subexpression”.
        2. They can be nested to any depth.
      2. Matches: a group
        1. Example:
          1. Find ‘gray’ or ‘grey’
          2. RegEx: gr(a|e)y
        2. However, it also create a variable which some call a “backreference”.
          1. $1 through $9
          2. Example:
            1. Wrap all “grays/greys” in strong tag
              1. Find: (gr(a|e)y)
              2. RegEx:
      3. Shorthand Name: none
    4. []
      1. Official name: Character Class
      2. Shorthand Name: Character Set
      3. Match: the first character, if it doesn’t exist try the next one, etc.
        1. Matches each character individually (i.e. it is not matching a string of characters).
        2. The order of the characters does not matter.
        3. If set to global, will match all characters.
      4. Examples:
        1. Find: all lowercase letters
          1. RegEx: [a-z]
          2. RegEx: [a-g1-4]
        2. Find: gray and grey
          1. RegEx: gr[ae]y
      5. Shorthand Character Classes (sometimes simply called “Character Classes”, but that’s less accurate)
        1. \d any number – shorthand for [0-9]
        2. \D anything but a number
        3. \s any space
        4. \S anything but a space
        5. \w any letter
        6. \W anything but a letter
  3. Anchors
    1. ^
      1. Official Name:
        1. Left Anchor (if outside of square brackets)
        2. Caret (if inside square brackets)
      2. Shorthand Name: none
      3. Matches
        1. If it’s before a letter, it means the letter following must be at the beginning of a string.
          1. Find: S at beginning of line
          2. RegEx: ^S
        2. If it’s inside square brackets, it means “not”.
          1. Example: [^m-z]
    2. $
      1. Offical Name: Right Anchor
      2. Shorthand: none
      3. Matches: If after a letter, it means the letter previous must be at the end of a string.
      4. Example
        1. Find: ! at end of string
        2. RegEx: !$
  4. Quantifiers – controls the number of times the preceding character is found
    1. ?
      1. Official name: question mark
      2. Shorhand Name: none
      3. Matches: 0 or 1 repetition of the preceding character
      4. Unsure, but careful
        1. I don’t know what I want! I just know I don’t want a lot of it.
      5. Example
        1. Find metacharacter with or without the “s”
          1. RegEx: metacharacters?
        2. Find all variations of Jennifer
          1. Jenn(ifer)?(s)?
          2. Jenn(ifer)?(s|y)?
          3. we’ll do further variation on this in the next section
    2. *
      1. Official Name: Asterisk or Star
      2. Matches: 0 or more repetition of the preceding character
      3. Shorthand Name: The Star
        • I’m the star, I’ll take everything, even if it’s not there.
          1. “Even if it’s not there” means it won’t break the regular expression.
      4. Example
        • Find metacharacter with or without the “s”
          1. RegEx: metacharacters*
        • Find all variations of Jennifer and includ the last name (whether or not it exists).
          1. Jenn(ifer)?(s|y)?\s\w
        • Find dollar amounts with or without dollars (i.e. could be sense only).
          1. \$\d*.
    3. +
      1. Official Name: Plus sign
      2. Matches: 1 or more repetitions of the preceeding character
      3. Shorthand Name: More friends!
        • He always wants more friends, and won’t take no for an answer.
      4. Example
        • Find: metacharacter with one or more s’s
        • RegEx: metacharacters+
    4. {}
      1. Official Name: Repetition Operator
      2. Shorthand Name: quantifier, or curly brackets
      3. Matches: n number of repetitions of the preceding character
      4. Example
        1. Find: metacharacters where there are 3 “s” only
          1. RegEx: metacharacters{3}
          2. RegEx: metacharacters{2,3}
          3. RegEx: metacharacters{4,}
        2. Find a standard telephone number
          1. {n} [0-9]{3}-[0-9]{4} finds 123-4567 (a standard telephone number)
  5. \
    1. Official Name: Backslash
    2. Matches: forces the following metacharacter to be treated as a literal character.
    3. Example
      1. Find: dollar amounts
      2. RegEx: \$\d*.\d{2}


Notes on Page Performance

[Note: I wrote this 03-31-2015 with the primary subject being This was my research at the time and not all statements may be true.]

  • Terms
    1. Page Performance
      1. How fast the page loads
    2. User Experience (in this context)
      1. How fast the user thinks the page loads
    3. Parse
      1. Break into pieces, and/or step through the pieces.
  • Page performance vs. user experience
    1. A page can perform well, but be a bad user experience.
    2. More about this later.
  • Load times
    1. Optimal: under 1 sec
    2. How fast is the homepage?
      1. 5 seconds
      2. 2171 DOM elements
      3. (Source:
  • How a page is built/rendered
    1. The execution is top down and single threaded.
      1. Single threaded: processing one command at a time
    2. As soon as the parser hits a closing script tag, it must download and execute the entire script before parsing any more of the HTML (source).
      1. “This means often the parser must idly wait while scripts and stylesheets are downloaded.”
      2. Unless it has the async attribute.
    3. JS can not execute until all CSS has been downloaded.
      1. $(document).ready()  fires when the DOM is complete. – not necessarily needed
        1. It seems that’s when all CSS is downloaded and all JS has been executed… that can not be right.
    4. Process (overly simplistic)
      1. Read the HTML and parse it into a DOM tree.
      2. Load linked resources (stylesheets, scripts, images, media)
      3. Calculate the page layout (positions, sizes, colors, fonts, etc.)
      4. Render the page
  • Make it faster (for real):
    1. Reduce file size – greatest advantage here usually
      1. Minify CSS and JS
      2. “the average web page is now more than 1.8 megabytes, with images alone accounting for a full megabyte of that.” (source)
      3. “62% of the weight of the web is images” (source)
      4. home page – 1.3 MB
        1. 653 KB were images
        2. 500 KB were JS
    2. Reduce number of files
    3. Move CSS and JS to external files
      1. Research blocks of styles – how bad this – Solutions pages
        1. Definitely, this should go into an external file
    4. Reduce the number of inline scripts
    5. Use CSS/HTML to replace images where possible
    6. Reduce the number of domains which your assets are called from
    7. Images: set height and width so browser doesn’t have to calculate this
      1. Is this still true? Especially given responsive design
    8. Use valid markup
      1. Browsers do not need to error-correct when you do this
    9. Reduce by depth
      1. When reflow happens, it executes faster if DOM is not super deep.
    10. Target a select set of browsers to develop for
      1. “Do not require your content to appear pixel-perfect in all browsers” (
    11. Smart page structure
      1. head
        1. css
        2. scripts (necessary during page load)
      2. body
        1. content
        2. scripts (not necessary during page load – majority of scripts should go here)
          1. Scripts are parser blocking, meaning when the browser comes to a script tag, it downloads the entire file before continuing with the parsing.
    12. Javascript calls
      1. Use async where possible <script async >
        1. “Otherwise the browser will not render anything that is after the script tags that do not have these attributes.”
        2. Good to use when the DOM does not need to be finished while this JS runs and when no other scripts depend on this one being loaded.
        3. Best used for third party scripts.
        4. There’s no need to use async of script is loaded at the bottom of the page.
        5. Download and execute while the page is loading.
    13. Minimise browser reflow
      1. “Reflow is .. the web browser process for re-calculating the positions and geometries of elements in the document” (source)
      2. What triggers reflow?
        1. Add/remove element from the DOM
        2. Change an element’s class
        3. Resize the window
    14. Optimize CSS
      1. Remove unused CSS
      2. Minimize complex CSS selectors – descendant selectors in particular
        1. This may be something that we ignore as we use a CSS preprocessor. And that’s fine with me.
    15. Optimize JS
  • Make it faster (perceived)
    1. Speed Index: time for above-the-fold content to load (source)
      1. Load content above the fold quicker than all other content.
    2. Place most important/desired content at the top
      1. Perception of speed is influenced by how efficiently users can get what they most want out of your site
    3. Reassure users during wait times.
  • Chrome dev tools and Firebug
    1. Chrome – Network panel – better
      1. Nifty options at the top, “from cache”
    2. Firefox – Net panel – has some cool stuff
  • Browser differences
    1. “in Firefox there is this setting which limits the number of simultaneous requests per domain”
  • How fast is my function?
    1. var t0 =;
      [function here]
      var t1 =;
      console.log(“Call to doSomething took ” + (t1 – t0) + ” milliseconds.”);
    2. Chrome – Profiles – “Collect JavaScript CPU Profile”
      1. Start the profile, refresh the page, and then stop the profiler
  • Sources
    4. Kind of helpful page on the “Net” panel in Firebug:

Published Chrome Extension: Generate the Optimum jQuery Selector

I published my first Chrome Extension yesterday:

It can also be found on GitHub:

There’s certainly a Phase 2 or Phase 3 worth of features I’d like to add, to make it far more valuable, and I don’t think it’s totally bug free, but, “beta version” is live.


Creative Layouts

I haven’t posted in a while but felt the need to post this:

Their layout and interactions are unique but not unintuitive – definitely creative and certainly thought provoking for considering more new/different/effective layouts and animations.

And I probably like this one because it looks a lot like my site. That said, it does things my site doesn’t, and I appreciate it’s uniqueness:

This is an interesting layout, also with some great animation, but it doesn’t work on all breakpoints. Probably just needed a bit more work.

Appropriate, smart use of the full-screen approach – beautiful for this journalistic enterprise.

Love this as an excellent example of responsive design. Also the particular design elements they chose aren’t obvious, so it’s a nice deviation from the normal (for example, no use of the hamburger icon).

Super fun use of a map and a very creative UI in general:

Fabulous layout (albeit not that new) combined with video in a very effective manner:

Principles of Selecting Tags

  1. Divs should be used as a last resort.
  2. Divs are not evil.
    1. Feel free to use them. As a last resort.
  3. How do I know when to use a div?
    1. When no other tag will do.
  4. How do I  know when no other tag will do?
    1. By learning what those other tags do.
      1. Please go here:
  5. But it’s all so amorphous! Everything is so unclear! We don’t know exactly when to use these tags!
    1. First, calm down.
    2. Second, they are intentionally broad in scope. This is called flexibility.
    3. Third, this is where your team comes in.
      1. Decide how you plan to use the tags.
      2. Leaving some flexibility is ok and probably preferable.
      3. Giving your team time to learn is ok, in fact, it’s expected.
    4. Fourth, to some small extent, the standard is still being developed.
      1. This is normal in web development and does not negate the value that using the standard provides.
    5. Fifth, this is not moral.
      1. This is not a situation of right and wrong. No one dies if you do this “wrong” (primarily because there is no wrong). These are HTML tags for crying out loud!
  6. Do I replace all divs with sections?
    1. No!
    2. A section is a set of elements you wish to group.
      1. Most likely your section will contain many divs.
  7. Are these nestable? How many times can I use them?
    1. All are nestable (although probably not nav and button).
    2. There is no limit to how many times you can use them.
      1. Why? You probably have  more than one nav, more than one article or section, etc.
    3. Principle of the matter: each set of content is wrapped in something which accurately describes the purpose of the content inside.
  8. What about header tags?
    1. Inside sectioning elements (article, aside, section, and nav), these restart (i.e. you start over at H1).
    2. They should still be used.
    3. Didn’t they provide structure before?
      1. No, they didn’t. Read the smashing magazine article below.
  9. Just make it easy for me so I don’t have to read anything:
    1. Article – stuff about one topic and where it can stand alone and still make sense
    2. Aside – peripheral information
    3. Header – stuff that is not main content that goes at the top
    4. Footer – stuff that is not main content that goes at the bottom
    5. Nav – self explanatory
    6. Button – self explanatory
    7. Section – stuff you wish to group which doesn’t fit any of the above tags
  10. Why does this matter?
    1. We have a worthless DOM otherwise.
      1. A primary purpose of the DOM is to communicate the meaning of the content. Since, by definition, divs mean nothing, making divs the backbone of your page means your DOM is communicating nothing.
    2. With a non-worthless DOM, we give parsers what they’ve always needed: a DOM which actually communicates the meaning of primary parts of the page.
    3. There’s also CSS and JS benefits we can get into later.
  11. It still doesn’t make sense!
    1. Give yourself time to learn (and also fix anything I may have gotten wrong above).
    2. Please read:

Example: full-screen, responsive animation/interaction done well

I haven't fully looked into this, or looked at the code much, but the user experience (at least on desktop) is pretty great. This is an example of using some trends – full-screen images, snapping-to, and some animation and video – well. It's easy to use trends/"new exciting things" poorly, but this site is even responsive! And, most importantly, the technology (the trends I listed above) actually fit the content. In other words, the medium fits the message, as opposed to just using a technique because it's cool or flashy. Here, it makes sense that the map is full screen, the images full screen, and they snap into place.

Sublime Text – Auto Saving

A common problem is refreshing a browser, noticing no change, assuming your code is wrong, attempting to fix it, no worky, and then after a long time realizing that you had simply never saved the file and probably your code was fine the whole time.

In walks Sublime! Go to "Preferences" then "Settings – User" and add the following line:

"save_on_focus_lost": true,

And you are done! Now every time that file in Sublime no longer has focus, it will automatically save.

Write a Macro and an Advanced Find/Replace for Sublime Text 2

I was recently given the task of converting many PDFs to HTML. This is not fun. However, it’s fun if you get to play with the Sublime Text 2 settings/packages/amazing stupedous power. Here’s what I wanted to do:

  1. In Adobe Reader, save PDF as HTML. Against that, do all of the following.
  2. run HTML Tidy
  3. delete doctype tag
  4. delete opening/closing HTML tags, and closing Body tag
  5. unindent two tabs
  6. delete opening Body tag
  7. delete head tag (and all child tags)
  8. delete style blocks
  9. delete all br tags
  10. delete all •
  11. delete all classes
  12. delete all span tags
  13. remove all width and height attributes from image tags
  14. replace “ with “
  15. replace ” with “
  16. replace ’ with ‘
  17. replace copyright symbol ©
  18. replace trademark sybmol ™
  19. replace registration symbol ®
  20. reconnect words that have been randomly broken into multiple “words”
  21. convert all totally uppercase strings to “Title Case”
  22. wrap each section in the appropriate tag
  23. style as needed (should hardly need anything given the previous step and the fact that styles have already been written)

Using Sublime Text, steps 2 through 19 could be automated. Here’s how.

  1. Install “HtmlTidy” package
    1. Oen Command Palette, type “install package”, type “HtmlTidy”.
    2. This assumes you’ve already installed the package “Package Control”. If no, do so.
  2. Install “RegReplace” package
    1. Open Command Palette, type “install package”, type “RegReplace”.
    2. It actually appears this is the only way to automate a large set of find/replace commands in Sublime Text. Rather surprising, but true. Anyway, this package works great.
  3. Read up on Macros. It’s really, really easy. Mostly you just need to know ctrl+q. This command both starts and stops recording of a macro.
  4. Record a macro for steps 2 through 5. Ctrl+q to both start and stop it. After that Tools -> Save Macro. Name it for future use.
  5. Start using RegReplace to do steps 6 through 19.
    1. You’ll want to copy over two files, and then customize those files to your heart’s content.
  6. (There’s actually more that could be said here, more detail, but I’ve run out of time, and my memory is bad. Either way! This post is mostly complete and still has some value.)

My sources:


Who Woulda Known

In my typical fashion, I'm going to create a new blog post to retain information that should be managed in a different way in the hopes that someday I add that missing functionality.

Goal (in the far off nebulous but very happy future):
Add a "Who Woulda Known" section to my site to record the quirks and anomolies that drive us nuts. Or at least me. I'm sure others could benefit too. For now, all such content will go below.


  1. In WordPress, if using a child theme and you want to update an include file (from the parent theme) and it just isn't working, then check the path to that file. If it is get_template_directory(), change it to get_stylesheet_directory(). Works like a charm.


    1. Source:
    2. If you are in functions.php and overriding the parent theme, use get_stylesheet_directory_uri().

Object Oriented Programming

Not actually being a back end developer, I lack some helpful concepts for the relatively small amount of programming that front end developers do (JavaScript primarily). And one concept that has always eluded me a bit is "Object Oriented Programming". What, my friends, is an object?! I had never really heard it defined. I just ran into the following and wanted to share it:

You may be wondering what OOP means by now. Object Oriented Programming is a relatively new concept, whereas the sum of the parts of a program make up the whole. Think of it this way: you are building a model car. You build the engine first. It can stand alone. It is an engine and everyone can see it's an engine. Next you build the body. It can also stand alone. Finally, you build the interior including the seats, steering wheel, and whatnot. Each, by itself is a object. But it is not a fully functioning car until all the pieces are put together. The sum of the objects (parts) make up the whole.

Continuing with the model car example, when you built the engine, you didn't use any of the parts that would later build the seats (a 350 four-barrel engine with a seat belt sticking out if the piston would look pretty silly). The point is that all the parts that made up the engine were of a certain class of parts. They all went together. Ditto with the body and then the interior.