SlyTrunk

I was fortunate enough to intern at Yahoo! while I was studying for my Masters degree at San Francisco State.

The experience seismically altered my outlook on work, careers, and the impact empowered engineers can have.

The team and individuals I worked with have had an incredible impact on me, both professionally and personally;  it was at Yahoo! that I first worked with Sly Trunk Co-founders Shawn and Luke, and my boss at Yahoo! is now my daughter's Godfather!

So it's with great excitement that we take the first steps towards building an internship program at Sly Trunk. We're thrilled to be bringing more talent to Sly Trunk, and I'm excited to try and give current students as much of the great opportunity I enjoyed so much.

We're pacing ourselves, and beginning our search at SDSU. Check out the December 2013 listing on their jobs page:

http://www.cs.sdsu.edu/current-job-listings/

Since we're now spread all over the country, it's a lot harder to notice the cool software that we're each using. As with many "remote" obstacles, this was overcome by asking.

So here is the First Annual Sly Trunk Software Census, for 2013.

10 Engineers, 4 states, 7 Cities, lots of computer time, here goes!

For Glo.com, a site where all content is loaded dynamically within the stack of the "magazine", not being able to also dynamically load Pinterest Buttons is a problem. Especially when the content is so darn pinnable!

Pinterest acknowledge the pickle we're in:

Is there a callback option?  How about a way to dynamically create Pin It buttons when we need them?

Not yet.  We know you want more advanced options like these; we are figuring out what to do about them now!

- Pinterest Help Center

Not deterred by the official word on dynamic Pinterest buttons, Luke came up with a nice way to load Pinterest "Pin It" buttons dynamically.

1. Parse the chunk of DOM containing your Pinterest tag

On the initialization of your content, say a gallery slide, isolate and handle the regular Pinterest Tags within the slide via JS. No need to load the external Pinterest script here.

2. Load a corresponding iframe into each tag

Passing the Pinterest data from the tag into the iframe as URL params.

3. Serve a bare bones page within the iframe

Bare bones so that it is highly cacheable. All the logic is tied up in the JS  which is the only asset on the page at serve time. The JS reads the Pinterest data from the URL params, builds and places a corresponding Pinterest Tag on the page, and loads the external Pinterest script which parses the page, interprets the tag and renders the button.

Magic.

Dynamic Pinterest Button iFrame HTML

https://gist.github.com/5032724

Simple JS for building a DOM tag containing the Pinterest data from the URL and loading the external Pinterest script to parse it.

https://gist.github.com/5032765

See it in action!

2012 Victoria's Secret Fashion Show on Wonderwall

2013 Golden Globes on Wonderwall

2012 Academy Awards on Wonderwall

Week In Photos on Wonderwall

I wrote about some of the technical details in a blog series. Enjoy.

The Base Gallery

Scaling The Photos

Photo Zoom!

Full Screen Galleries: Example Victoria's Secret Fashion Show

The Base Gallery

Scaling The Photos

Photo Zoom!

Welcome to the final post in this series detailing the implementation of a wonderful Full Screen Zoomable photo gallery.

Implementation details:

YUI Drag, constrained to a region

Single large image, i.e. no size stepping on zoom

All browser resizing via CSS up to natural image dimensions

Zooming relative to browser dimensions

Getting in an out of the zoom experience, and how the zoom experience relates to the base gallery in the DOM isn't covered because it's not that interesting and it's no doubt going to be affected by the site you're implementing on. If you really want to know, find a full screen gallery on Wonderwall and dig into it via the dev tools.

Step 1: Establish the Image Ratio

We need an element with the same dimension ratio as the zoomed image. It needs to be as big as possible yet be completely contained by and centered within out viewport. Basically the same idea that we used to scale the photo within the slide in the base gallery. We'll use this position:relative element to scale up a bounding box that will restrict the photo dragging to something reasonable.

I'm doing this via a div sized via JS using the same logic that we used in Part 2.

https://gist.github.com/4046956

Step 2: Establish a boundary

The boundary will be sized relative to the ratio we established in step #1. Let's start with a boundary twice the size of the base ratio element, and take 25% as our zoom step size. We can use a simple LESS mixin to scale the boundary based on the value of a class on the container:

https://gist.github.com/4021373

Step 3: Size the photo relative to the boundary

We can build on this mixin to scale the zoomed image relative to the boundary. The orientation specifics fine tune the placement given that our content is celeb photos and we'd rather center heads than belts, but you could equally center them. The minus 1% provides a little buffer so that it is apparent that you've dragged to the limits of the container.

https://gist.github.com/4021436

Step 4: Wire up the zoom controls and preserve the image positioning

However you plan to zoom, via buttons, via double clicks etc. hook that up to change the class value on the container node. That will scale the image nicely via CSS. One last thing remains is the scale up or down the left/top positionings. This function does both of those things.

https://gist.github.com/4021633

Hope this helps.

DOM Diagram for the base gallery.

See Parts 1 & 2 of our Full Screen Gallery Series for the writeup

Full Screen Galleries: Example Victoria's Secret Fashion Show

The Base Gallery

Scaling The Photos

Photo Zoom!

In the Part 1 of this series, I described how to build a simple gallery with slides that scaled with the browser window.

In Part 3, I tackle the photo Zoom experience.

Now in Part 2, I'm going to explain how to get your photos to scale within the gallery slides.

Gallery Slide DOM. Nothing very exciting here, which is good. Feel free to add something more meaningful to the anchor tag href. I'm listening to clicks on it to trigger the zoom experience. There is also a diagram showing how the DOM fits together.

https://gist.github.com/4020367

Gallery Slide CSS. Inline comments do the talking.

https://gist.github.com/4020397

JS to size the photo within the wrap. I was developing this solution in Chrome and was able to simply use max-width:100% and max-height:100% on the image to have it size correctly. More importantly the parent containers, in particular the inline-block anchor tag would shrink to wrap the image. Firefox and IE didn't play so nicely, and need explicit dimensions specified somewhere in the tree.

So reluctantly, but necessarily, we move onto our first snippet of JS. Leaning towards verbose in the interest of being explicit, this code simply sizes the image so that it fits snugly within the wrap, regardless of the ratio of browser or image dimensions. Because we want to accommodate folks with big monitors, I also scale up the images beyond their natural size.

https://gist.github.com/4020359

The JS relies on having the image dimensions data encoded in the DOM somewhere (classes imgH and imgW) at load time. This makes it possible to size the images before they load. You could listen to the loader and inspect the image to get that data if you don't have access to the sizes on the server, but it'll be more complicated/gross.

Put a nice CSS3 transition in the image dimensions to smooth the resizing (height 0.3s ease-in-out, width 0.3s ease-in-out), and we're golden. A gallery which scales to the browser, with scaling slides, and scaling photos.

Remember the decorator in the DOM up top? You can use that to position a sweet magnifying glass in a corner of the photo hinting at the zoom behavior covered in the next post!

Up Next in Part 3: ZOOM!

The latest Wonderwall content template will be launching soon launched on Thursday as a way to showcase their amazing high resolution celebrity photos. It's a simple immersive experience, which presented some interesting technical challenges. In this three part series, I'm going to talk about my approach and some of the technical details that enable the design to shine.

Full Screen Galleries: Example Victoria's Secret Fashion Show

The Base Gallery

Scaling The Photos

Photo Zoom!

Overview

First up, an overview of the experience we're trying to build for the base, not-zoomed-in gallery.

Regular horizontal carousel composed of slides, with a single photo per slide

One slide in view, with a "peek" into the next slide (to the right)

Slides scale according to the browser size

The Code

Time to dust off your percentages. We want to percolate the browser size down to the gallery DOM elements. So width: 100%, height:100% on every element from the body down to your gallery.

The gallery DOM is simple, but each element in the nesting has an important job. There is also a diagram showing how the DOM fits together.

https://gist.github.com/4019663

galleryViewport: We want this element to mirror the browser window size and prepare for the horizontal carousel.

https://gist.github.com/4019684

gallerySlides: Make some space for a header and footer. Set a big width, proportional to the browser width to accommodate a realistic upper bound for the gallery size - I use @maxSlideCount:50, so width=5000%. The width is needed for IE to prevent the UL wrapping at 100%. We're going to be moving the UL for navigation, so let CSS3 animate the transition.

https://gist.github.com/4019705

gallerySlide: Float left, display inline block, vertical-align - a simple horizontal carousel. The width and margin-right have to be calculated relative to the parent UL.gallerySlides, whose 5000% width we now have to think of as 100%. LESS makes it easy to calculate based on the number of slides you want to accommodate. We have @maxSlideCount:50, so the parent width=5000%. The width of a single slide therefore will be a 50th the width of the parent, or 100%/@maxSlideCount=2%. We want a peek into the next slide that is 15% of the browser window. LESS to the rescue: (((100%/@maxSlideCount)/100) * 15).

https://gist.github.com/4019773

The result of this is a cross-browser horizontal carousel with slides that scale with the browser and a consistent peek into the next slide. The navigation buttons you saw in the DOM should be positioned relative to the viewport, but you could also have them per-slide.

Up Next in Part 2: Making the slide photos scale with the browser

Then in Part 3: ZOOM!

The Glo.com iPad App is now available from the Apple App Store; Sly Trunk's first foray into iOS app development. More coming soon!

Changes were introduced in Safari and Webkit in iOS 6 that made content in certain scenarios flicker or flash following or during transitions. The tried and trusted pre-iOS 6 way to fix flickering was to scatter various css hacks to fool webkit into delegating to the GPU, which provided enough oomph to avoid the unsightly flickering. No doubt liberal usage of the well documented hacks were taxing device batteries, so as per the release notes:

WebKit no longer always creates hardware-accelerated layers for elements with the -webkit-transform: preserve-3d option. Authors should stop using this option as a way to get hardware acceleration.

iOS SDK Release Notes for iOS 6

Fortunately, the majority of the borderline scenarios in my Glo.com hybrid app escaped the flickering; perhaps removal of the hack was accompanied by improvements to the default rendering engine. One bug that was quickly identified, however, boiled down to scrollable sub elements, i.e.:

overflow: hidden;

overflow-y: scroll;

-webkit-overflow-scrolling: touch;

In particular, toggling -webkit-overflow-scrolling: touch; via Adobe Edge Inspect would trigger the flicker/re-rendering even outside the context of a transition. This ruled out initializing scrollable elements post-transition.

We're doing a lot of YUI App Framework development in the office. The NFL draft client is in the wild, and we're working on some exciting mobile experiences.

Flicker on -webkit-overflow-scrolling: touch; elements

We're using -webkit-overflow-scrolling: touch; in various places to provide native feeling scrollable content. One issue that keeps cropping up is a distracting flicker on such elements following a transition.

There are numerous proposed fixes, including -webkit-perspective: 1000; and -webkit-transform: translate3d(0,0,0); but it feels weird littering CSS with these things in the hopes that somewhere you put it works.

I've found the simplest way to solve the flicker is to add the following to the elements that spill out of the scrollable area. Hat tip to stackoverflow.

<![CDATA[// <![CDATA[ // <![CDATA[ // ]]]]]]><![CDATA[><![CDATA[> // ]]]]><![CDATA[>]]>

I have also applied the same solution to a more general selector with the desired results (for a UL with a background image), namely:

<![CDATA[// <![CDATA[ // <![CDATA[ // ]]]]]]><![CDATA[><![CDATA[> // ]]]]><![CDATA[>]]>

Both of these assume a setup like this, which defines a horizontally scrollable area containing a list of content:

<![CDATA[// <![CDATA[ // <![CDATA[ // ]]]]]]><![CDATA[><![CDATA[> // ]]]]><![CDATA[>]]>

YUI App Framework Default Transitions

We are working on a splash page for a project that includes an iframe widget of fixed height. I noticed in Safari on the new iPad that the iframe grows vertically, and a little searching revealed that iOS increases iframe height to fit the rendered content.

It is a logical divergence from desktop Safari, but in this case I really wanted the height of my iFrame to remain fixed.

There are a number of solutions out there, revolving around  -webkit-overflow-scrolling:touch but this worked for me, and avoids anything unpleasant like fixed height or absolutely positioned block elements.

The trick is to percolate the specified height of the iframe container into the body of the document and onto an element which can act as the body container.

// <![CDATA[ // <![CDATA[ // ]]]]><![CDATA[> // ]]>

It's a couple of weeks since I first wrote about LESS. The good news is that we now have a solution that bridges the gap between PHP and LESS. The even better news is that we have LESS generated CSS in production today, and that it does not impact end user load times or radically alter our development flow.

Recap

Shortly after writing about our anticipated use of lessphp, I discovered that its coverage of the language is incomplete; it failed to compile Twitter Bootstrap for example.

less.js is the LESS implementation of choice, so I worked with LESS.app for a few days (a simple Mac app' for compiling LESS files locally that uses less.js under the covers) to get a feel for how LESS would fit into our development process. I found, for instance, that I wanted both .less and .css files checked into SVN (initially at least).

I also had to get up to speed on node.js as a server side container for less.js, a positive experience that I wrote about on my personal blog.

Our Solution

In our development environment:

A custom HTTP LESS server is running on our dev machine on node.js, listening on a specific port

Where we minify and concat our CSS at request time, we now also make requests to the LESS server for CSS files that have a corresponding .less file

The LESS server takes the .less files referenced in each of the local HTTP GET requests and compiles them

The LESS server runs as root and as such is capable of writing to the local file system (something that would be difficult to do as part of the execution of a web request within apache)

The compiled CSS is served, and is persisted in the file system ready to be checked in.

N.B. The CSS file corresponding to the LESS file being compiled should already exist at request time time. This ensures that the node.js process running as root will not create files within developer file systems, it will only modify existing files.

On production hosts:

Static CSS (albeit CSS compiled from LESS and checked into SVN) is served as it always has been

Try it yourself

Our less server is available as a Slytrunk repository on github.

It seems as though adding ellipses to pagination navigation would be straight forward, and that concise utilities would exist to help out. Two incorrect assumptions later, I set about tackling the problem and packaging the resultant code as a utility, available from Sly Trunk on github.

Desired behavior

First item visible

Last item visible

Selected item visible

Remaining number of visible items surround selected item, favoring looking ahead

Number of visible items a parameter

The utility annotates the input array of items based on this logic. The annotated array can then be serialized to HTML including tag classes corresponding to the newly added ellipsis annotations, and then be styled accordingly.

Further, the utility provides the option of annotating the markup in such a way that the client (JS in the browser in our case) can update the ellipses in page for dynamic navigation. I avoided duplicating any of the logic used to determine which items were hidden etc. via simple bounding box annotations.

It's a fairly straight forward algorithm when laid out in code, and it exists as static functionality within a single class with a demo file on github - let us know if you find it useful, or find any bugs!