Thursday, June 18, 2015

Let's face it, some of the W3C specs produced by the different working groups weren't meant to be read by the average developer or web designer. You'd be better off watching a flower bloom than wrapping your head around the various concepts that are presented in the different documents. I recently spent a short amount of time going through different specifications in the HTML and CSS working groups and to my surprise there were a few that are straight forward and make for really great references if you're looking to gain a solid understanding of the concepts. Besides, it's these specs that ultimately make it into the browser (sometimes, r.i.p FileSystem API).

The following is an opinionated short list of the specs I find are easy enough for beginner and intermediate designers/developers to wrap their heads around. As I look through more of the specs I'll update this list.

HTML5 - http://www.w3.org/TR/html5/sections.html#sections
CSS Selectors Level 3 - http://www.w3.org/TR/css3-selectors/
CSS Selectors Level 4 - http://www.w3.org/TR/selectors4/
CSS Counter Styles Level 3 - http://www.w3.org/TR/css-counter-styles-3/
Compositing and Blending Level 1 - http://www.w3.org/TR/compositing-1/
CSS Masking Module Level 1 - http://www.w3.org/TR/css-masking-1/
CSS Transforms Module Level 1 - http://www.w3.org/TR/css-transforms-1/
Geofencing API - http://www.w3.org/TR/geofencing/


If you think there is a spec that I missed suggest it in the comments section and I'll take a look.

Tuesday, August 26, 2014

I'm a subscriber to the Smashing Magazine newsletter. Every once in a while when I receive one of their newsletters I'm presented with a nugget of information that is nothing short of pure gold. Their latest newsletter (August 26th, 2014) is one such email.

The following comes from their newsletter and are some optimization tips they present get your site to render quickly:

What's the best performance optimization strategy for a (responsive or non-responsive) website? Actually, it's pretty simple. You make sure that your WebPageSpeed's SpeedIndex is under 1000 and ensure that your main content is within the first 14Kb round-trip — and keep your critical rendering path as short as humanly possible. The latter usually means that you have a very clear understanding and agreement of what is critical for the page to start rendering and what is not so essential, and, consequently, could be deferred.

Google Pagespeed Chrome Extension

The next step would be to identify the JavaScript that can be deferred and load it asynchronously because otherwise it would block the construction of the DOM tree. You defer web fonts, too. This can be done by either storing them in localStorage (or potentially AppCache) or by using Web Font Loader if you don't have the WOFF files. You can also export critical CSS and embed it inline in HTML to fit within the 14Kb budget (for TCP Slow Start). This way you also avoid unnecessary HTTP requests. Also, you can load full CSS asynchronously once the page has started rendering or has fully loaded, e.g. on DomContentReadyor on Load event.

Well, that's pretty much it. And if your server-side configuration is solid, it's going to be very difficult to be very, very slow. Unless, of course, you don't optimize images. A little trick we've recently discovered is that PageSpeed Chrome extension provides a little handy tool to optimize images aggressively. Once you install the extension and run it for a given website, you'll find a tab called "Optimize Images". It doesn't just show a list of unoptimized files but also allows you to open and save perfectly optimized files without using any external tools. The compression is usually at least as good as in popular compression tools.

So that's basically the strategy we followed on Smashing Magazine, resulting inGoogle PageSpeed Score 97–99 — both on desktop and on mobile (although it varies depending on the advertising we display). Building a fast responsive site isn't that difficult as long as you are strict about what is and what isn't important on the page. For example, we defer loading of ads, tracking scripts, syntax highlighting, web fonts and other non-critical resources, all of which have helped us immensely speed up the entire site.

Nevertheless, some work still lies ahead of us. We are planning to move to new servers soon (server response time is just unacceptable with our current provider), and will defer the loading of Gravatars on article pages as well as move to SPDY shortly. An article explaining all of the mini-optimizations we've done over the last few months will be published on SmashingMag in early September.

Bottom line: if somebody tells you that responsive sites are fat, bloated, unusable and take too much time to develop, tell them that they're wrong. It's animplementation problem, not the technique itself. And with a proper strategy, it can be done right.
— Stay responsive!
Vitaly (@smashingmag)
I couldn't have said it any better. If you haven't subscribed to the Smashing Magazine newsletter please do so here, you won't be disappointed.

Wednesday, June 18, 2014

  

Earlier this year my colleagues and I worked on a digital plan for the marketing department in order narrow down our focus in getting the projects done in a uniform matter. Part of my contribution to the plan was determining what tools could be used in the creation of our micro sites, landing pages, and full websites. Being that a majority of my time is spent doing front end web design, picking a framework that was robust and made it easy to create responsive websites was a number one priority of mine. While there were a bunch of options to choose from, the two major frameworks that (pretty much) lead the pack were Twitter's Bootstrap and Zurb's Foundation. I wasn't too pleased with the uniformity I saw with sites built with Bootstrap so ultimately chose Foundation for our development.

Things were great for a long while and I was able to take our designers mockups and transform them into functioning sites with little problem thanks to Foundations various plugins and easy grid system. The downside which ultimately hurt development was that the lack of support for older versions of Internet Explorer (primarily IE 8 which a lot of our customers use). Although usage of IE 8 is dwindling (http://theie8countdown.com/) we still needed to support it and this resulted in me using hacks and extra markup to get things to function.......barely. Fast forward to a couple of months ago.

I personally decided to ditch Foundation for Bootstrap, both for personal projects and work related sites. The sheer fact that it supports IE 8 was a huge plus for me and overriding their inherit styles out of the box was much easier than in Foundation. I was also pretty happy that it supports both LESS and SASS for writing style sheets (Foundation only supports SASS) and that the ecosystem for themes is HUGE! Overall, I'm pretty happy with Bootstrap and I've realized that the previous uniformity I saw was only skin deep and didn't take advantage of what was really possible. I'm looking forward to seeing how Bootstrap evolves!

Friday, December 13, 2013

When Google Glass was first announced I was extremely fascinated with the technology and wondered what the implications of it were. Like everyone that was excited about the announcement I went to the Glass website and told them what I would do with Glass if I was given the chance to get a pair. This was done with a grain of salt because I knew the world was practically making their case and the program was extremely limited. Well, that as well as the fact that there was a $1500 price tag attached to the early release device which would make anyone cringe.

Now, lets fast forward a year. I was recently offered the chance to receive an invite to the explorer program thanks to some organizers at the Google Developers meet up I attend every once in a while. Once the time came in which they sent me the email practically saying "give me your money" I jumped at the chance and now, I am a Glass Explorer! Being a prototype device I have to admit that it is extremely advanced, from its bone conducting speaker to the handful of versatile voice commands. More than wearing it myself I like showing it to people in hopes of spreading a little awareness to break down the many phobias you tend to read about in recent news. Being a programmer I'm also trying to think of what I could experiment with to see how flexible it is. I haven't walked around with it in public just yet because I don't want to be labeled "that guy" but I predict that will change soon.

Playing darts while wearing glass.
 
The first photo I took with Glass at the Glass studio in NYC