Cloud Four Blog

Technical notes, War stories and anecdotes

One amazing video that shows the potential of the physical web

Michael Mahemoff‘s recent article on how Progressive Web Apps have Leapfrogged the Native Install Model reminded me of a video I discovered while researching my new Adapting to Input talk.

I keep revisiting the video because it shows how the physical web can provide a substantially better experience than the native app install process.

Here’s the video from Matthew Sibigtroth:

Let’s compare the install process for the physical web versus what it would likely take using native apps.

Physical web install process

  1. Look in drawer for physical web beacons.
  2. Select physical web beacon.
  3. Web page launches. Prompts for pairing with toy.
  4. Select toy to complete pairing.
  5. Control toy.

There are two challenges in this process that will be solved with time. First, people need to know about physical web beacons. Second, the physical web and web bluetooth specifications are new and cross browser support is limited.

In fact, this process will likely be streamlined further in the future when the phone automatically notifies the user about nearby beacons.

Native app install process

  1. Confirm that the toy has an app for your platform.
  2. Open app store.
  3. Search for toy. Hope the toy has a unique name so you can find the app easily.
  4. Install the app and enter app store password if necessary.
  5. Wait for app to download.
  6. Open app.
  7. Pair with toy.
  8. Control toy.

Three fewer steps may not seem like much, but the total process is much slower. Apps are usually several megabytes in size making that step alone take much longer than the comparable step for the physical web.

Put a different way, it only takes 18 seconds from when the person first touches the screen to when the toy can be controlled. And that is with the person going slowly so that the people viewing the video can see each step.

It took me nearly 8 seconds on my phone to simply find, launch, and get to the home screen of the app store.

Yes, that will be faster for other people depending on placement of the app store icon, how recently they used the store, and network speed. But it is hard to envision that process ever being faster than simply following the physical web beacon.

The easier install process of the physical web and progressive web apps makes for an exciting future.

Service Workers at Scale, Part I: CDNs and Multiple Origins

We recently got the opportunity to develop a service worker for use on Smashing Magazine, which we’ll write about in more detail soon. This is the first of a multi-part article that will examine some of the solutions we arrived at and lessons we learned.

One of the challenges we’ve encountered while developing this worker is strategic caching for external resources. Most of the service worker examples we’ve seen address handling requests for local resources on the same domain. But pages served by complex sites often need to fetch (and cache) assets from external domains as well. Things can get complicated when these various domains need special handling, so we need a manageable way to structure our service worker to evaluate requests for both local and external resources.

Special handling for CDNs and subdirectories

The host of our service worker happens to be a WordPress site with assets requested from both the local server as well as CDNs. We need to handle fetch events differently depending on which domain or subdirectory they relate to. Some CDN requests need to be routed to cache functions, and some local requests (such as those for pages within the admin area) need to be ignored altogether. To fulfill this behavior, we need some way to designate rules for different URL origins.

One approach uses regular expressions. We need to match the URLs of fetch event requests against a set of base URLs, and using RegExp for this makes sense. In practice, this method works well initially, but maintenance becomes more of a concern as the patterns get more complex.

Take for example an entry to match “content pages”:

const CACHE_PATTERNS = {
  // ...
  contentPage: new RegExp(
    `^${self.location.origin}\/((?!wp-admin).*)$`
  ),
  // ...
};

This will match any local URLs except for ones with wp-admin following the first slash. It’s not a complicated pattern as-is, but what about when we need to add another subdirectory exception? Is there another approach that will cater more to maintainability and comprehension?

Comparing URLs with the URL class

Let’s substitute the great power and responsibility of regular expressions for a more explicit way to classify URLs. Using a Map structure to represent the base URLs to handle fetch events for, we can “flag” some items to indicate them as subdirectories to ignore:

const CACHE_FLAGS = {
  ignore: -1
};
 
const URL_MAP = new Map([
  ['/'],
  ['/wp-admin/', CACHE_FLAGS.ignore],
  ['/search-results/', CACHE_FLAGS.ignore],
  ['http://1.gravatar.com/'],
  ['https://media-mediatemple.netdata-ssl.com/wp-content/'],
]);

It’s more verbose, but it provides a clear interface for maintaining the list of base URLs we want to act on.

From this core list, we can derive more specific ones. Each of the derived lists consists of URL instances:

const URLS_TO_IGNORE = [];
const URLS_TO_HANDLE = [];
 
URL_MAP.forEach(function (flag, baseUrl) {
  const url = new URL(baseUrl, self.location);
  if (flag === CACHE_FLAGS.ignore) {
    URLS_TO_IGNORE.push(url);
  } else {
    URLS_TO_HANDLE.push(url);
  }
});

With our subjects of interest stored as URL instances, we can then use properties like origin and pathname in our logic:

function isIgnoredUrl (url) {
  // URL minus the query string and hash
  const urlBase = `${url.origin + url.pathname}/`;
  const isMatch = ({ origin, pathname }) =>
    urlBase.startsWith(origin + pathname);
 
  return URLS_TO_IGNORE.some(isMatch) // flagged "ignore"
    || !URLS_TO_HANDLE.some(isMatch); // altogether unlisted
}

Should this request be handled?

With our URL classifications and helper functions in place, the fetch event handler can use them to decide if it needs to intercept a request:

self.addEventListener('fetch', function (event) {
  const request = event.request;
  const url = new URL(request.url);
  const isGet = request.method === 'GET';
 
  // Requests we don't care to handle
  if (!isGet || isIgnoredUrl(url)) {
    event.respondWith(fetch(request));
    return;
  }
 
  // Requests we do care to handle
  event.respondWith(
    // Additional cache and/or fetch strategy
  );
});

Coming up next: Using URL properties for Offline fallbacks

In part two, we’ll take a look at another unique challenge this project presented: serving URL-aware offline fallbacks.

The Year of the Ugly Unicorn

I have always considered myself a “designer who codes”. I enjoy that aspect of the web, even while in a purely visual design role.

Not too long ago, in a previous visual design position I was in, I had a manager refer to me as a code “dabbler”. This actually offended me. Surely countless hours spent reading books, doing tutorials, hacking away, building websites makes me more than a “dabbler”? I thought to myself, I am not a “dabbler”, I am a unicorn!

Proof of this unicorniness? I packed up my design and code skills, and found a new work home at Cloud Four, haven to unicorns just like myself. Everyone at Cloud Four is a kind of unicorn… magnificent designing developers and developing designers.

Cloud Four Unicorn

But after a few months of having my code reviewed by my fellow unicorns, I felt less like a magnificent unicorn and more like this:

Ugly Unicorn

Working in code every day has given me a new perspective… I am an Ugly Unicorn.

I found myself spending little to no time in photoshop or sketch and jumping into the deep end of pattern libraries and prototypes. For the first time I was working on a team, submitting code, using git and creating pull requests. Here is a little how that went:

no-good

PR

Yikes. I kept hearing the those words echo through my head: code dabbler, code dabbler, code dabbler. Over the last year I have been waiting for an “ah-ha” moment where things would click and I would feel super comfortable and confident in my skill set, that really hasn’t been the case.

As someone who knows a little code (aka: super smug person who considers themselves a unicorn), it’s easy to be like, “Hey, just learn to code”. However, stepping out of your knowledge base and comfort zone can be a scary place. It can even be daunting just knowing where to begin. Some designers I have talked to are straight up hostile when the idea of having to learn to code is mentioned. One designer friend of mine was appalled at the idea that now after having invested so much time, energy and money into her design education she would additionally have to learn to code. What I wanted to say to my friend, and also what I should remind myself of at times is that, it’s going to be okay. You don’t have to become a developer.

It’s not about being an expert at both design and development. You will always have a strong leaning towards one or the other. I will always be a designer first. I will never look at something and not want to make it beautiful. Also, there are developers out there that not only can see and appreciate design, but can put together typographic systems and pick amazing color palettes, however, at their core they are developers. People have their natural strengths, but that doesn’t preclude them from having other talents and appreciations.

When I look at a problem, it will always be from the perspective of a designer. I like to solve the big problem, piecing the code together to get my idea out as quickly as possible. Then I worry about making the code better later. The main point is getting the design, or the experience out of my head and into the browser, where I can squish my screen, or pull it up on my phone. I don’t have to be an amazing developer, or a decent developer or even developer at all. I just need the tools necessary to realize my vision for the design problem I am trying to solve.

I like to look at having technical skills the same way I would look at having presentation skills. Or project management, writing, and concepting skills. We are not just pixel pushers, we are designers. We are complex thinkers, makers and problem solvers. That goes way beyond just the presentation layer of a design. It’s about a breadth of knowledge that informs your creative process. Code informing visual design. And vice versa, visual design informing the code.

I don’t believe there are natural born unicorns. People are not just magically amazing designers and awesome developers. I do believe in the constant and perpetual learner. What being a unicorn is really about is just having a hunger for knowing more. Not stopping at just enough knowledge. Unicorns are just people who are curious. You show me a unicorn, and I see someone who likes to learn not just about their own discipline, but also the ones that overlap theirs.

Some practical advice from a Ugly Unicorn

A basic knowledge of HTML and CSS is enough to start designing in-browser. Start a CodePen account. Keep reusable snippits that you can incorporate into prototypes. Bookmark and save plugins that can help you prototype quickly. You don’t have to become a developer, it’s about getting your idea out. Be okay with feeling like you kinda suck, or feeling uncomfortable. Embrace being an ugly unicorn. Even though it feels weird and messy stepping out of your pixel-pushing comfort zone, you will ultimately be embracing the responsive web.

Element Collages… are FUN!

After documenting our collective inspiration in the form of Mood Boards, our next design exercise for the redesign of cloudfour.com was Element Collages.

We used a few points of reference before starting our Element Collages. First was Dan Mall’s post from 2012, in which he talks about evolving Element Collages from Style Tiles. We also referred to Clearleft’s post that explains their usage of Element Collages and how they arrived at using them as a deliverable.

We also had a few bits of background that we used to inform our collages:

Round One

Armed with all of that knowledge we set out on our first round of Element Collages. Each of us did a unique collage and posted our work in Basecamp. Along with our collage we posted our ideas and thought processes on color palette, imagery, typography, and any other areas of note. People posted feedback and knee-jerk reactions in Basecamp, however, we reserved most of our feedback for in person discussion.

Once our collages were ready for review, Tyler prepared a simple google survey which asked questions about each collage such as likes, dislikes, how well it embodied our brand characteristics, and how we felt about its design characteristics overall. The reasoning for doing a survey, even though it was an extra step and more work, was to give every team member an equal voice (rather than just the loudest voices in the room). It also gave everyone a chance to collect their thoughts prior to an in-person discussion.

The results of the survey gave us an idea of what the strengths of each collage were.

It was clear that Cloudfourians were really drawn to illustrations that Tyler and Sara used in their collages.

tyler-illustration Illustration by Tyler Sticka sara-illustration Illustration by Sara Lohr

Erik’s had strong typography, and a dramatic color palette.

erik-type
erik-colors

Final Round One Collages

 

Round Two

Taking these insights, we moved into the second round.

We borrowed elements from each other that we felt worked well. We revised, refined and reworked our collages.

nicole-collaborates

Final Round Two Collages

 

At the end of the second round, we had a final survey which zeroed in on which collage was our favorite. Tyler painstakingly compiled the results from each survey and created two keynote presentations that we used to facilitate our in person Element Collage discussions.

favorite-graph

 

Tyler’s final Element Collage ended up being the group favorite.

final-element-collage

Given the collaborative nature of the second round, Tyler’s collage ended up borrowing many elements from the other collages. He uses Erik’s color palette as a starting point and brought in Sara’s “we ♥️” treatment for the hero illustration, just to name a few. Overall, the team felt this collage was friendly, cheerful and welcoming. The illustrations added personality and the design evoked a sense of clean freshness. Most importantly, it felt the most like Cloud Four.

We are currently in the process of working on our Pattern Library. You can follow all Cloud Four redesign fun in real time by joining our public Slack channel and our project board on Trello.