Max Quattromani

Accelerated Mobile Pages

Mon, 28 Mar 2016 00:00:00 GMT

AMP HTML is HTML with some restrictions for reliable performance and some extensions for building rich content beyond basic HTML. The AMP JS library ensures the fast rendering of AMP HTML pages. The Google AMP Cache (optionally) delivers the AMP HTML pages.

Last October, Google announced the introduction of its Accelerated Mobile Pages project, a new open-source initiative aiming to “dramatically improve the performance of the mobile web.”

For several reasons I decided to give AMP a runthrough on my own site. Firstly, my site is almost entirely static - making it a perfect candidate. Secondly, the content that primarily changes are the articles, like this one. Last, but not least, I want to give my site the fastest possible deliver in the most performant manner.

Leading up to this switch I had always taken pride in my clean semantic markup and lean CSS. In fact, when it came time to inline my CSS in the "amp-custom" style tag (which has a limit of 50kb) I was pleasantly surprised that I was already under that threshold.

My biggest bump in the road came in the form of mobile navigation. I previously had a nice off-canvas mobile nav solution that I have, since creation, reused on a number of projects. AMP does not allow author-written JavaScript or any third-party JS. So I immediately had a broken experience in mobile. Fortunately I had a free Sunday evening and rewrote the

Website Launch List

Sun, 02 Aug 2015 00:00:00 GMT

[x] meta tags
[ ] Viewport tags

[ ] favicon(s)
[ ] Twitter Cards
[ ] OG tags
[ ] print.css
[ ] WAI-ARIA
[ ] Images - alt tags
[ ] Page titles
[ ] Terms of Use
[ ] Privacy
[ ] Style Guide
[ ] Pattern Library
[ ] robots.txt
[ ] humans.txt
[ ] sitemap.xml
[ ] Google Analytics

Atomic Design & Development

Wed, 25 Mar 2015 00:00:00 GMT

WE’RE NOT DESIGNING PAGES, WE’RE DESIGNING SYSTEMS OF COMPONENTS

~ STEPHEN HAY

Atomic design is a system for web development that focuses on the smallest, most common elements with clarity and precision first and then works it's way up and out to build more complex components.

Commonalities

All websites at their core are composed of the same tags.

<html> to tell the browser this is an HTML document
<body> defines the document body
<div> a container for encapsulating elements
<section> defines sections in a document
<header> represents a container for introductory content
<footer> defines a footer for a document or section
<h1> - <h6> for headings
<p> tags for paragraphs
<a> tags for links and navigation
<img> for images
<ul>or ``

for unordered lists

for list items
to define a user input to capture user input

Protoyping

Sun, 30 Nov 2014 00:00:00 GMT

One of my favorite things to do as a front-end developer is to sandbox new components. Oh sure, we all have to bug fix, feature add, and unit test - but the chance to build something new, solve a new problem, start fresh brings a crazy kind of nerd-joy that I can't articulate well enough in this forum.

I was thinking this morning while making breakfast about a new kind of layout and as I was plotting a little Sunday development; I realized that I have a very distinct process for jumping into these projects, but I've never layed it out step-by-step.

Previously I have laid-out my Software Development Life Cycle and as a theory I still refer to it when working with teams looking for an overall process. This is a different process, one with physical steps more clearly defined. One that pays criticial attention to the UI, Web Standards, and Accessibility. Additionally; protoyping components using this method, or a similar one, lends itself perfectly to the Agile Development environments that so many of us work in now. Okay, here goes:

Always a visual; as simple as a sketch or complete as a fully developed comp.
Mobile-First; HTML first - the key to production-ready code written in the prototype phase is to be purely semantic. The path to purely semantic HTML is to establish it before any style or function code decisions are made.
```
My compenents tend to follow this architecture (as an example):
```
```
<div class="widget">
  <h3>Heading</h3>
  <ul>
    <li></li>
    <li></li>
    <li></li>
  </ul>
  <label for="">Input Field</label>
  <input type="text">
</div>
```
This sets me up for really clean CSS, with no crazy nesting requirements. It also let's me maintain global styles for elements like headings, lists, and forms - with the power to customize on an as-needed basis.
It's CSS time! Creating reusable, modular, and DRY components that don't bleed into the DOM and can therefore be used on any page of a site, and along with any other component, makes front-end to back-end hand-offs a breeze.
- CSS is written in Sass/Less.
- Taskrunners: Grunt or Gulp take care of compiling, concatenating, and minifying as I work - this keeps code performant and end-product-testable in the early stage. A big win! There's nothing worse than trying to improve performance once a project has reached QA or UAT.
- I have some CSS/Sass best practices already established. Adhering to these consistently prevents a lot of headache.
```
.widget {
  h3 {
    ...
  }

  ul {
    ...

    li {
      ...
    }
  }
}
```

Browser Test.

<ul class="bulleted">
    <h4>Desktop Browsers</h4>
    <li>Chrome - last 3</li>
    <li>Firefox - last 3</li>
    <li>Safari - most recent release</li>
    <li>Internet Explorer (IE8 - IE11)</li>
    <hr>
    <h4>Mobile Browsers</h4>
    <li>
        iOS: Safari
    </li>
    <li>
        iOS: Google Chrome
    </li>
    <li>
        Android 4.x: Google Chrome
    </li>
    <li>
        Android 4.x: Firefox
    </li>
    <li>
        Windows: IE Mobile
    </li>
</ul>

The last piece to get added is functionality; Javascript. I lean towards UI functionality written in jQuery more than vanilla javascript. I have some specific, past-experience reasons for this:

<ul class="vertical bulleted">
    <li>
        Typical front-end functionalities revolve around reveals; hide/show, slide-up, slide-down, close, etc. These are quickly, and reliably achieved using jQuery.
    </li>
    <li>
        I like to write my FED functions as self-instantiating plugins. This allows me to reuse utilities that can be chained along with already existing ones. The idea for this came from  a terrific article on <a href="http://learn.jquery.com/plugins/basic-plugin-creation/">Creating a Basic Plugin.</a> I structure any new plugin following this format:


(function($) {

  $.fn.widgetFunction = function() {
    $('.widgetFunction').change(function(){
      if ($(this).val() != 'null'){
        window.location.href = $(this).val();
      }
    });
  }

}(jQuery));

$('.widgetFunction').widgetFunction();

    </li>
    <li>
        Lastly; I find that javascript almost always gets re-written by the back-end developer after hand-off anyway. 
    </li>
</ul>

Create a process and stick to it

This process works for me. It is based on the roles that I have had the opportunity to hold. Your experience and/or role on a team may be different, but having a process, however it looks, will increase your productivity, improve your code quality, and make you the hero of your back-end team.

Now get in the sandbox and start playing!

Creating the Style Guide

Mon, 17 Nov 2014 00:00:00 GMT

Back in February I was looking to move on from my position as Manager of Front-End Development at TWC. Through a previous co-worker, I was connected to and had the chance to interview with GLG. During the phone screen I got asked one of those great interview questions; "What are you passionate about?"

I paused, collected my thoughts, and began talking about style guides and pattern libraries. As a designer and developer, I have a true affinity for the math and art that goes behind great web development - out of this comes my love for patterns.

As we wrapped up, I got asked to come to Austin to meet the team and do a round-table type interview, the catch was that I had to bring a project, code and all, to share with them. Nothing I had done for money, but what I did for ME!

For about a year or so previously, I had been collecting a number of different compartmentalized snippets, best practices, and modular components. I decided to use this opportunity to create a collective style guide. This interview project became Scaffold, my boilerplate/starter kit.

Since then, every site I have built has been built on Scaffold. I have improved it along the way and made the process simpler to spin up new sites using Bower (more on this in a future post).

As it has improved and become something that I wanted to show-off, I have become more and more critical of things that are included or, possibly more important, not included.

About a week ago, my personal site style guide got a shout-out from Una Kravets in her article about Style Guides and Pattern Libraries.

This is the first-time I had ever had anyone write about my work other than me - kinda cool really! and I'm super-grateful to Una for the mention.

Just a few days later I read a twitter thread started by Cameron Wardzala that germinated into an idea to create a solid style guide resource.

Anna Debenham, Brendon Falkowski, and Brad Frost have spearheaded this awesome project of collecting resources and examples of style guides.

Fortunately for me, Anna included the ability for the community to contribute. I offered up my style guide as an example and it was graciously accepted - again, very cool!!

Since she published the site I have had the chance to read all of the other resources and be inspired by the other examples. This newfound collective intelligence is probably gonna prompt me to improve mine even more. Stay tuned.

...and buy Anna's book Front-End Style Guides.

Using Google Docs with Jekyll

Wed, 05 Nov 2014 00:00:00 GMT

I've been using Jekyll for almost a year now and every time I do it gets better. So much so that I decided to build a client-site using Jekyll as the CMS. I of course discussed this with them first, disclosed some of the differences between WP (which they were currently using) and Jekyll. After some research and compromises, we decided to 'go for it!'

Fast-forward four months, site is launched and live, client loves it - but the reality of losing some of that WYSIWYG functionality was sobering and concerning them.

We revisited earlier conversations about this, clarifying that Jekyll is a 'static' site generator, but now we needed a solution. I couldn't find any packages out there that solved this exact problem, so I came up with my own. Rudimentary certainly, but completely effective.

A specific request my client had was to be able to update their careers page, basically a listing of states containing available jobs; just a list, nothing fancy - enter Google Docs, mainly spreadsheets.

Google Spreadsheets can be output as json data, so a simple list formated correctly replaces the data I had originally built in _data/careers.yml, then looping through this data using jQuery .getJson(), I get the data output as needed. I give my client access to the spreadsheet, they update it and voila - their page is updated.

Here's the little script I'm using:


$.getJSON('https://spreadsheets.google.com/feeds/list/1IT57mBl8Eu8r-yCRt8srnxYb9nAtp57U1ZpHq5nosY0/od6/public/values?alt=json', function(data) {

  for (i = 0; i < data.feed.entry.length; i++) {
    var state = data.feed.entry[i]['gsx$state']['$t'];
    var title = data.feed.entry[i]['gsx$title']['$t'];

      careers = $('<ul class="bulleted"/>');
      careers.append('<li>' + title + '</li>');

      if (state == 'California') {
        $('.california-list').append(careers);
      }

      if (state == 'Colorado') {
        $('.colorado-list').append(careers);
      }

      if (state == 'Texas') {
        $('.texas-list').append(careers);
      }

      if (state == 'Utah') {
        $('.utah-list').append(careers);
      }
  }

});

The end-result looks like this: http://terracareassociates.com/careers/

In the future, I'll be expanding this to additional portions of the site so they have more control. This keeps them out of the code and build process and presents as a simple solution to simple, needed content updates.

Next, I'll discuss moving them off of the Jekyll blogging platform and using Bloggers API on a subdomain to give them more control of their articles - again removing that non-WYSIWYG hurdle.

The Last Conversation I had with my Mom

Wed, 22 Oct 2014 00:00:00 GMT

A year ago today, it was a Tuesday, was the last time I had a conversation with my mom.

I was pacing the halls of the Stanley Hotel in Estes Park, CO. I was there for the #cssdevconf and had wrapped up my sessions for the day. I had texted to her to catch up like we did pretty often and had something to share with her. I was feeling elated that I was being paid to attend this conference and stay at this cool hotel and isn't my life great, blah blah blah, and I couldn't wait to share that with her.

Mom was a big part of the reason I was there - she pushed me, she prodded me, she cajoled me to go back to school a few years earlier. It was a particularly tough time for me personally and it worked. It kept me focused and driven.

After finishing with degree in hand, I landed this great job at Time Warner Cable and was having success after success, personally and professionally.

We talked for about an hour. Well, I talked, she did what she usually did, she just listened. Mostly about me, my kids - the usual. She shared with me that she was frustrated because she needed to have another follow-up surgery and was angry that she wouldn't be golfing for a while, likely until after Thanksgiving - and did we want to come to Texas for Turkey Day.

We wrapped up our conversation and I wished her well and told her I'd call her after her surgery to see how she was.

That was the last time I heard her voice.

On Thursday my dad called in tears, frustrated, cursing God. It hadn't gone well and there was a good chance that mom would need long-term care after she went home. He knew how independent she was and that she was gonna hate having someone else hovering and helping with normal tasks that we all take for granted.

I made plans to leave after work the next day and drive down to be with them and help for a few days. He called the next day in better spirits and it looked like it was all gonna be ok. I was relieved and told him I might come down in a week - give her time to get home and settled, I reasoned.

The next morning, Saturday, I was out picking up coffee and donuts when my bother Jimmy called to tell me that it had turned for the worse and he was really worried. I went home and took a shower while Patti packed a bag for me and I was on the road less than 25 minutes after that call.

My brother Scott had flown down and it timed just right that I picked him up at the airport when I hit town. By the time we had gotten to the hospital my dad hadn't slept in three days and hadn't left the hospital.

I sent him home with Scott to get some rest and I'd stay by moms side for the night.

Mom hung on until just into Monday morning.

I miss her every day. We still talk every day. Well, I talk, and I know she's listening.

Copying the sender with Brace Forms

Fri, 19 Sep 2014 00:00:00 GMT

tl;dr - take me to the code

I have fallen in love with Jekyll and hosting projects on Github. This has become my inspiration workflow.

Get an idea.
Buy a domain name.
Run my framework build.
Sprinkle in Jekyll.
Change the CNAME file, and BAM!

As I started my Jekyll Journey I realized that my typical email.php goto for forms wasn't gonna work (Github doesn't support php). So I went all #lazyweb and sent a tweet out asking for recommendations, along with googling an answer.

There are a number of decent solutions out there, simpleform and wufoo just to name a few. The limitations to those services though are primarily the number of forms you can process in a month. With both of those previusly mentioned - that limit is 100 per month. I need more than that for a few of my builds, so I kept looking.

Behold! forms.brace.io -- this just became my new favorite thing! Super simple integration, up to 1000 submissions per month with their free account and some built in goodies like _replyto, _cc, and _next. So I dove right in - everything was solid.

Shortly after I launched a little web-based office football pool picking site, I had a feature request to copy the submitter with their picks from the form.

I emailed the team at brace.io -- who has been super responsive and helpful in the early on if/when I ran into any issues -- and asked if/how I could use the _cc operative to do such a thing. Unfortunately, they had no baked in solution.

--

I needed this and I didn't want to start over with a different form solution so I looked at a few different methods involving Jekyll liquid tags; either I'm not smart enough or liquid tags can't capture and output values as they're input into a field.

No matter, a much simpler solution was available:

First things first -- here's my form field for the user to input an email. I want to capture this!


<input id="email" type="email">

I will need this captured email address to populate the value attribute of this hidden field:


<input type="hidden" id="copy" name="_cc" value="">

*that _name="_cc" is the Brace method for, you guessed it, cc'ing an additional email box

I WAY overthought this - the solution using jQuery was apparently just too straightforward the first time around:


$(function() {
  $('#email').change(function() {
    var value = $(this).val();
    $('#copy') .val(value);
  });
});

Now whenever that email input changes, wether typed OR autofilled, the value in my hidden field populates and brace does the rest on the backend.

Hope this helps! Happy Jekyll'ing!!

Designs by Puppy

Thu, 28 Aug 2014 00:00:00 GMT

Just a quick thought I had this morning: my puppy, Pixel, is the perfect user-testing subject. Pixel has pretty basic needs: feed me, shelter me, scratch my belly, be kind to me.

--
That's it.

Now I'm not comparing human-users to dogs, but human's needs and wants, at a basal level, are pretty simple. The scope of those needs are vast and varied, but once the need is established - we just want to get it met.

Too many times when designing something I find myself overcomplicating things, trying to "think ahead" of the way my users will interact with a component.

At the end of the day, the thing I'm building has to do the thing it was designed to do.

--
That's it.

Everything else is superfluous. What my high school art teacher would call "Visual Bullshit."

My designs tend to lean to the simplistic already, but when I tell people that I am usaully referring to the visual aesthetic. Pixel would agree that I need to be more simplistic when tackling the functionality as well.

Using calc() in less

Fri, 22 Aug 2014 00:00:00 GMT

Not sure if anyone else has run into this problem, but to celebrate a victory pulled from the jaws of defeat, I thought I’d share this tip.

To use css3 calc() with less you’ll need to play with the format a touch.

let’s assume a column gutter of .5em...in vanilla css, it looks like this -


.half {
  float: left;
  width: calc(50% - .5em);
}

but if you run this little gem through less, it outputs:


.half {
  float: left;
  width: (49.5%);
}

to get around this we need to tune down less’s aggression with the maths by escaping the percent unit.


.half {
  float: left;
  width: calc(~"50% - “.5em);
}

and huzzah! we get the expected output:

.half { float: left; width: calc(50% - .5em); }

Max Quattromani

Accelerated Mobile Pages

Website Launch List

Atomic Design & Development

Commonalities

Atoms

Molecules

Organisms

Templates

Pages

Organization

Embrace the Cascade

Base

Layout

Module

State

Theme

Example Time!

Our Close State

Our Reveal State

Setup

In Conclusion

Resources

Protoyping

Create a process and stick to it

Creating the Style Guide

Using Google Docs with Jekyll

The Last Conversation I had with my Mom

Copying the sender with Brace Forms

tl;dr - take me to the code

Designs by Puppy

--
That's it.

--
That's it.

Using calc() in less

Max Quattromani

Accelerated Mobile Pages

Website Launch List

Atomic Design & Development

Commonalities

Atoms

Molecules

Organisms

Templates

Pages

Organization

Embrace the Cascade

Base

Layout

Module

State

Theme

Example Time!

Our Close State

Our Reveal State

Setup

In Conclusion

Resources

Protoyping

Create a process and stick to it

Creating the Style Guide

Using Google Docs with Jekyll

The Last Conversation I had with my Mom

Copying the sender with Brace Forms

tl;dr - take me to the code

Designs by Puppy

-- That's it.

-- That's it.

Using calc() in less

--
That's it.

--
That's it.