On this page:

February 24, 2016

Cloud Four Blog

Shared Visions and Sticky Notes

When we started redesigning cloudfour.com, I knew I wanted the entire team to feel a sense of ownership in the end result. To establish an inclusive design direction without designing a camel, we had to distill the collective input of every team member into one guiding vision… a singular “us.”

Fortunately for us, few problems in the universe cannot be solved by getting in a room and writing things on sticky notes.

After broadly discussing our hopes and dreams for the redesign, we jotted down words on stickies that described how we wanted Cloud Four to feel.

Each of us presented and clustered these notes on the whiteboard, grouping those that seemed thematically related.

Collage of sticky note exercise photos

Then, we agreed on informal titles for each cluster. These became (in no particular order):

  • Leadership
  • Academic
  • Open
  • Ahead
  • Craft
  • Integrity
  • Cheerful
  • Web ❤
  • Responsive
  • You
  • Boutique
  • Portland

We managed to swiftly condense 93 sticky notes from nine team members into twelve tidy descriptors. I call that a successful exercise!

These directly informed our mood boards… but that’s a story for another post!

by Tyler Sticka at February 24, 2016 09:44 PM

Redesigning Cloud Four in the Open

We finally have the time to give our perpetual back-burner project the attention it deserves. And we decided we wanted to try something different this time.

We’re going to redesign Cloudfour.com in the open!

We’ve never done something like this before. Consider it a grand experiment.

We started the design a while ago before client needs overwhelmed us. We created mood boards and element collages. We even started a pattern library and plan on open sourcing the tool we’re using to build it.

Sample element collage from our redesign

Over the coming days, we’ll share with you what we’re working on and our thinking behind it.

In the meantime, if you want to follow along, you can join our public redesign Slack channel, read archives of that same Slack channel, and check out our in-progress pattern library.

We’re looking forward to sharing our progress with you and getting your feedback along the way.

by Jason Grigsby at February 24, 2016 04:35 PM

February 18, 2016

Blog – Brad Frost

Frontend Design

Frontend design

Somewhere between design – a world of personas, pixels, and polish – and engineering – a world of logic, loops, and linux  – lies frontend design. Frontend design involves creating the HTML, CSS, and presentational JavaScript code that makes up a user interface. 

A frontend designer (who may also go by UI developer, client-side developer, UI engineer, design engineer, frontend architect, designer/developer, prototyper, unicorn, or Bo Jackson) lives in a sort of purgatory between worlds:

  • They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
  • They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
  • They can write JavaScript, but may not spend their time writing application-level code, wiring up middleware, or debugging.
  • They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.

Of course this varies from person to person. Sometimes one person handles frontend design in addition to their other roles. They may primary be a developer (making them a “full-stack developer” as the kids say) or they may be a designer (making them a “full-stack designer” I guess?). Sometimes – especially as organizations get larger – frontend design is handled by people who often find themselves awkwardly siloed in one department or another. I talk about my own experience in my book:

When a previous employer discovered I wrote HTML, CSS, and presentational JavaScript, they moved me to sit with the engineers and back-end developers. Before too long I was being asked, “Hey Brad, how long is that middleware going to take to build?” and “can you normalize this database real quick?”

Here’s the thing: I’ve never had a computer science class in my life, and I spent my high school career hanging out in the art room. Suffice it to say those requests made me extremely uncomfortable.

There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still technically code, frontend development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages. This misunderstanding tends to give many frontend developers, myself included, a severe identity crisis.

This distinction between frontend UI code and “real programming” has real ramifications on organizational structure:

Organizationally, there is often a massive divide between designers and developers (or “marketing” and “IT”, or “creative” and “engineering”, or some other divisive labels). Designers and developers often sit on different floors, in different buildings altogether, in different cities, and sometimes even in different countries in different continents. While some of this organizational separation may be justified, creating a division between designers and frontend developers is an absolutely terrible idea.

Here’s the thing: HTML, CSS, and presentational JavaScript build user interfaces – yes, the same user interfaces that those designers are meticulously crafting in tools like Photoshop and Sketch. In order for teams to build successful user interface design systems together, it’s crucial to treat frontend development as a core part of the design process.

That’s why I’m encouraged to read about how companies like Optimizely are structuring their teams to include frontend work as part of the design process. Jonathan Snook shared some absolutely brilliant thoughts on the topic based on his experience at Shopify. I’m excited to see this awareness cropping up, and encourage organizations to include frontend design as a key part of their design process.

I personally think that people who are skilled at frontend design are in a great position to help bridge the divide between the design and development worlds. They are mortar that help hold the bricks in place. Existing in purgatory between worlds may sound like a bad thing, but it doesn’t have to be! Embrace the fuzziness, encourage frontend designers to exist between worlds, and let collaboration and great work ensue.

by Brad Frost at February 18, 2016 01:38 AM

February 17, 2016

Cloud Four Blog

Jeb Bush’s Responsive Images Problem

It’s political season here in the United States, and it is great to see politicians taking technology issues seriously.

Take Jeb Bush for example. His campaign has gone out of its way to highlight the importance of planning the focal point of your responsive images carefully.

On small screens, the web page carefully positions the campaign logo right in the middle of the candidate’s face. This makes sense as there are two Bushes in the photograph so the logo helps us identify which Bush is running this time.

Screenshot of Jeb Bush web page on iPhone 4s where the logo is on top of Jeb's face

Careful planning ensures that there aren’t any embarrassing crops of the Bush brother we’re focusing on.

Jeb Bush split in half by a crop

At wider screens, the campaign crops out one Bush brother so we can focus in on the signup form. The last thing the campaign wants is for Jeb’s brother to overshadow him.

Wider screen that only shows George Bush

Animated gif showing unintentional cropping of Jeb Bush

You can see the full cropping in action at the Jeb Bush SC Signup Page or in the video below:

Alright, I’ve had enough fun at poor Jeb’s expense. This could easily happen to any web site owner.

Jeb Bush’s signup page demonstrates the needs for organizations to coordinate on how photographs will be created and utilized within responsive designs—particularly in cases where cropping will occur in the browser.

And it illustrates why Simon Bächler has started the Universal Images Working Group—a W3C Community Group—to work on embedding art direction rules inside meta data on the image files themselves.

The meta data would contain information on what can be cropped from an image and where the safety area—the area that should never be cropped—is located:

Photo of Monks containing crop marks and safety areas

The above image is from the Universal Images Demo page.

This idea is similar to what film and TV have been doing for years to ensure their work is cropped in an acceptable fashion. I’m already seeing organizations adopting this technique for responsive images.

Kevin Mack and Tim Vonderloh presented how they used what they called Asset Template Guides (video, slides) on a client project.

Netflix provides photographers with a prototype of the page in addition to guidelines and a template. “The photographer had the tool to be able to drop the images in as he was shooting them and we could see them in a prototype and see how they would look across screen sizes,” Anna Blaylock explained in an interview.

If you’re interested in working on this problem, the Universal Images Community Group could certainly use your help.

The big lesson here is that if cropping is part of your responsive images strategy, you need to plan ahead to avoid accidentally cropping the most important parts of a photograph.

Jeb and George chest bump

Thanks to Aileen for pointing out the Jeb Bush sign up page.

by Jason Grigsby at February 17, 2016 09:45 PM

February 11, 2016

Cloud Four Blog

Simpler SVG Icons

As a follow-up to my post discouraging the use of icon fonts, I recently wrote about the SVG icon process we’ve been using at Cloud Four. While most of the feedback I received was positive, some felt the steps I described seemed complicated, even intimidating.

I can’t entirely disagree. Our designers find the process easy to use (save SVG to folder, optionally update YAML file, use in HTML), but it does require quite a bit of elbow grease up-front.

And while I’d argue that our process is only modestly more complex than comparable icon font setups (examples here, here, here and here), I completely understand how it might feel overwhelming to anyone new to the SVG format (which is most of us, if we’re honest).

So I thought it might be helpful (and fun!) to devote a post to some of the simpler ways you can start using SVG icons today. Whether these options serve as your “toe in the water” or your production-ready technique of choice, I think you’ll find all of them more approachable.

Use Images

SVG is an image format, which means you can use it just like an image:

<img src="my-icon.svg" alt="Niftiest Icon Ever">

Crazy, right? Or if your icons are purely decorative:

.my-icon {
  background-image: url("my-icon.svg");
  /* width, height, etc. */

Neither of these techniques inherit the parent element’s text color, a feature we’ve all taken for granted since 2011. But unless your site’s color palette is enormous, they’ll probably work just fine.

Copy and Paste SVG Source

We use this technique a lot when we’re prototyping. Most of the time, you can copy and paste the source of an SVG right into your HTML document:

See the Pen SVG icon pasted into HTML by Tyler Sticka (@tylersticka) on CodePen.

The markup’s a little messy and there’s no caching to speak of, but it works just fine. SVG elements can even inherit the parent text color!

(Tip: If you find yourself saving files over and over just to copy their contents, try clicking the “Show Code” button in Illustrator’s Export dialog instead. There’s also a “Copy Layer as SVG” plugin for Sketch.)

Use a GUI

Detail of IcoMoon interface

If you really want to compile your icons into a single resource but don’t want to mess with Gulp or Grunt, several web apps exist that will guide you through the process. Our favorites are:

  • IcoMoon: Can generate an SVG sprite or an icon font (or both) using any combination of stock icons or your own.
  • Grumpicon: Generates a CSS file with embedded SVG, as well as PNG fallbacks.

Both apps are free and easy to use, generating helpful code samples along with the assets themselves.

Use Pre-Made Icons

In addition to the stock icons available via the aforementioned IcoMoon, there are a growing number of SVG icon packs available. Some of the best we’ve seen so far:

  • Material icons: Google’s material design icons are open source, and available individually or as as a sprite.
  • Evil Icons: Free and open source icon pack with an intuitive markup syntax.
  • Glyph: Large icon pack available via Creative Commons.
  • Iconic: Not free, but SVG version is incredibly full-featured.
  • Resources like The Noun Project, SVG Icons and iconmonstr offer lots of great stock icons in SVG format.

If you have a favorite icon pack that doesn’t offer SVG as an option, ask for it! For example, here’s an open issue in the FontAwesome repo requesting the format.

And Many More!

SVG as a format is only as complicated as you need it to be. None of the aforementioned techniques are inherently less valid than the fancy-schmancy process we use at Cloud Four. You can start simple and stay there, or you can choose to expand on your process later on.

So give it a try! It’s probably less scary than you think.

by Tyler Sticka at February 11, 2016 06:29 PM

February 10, 2016

Cloud Four Blog

Looking for our next project

We have a couple of projects wrapping up soon and for the first time in two years, we’ve got openings for new clients. So if you’ve ever wanted to work with us, now is the time!

In case you’re not familiar with what we specialize in, we’re typically hired by web teams to help with complex responsive projects. The team wants it done right the first time because of the timeline or because of the high stakes involved.

Our clients often want to learn how to do this work so that their web teams can take on these projects in the future. Our projects are usually a mixture of doing and teaching.

We’ve also built quite a few Javascript applications and are enthusiastic about progressive web apps these days. Lyza wrote one of the best intros to Service Workers—a key part of progressive web apps—for Smashing Magazine.

So if you’re looking for help or if you know someone you think we might be a good fit for, we’d love to hear from you!

by Jason Grigsby at February 10, 2016 05:23 PM

February 04, 2016

Cloud Four Blog

The Power of Responsive Design Sprints

In 2008, I sat gobsmacked in Web 2.0 Expo session. The topic of M. Jackson Wilkinson‘s presentation was “Design and User Experience in the Agile Process“, and I literally couldn’t imagine designing that way.

Fast forward seven years, add responsive design to the mix, and I can no longer imagine designing any other way. Responsive Design Sprints are key to our process.

Why agile for design?

Our path to agile for design started with moving to agile for development. Lyza and Megan spearheaded a move to agile development a few years ago and that change influenced the way we looked at projects.

Because of our success using agile for development, we were primed to try it when responsive design broke our existing design process.

We’ve found that agile design is ideally suited for designing responsive patterns. It allows us to focus on small pieces of a design and iterate on them quickly.

What is a Responsive Design Sprint?

Most of the time when people talk about design sprints, they’re referring to product design sprints. This is the process that Google Ventures, our friends at Fresh Tilled Soil and others have developed and promoted as a way to quickly validate product design and direction.

Thoughtbot's Product Design Sprints diagramThoughtbot’s Product Design Sprint Phases

Product design sprints are an exceptionally useful tool. The phases in our sprints have some similar characteristics—you’ll see parallels to the Understand, Diverge and Prototype phases in particular.

However, Responsive Design Sprints are decidedly different in what they’re trying to accomplish and diverge from Product Design Sprints in some specific ways.

Pre-sprint planning

Our first step when planning a project is to break the site down into the patterns—from the lowest level to higher-level components—that we need to design.


This is our starting position for each sprint, but because we’re working in an agile fashion, we’re flexible and can change what patterns are being worked on. We can also spend more time on patterns or bring patterns in from later sprints if we’re ahead of our plan.

Before each two-week sprint, we collaborate with our clients to figure out what patterns will be covered in the upcoming sprint. This not only allows us to confirm that our priorities are correct, but it also gives our clients a heads up on what they need to prepare for the sprint kickoff.

Sprint Day 1 — Client briefing and small screen sketching

Client briefing

Each sprint starts with a briefing on the patterns for that sprint. This briefing is led by the client team.

During the briefing, the client team provides everything they know about the patterns including:

  • How the patterns are used.
  • Any edge cases for the patterns.
  • Analytics information on the patterns.
  • User testing that has been done.
  • Support or user feedback on patterns.

If we’re dealing with foundational patterns like typography and buttons, the briefing could simply be going over any existing brand and style guidelines.

However, when we start working on more complex patterns—for example a shopping cart interface—there is often quite a bit of information about the pattern to convey.

Small screen sketching

After the briefing, we start group sketching sessions. Ideally, we do this with our client, but often we work with teams in other parts of the world so we only get to sketch together a couple of times during a project.

Everyone participates in the sketching irrespective of roles. Sketching small screen designs helps people start thinking more tangibly about the constraints of small screens. It is one of the reasons why we include clients in sketching exercises whenever we can.

We pick the portions of the patterns that we think are going to be the most difficult to fit on small screens and sketch those. This often means that we’re not sketching the entire interface or even the entire pattern that we’re looking at, but instead just a small portion of the pattern that looks particularly troublesome.

Sketches on sticky notes

We sketch on small sticky notes using Sharpies. Every sketching session is time-boxed. The constraints on time, size and low fidelity markers prevent people from getting too detailed in their drawings.

And we use Sharpie brand markers because Tyler is a marker snob.

(Tyler here: The store-brand ones bleed too much!!)

Each person posts their sketches on the board and talks about what they saw and how they were trying to solve the problems. The conversation around the sketches is just as important as the sketching itself.

Photo of me presenting some of my terrible sketches

The goal of the sketching session is to give the designers some ideas on how they might solve the problems that the patterns represent. We do multiple sketching sessions until people feel they have enough material to explore.

Focus on small screens first

For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.

If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.

If you nail the small screen design, the larger sizes will be easy by comparison.

Sprint daily activity — Quick design iterations

We move immediately from sketches to testing our ideas in the browser. We create quick prototypes of the designs that we then share with the client team in Slack.

The video above shows collaboration happening on day 2 of a new project. We’re showing simple small screen designs in the browser and getting feedback both from our co-workers and the client team.

Often, we will have members of the client team working on patterns as well. They may be sharing mockups, photographing sketches, or even coding prototypes.

What matters most is that we’re sharing ideas quickly and iterating towards better solutions.

LICECap, the worst named, best tool ever

One of the advantages of designing in the browser is that we’re able to demonstrate how things should interact. But when we’re working with distributed teams, we need a tool to show the interaction.

That’s where LICECap comes in. LICECap makes it easy to capture screen video and save it as an animated gif.

So instead of saying to a client, “imagine we hide all of the controls behind a single button until someone clicks on it” and hoping that the client understands, we simply post an animated gif in Slack.

Animated gif showing add to cart interaction

The animated gif eliminates confusion and facilitates quick feedback.

Mid-sprint review meetings

The amount and frequency of review meetings in a sprint change from project to project, but generally we’ll have one review meeting late in the first week of the sprint to make sure we’re on the right track.

We share our screens and show any in-progress work. Those who have been active in our shared Slack channel will have seen most of the work already, but the meeting ensures that all stakeholders are looking at the patterns early in the sprint.

Depending on the complexity of the pattern, by the second review meeting we’ll have examples of how the pattern will adapt as the screen size increases.

Sample two-week sprint schedule

End of sprint review

At the end of the two week period, we have one final meeting to review the progress on the patterns tackled during the sprint. Nothing in this meeting should be a surprise because we’ve been sharing our work throughout the sprint.

After we’ve reviewed the patterns, we talk about what worked well during that sprint and what we could improve on for the next sprint. We’re not only iterating on the designs, but on the process itself.

This isn’t rocket science, but it feels new just the same

Nothing I’ve described here is new.

Agile processes have been around for years. Many people have talked about how responsive design makes pattern libraries more important than ever.

But the combination of responsive design, patterns libraries, sprints, gifs, and constant communication via Slack creates a radically different design process. Even if the pieces that comprise them aren’t new, Responsive Design Sprints certainly are.

Most importantly, Responsive Design Sprints work exceptionally well.

They helped us convert complex interfaces that seemed insurmountable. When we were asked to convert an e-commerce design to responsive in only three months, it was Responsive Design Sprints that helped us move quickly and finish the project a week ahead of schedule.

I can only imagine how stunned 2008 me would be to see what our design process looks like now.

by Jason Grigsby at February 04, 2016 06:02 PM

February 02, 2016

Cloud Four Blog

Case Study: Our SVG Icon Process

When I wrote about why you shouldn’t use icon fonts in your next web project, I had no idea it would spark so much heated debate and intense discussion. One recurring question stood out to me: How might one actually implement an SVG icon system?

It’s a surprisingly difficult question to answer. Should you use <img>, <svg>, <object> or pure CSS? Will you combine your icons into a single sprite or keep them separate? If you do combine them, do you use an old-school technique or embrace SVG’s built-in features? Can JavaScript factor in somehow?

Though this variety of options might feel overwhelming, it’s ultimately a good thing. SVG’s versatility empowers us to craft the most appropriate solution for our audience and use-case.

So as much as I’d like to, I can’t say exactly how you should implement SVG icons in your next project. There’s no substitution for research and trying stuff out when it comes to finding the best fit for your project.

Instead, I’m going to show how we tend to assemble and implement SVG icons, and why we do it that way.

What We Do

The icon process we’ve adopted here at Cloud Four is a byproduct of the types of projects we take on, which tend to be large responsive redesigns or brand-new responsive interfaces. Our most common deliverables are in-browser mockups and pattern libraries. We often work with existing in-house teams, designing or extending icon systems based on their brand guidelines.

The front-end problems we solve tend to be those that are too complex or idiosyncratic to tackle with a framework or a simple content reflow. Our most common use of icons is to reinforce the meaning or relative importance of interface controls (a plus next to the word “Add,” a checkmark next to the word “Okay,” etc.).

Our Requirements

With this context in mind, we can assemble a list of requirements:

  • Accessibility: Because our icons represent or reinforce content, they should exist in markup.
  • Design: Our icons will most often coexist with text. They should inherit the text color and flow with the text by default.
  • Performance: Icons should be consolidated into a single, external sprite to avoid multiple requests and maximize caching.
  • Workflow: Whatever icon prep we can automate should be baked into our existing development tools (Node.js and Gulp).
  • Browsers: Our projects tend to be optimized for IE9+, Android 4.3+ and the usual array of less finicky modern browsers.

With requirements in hand, it’s time to build an SVG icon system!

1. Exporting Icons

Though our team digs Sketch for UI explorations, we still feel like Illustrator is a bit more intuitive for the design of icons and other illustrative elements.

We maintain a master icons.ai file in a shared spot (usually Dropbox), with each icon in the library residing in its own named artboard. We can see every icon in the context of its siblings, make any final tweaks for consistency, and simplify or combine any overlapping or unnecessary paths.

Screenshots of Illustrator artboards with icons

During this process, we purposely avoid preparing different rotations of the same icon. Traditionally, icon sets have exported separate assets for “left arrow,” “right arrow,” etc., but with SVG this repetition is redundant and unnecessary. Later on, we’ll walk through how to create simple rotational variations of the same icon.

Once everything’s looking good and feeling clean, we use Illustrator CC’s recently-improved exporting to generate SVGs from our artboards. After removing anything Illustrator over-enthusiastically prepended to our filenames, we’re ready to smoosh all of our icons into a single sprite.

2. Creating Our Sprite

As mentioned earlier, our team likes using Gulp for our local environment. If you’ve never used Gulp before, here’s a great article covering the basics. We’re going to write a Gulp task called icons this will compile a folder of separate, unoptimized SVG icons into a single, optimized sprite we can reference from our HTML.

Of the handful of plugins we’ve tried for accomplishing this sort of thing, our favorite is currently gulp-svg-sprite. It boasts a wealth of output modes and configuration options, making it the perfect choice for control freaks like yours truly.

For our icons task, we’ll be using the plugin’s symbol “mode.” This will transform each of our SVG files into a <symbol> element, which we’ll be able to reference by ID later.

Here’s what our SVG task might look like:

var gulp = require('gulp');
var svgSprite = require('gulp-svg-sprite');
var svgSpriteConfig = {
  mode: {
    symbol: {
      dest: '',
      sprite: 'icons.svg'
gulp.task('icons', function () {
  return gulp.src('./src/icons/**/*.svg')

This task will:

  1. Find every SVG file in the src/icons directory.
  2. Pass those files to the gulp-svg-sprite plugin, which combines them into a single icons.svg file using the symbol output mode.
  3. Output the result to the dist directory.

Now if we run gulp icons, we should find a shiny new icons.svg file in our dist directory, ready to be referenced from our markup.

3. Including Icons in Our Markup

Now that we have our SVG sprite, we can reference it from our markup using <svg> and the <use> element:

  <use xlink:href="icons.svg#back"/>

This markup tells the browser “use the symbol with ID back from the file icons.svg.” This means our external file is nice and cacheable, and we can reference the same icon asset multiple times from the same file! Hooray!

Except, it looks like garbage:

Unstyled SVG icon in document

We haven’t told the browser how we want our icons to be sized, filled or aligned based on their surroundings. To do that, we need some CSS.

4. Styling Icons

We don’t want to style every svg because SVG can be used for a lot more than icons. Instead, we’re going to create a class. Our team likes using SUIT CSS naming conventions, so we’ll name our class Icon:

.Icon {
  /* Flow with text content */
  display: inline-block;
  /* Inherit the parent text color */
  fill: currentColor;
  /* Use the parent font-size for width and height */
  height: 1em;
  width: 1em;
  /* Vertically align icon with adjacent text */
  vertical-align: middle;
  /* Align more nicely with capital letters */
  position: relative;
  top: -0.0625em;

(Props to Chris Coyier and Jonathan Snook!)

Here’s the result after adding class="Icon" to our SVG element:

Styled SVG icon in document

Success! Our icons are successfully inheriting their size and color, and aligning nicely with adjacent type.

This accomplishes most of what we set out to do, but we haven’t taken advantage of what makes SVG special just yet. Let’s fix that.

5. Adding DRY Variations

Back when we were exporting icons, we only exported a single arrow asset (back.svg), the contents of which looked something like this:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path d="M22,10H6.83l3.59-3.59A2,2,0,0,0,7.59,3.59l-7,7a2,2,0,0,0,0,2.83l7,7a2,2,0,0,0,2.83-2.83L6.83,14H22A2,2,0,0,0,22,10Z"/>

Let’s pop open our favorite code editor, and create a new forward.svg file to compliment it:

<svg xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 24 24">
  <use xlink:href="#back" transform="rotate(180 12 12)"/>

Here’s what’s going on:

  1. Our <svg> element is identical to back.svg, except we’ve added an xmlns:xlink attribute. This helps avoid errors during optimization by letting the plugin know that this SVG will reference other elements.
  2. Instead of including the forward icon’s path data, we reference our existing #back icon from a <use> element (similar to how we reference icons from our markup).
  3. The transform attribute rotates the icon 180 degrees from the center of our viewBox.

If we recompile our sprite, we should now be able to reference both icons from our markup:

Original arrow icon and derivative icon in document

Any changes made to back.svg will cascade to forward.svg (or any future variations). Plus, we save a small amount of file-size in the compiled sprite. Win/win!

6. Enforcing Mandatory Colors

Sometimes there are icons that really shouldn’t inherit everything about the parent. A common concern we hear from design teams is that the meaning of certain icons (in particular those representing “error” or “warning”) can be diluted over time if they are applied inconsistently.

In these cases, it’s helpful to remember that SVG elements are subject to the same style cascade as everything else. By specifying mandatory colors via attributes on the elements themselves (fill, style, etc.), we can overrule some or all color inheritance.

As an example, this error.svg file has fill attributes on the elements themselves:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
  <path fill="#ff4136" d="M13.74,3l9,15.7A2.21,2.21,0,0,1,20.9,22H3.1a2.21,2.21,0,0,1-1.8-3.34l9-15.7A2,2,0,0,1,13.74,3Z"/>
  <path fill="#fff" d="M10.59,17.82a1.41,1.41,0,1,1,1.4,1.4A1.42,1.42,0,0,1,10.59,17.82Zm2.77-9.63a32.3,32.3,0,0,1-.61,4.5l-0.34,2.11H11.6l-0.34-2.11a32.77,32.77,0,0,1-.61-4.5A1.24,1.24,0,0,1,12,6.78,1.24,1.24,0,0,1,13.36,8.18Z"/>

Even with our .Icon class applied, these colors will not be overruled:

Error icon that will not inherit its fill color from document

7. Improving Accessibility

Arguably the best reason to adopt SVG is to take advantage of its accessibility features. Thanks to Léonie Watson’s Tips for Creating Accessible SVG, we know to add the following elements and attributes to our icons:

  viewBox="0 0 24 24"
  aria-labelledby="title desc">
  <title id="title">Back</title>
  <desc id="desc">A leftward arrow</desc>
  <path d="M22,10H6.83l3.59-3.59A2,2,0,0,0,7.59,3.59l-7,7a2,2,0,0,0,0,2.83l7,7a2,2,0,0,0,2.83-2.83L6.83,14H22A2,2,0,0,0,22,10Z"/>

This insures that our icons have human readable fallbacks for blind and partially sighted people in a variety of user agents.

But there’s a problem with this approach. IDs must be unique, and we’ll be combining multiple files into a single SVG document. Our accessibility efforts will be thwarted if two <title> or <desc> elements attempt to use the same ID within the same document.

We could just be really diligent about choosing unique IDs, but that’s kind of a pain. If only we could manage these titles and descriptions in a central location, relying on our Gulp task to assign unique identifiers…

Luckily, we can! All we need to do is provide all our titles and descriptions in a separate YAML file:

  title: Back
  description: A leftward arrow

  title: Error
  description: A red sign with a white exclamation mark

  title: Forward
  description: A rightward arrow

  title: Search
  description: A magnifying glass

Then update the Gulp task with the location of that file:

var svgSpriteConfig = {
  mode: { /* ... */ },
  shape: {
    // Titles and descriptions
    meta: './src/icons/icons.yaml'

When we run gulp icons again, gulp-svg-sprite will add <title> and <desc> elements with unique, namespaced IDs and update the aria-labelledby attribute accordingly.

(It’s important to note that while we’ve specified <title> and <desc> elements within our sprite, you should still take care to use accessibility attributes in the page itself when the icon’s meaning is not re-enforced by its surrounding content.)

8. Supporting More Browsers

Time to address the elephant in the room…

Our icon sprite is a separate file, which is great for caching. But referencing symbols in an external file doesn’t work in Internet Explorer (though it does in Edge).

Icons not displaying in IE10

To address that, we’re going to use a polyfill called svgxuse. The script works by detecting failed external references, loading the referenced file via AJAX, injecting the sprite into the page itself, and updating the xlink:href attributes to point to the in-page resource. We like svgxuse because it minimizes the duplicated path data while retaining the ability for icons to reference each other.

The polyfill will work as-is, but we should make a couple of changes one small change to our task config to avoid any collisions with in-page content:

var config = {
  mode: { /* ... */ },
  shape: {
    // Titles and descriptions
    meta: SRC + '/icons/icons.yaml',
    // Add suffix to IDs
    id: {
      generator: '%s-icon'

Now we won’t have to worry about the SVG sprite being visible in Internet Explorer, and the IDs for our icons are far less susceptible to collisions once they coexist in the same document. Once we update our icon references to include the -icon suffix, we should have our target browsers covered:

Icons displaying in IE10 with svgxuse

Update: An earlier version of this post included specific configuration options for hiding the injected SVG sprite, but svgxuse handles that automatically now. Open source is awesome!

Putting It All Together

We made it! Here’s what we accomplished:

  • Our Gulp task will compile a folder of icons into a single, cacheable SVG sprite.
  • Individual icons can be referenced one or more times from anywhere in our HTML document.
  • By default, icons will base their position, size and color on their parent elements and surrounding text.
  • Icons may defy the default styles where appropriate.
  • To avoid repetition, some icons can be simple variations of others.
  • We can specify conflict-free accessibility details within icons.yaml.
  • When external references fail, the asset will be injected into the page itself.

You can see a live demo of the end result or browse the code.

Our completed SVG icon demo

Before we pat ourselves on the back too vigorously, it’s important to remember that that there is no one, true SVG icon process. Your ideal setup might involve the picture element, grunt-svgstore, SVGInjector or even an existing library. It can and should change based on the needs of your project. We modify ours all the time.

So consider this just one potential starting point for your own SVG icon system. I hope you’ll share what you come up with!

by Tyler Sticka at February 02, 2016 05:23 PM

February 01, 2016

Cloud Four Blog

Converting an existing site or app to a responsive design

Over the last few years, we’ve converted quite a few existing sites and applications to responsive web design. We’ve gotten pretty good at it so I thought I’d share our process.

Not a full redesign

Many of our clients have come to us with desktop sites that are working well that they are rightly afraid of messing up.

For example, when we first starting working on the Walmart Grocery site, the main Walmart desktop site had recently undergone a major redesign effort. We liked the new design, and were pleased to see that the designers had already considered touch-friendly targets.

Walmart.com Homepage

Given how recently Walmart had redesigned the site, any responsive plans that required a full redesign were non-starters. This wasn’t the time to rebrand the site.

In addition, Walmart and many of our other clients are running successful businesses on their desktop sites. They conduct user testing and constantly analyze site usage to optimize performance and profits.

Therefore, our goal has been to convert the site to a responsive web design with as little disruption to the business as possible.

Not a responsive retrofit

At the same time, these projects have been much more extensive than a responsive retrofit. Ben Callahan has written about several techniques for responsive retrofits. In the article, Ben poses the following scenario:

To start over with something like this would be a year long project costing hundreds of thousands of dollars. Is there anything you can do with just CSS to make the existing experience a bit better for smaller screens?

Ben does a wonderful job describing the techniques people can use to apply CSS with scalpel-like precision to start a site on their way to responsive without making major changes to the underlying code. If that’s the constraint you’re working with, I highly recommend his article.

For the most part, our clients have different constraints. They don’t mind changing markup if necessary. And they expect the CSS to change quite a bit.

What they want to preserve is the wide screen experience because that is what is currently working and what their users are accustomed to.

Responsive conversions

If they’re not responsive redesigns and they’re not responsive retrofits, what do we call projects where an organization wants to move to responsive design, but wants to preserve the desktop experience?

For lack of a better term, I’ve been referring to them as responsive conversions.

The desktop experience will have to change some

Clients often seek to preserve the desktop experience for completely understandable reasons. This often leads to a mandate that the “desktop site cannot change.”

Unfortunately, it isn’t possible to convert a site to responsive design without some changes to the wide screen version. Inevitability, there are situations where tweaks to the desktop experience would make the responsive implementation significantly easier.

And more times than not, the changes that come from figuring out how to design the mobile experience make the desktop experience better.

For these responsive conversion projects, our guiding principles have been:

  • We will do our best to keep the wide screen experience feeling as close to its current experience as possible.
  • Under the hood, we’re free to do whatever is necessary to make the site responsive.

We strive to make the experience better no matter what size screen someone is using.

Breaking the existing site into smaller patterns

Our first step in converting an existing site into a responsive design is to identify the patterns we think we will need to design.

This process usually consists of a couple of team members sequestering themselves in a room and reviewing the site and writing on sticky notes what patterns they see. This pattern identification provides us with a guide for estimating the time we think projects will take.

The results of a high-level pattern identification.

Recently, Charlotte Jackson wrote about an exercise that teams can undertake to identify patterns. We’re looking forward to trying this on a future project.

Ordering the patterns into sprints

After we’ve identified the patterns, we start organizing them into sprints. Some of the things we consider when organizing the sprints are:

  • In general, we want to start with the smallest patterns and build up to the most complex.
  • We check with our client to see if any components are particularly important and need to be addressed earlier. If so, we figure out any dependencies for those components and prioritize them.
  • As each sprint passes, our velocity increases as does our ability to tackle more complex components.


The whole point of agile is to be flexible so this plan isn’t set in stone. But it does give us a starting point and lets our clients know what they need to prepare for each sprint. Our client team plays a huge role in making each sprint successful.

Responsive Design Sprints

The biggest change to the way we work is that we now design in sprints. Responsive design sprints are a topic worthy of their own article and I plan to write more about them soon.

In the meantime, here are the highlights of the way we approach these design sprints:

  • Sprints focus on patterns.
  • We work with the client ahead of time to determine what patterns will be tackled in an upcoming sprint.
  • At the beginning of each sprint, the client team presents everything they know about the patterns—how and when they are used; what user testing has been done; and any edge cases we need to consider.
  • We then start sketching small screen versions of the patterns.
  • Once we’ve got a good direction, the team divides up the work and starts designing in the browser.
  • We share what we’re designing with our clients nearly every day via Slack so we’re constantly adjusting and refining the designs.
  • At the end of our two-week sprint, we’ve got working prototypes of those responsive patterns.

Sample two-week sprint schedule

There is much more to say about this process. Read my follow up article on The Power of Responsive Design Sprints.

Rinse and repeat until we’re “done”

Once we start the responsive design sprints, we simply continue the formula until all of the patterns and components that we’ve been tasked to design are complete.

One of the interesting things about this process is that the definition of what “done” means changes from project to project. There are a couple of reasons for this.

First, our client’s engineering team is often responsible for taking our work and integrating it into whatever backend system they use. In these cases, our work can be complete long before the site launched and officially “done.”

Second, we’re frequently asked to teach web teams. On more than one project, we’ve had designers and developers from the client’s team embed inside our team to learn from us.

This means that we start projects with the goal of teaching the team to fish for themselves and once they can, we hand over the project to their designers to finish things up.

The process works

When we’re confronted with a complex fixed-width interface, I often have no idea what the responsive version of that interface will be. But I do know even the most complex interfaces can be converted to a responsive design by breaking them into smaller patterns and designing in sprints.

I have complete faith in the process because I’ve seen it work multiple times. If you’re stuck on a complex responsive design, I recommend giving it a try. If you need help, let us know.

(P.S. You may enjoy my follow up article on the Power of Responsive Design Sprints)

by Jason Grigsby at February 01, 2016 05:23 PM

MobileMonday London

Mobile Miscellany, 1 Feb 2016: Free MWC Exhibition Pass Competition and Possible Stay-at-Home Drinks

Not got your MWC Ticket yet? We have a competition from our lovely friends over at 51Degrees who have some exhibition passes to give away!

51Degrees is the purveyor of the finest quality device detection to improve your Web presence and unsurprisingly they'll be spreading the message at this year's MWC. They'd like to meet you there, and to help you do that they have some passes they'd like to give away.

Here's the entry form: https://51degrees.com/MWC-2016

Entries must be in by Weds 10 Feb and the draw will be on the 11th.

As if that was not enough, they've kindly indicated that they are interested in supporting a stay-at-home drinks for those of us who are not going. Let us know (contact@mobilemonday.org.uk or tweeting us at @momolondon) and if there are enough of us Cinderellas we'll organise a get-together.

That's it for this Micro Miscellany.


by Jo Rabin (noreply@blogger.com) at February 01, 2016 11:54 AM

January 29, 2016

Cloud Four Blog

Listen to WalmartLabs on the RWD Podcast

WalmartLabs LogoWe had the great fortune to help WalmartLabs convert their sites to responsive design, and it is always nice to see our clients get recognized for their hard work.

Mini Kurhan and Olawale Oladunni, two designers at WalmartLabs, were recently interviewed by Ethan Marcotte and Karen McGrane for the Responsive Web Design Podcast.

I highly recommend giving the interview a listen. There is also a transcript of the interview if you prefer.

It was great hearing Mini and Ola talking about the challenges Walmart faced and how they overcame them. It was a massive effort to convert the sites to responsive design and the Walmart team did a fantastic job. We had a blast working with them.

If you want to learn more about the Walmart redesign, particularly when it comes to responsive images, check out Mini and Ola’s presentation from Responsive Field Day.

by Jason Grigsby at January 29, 2016 06:18 PM

January 27, 2016

Blog – Brad Frost

Email Responses #3: UX Designer or Front-End Developer?

I am currently going through the frustration of working in a traditional ‘waterfall agency’. They are not going to change process, client work is suffering and it’s got to the point that I am looking for a new job.

Like yourself, I am very much a designer with front end skills (design, css3, html5, responsive, 12 years experience) minus the heavy duty javascript skills. I can work around JS with some jquery or sourcing plugins that work.

My question to you is whether my skillset covers both the ux designer and front end dev role? I see many job opportunities for both but it’s sometimes difficult to choose between.

I’m of the belief that every person who helps make a product is a UX designer. The copy editor who’s making content easy to read and navigate is a UX designer. The backend developer who’s making the site secure and fast is a UX designer. The visual designer who’s using color, typography, and texture to make the site easier to use is a UX designer.  Etc. Etc.

I don’t necessarily think you have to choose between the two. Quite honestly, most organizations don’t recognize front-end design (a shorthand I use for a UI-focused frontend developer) as a thing, so that wouldn’t necessarily be reflected in job postings.

I’d say apply to places for both these roles, and when you land interviews explain what skills you have, what problems you enjoy solving, and what topics you’re passionate about. Talk about the importance of mortar. If the interviewer responds with “sorry, we’re looking for someone to crank out a bunch of static wireframes” or “sorry, we’re looking for someone who can build out this RESTful API” then I’d say it’s better to pass than be pigeon-holed. But there most certainly are opportunities out there for you to do what you do best. You have to be willing to articulate what you want in order to get it. And once you get it, have the courage to work the way you need to rather than be stifled by a finite bulleted list of job requirements.

by Brad Frost at January 27, 2016 04:33 PM

January 26, 2016

Martin's Mobile Technology Page

ATTENTION: I'm Moving - Please Update Your Bookmarks And Feeds

There we go, after 10 years at Typepad I've decided to move this blog to a new location! To continue following me please update your Bookmarks and Feeds:

The Blog

The RSS Feed

See you on the other side!

Huston, Uberspace base here, the blog has moved...

by mobilesociety at January 26, 2016 11:12 PM

Blog – Brad Frost

Performance Budget Builder

Performance budgets are awesome. So I made a thing to help you make performance budgets.

Make A Performance Budget

The Performance Budget builder lets you lay out your template types, set a size budget for each template type, then plug in the sizes for each asset category that will load in the template. The tool will adjust each category’s width accordingly and yell at you if you exceed your budget. Pretty fun! Fair warning, this is mostly an experiment and hasn’t been cross-browser tested or anything like that. Feel free to take it and run with it.

There’s a lot that can be said about performance budgets, but I’ll leave that to the pros. Check out these great resources:

by Brad Frost at January 26, 2016 06:14 PM

Cloud Four Blog

Responsive Image Breakpoints Generator

Responsive image breakpoints have vexed me for nearly four years. They have been my personal koan—my unsolvable problem—until today.

Logo for ResponsiveBreakpoints.comSee a couple of years ago, I had a crazy idea to pick image breakpoints using performance budgets. John got excited by this idea and built a rough prototype of how this might work.

I used the script John wrote to create a demo page showing how a performance budget could be used to select image breakpoints. But the script was never intended to be a production tool.

Still, the idea had legs. And it was clearly something other people could use:

Unfortunately, building such a tool was beyond my skill level. The job called for someone who understood image processing and compression much better than I do.

That’s why I’m thrilled to share that Cloudinary took up the challenge and built the Responsive Image Breakpoints Generator.


The Responsive Image Breakpoints Generator works better than I could have imagined. From an end user standpoint, you simply:

  1. Select the smallest and largest size your image will be used at.
  2. Set your performance budget.
  3. Upload your image.

That’s it! The tool does the rest. The generator will:

  • Determine the optimal number of images you need.
  • Provide you with sample code for those images.
  • Offer a zip file for download that contains all of the images and code you need.

And the kind folks at Cloudinary have made the tool free to use and open sourced the front-end code.

They’ve also integrated this capability into their platform and API so if you want to use the tool in an automated fashion, you can do so. They even have a free tier of their service that includes 7,500 monthly image transformations which is more than enough for small sites.

Nadav Soferman, a co-founder of Cloudinary, has written in more detail about the tool and why it is important at Smashing Magazine.

Simply giddy

I can’t begin to tell you how excited and honored I was to find out that Cloudinary was working on building my crazy idea. It has been all I could do to keep it secret for the last couple of months while they put the finishing touches on the site.

Thanks to Nadav, Tal and the whole team at Cloudinary for making this tool a reality and giving it away to the web community!

by Jason Grigsby at January 26, 2016 04:01 PM

January 25, 2016

Blog – Brad Frost

Experts Weigh In: What Is The Most Common Web Design Mistake You See?

Adobe asked me to weigh in on the most common web design mistake I see. The answer in a word: bullshit. But of course I elaborated a bit.

I think the most common web design mistake I see is sites not respecting users and their time. This is represented in a number of ways:

  • Bloated, slow-loading pages
  • Overly-aggressive advertising
  • Popups and overlays
  • Dark patterns
  • Other superfluous or intentionally deceptive practices I lovingly classify as bullshit.

Users of the Web are inundated with more information than ever before, so it’s up to us as people creating for the Web to respect users and their time. That means giving them what they want as quickly as possible. That means putting up a fight when asked to implement cruddy and/or deceptive practices. That means respecting your craft.

by Brad Frost at January 25, 2016 06:12 PM

January 24, 2016

Martin's Mobile Technology Page

LTE-A Pro for Public Safety Services - Part 3 – The Challenges

In case you have missed the previous two parts on Private Mobile Radio (PMR) services on LTE have a look here and here before reading on. In the previous post I've described the potential advantages LTE can bring to PMR services and from the long list it seems to be a done deal. On the other hand there is unfortunately an equally long list of challenges PMR poses for current 2G legacy technology it uses that will not go away when moving on the LTE. So here we go, part 3 focuses on the downsides that show quite clearly that LTE won't be a silver bullet for the future of PMR services:

Glacial Timeframes: The first and foremost problem PMR imposes on the infrastructure are the glacial timeframe requirements of this sector. While consumers change their devices every 18 months these days and move from one application to the next, a PMR system is static and a time frame of 20 years without major network changes was the minimum considered here in the past. It's unlikely this will significantly change in the future.

Network Infrastructure Replacement Cycles: Public networks including radio base stations are typically refreshed every 4 to 5 years due to new generations of hardware being more efficient, requiring less power, being smaller, having new functionalities, because they can handle higher data rates, etc. In PMR networks, timeframes are much more conservative because additional capacity is not required for the core voice services and there is no competition from other networks which in turn doesn't stimulate operators to make their networks more efficient or to add capacity. Also, new hardware means a lot of testing effort, which again costs money which can only be justified if there is a benefit to the end user. In PMR systems this is a difficult proposition because PMR organizations typically don't like change. As a result the only reason for PMR network operators to upgrade their network infrastructure is because the equipment becomes 'end of life' and is no longer supported by manufacturers and no spare parts are available anymore. The pain of upgrading at that point is even more severe as after 10 years or so when technology has advanced so far that there will be many problems when going from very old hardware to the current generation.

Hard- and Software Requirements: Anyone who has worked in both public and private mobile radio environments will undoubtedly have noticed that quality requirements are significantly different in the two domains. In public networks the balance between upgrade frequency and stability often tends to be on the former while in PMR networks stability is paramount and hence testing is significantly more rigorous.

Dedicated Spectrum Means Trouble: The interesting questions that will surely be answered in different ways in different countries is whether a future nationwide PMR network shall dedicated spectrum or shared spectrum also used by public LTE networks. In case dedicated spectrum is used that is otherwise not used for public services means that devices with receivers for dedicated spectrum is required. In other words no mass products can be used which is always a cost driver.

Thousands, Not Millions of Devices per Type: When mobile device manufacturers think about production runs they think in millions rather than a few ten-thousands as in PMR. Perhaps this is less of an issue today as current production methods allow the design and production run of 10.000 devices or even less. But why not use commercial devices for PMR users and benefit from economies of scale? Well, many PMR devices are quite specialized from a hardware point of view as they must be more sturdy and have extra physical functionalities, such as a big Push-To-Talk buttons, emergency buttons, etc. that can be pressed even with gloves. Many PMR users will also have different requirements compared to consumers when it comes the screen of the devices, such as being ruggedized beyond what is required for consumer devices and being usable in extreme heat, cold, wetness, when chemicals are in the air, etc.

ProSe and eMBMS Not Used For Consumer Services: Even though also envisaged for consumer use is likely that group call and multicast service will be limited in practice to PMR use. That will make it expensive as development costs will have to be shouldered by them.

Network Operation Models

As already mentioned above there are two potential network operation models for next generation PMR services each with its own advantages and disadvantages. Here's a comparisons:

A Dedicated PMR Network

  • Nationwide network coverage requires a significant number of base stations and it might be difficult to find enough and suitable sites for the base stations. In many cases, base station sites can be shared with commercial network operators but often enough, masts are already used by equipment of several network operators and there is no more space for dedicated PMR infrastructure.
  • From a monetary point of view it is probably much more expensive to run a dedicated PMR network than to use the infrastructure of a commercial network. Also, initial deployment is much slower as no equipment that is already installed can be reused.
  • Dedicated PMR networks would likely require dedicated spectrum as commercial networks would probably not give back any spectrum they own so PMR networks could use the same bands to make their devices cheaper. This in turn would mean that devices would have to support a dedicated frequency band which would make them more expensive. From what I can tell this is what has been chosen in the US with LTE band 14 for exclusive use by a PMR network. LTE band 14 is adjacent to LTE band 13 but still, devices supporting that band might need special filters and RF front-ends to support that frequency range.

A Commercial Network Is Enhanced For PMR

  • High Network Quality Requirements: PMR networks require good network coverage, high capacity and high availability. Also due to security concerns and fast turn-around time requirements when a network problem occurs, local network management is a must. This is typically only done anymore by high quality networks rather than networks that focus on budget rather than quality.
  • Challenges When Upgrading The Network: High quality network operators are also keen to introduce new features to stay competitive (e.g. higher carrier aggregation, traffic management, new algorithms in the network) which is likely to be hindered significantly in case the contract with the PMR user requires the network operator to seek consent before doing network upgrades.
  • Dragging PMR Along For Its Own Good: Looking at it from a different point of view it might be beneficial for PMR users to be piggybacked onto a commercial network as this 'forces' them through continuous hardware and software updates for their own good. The question is how much drag PMR inflicts on the commercial network and if it can remain competitive when slowed down by PMR quality, stability and maturity requirements. One thing that might help is that PMR applications could and should run on their own IMS core and that there are relatively few dependencies down into the network stack. This could allow commercial networks to evolve as required due to competition and advancement in technology while evolving PMR applications on dedicated and independent core network equipment. Any commercial network operator seriously considering taking on PMR organizations should seriously investigate this impact on their network evolution and assess if the additional income to host this service is worth it.

So, here we go, these are my thoughts on the potential problem spots for next generation PMR services based on LTE. Next is a closer look at the technology behind it, which might take a little while before I can publish a summary here.

by mobilesociety at January 24, 2016 07:42 AM

January 20, 2016

Martin's Mobile Technology Page

50+ Gbit/s for Vodafone Germany on New Year's Eve

Like every year Vodafone has released numbers on mobile network usage during New Year's eve between 8 pm and 3 am as this is one of the busiest times of the year. This year, Vodafone says that 185 TB were used during those 7 hours. Let's say uplink and downlink are roughly 9:1 which would result in a total amount of 166.5 TB downloaded during that time. Divided by 7 hours, 60 minutes and 60 seconds and then multiplied by 8 to to get bits instead of bytes results in an average downlink speed at the backhaul link to the wider Internet of 53 Gbit/s. An impressive number, so a single 40 Gbit/s fiber link won't do anymore (if they only had a single site and a single backhaul interconnection provider, which is unlikely). Back in 2011/2012 the same number was 'only' 7.9 Gibt/s.

On the other hand when you compare the 53 Gbit/s for all Vodafone Germany customers to the 30 Gbit/s reached by the uplink traffic during the recent 32C3 congress or the sustained 3 Gbit/s downlink data rate to the congress Wi-Fi generated by 8.000 mobile devices, the number suddenly doesn't look that impressive anymore. Or compare that to the 5000 Gbit/s interconnect peaks at the German Internet Exchange (DE-CIX). Yes, it's a matter of perspective!

If you've come across similar numbers for other network operators please let me know, it would be interesting to compare!

by mobilesociety at January 20, 2016 06:50 AM

January 19, 2016

Martin's Mobile Technology Page

Update: Secure Hotel Wi-Fi Sharing Over A Single VPN Tunnel For All Your Devices With A Raspberry Pi

WifipiBack in 2014, I came up with a project to use a Raspberry Pi as a Wifi access point in hotels and other places when I travel to connect all my devices to a single Internet connection which can either be over Wifi or over an Ethernet cable. As an added (and optional) bonus, the Raspberry Pi also acts as a VPN client and tunnels the data of all my devices to a VPN server gateway and only from there out into the wild. At the time I put my scripts and operational details on Github for easy access and made a few improvements over time. Recently I made a couple of additional improvements which became necessary as Raspbian upgraded its underlying source from Debian Wheezy to Debian Jessie.

One major change that this has brought along was that IPv6 is now active by default. For this project, IPv6 needs to be turned-off by default as most VPN services only tunnel IPv4 but happily return IPv6 addresses in DNS responses which makes traffic go around the VPN tunnel if the local network offers IPv6. For details see here and here. Another change was that the OpenVPN client is now started during the boot process by default if installed while this was not the case before and does so reliably. As a consequence I could put a couple of 'iptables' commands in the startup script to enable NATing to the OpenVPN tunnel interface straight way.

In other words, things are better than ever and v1.41 on Github now reflects those changes. Enjoy!

by mobilesociety at January 19, 2016 06:54 AM

January 17, 2016

Martin's Mobile Technology Page

My First IPv6 "First Call" To My Own Services At Home

A date to remember for me: On 15th January 2016 I contacted my web server at home running Owncloud and Selfoss for the first time over IPv6. From an end user's point of view no difference is visible at all but from a technical point of view it's a great "first time" for me, made even sweeter by the fact that my PC was not connected to another IPv6-enabled fixed line but connected via tethering to a smartphone with dual-stack IPv4v6 cellular connectivity.

The Thing With Dynamic IPv6 Addresses for Servers

And it's been a bit of a struggle to put together, this IPv6 stuff is not as straight forward as I hoped it would be. For a crash course I wrote back in 2009 have a look, here, here, here and here. The major challenge that I had to overcome for this to happen is to find a dynamic DNS service that can handle not only dynamic IPv4 addresses but also dynamic IPv6. Noip.com, where I host my domain and where I use the dynamic DNS service can handle IPv6 addresses for my domain but only static entries. The response to a support question how to do dynamic IPv6 addresses with them resulted in the little informative answer that they are working on it but no date has been announced by when this will be available. Hm, looking at their record, they seem to be working on IPv6 already since 2011 so I won't get my hopes up that this will happen soon. Is it really that difficult? Shame on you!

O.k., another dynamic DNS service I use is afraid.org and they do offer dynamic DNS with IPv6. Unfortunately, they have a DNS entry time to live (TTL) for IPv6 of 3600 seconds, i.e. 1 hour. This is much too long for my purposes as my IPv6 prefix changes once a day and any change must be propagated as quickly as possible and not only after an hour in the worst case. They offer a lower TTL with a paid account, but their idea and my idea of how much this may cost are too far apart. I've found a couple of other dynamic IPv6 services but they were also not suitable for me because they also had TTLs that were too long for my purpose.

One option I found that didn't have this restriction is dynv6.com. Their service is free and they do offer IPv4 and IPv6 dynamic DNS with a TTL of 1 minute but only for their own domain. Not an option for me either, I want to be reachable via my own domain. Kind of a deadlock situation...

But here's how I finally go it to work: The Domain Name System has a forwarding mechanism, the "Canonical Name Record" (CNAME). By using this mechanism, I can forward DNS queries for my domain that is hosted at noip.com (let's say it's called www.martin.com) to my subdomain at dynv6.com (let's say my domain there is called martin.dynv6.com). So instead of updating the DNS entry for www.martin.com when my IPv6 address changes once a day I can now update martin.dynv6.com which has a TTL of 1 minute while the CNAME forwarding at noip.com from www.martin.com to martin.dynv6.com in the DNS system is static and remains unchanged.

As a result the web page name in the browser remains "www.martin.com" but I can use my dynamic IPv6 record at dynv6.com where customer specific domains are not offered. Not ideal but it will do until NO-IP.com gets their act together.

by mobilesociety at January 17, 2016 12:41 PM