Friday, November 13, 2015

Thoughts and notes from, An Event Apart conference

About four years ago, the main theme, mantra in all of "web world", including social media, blogosphere, meetups and conferences was "responsive web" which pretty soon turned into "responsible web" as web pages seemed to have had an immediate need to go on a "diet" to do well in the speed and performance aspect, more so in relation to keeping up with the responsive aspect.

Although we feel comfortable enough at this time to say that the Web industry has matured enough to understand the concept of "one-web" that works well on all platforms and devices and the term "responsive web" or "mobile web" is hopefully getting obsolete and web now inherently means "responsive web" as it was always intended to be, I am not yet sure if we have reached the point where websites are as fast and lean as they can be. Striving to be fast and lean is where the web seems to be focused right now (or needs to, if it isn't already). This was aptly represented by the focus of the An Event Apart Conference in San Francisco, Nov 2015, especially considering the fact that there were two talks exclusively focused on this topic and many others also included a heavy focus on the same topic as well.

Here's my consolidated "Cliff Notes" of sorts from:

Design Decisions through the Lens of Performance by Yesenia Perez; Desgining for Performance by Lara Hogan; Modern Layouts: Getting out of our ruts by Jen Simmons and CSS Grid Layout by Rachel Andew.

NOTE: I may have added general contextual information and resources here, which may not have been directly elaborated on, at this conference.  All the resources and links included here are public resources shared by the speakers and others.

The need for faster websites

Although the need for faster websites is unequivocally established and felt (or has been made to feel, as in Facebook 2G Tuesdays), here's a bit of a refresher on the need for faster websites:
  • Average size of websites now — 2.16MB! Increasing every week! 
  • Online shoppers expected pages to load in 2 seconds — and at 3 seconds, a large share abandon the site.
  • People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds.
  • 20% is the magic number that makes a web-page perceptibly faster/slower than its nearest competitor.
  • Visiting your website actually costs your users money! 
Ref: "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait,” New York Times, February 29, 2012"

What makes up the page weight?

  • Images (biggest contributor)
  • Custom web fonts (note that iOS 9 and many others give an option to disable custom fonts make sure you don’t have any gotchas with system fonts). 
  • Third-party scripts (tracking, marketing analysis, user analysis, heat maps and more). These tend to cause more http requests as well.
  • UI Interactions that mostly translate to Javascrip/jQuery scripts. 
  • Stylesheets: Not the biggest contributor but can easily get bloated with overly complex layouts and numerous breakpoints (and frameworks if used in the 'kitchen-sink' model).
Apart from the usual Web Page Speed tests, time for first render etc. the term Page speed index was also discussed... Lower the better.

The best Speed Index score was 819. The average was 3,658 (median 3,106), while the poorest had a score of 8,582.

Why do we end up with bloated websites? 


Slow, heavy sites are a result of…
  • Poor planning
  • Poor communication
  • Poor awareness

Fast sites build trust.

Yesenia made a bold statement with "Performance is a design feature. Not a technical concern." What I think she alludes to is, if there have been decisions made at the marketing, UX and Design phases of the web project that cause it to be "heavy", no amount of optimization in the later phases will help you much to make it much leaner, so make sure it is built on strong but lean foundations. 

On a similar note:
"Deciding a page can’t exceed 500kB when a mock-up containing three carousels and a full-screen high-resolution background image has already been approved isn’t going to do you much good."
—Tim Kadlec
If an “approved page layout” already has a carousel/full page background image, textures, parallax scrolling, tons of web-fonts, videos, numerous JS/jQuery UI  interactions and “must-have” third party tracking scripts and much more, optimization won’t help you much to get your page load faster.

How can we change this?

  • Create Reusable UI patterns that use common CSS; similar UI interaction patterns > common JS > Less code.
  • Use the same basic pattern and add minor variations for different conditions.
  • Simplify.
  • Consolidate the number of colors and font-weights in custom web-fonts.
  • Choose inherently smaller size images (shallow DOF, less texture, fewer details/noise).
  • Optimize images further (has links for automation too).
  • Use responsive images. Thanks to Jason Grigsby's Herculean effort, we have an exhaustive 10 part essay on responsive images
  • Use svg, svg sprites and icon-fonts when possible (smaller sizes).
  • Use CSS to create banners, backgrounds, gradients and whereever it is possible to replace images.
  • Remove unnecessary elements in markup ('divitis'); Clean up code; Don’t use “Kitchen sink” framework elements; drop rarely used CSS/JS libraries; Create the same effect, interactions with fewer lines of code and use plugins sparingly.
  • When there are no other options, lazy-load below the fold images.
  • Load scripts asynchronously (taking care of dependencies).
  • Create a performance budget
  • A Grunt task for keeping up with performance budget.
The above are predominantly design oriented tasks related to performance optimization as discussed in the talk and there is a lot more that can be addressed in code and on the server and this is by no means an exhaustive list. In this write-up as I am focusing more on the former.

Key takeaways from the performance talks 

  • Prioritize performance from the beginning.
  • Set a performance budget and prioritize as a project goal. Retroactive doesn’t really work.
  • Who is responsible for performance? No more performance cops or janitors. Change Culture.
  • Include performance goals in project specifications and documents. 

Front-end technologies we can look forward to, get excited about

Talk from Jen Simmons on "Layout should serve the content" and Rachel Andrew on CSS Grid Layout.  

Notice something on the web these days...?  

Summary: Web is not print, but it is OK to borrow or be inspired from print elements that were previously not possible on the web, as long as they are accessible, compatible with multiple viewports and user-friendly. Be careful of tab-orders and screen readers and don't over-do, or go overboard.  Many of these technologies may not work in all the browsers just yet, but most may be conducive to be used as progressive enhancement at this time. Below are some of those, many of which we are already using in although in smaller doses. 
  • CSS Shapes
  • CSS Regions
  • Multi-column layout
  • Flexbox
  • Dynamic Grids
  • CSS Grid Layout

Where are we on the browser support for these?

If you are thinking... Why Did You Tell Me About All This Stuff I Totally Can’t Use Yet?!

The answer is: Do Websites Need To Look Exactly The Same in Every Browser?

Find out here ;)

To sum up in one sentence... Progressive enhancement is the key.

CSS Grid Layout

Specs are still not finalized on this, but in a better shape than flexbox. No confusion with multiple syntaxes as it happened with flexbox. Get involved and give feedback. May not be ready for prime-time/production yet, but can be used in prototyping as of now. Provides many options that aren’t available or hard to achieve currently, the most notable being separation of content and presentation and content choreography (yes, as in changing the content in different viewports without actually changing source order in the DOM). Of course a polyfill is in the works as well.


Thursday, September 10, 2015

Susy the class-less wonder; more reasons to "Grunt"

A more descriptive title for this post would've been... "Semantic, responsive frameworks with Susy (& Co.) and Sass", but obviously I am going for the cheese-factor here... Anyone recognize the allusion to a certain Seinfeld episode in the first part of the title? Never mind you newbies too young for Seinfeld ;-)

I have been sitting on the first part of this blog post almost for the past 5 months since I first used Susy "framework". Recently when this Smashing magazine post beat me to it, I almost thought rather not bother writing another "been there done that" post but I suppose this could be sort of a TL;DR version while also covering some quick basics, hopefully in a more overview angle.

I've made this into a two-fer including yet another reason to "Grunt" as there seemed to be a segway for that. Even if you have been using Grunt, stick around for this cool grunt task find.

Why a semantic grid?

You wouldn't probably be reading this post if you didn't feel the need for semantic frameworks... We all know the pains of frameworks in general, dependencies of framework files; mark-up littered with presentational classes (small-12, medium-6, large-3 and what have you) although some frameworks have mixins to prevent those; version updates; bloat to some extent if not used responsibly, although not much compared to all those tons of crazy un-optimized images on your page (can't help bringing that up).

To clarify, Susy isn't the only framework to use this semantic approach, just the one that I've used... I hear the latest version of Foundation, 6.0 (not yet released as of this writing) is also one that's going towards that.

A few key things you need to know about Susy:

It isn't really a framework per se as in, a file/s (grids and more) that you physically include in your <head> as in Bootstrap or Foundation etc. So it doesn't add any additional files/size to your Sass, or compiled CSS files!!

Although you can install it as a Ruby gem, I want to really stress that it can be used stand-alone without any Ruby dependencies. Just include the Susy folder in your project folder as below!

You can use it with Compass if you are already using it, but, not a dependency.

You do need to be using Sass though. Sorry, "Less"er folks... another reason to switch to Sass :-b Some Sass compilers didn't work at the time of my use (threw some errors), and the one that worked for me is the Koala compiler.

But, more importantly, although Sass is used while in the pre-processor stage, it isn't really a dependency in the final output. Once CSS is compiled, all the widths, columns and gutters are converted into straight percentages and can be ported into any environment as just straight CSS without the need for any framework files.

So then, you may ask, why not just use plain percentages manually to begin with? Frankly for the kind of complex responsive layouts we use these days, I'd rather keep my code "DRY" and not have to calculate percentages, gutters, margins, suppressing margins for the last-child, first-child and so on for every other div or complex product grids, with different configurations in each media-query etc.,  but rather focus on layout and quick delivery (set it and move on!).

So how does Susy does the "magic" of sizing your columns, with gutters, margins, margin suppression etc. The pics below are self-explanatory. 

You set all your grid variables like below in the settings file (which you will be importing to your Sass files...

You will be using it in your Sass file like below although not the best complex use-case scenario (btw, the breakpoints below are just basic Sass mixins I used. Nothing special referring to Susy, but the @include span is).

And you will get the compiled CSS output like below... Ta Da!

One more (rather two more) reason/s to use Grunt

Although it isn't quite possible to port Susy to Less in a completely automated way, there is a Grunt task for converting Sass to Less in general! Better to just convince others to use Sass, I guess. 

Here's a cool Grunt task for Sass > Less that someone has cared to share on Github.

In general if you just want to "cleanify" your pre-processor compiled CSS, eg. when porting/delivering it to another environment, perhaps as a front-end deliverable, here's the Grunt task to "cleanify" pre-processor output.

I've also wondered if all that ugly pre-processor CSS output with ungrouped media-queries for each element would cause performance issues, but I read this post testing that hypothesis which assured they didn't find significant performance issues with the pre-processor CSS output. Nevertheless it is still good to clean up . Kidding aside, these tasks can be really useful in real-world situations. 

To clarify, I didn't write the above grunt-tasks but just recognizing and linking to someone else's good work. I have personally used the second one and I love the output! Not sure how you would accomplish things like above (and lots more) without Grunt.

If you can think of some grunt-work, there's perhaps a Grunt task for that and someone has already shared it for the world to use. Good to use it and spend the time on something more challenging or less "grunty (or the interns could work on something more interesting  ;)) If you still aren't convinced to use Grunt, read the famous Chris Coyier's post on using Grunt.

A few notes from when I was trying to install Node and Grunt below. These may seem simple enough but will save you a lot of time wondering why your grunt task isn't running or some other snafu.

  • You need to first install Node JS (lots of details in the above post).
  • If Node JS install isn't working, install with sudo command.
  • You MUST HAVE the package.json (which will have your dependencies and your Grunt tasks) in your project root directory and the Gruntfile.js (which will have your grunt tasks).
  • You will be installing packages via npm (node package manager) and they all get downloaded into separate folders, but I found it way simpler to just put the necessary grunt tasks js files right into just the "tasks" folder off of your project root and just referencing directly in your Gruntfile.js (if you have it elsewhere, make sure you configure your paths right).

Hope this will be helpful to some. In general they serve as my own reference for later :) 

Friday, August 14, 2015

Client-side HTML imports: Tip of the web components iceberg!

Here's yet another article for a very simple and common use case for one of the web-components and a sneak peek into all the other exciting possibilities. Web components unfortunately aren't supported even by modern browsers with the exception of Chrome. But... fortunately for us who want to push the boundaries of web, of course there are polyfills, so continue reading!

What are web components?

I think two of these definitions give a good overview of what web-components are:
"Web Components consists of several separate technologies. You can think of Web Components as reusable user interface widgets that are created using open Web technology. They are part of the browser and so they do not need external libraries like jQuery or Dojo. An existing Web Component can be used without writing code, simply by adding an import statement to an HTML page. Web Components use new or still-developing standard browser capabilities".

"Web Components are a set of standards currently being produced by Google engineers as a W3C specification that allow for the creation of reusable widgets or components in web documents and web applications. The intention behind them is to bring component-based software engineering to the World Wide Web. The components model allows for encapsulation and interoperability of individual HTML elements."

Here is a very simple use case for one of the basic web-components:

Let's say you have many templates, components which share a header, nav, footer, search or some other reusable component... Frankly there isn't much of an issue in the context of a web-application or a server-side techology if you want to include and reuse those and you would resort to one of these many ways: "include", "import", "partial" "embed" whatever you call it, based on the server-side or client-side stack you're using (obvious from their nomenclature), the very basic and simple of them being the server-side includes, usable even on a static set of pages, without even the need to have the .shtml extension. So you ask, then what's the problem? But just think about it... shouldn't an age-old technology of including a basic reusable component/module be part of the basic HTML standards,  inherent of HTML, without needing additional client-side or server-side scripting or having to run on a server?

Yes, there is, and that's just one example of web components, the HTML import (code below)! As simple as it should be, but it doesn't work everywhere,  out of the box! Yes, this is dated as of 8/2015!

Apparently Chrome supports web components the best, but it doesn't render HTML imports locally even with a Node http server. So there you go! so near, yet so far!

  <link rel="import" href="/yourincludesfolder/nav.html">

So how would we approach this now, outside of a web-app? 

Let's say I am working on a static set of HTML.CSS, JS pages/front-end prototypes, one of the common patterns of front-end development that is becoming part and parcel of many workflows.

In a simple case of Brackets IDE (if I may call it that), that runs on an integrated Node JS process and hence has a "built-in" local server, one would think that it would be obviously be able to run a simple server-side include. But not yet, although it seems to be in the works.

If you have Node installed globally,  you would think you'd automatically have the http server. But no, you need to install it. OK, fine, you install and run the Node Http server in your project directory and then you'd be able to have a simple SSI? Wrong again! Node http server doesn't recognize SSIs or includes.

OK, we see there is an SSI parser for Node, let's install that for our project...

npm install ssi

You'd think, Ta Da! Nope, nothing automagic yet... with some more work/"pain" you can perhaps make SSI work or use Express JS and what not, but all I need is a freakin include!

So I say, fuhgeddaboutit! Just install MAMP locally and move on! And I did.

Install MAMP; change the httpd.conf or .htaccess file (rather just uncomment) to be able to recognize SSI, and if you'd rather use them with just .html and not .shtml, add below and you're done!

AddHandler server-parsed .html
AddHandler server-parsed .htm

Easy, peasy? Yes, but obviously after the above long suffering paragraph, that's not the point that I am trying to make here. Shouldn't having an include be more basic than that? 

We don't have to need JS application frameworks or server-side technologies or anything much else for an include and this is just the tip of the iceberg of what's possible with web components. They help us build reusable, stand-alone Web-UI widgets that are platform, framework agnostic and portable into any technology/platform. With frameworks coming up like the flavor of the day these days... Angular, React, Ember, Backbone, Node... and many organizations taking the Atomic Design, pattern-library approach, it makes perfect sense to have a componential approach to building encapsulated Web-UI widgets, eg. an accordion, image slider, alerts, ratings, comparison tables, video player, calendar or a custom flex elements to name a few and web-components make this possible. They also offer data-binding and exist outside of the application layer, hence separating the UI (front-end) and application concerns.

It seems like the picture is quite rosy so far, but some of the cons could be the other side of the encapsulation aspect of the scoped CSS (within the shadowDOM of the widgets), but if you are UI widgets reusing within your own organization, that should not be much of an issue except during re-branding perhaps in which case you'd probably be overhauling more than just CSS. Although I haven't used web components yet, the other cons I have come across seem more like the growing pain aspects of web-components, browser issues, polyfills/libraries slowness and such.  

I hope more browsers natively support web components soon... until then we have polyfills and Polymer (see below), although that is counter-intuitive to the very premise of web-components!

Here's a more detailed article by Lea Verou (representative of perhaps many more) with similar thoughts and more links to what web components are, can do and how you can use them now.

If you get disheartened by the above link, don't miss the resources below.  (from the horse's mouth)

I highly recommend watching the video below from the Polymer folks at Chrome which is quite encouraging, not to mention the lightest version of the library is currently just 19K and good to hear that performance is getting better with every version. (no article can be complete w/out a CSS tricks reference!) (get inspired).