{"version":"https://jsonfeed.org/version/1","title":"Aaron Gustafson: Content tagged mobile","description":"The latest 20 posts and links tagged mobile.","home_page_url":"https://www.aaron-gustafson.com","feed_url":"https://www.aaron-gustafson.com/feeds/mobile.json","author":{"name":"Aaron Gustafson","url":"https://www.aaron-gustafson.com"},"icon":"https://www.aaron-gustafson.com/i/og-logo.png","favicon":"https://www.aaron-gustafson.com/favicon.png","expired":false,"items":[{"id":"https://www.aaron-gustafson.com/notebook/rebuilding-a-php-app-using-isomorphic-javascript-with-eleventy-and-netlify/","title":"✍🏻 Rebuilding a PHP App using Isomorphic JavaScript with Eleventy & Netlify","summary":"Back in the early days of the iPhone, I created tipr.mobi, a tip calculator that always produces a palindrome total. This is an overview of the minimal work I did to make it a modern web app that can run without a traditional back-end.","content_html":"

Back in the early days of the iPhone, I created Tipr, a tip calculator that always produces a palindrome total.1 This is an overview of the minimal work I did to make it a modern web app that can run without a traditional back-end.

\n

# What I had to work with

\n

The previous iteration of Tipr was built in my hotel room while I was on site doing some consulting for a certain Silicon Valley company. I was rocking a Palm Treo 650 at the time and that day a few of my colleagues had lined up to wait for the release of the very first iPhone. At the time, web apps were the only way to get an “app” on the iPhone as there was no SDK or even an App Store.

\n
\n

\"\"

\n
Tipr on the 1st generation iPhone, in the hands of Micah Alpern, June 2007.
\n
\n

I did a lot of PHP development back in the day, so armed with all of the mobile web development best practices of the day, I set about building the site and making it speedy. Some of the notable features of Tipr included:

\n\n

At the time, most of these approaches were very new. As an industry, we weren’t doing a whole lot to ensure peak performance on mobile because most people’s mobile browsers were pretty crappy. This was the heyday of Usablenet’s “mobile friendly” bolt-on and WAP. Then came Mobile Safari.

\n
\n

\"\"

\n
Tipr in the original Apple App Store, back when web apps were first class citizens on iPhone OS.
\n
\n

# A lot has changed since 2007

\n

The Tipr site has remained largely untouched since I built it in the Summer of 2007. That October, I added a theme switcher that made the site pink for October (Breast Cancer Awareness Month). I added a free text message-based interface using the then-free TextMarks service and a Twitter bot as well. But as far as the web interface went, it remained largely untouched.

\n

Here are a handful of things that have come to the web in the intervening years:

\n\n

Phew, that’s a lot! While I haven’t made upgrades in all these areas, I did sprinkle in a few, mainly to make it a true PWA and boost performance.

\n

# Moving from PHP to a “static” site

\n

Much of my work over the last few years has been in the world of static site generators (e.g., Jekyll, Eleventy). I’m quite enamored of Eleventy, having used it for a number of projects at this point. Since I know it really well, it made sense to use it for this project too. The installation steps are minimal and I already had a library of configuration options, plugins, and filters to roll with.

\n

While in the process of migrating to Eleventy, I also took the opportunity to

\n\n

I also swapped out the PHP logic that governed the pink color theme for a simple script in the head of the every page. Since the color change is an enhancement, rather than a necessity, I didn’t feel like it was something I needed to manage another way.

\n

The greatest challenge in moving Tipr over to a static site was setting up the tip calculation engine, which had been in PHP to ensure it would work even if JavaScript wasn’t available.

\n

# Migrating the core logic to isomorphic JavaScript

\n

When I originally built Tipr, JavaScript on the back-end wasn’t a thing. That’s why the core tip calculation engine was built in PHP. At the time, even XHR was in its infancy, so the fact that I could use PHP to do the calculations for both the server-side—for when JavaScript wasn’t available—and client-side—when it was—was pretty amazing.

\n

Today, JavaScript is ubiquitous across the whole stack, which made it the logical choice for building out the revised tip calculator. As with the original, I needed the calculation to work on the client side if it could—saving a round trip to the server—but to also have the ability to fall back to a traditional form submission if the client-side approach wasn’t feasible. That would be possible by having client-side JavaScript for the form itself, with the server-side piece handled by Netlify’s Edge Functions (integrated through Eleventy’s Edge plugin).

\n

From an architectural standpoint, I really didn’t want to have my logic duplicated in each place, so I began to play around with ensconcing the calculation logic in a JavaScript include, so I could import it into the form page itself and a JavaScript module that the Edge Function could use.

\n

You can view Tipr’s source on GitHub, but here’s a basic rundown of the relevant directories and files:

\n
netlify\n  edge-functions\n    tipr.js\nsrc\n  _includes\n    js\n      tipr.js\n  j\n    process.njk\n  index.html\nnetlify.toml
\n

# src/_includes/js/tipr.js

\n

This file contains the central logic of the tip calculator. It’s written in vanilla JavaScript with the intent that it would be understandable by the widest possible assortment of browsers out there.

\n

# src/index.html

\n

The homepage of the site is also home to the tip calculation form. Below the form is an embedded script element containing the logic for interacting with the DOM for the client-side version of the tip calculator. I include the logic at the top of that script:

\n
<script>\n  {% include \"js/tipr.js\" %}\n\n  // The rest of the JavaScript logic\n</script>\n
\n

# src/j/process.njk

\n

This file exists solely to export the JavaScript logic from the include in a way that it can be consumed by the Edge Function. It will render a new JavaScript file called “process.js” and turns the central processing logic into a JavaScript module that Deno can use (Deno powers Netlify’s Edge Functions):

\n
---\nlayout: false\npermalink: /j/process.js\n---\n\n{% include \"js/tipr.js\" %}\n\nexport { process };\n
\n

# netlify/edge-functions/tipr.js

\n

We define Edge Functions for use with Netlify in the netlify/edge-functions folder. To make use of the core JavaScript logic in the Edge Function, I can import it from the module created above before using it in the function itself:

\n
import { process } from \"./../../_site/j/process.js\";\n\nfunction setCookie(context, name, value) {\n  context.cookies.set({\n    name,\n    value,\n    path: \"/\",\n    httpOnly: true,\n    secure: true,\n    sameSite: \"Lax\",\n  });\n}\n\nexport default async (request, context) => {\n  let url = new URL(request.url);\n\n  // Save to cookie, redirect back to form\n  if (url.pathname === \"/process/\" && request.method === \"POST\")\n  {\n    if ( request.headers.get(\"content-type\") === \"application/x-www-form-urlencoded\" )\n    {\n      let body = await request.clone().formData();\n      let postData = Object.fromEntries(body);\n\n      let result = process( postData.check, postData.percent );\n\n      setCookie( context, \"check\", result.check );\n      setCookie( context, \"tip\", result.tip );\n      setCookie( context, \"total\", result.total );\n\n      return new Response(null, {\n        status: 302,\n        headers: {\n          location: \"/results/\",\n        }\n      });\n    }\n  }\n\n  return context.next();\n};\n
\n

What’s happening here is that when a request comes in to this Edge Function, the default export will be executed. Most of this code is directly lifted from Netlify’s Edge Functions demo site. I grab the form data, pass it into the process function, and then set browser cookies for each of the returned values before redirecting the request to the result page.

\n

On that page, I use Eleventy’s Edge plugin to render the check, tip, and total amounts:

\n
{% edge %}\n  {% set check = eleventy.edge.cookies.check %}\n  {% set tip = eleventy.edge.cookies.tip %}\n  {% set total = eleventy.edge.cookies.total %}\n  <tr id=\"check\">\n    <th scope=\"row\">Check&nbsp;</th>\n    <td>${{ check }}</td>\n  </tr>\n  <tr id=\"tip\">\n    <th scope=\"row\">Tip&nbsp;</th>\n    <td>${{ tip }}</td>\n  </tr>\n  <tr id=\"total\">\n    <th scope=\"row\">Total&nbsp;</th>\n    <td>${{ total }}</td>\n  </tr>\n{% endedge %}\n
\n

Side note: The cookies get reset using a separate Edge Function.

\n

# netlify.toml

\n

To wire up the Edge Functions, we use put a netlify.toml file in the root of the project. Configuration is pretty straightforward: you tell it the Edge Function you want to use and the path to associate it with. You can choose to associate it with a unique path or run the Edge Function on every path.

\n

Here’s an excerpt from Tipr’s netlify.toml as it pertains to the Edge Function above:

\n
[[edge_functions]]\nfunction = \"tipr\"\npath = \"/process/\"
\n

This tells Netlify to route requests to /process/ through netlify/edge-functions/tipr.js. Then all that was left to do was wire up the form to use that endpoint as its action:

\n
<form id=\"calc\" method=\"post\" action=\"/process/\"></form>
\n

# Isomorphic Edges

\n

It took a fair bit of time to figure this all out, but I’m pretty excited by the possibilities of this approach for building more static isomorphic apps. Oh, and the new site… is fast.

\n
\n
\n

Footnotes

\n
    \n

  1. Why a palindrome? Well, it makes it pretty easy to detect tip fraud because all restaurant totals will always be the same forwards & backwards. It’s a little easier than a checksum. ↩︎

    \n
    2. \n
\n
\n","social_text":"Wherein I migrate @tipr from a #PHP-based mobile web app to a #serverless #PWA.","url":"https://www.aaron-gustafson.com/notebook/rebuilding-a-php-app-using-isomorphic-javascript-with-eleventy-and-netlify/","tags":["mobile","progressive enhancement","progressive web apps","web development"],"image":"https://www.aaron-gustafson.com/i/posts/2023-02-03/hero.jpg","date_published":"2023-02-03T20:40:59Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/accessibility-features/","title":"🔗 Accessibility features","content_html":"

Interesting study of ~2 million Dutch smartphone users reveals how many people are using accessibility features on their phones (and which ones). It’s more than you think.

\n","social_text":"Interesting study of ~2 million Dutch smartphone users reveals how many people are using accessibility features on their phones (and which ones). It’s more than you think.","url":"https://www.aaron-gustafson.com/notebook/links/accessibility-features/","external_url":"https://appt.org/en/features","tags":["accessibility","mobile"],"image":"https://beta.appt.org/share.png","date_published":"2022-09-28T16:01:55Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/mobile-devs-making-the-same-security-mistakes-web-devs-made-in-the-early-2000s/","title":"🔗 Mobile Devs Making the Same Security Mistakes Web Devs Made in the Early 2000s","content_html":"

Anyone who’s seen one of my forms talks knows how adamant I am about this: you can never trust the client! Doesn’t matter if that client is a web browser or your mobile app.

\n","social_text":"Anyone who’s seen one of my forms talks knows how adamant I am about this: you can never trust the client! Doesn’t matter if that client is a web browser or your mobile app.","url":"https://www.aaron-gustafson.com/notebook/links/mobile-devs-making-the-same-security-mistakes-web-devs-made-in-the-early-2000s/","external_url":"https://www.bleepingcomputer.com/news/security/mobile-devs-making-the-same-security-mistakes-web-devs-made-in-the-early-2000s/","tags":["mobile","security"],"image":"https://www.bleepstatic.com/content/posts/2018/06/04/phone-apps.jpg","date_published":"2018-06-27T20:11:03Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/designing-for-everyone-building-great-web-experiences-for-any-device/","title":"📢 Designing for Everyone: Building Great Web Experiences for Any Device","summary":"In this session, I help you think about user experience from its foundation, so you understand what it means to build adaptive web experiences – whether in an app, in a browser, or beyond.","content_html":"

As the capabilities of the web platform advance, and the pervasiveness of web content proliferates, fundamental design principles are more important than ever: How do you enhance your experience as new capabilities become available in Microsoft Edge and other browsers? You’ve considered how your content looks and operates on mobile, but how does that design adapt to desktop devices? Is it usable via “headless” interfaces like screen readers or Cortana? Does your content adapt gracefully to the constraints of its environment?

\n

In this session, I help you think about user experience from its foundation, so you understand what it means to build adaptive web experiences – whether in an app, in a browser, or beyond. We’ll show you some of the newest capabilities coming to Microsoft Edge that let you build differentiated experiences on Windows 10. You’ll walk away practical, cross-platform code examples you can put to use in your projects today, and foundational principles to ensure that your projects are ready for anything.

\n","social_text":"In this session, I help you think about user experience from its foundation, so you understand what it means to build adaptive web experiences – whether in an app, in a browser, or beyond.","url":"https://www.aaron-gustafson.com/speaking-engagements/designing-for-everyone-building-great-web-experiences-for-any-device/","tags":["progressive web apps","mobile","performance","progressive enhancement","responsive web design"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2018-05-07T13:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/remember-palms-webos-maybe-not-but-apple-and-google-definitely-do/","title":"🔗 Remember Palm’s WebOS? Maybe not, but Apple and Google definitely do","content_html":"

WebOS… so far ahead of its time:

\n\n

And all of these features were available eight years ago!

\n","url":"https://www.aaron-gustafson.com/notebook/links/remember-palms-webos-maybe-not-but-apple-and-google-definitely-do/","external_url":"https://www.salon.com/2017/09/03/remember-palms-webos-maybe-not-but-apple-and-google-definitely-do/","tags":["user experience","mobile"],"image":"https://mediaproxy.salon.com/width/1200/https://media.salon.com/2017/09/pre.jpg","date_published":"2017-09-12T15:48:04Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/freedom-251-maker-says-2-lakh-rs-251-phones-ready-will-launch-cheapest-hd-led-tv-853073/","title":"🔗 Freedom 251 Maker Says 2 Lakh Rs. 251 Phones Ready, Will Launch 'Cheapest' HD LED TV","content_html":"

The world’s cheapest smartphone (251 Indian Rupees—less than US$4) is here. The specs:

\n\n

The rollout is slow and units are being sold at a loss, but still. This is amazing and the program, which is subsidized by the Indian government, will bring the web to millions who have not been able to access it previously.

\n","url":"https://www.aaron-gustafson.com/notebook/links/freedom-251-maker-says-2-lakh-rs-251-phones-ready-will-launch-cheapest-hd-led-tv-853073/","external_url":"https://gadgets.ndtv.com/mobiles/news/freedom-251-maker-says-2-lakh-rs-251-phones-ready-will-launch-cheapest-hd-led-tv-853073","tags":["Android","mobile"],"image":"https://cdn.ndtv.com/tech/images/gadgets/freedom_251_14_ndtv.jpg","date_published":"2016-07-13T14:12:42Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/google-chrome-android-data-saver-image-blocking/","title":"🔗 Chrome for Android can now save more data by blocking website images","summary":"Full circle, eh? The Blazer browser on my Palm Treo 650 had a “Lightning Mode” that switched off (optionally) images, CSS, and JavaScript.","content_html":"

Full circle, eh? The Blazer browser on my Palm Treo 650 (circa 2004) had a “Fast Mode” that switched off (optionally) images, CSS, and JavaScript.

\n","url":"https://www.aaron-gustafson.com/notebook/links/google-chrome-android-data-saver-image-blocking/","external_url":"https://www.theverge.com/2015/12/1/9827386/google-chrome-android-data-saver-image-blocking","tags":["Android","mobile","performance"],"image":"https://cdn.vox-cdn.com/thumbor/hH7yWh5QlKVwM0cvVwiAVl8aC8E=/0x122:2039x1269/1600x900/cdn.vox-cdn.com/uploads/chorus_image/image/47776499/chrome1_2040.0.0.jpg","date_published":"2015-12-01T19:42:27Z"},{"id":"https://www.aaron-gustafson.com/notebook/bringing-sanity-and-order-to-device-testing/","title":"✍🏻 Bringing Sanity and Order to Device Testing","summary":"With the constant onslaught of new devices, form factors, and considerations, it’s tempting to throw up our hands and find another line of work. Thankfully, however, all is not lost.","content_html":"

It seems like every other day the public is granted some new means of accessing the web. Some days it’s a new browser. Others it’s a new smartphone. Or a tablet. Or an e-reader. Or a video game console. Or a smartwatch. Or a TV. Or a heads-up display. Or a car. Or a refrigerator.

\n

I worked on one project where the client provided me with a spreadsheet detailing 1,400 different user agents that accessed the login screen for the m-dot site. In two days!

\n

As further evidence, consider the enlightening details of this post from Jason Samuels of the National Council on Family relations, a non-profit organization:

\n\n

That last stat blows my mind every time I read it. You can’t design for 200 different screens, let alone 1,000. It’s a fools errand. And don’t even think of trying to test on that many devices.

\n

And yet, here we are designing websites that can (and will) go anywhere. We need to thoroughly test because we can’t make any assumptions about the browsers and devices being used to access our content.

\n

Testing can be tedious, time consuming, and costly. Surely there’s a way to make it easier. There sure is: Instead of getting hung up on creating one experience that needs to be nearly identical on every browser, we can be smarter about how we build things and treat experience as a continuum.

\n

We can build websites that are both nimble enough to work on low powered devices over slow networks and smart enough to take advantage of advanced features and sensors when opportunity knocks.

\n

Wha?! We can have our cake and eat it too? Yes. Yes we can.

\n

# Start on Solid Footing

\n

When dealing with the insane proliferation of web-enabled devices and the great unknown of where our websites will go, it pays to take a step back and focus on what’s important. We need to ask ourselves two simple questions:

\n
    \n
  1. What is the purpose of this page, this form, this interface?
    2. \n
  2. What is the simplest way to realize that purpose?
    3. \n
\n

Then we need to build that first. Typically we’re talking text, some basic HTML, actual links to other pages, and forms that submit to a back-end of some sort. This is our minimum viable product and it will work anywhere.

\n

Then we can look for opportunities to enhance the experience, all while keeping that functional core at the center of the experience.

\n

We can use CSS to add visual hierarchy to the page, provide some visual interest, and adjust the layout to create a good reading experience on a wide range of screen sizes. We should start from the narrowest screen size we can imagine and let the content guide our breakpoint decisions.

\n

We’ll use JavaScript to give real-time feedback to our users. We’ll hijack forms and links to lazy load additional content or otherwise avoid full-page refreshes. Heck, we can even take over the entire page and convert it into a single page app.

\n

But we should never sacrifice the functional core.

\n

This approach to designing for the web is called progressive enhancement and it’s the number one tool for dealing with the one-two punch of older browsers and device proliferation.

\n

# Be Conservative in Your Delivery

\n

What makes progressive enhancement so helpful when it comes to dealing with this swirling mass of devices and browsers is that the core experience will always be available. There is nothing precluding our users from accessing it, even on a crappy WAP browser or a text-based browser like Lynx or even some no so far-future talking computer that only “sees” the web as text.

\n

In order to ensure we don’t accidentally deliver advanced features to less capable browsers like these, we just need to be smart about how we load stuff like CSS and JavaScript.

\n

Some basic CSS—think typography, color, etc.—will be usable by just about anyone, so we can put all that stuff in one CSS file (e.g., basic.css) and include it with a standard link. Then we can tuck all of our layout rules and other advanced CSS into a separate CSS file (e.g., advanced.css) that we link to with an associated media query.

\n
<link rel=\"stylesheet\" href=\"default.css\" media=\"all\" />\n<link rel=\"stylesheet\" href=\"advanced.css\" media=\"only screen\" />
\n

Any browsers that don’t understand media queries will ignore the second CSS file entirely and receive only the linear, mobile view. Easy peasy, and IE8 gets the mobile layout (a baseline level of support that is not likely to cause you any testing headaches).

\n

You can even take things a step further and use the @supports block within advanced.css to limit certain rule sets to only the browsers that support specific CSS features.

\n

Of course, CSS support issues are nothing compared to JavaScript, so sometimes it’s best not to deliver certain bits of JavaScript-based functionality to browsers that can’t handle it. This is where feature (and object) detection becomes incredibly useful:

\n
if (\"querySelector\" in document) {\n  // We can use querySelector!\n}
\n

You can also use inverted conditional comments to prohibit older versions of IE from getting JavaScript in the first place (which means you don’t even need to worry about debugging JavaScript there). Here’s an example that hides main.js from IE8 and below, but makes it available to IE9 on up and to every other non-IE browser.

\n
<!--[if gt IE 8]><!-->\n<script src=\"main.js\"></script>\n<!--<![endif]-->
\n

By being conservative in what we deliver to browsers we ensure the greatest level of support, but can still optimize for more advanced ones. This makes testing so much easier because we know older browsers will be okay with the basics and we aren’t trying to use JavaScript features unless we know they’re available.

\n

# Test, Test, Test

\n

Progressive enhancement helps us avoid a lot of rendering and scripting issues before we even get to the testing phase of a project, but eventually we do need to sit down and run our projects through their paces.

\n

In order to keep testing manageable during development, it’s best to test in one browser we know to have good web standards support. It will provide a basic gut-check for our work. Once we are pretty confident things are working as they should be, we can begin more thorough testing on a variety of browsers and devices.

\n

I personally keep several versions of each major browser on my laptop at any given time. I work on a Mac, so I typically have a few versions of Chrome, Firefox, and Opera lying around. You can get older versions of these browsers here:

\n\n

It’s near-impossible to get older versions of Safari running on modern versions of OS X, so I typically just have the latest version locally.

\n

For testing on Windows versions of said browsers, I typically have anywhere from 3-5 virtual machines running various Windows versions with their associated browser version and (typically) a copy of Chrome, Firefox, and Opera for good measure. The MS Edge Dev site offers free Windows VMs for download. If you’re just looking to get a gut-check in the latest and greatest from Microsoft, there’s also the Remote.IE service, which allows you to connect to a virtualized version of the browser.

\n

If you develop on Windows or Linux, you’ll need access to a Mac or you’ll have to rely on virtualization to test on that platform. I’ll discuss virtualization in a moment.

\n

Once you’ve thoroughly tested in the various desktop browsers, it’s time to take the deep dive into the world of devices. If you’re unsure where to begin, take a look at your analytics, but take them with a grain of salt. Analytics can lead you to make false assumptions. For example, if you see a low percentage of Blackberry users, could that be because your site just doesn’t work well in Blackberry so they don’t stick around (or come back)? Beware the self-fulfilling prophecy.

\n

If you have the budget, by all means pick up some devices to have on hand for testing. You can use tools like Adobe’s Edge Inspect, Vanamco’s Ghostlab, or Viljami Salminen’s Remote Preview (or a combination of all of the above) to synchronize browsing on a handful of devices. Some of these tools also allow for remote inspection of the device to debug CSS and JavaScript. Weinre (which Adobe Edge Inspect uses) and Vorlon.js also provide remote inspection functionality.

\n

If you are lucky enough to have one nearby, you should stop by your local open device lab (ODL) to run your tests. ODLs are free community resources, typically offered by a web design studio or an individual who happens to be sitting on a ton of devices. Someone at the ODL should be able to help you pick out devices to test on and introduce you to the testing tools they have available in the lab.

\n

If you don’t have an ODL nearby, you can also do some guerrilla-style testing in your local mobile phone or electronics store. Just make sure they have real devices… you won’t get far on the fake plastic ones.

\n

If none of these are options for you, there’s always virtualization. You can download and install emulators for a variety of mobile browsers and devices. Additionally, services like Browserstack and CrossBrowserTesting offer access to hundreds of virtual desktops and devices for a nominal fee.

\n

Virtualization will never give you the same experience as holding a real device in your hand. The performance is rarely the same and you don’t get any sort of feel for how the device responds to your input. I once stumbled on an Android 2.3 bug wherein generated content was being re-generated and re-inserted every time the device was rotated. I doubt I would have discovered that using an emulator. That said, emulators can help you get a rough idea of whether your interface works or not.

\n

Regardless of the means by which you procure your testing devices, try to cover a good cross-section. Pick some low-end ones, a couple older high-end devices, and handful of the latest flagships, and a wide variety of screen sizes and resolutions. Make sure you have good coverage in terms of operating systems too—the latest iOS and Android versions are a given, but make sure you have a Windows device or two, a few Blackberry options, and some older Android and iOS versions in the mix. Then throw in an oddball or two to see if your interfaces hold up.

\n

It’s important to bear in mind that we will never be able to give each user on each device exactly the same experience. We need to be okay with that—experience is a continuum. As long as our users can accomplish what they need to on our sites, they will be well-served.

\n

# Bonus Points: Embrace Patterns

\n

If we really want to make things easy on ourselves (and our team), we should consider building a pattern library before we build a single page of our website.

\n

Breaking our interfaces down into discrete, repeatable patterns (e.g., a label and form control, a tabbed interface, etc.) lets us look at each in isolation and test it that way too. Testing in isolation is far easier than trying to debug a page with a lot of moving parts.

\n

Gathering our patterns into a live, web-based pattern library allows anyone on our team to collect the patterns they need to build a given interface as easily as they’d assemble a plate at a smörgåsbord. And if we really want to streamline the building and testing process, we can even make the patterns importable into the live site so everything stays in sync.

\n

# Don’t Fear the Zombie Apocalypse

\n

With the constant onslaught of new devices, form factors, and considerations, it’s tempting to throw up our hands and find another line of work. The pace of advancement is so brisk, it’s just hard to keep up, let alone feel like we’re on top of where things are headed.

\n

Thankfully, however, all is not lost. By taking a step back and focusing on what matters, embracing experience as a continuum, and being deliberate in how (and when) we deliver certain features and functionality to browsers, we’ll head most issues off at the pass.

\n

This relieves some of the pressure (and frustration) from the testing process and frees us up to test on a wider variety of devices and browsers, which means we’ll be able to provide a solid experience for more users, no matter what marvel of technological wizardry they happen to be using at the time.

\n

Everybody wins.

\n","url":"https://www.aaron-gustafson.com/notebook/bringing-sanity-and-order-to-device-testing/","tags":["web design","mobile","devices","progressive enhancement","web development"],"date_published":"2015-06-05T13:56:03Z"},{"id":"https://www.aaron-gustafson.com/notebook/tips-for-surviving-googles-mobilegeddon/","title":"✍🏻 Tips for Surviving Google’s “Mobilegeddon”","summary":"Today is the day Google updates it algorithm to take into account mobile-friendliness. Here are a few tips that will help you embrace mobile without tearing your hair out.","content_html":"

Today is the day Google updates it algorithm to take into account mobile-friendliness. Here are a few tips that will help you embrace mobile without tearing your hair out.

\n

# 1. Embrace mobile-first CSS

\n

This is a quick win. I’ve done the mobile-first overhaul on a number of existing sites over the last few years and the best strategy I’ve found is this:

\n
    \n
  1. Create two CSS files. Name the first something like “basic.css” and link to it with media="all". Name the second something like “advanced.css” and link to it with media="only screen".
    2. \n
  2. Move all of your existing desktop-only CSS into advanced.css and wrap the rules in a media query corresponding to your design width (e.g. @media (min-width:60em) for a 960px max width).
    3. \n
  3. Open a page from your site in a new browser window and make it as small as possible. Move any basic typographic and color styles from advanced.css to default.css and refresh the page. How does it look? Make the browser wider. Still acceptable? Awesome! This is the CSS you’ll serve to older browsers that don’t understand media queries and it forms the basis of your larger screen styles.
    4. \n
  4. Shrink the browser back down to the smallest it can go and create a breakpoint for that size in advanced.css (e.g. @media (min-width:10.5em) if you want to small target devices like the Pebble). Move any styles you want applied in this scenario from your “full screen” breakpoint and add any new rules you need to make things look good.
    5. \n
  5. Increase the browser width until the layout looks odd, then make a new breakpoint and move in or add the necessary styles.
    6. \n
  6. Rinse & repeat until you get up to the “full screen” layout.
    7. \n
  7. Move your print styles—you do have print styles, right?—into default.css and wrap them in a print @media block.
    8. \n
\n

For another approach to responsive retrofitting, check out this piece from Ben Callahan.

\n

# 2. Focus on key tasks

\n

Every page has a purpose. If it doesn’t, you don’t need it. Find the page’s purpose and make that the focus. Eliminate distractions and reduce the amount of friction a user encounters when trying to accomplish the task.

\n

If company or client politics preclude you from getting rid of all distractions on a page, consider a lazy-loading strategy to bring them in with JavaScript only when there is more screen real estate.

\n

# 3. Get smarter about images

\n

Images are great, but they often comprise the majority of a web page’s bulk. To slim things down, first consider whether a given image is actually needed. If it isn’t, get rid of it. If it offers an enhancement, but isn’t crucial, consider lazy-loading it after page load. If the image is really important, use srcset and sizes (or the picture element) to deliver the smallest and yet most appropriate image to your users, based on their device.

\n

# 4. Embrace the continuum

\n

As designers and developers, we often try to control everything. But we have to realize that we can’t control everything on the Web. People on different devices have different capabilities and considerations. They will need your website to be flexible enough to allow them to accomplish their goals no matter what.

\n

Understanding that is key to building experiences that move seamlessly across devices. You know, progressive enhancement. It’s key to embracing the Web for all of its inherent web-iness.

\n
\n

And there you have it: 4 simple, but effective guidelines for creating awesome websites that will fair well under Google’s new algorithm. And guess what: Your users will benefit too.

\n","url":"https://www.aaron-gustafson.com/notebook/tips-for-surviving-googles-mobilegeddon/","tags":["web design","mobile","progressive enhancement"],"date_published":"2015-04-21T13:10:12Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/adaptive-designs-across-devices/","title":"📢 Adaptive Designs Across Devices","summary":"Progressive Enhancement, the heart of Adaptive Design, makes the life of a design less complicated. Aaron and Jenn will show you how to create a solid core and build out to craft amazing user experiences that work regardless of devices capabilities or deficiencies.","content_html":"

Progressive Enhancement, the heart of Adaptive Design, makes the life of a design less complicated. Aaron and Jenn will show you how to create a solid core and build out to craft amazing user experiences that work regardless of devices capabilities or deficiencies.

\n

Practical takeaways from this workshop:

\n\n","social_text":"Progressive Enhancement, the heart of Adaptive Design, makes the life of a design less complicated. Aaron and Jenn will show you how to create a solid core and build out to craft amazing user experiences that work regardless of devices capabilities or deficiencies.","url":"https://www.aaron-gustafson.com/speaking-engagements/adaptive-designs-across-devices/","tags":["progressive enhancement","mobile","user experience"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2015-04-13T13:00:00Z"},{"id":"https://www.aaron-gustafson.com/appearances/podcasts/2015-01-26-cross-device-adaptive-design/","title":"🎧 Cross-device Adaptive Design","content_html":"

Jenn Lukas and I talked to Jared about responsive web design, progressive enhancement, and mobile in advance of our talk and workshop at UXIM in April.

\n","url":"http://archive.uie.com/brainsparks/2015/01/26/aaron-gustafson-jenn-lukas-cross-device-adaptive-design/","tags":["responsive web design","progressive enhancement","mobile"],"date_published":"2015-01-26T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/an-onslaught-of-low-cost-smartphones/","title":"✍🏻 An Onslaught of Low-cost Smartphones","summary":"It seems every week we are seeing more and more low-cost devices being launched in an effort to connect the unconnected. Here’s why that maters to you.","content_html":"

It seems every week we are seeing more and more low-cost devices being launched in an effort to connect the unconnected. For instance, this past week saw the announcement of two new entries in the Microsoft Lumia line, the 435 and the 532, and the announcement of Samsung’s first Tizen phone, the Z1.

\n

The two Lumia devices are the cheapest Windows Phone offerings to date: The Lumia 435 is €69 (about US$80) and the Lumia 532 is just slightly more expensive at €79 (about US$94). By comparison, the Lumia 535 was the previous low-cost Windows Phone winner at US$135. And Samsung’s Z1, which is aimed at the Indian market, runs a mere Rs 5,700 (roughly US$92).

\n

Now if you’ve read this far, you are probably wondering why this matters. Well, spec-wise, many of these lower-end devices are far from what we are used to. All of these devices are running a resolution of 800×480. And their processing speeds are slower than the device you likely have in your pocket. But they are all far cheaper too. And remember that people in China and India have far less disposible income than we do.

\n
\n

\"A

\n
\n

If you only earned US$295 a month, a US$799 smartphone would likely be out of the question.

\n

As Web designers and developers, we need to expose ourselves to the Web as others see it. This is why we need to view our sites and applications on lower-end devices and over lower-speed—2G, 3G, etc.—connections. Only by testing our wares can we truly ensure our content and services are available and accessible by anyone, anywhere, on any device. You know, the vision for the Web.

\n

Of course you probably don’t have the budget to purchase a bunch of devices, no matter how cheap they are. So how do you test on them? Visit a local Open Device Lab like the one we have here in Chattanooga. Or if you don’t have one near you, consider getting together with some colleagues and starting an ODL in your area.

\n","url":"https://www.aaron-gustafson.com/notebook/an-onslaught-of-low-cost-smartphones/","tags":["mobile","web design","devices"],"date_published":"2015-01-15T16:58:11Z"},{"id":"https://www.aaron-gustafson.com/notebook/webos-is-back/","title":"✍🏻 webOS is Back","summary":"It may have been the laughing stock in the app development community, but I’ve always had a soft spot in my heart for webOS. And now it’s back!","content_html":"

You may not remember it, but Palm’s groundbreaking—yes, I said groundbreaking—operating system, webOS, has been resuscitated yet again. This time by LG.

\n

For those of you who may have missed out on webOS in the past, here’s a primer: webOS was developed by Palm and debuted on the Palm Pre in 2009. It was the first “HTML5-based” operating system. Yes you read that right: the OS was built on HTML, CSS, and JavaScript. In 2009. Six. Years. Ago.

\n

Applications for webOS were written using the front-end Web stack, with the JavaScript application logic tied into the device via the Mojo—and later Enyo—JavaScript application framework. Though novel at the time, this concept has since taken off in the intervening years. Windows, Firefox OS, and countless “unified” app development platforms have embraced the front-end Web stack as a means of building software.

\n

webOS also supported multitasking, which was not common back then. And to make it easy to manage, webOS introduced the brilliant card metaphor for viewing and switching between running applications. Apple, of course, ripped that idea off for iOS 7. If you dig that feature on your iPhone you have Palm to thank.

\n

Sadly, Palm usage was on the decline when webOS debuted so operating system never really took off. Eventually Palm was engulfed by HP, which launched the ill-fated HP TouchPad. It too failed to gather any steam and we thought webOS was dead (despite many proclamations to the contrary from well-meaning folks at HP).

\n

In 2013 HP announced it was selling parts of webOS to LG for use in smart TVs. It was a glimmer of hope for the beleaguered OS. And now, not only do we have webOS based smart TVs, but LG’s new smart watches are sporting the OS as well. And LG has not ruled out bringing it back for a phone either.

\n

I’m happy to see webOS sticking around. It may have been the laughing stock in the app development community back in the day, but I’ve always had a soft spot in my heart for it.

\n","url":"https://www.aaron-gustafson.com/notebook/webos-is-back/","tags":["mobile","devices","web design"],"date_published":"2015-01-08T15:17:09Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/reflecting-on-the-revamped-sherpa/","title":"📄 Reflecting on the Revamped Sherpa","content_html":"

I turn the spotlight on the Sherpa site and walks through some of the choices we made for the mobile-first overhaul of this site.

\n","url":"http://webstandardssherpa.com/reviews/reflecting-on-the-revamped-sherpa/","tags":["mobile","web design"],"date_published":"2014-10-28T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/native-vs-stylable-tug-of-war/","title":"✍🏻 The “Native” vs. “Stylable” Tug of War","summary":"In his astute post “‘Native experience’ vs styling select boxes”, Bruce Lawson correctly identified a common tension in the web world: wanting better form controls vs. wanting to throw away what the browser does. Here are my thoughts.","content_html":"

In his astute post “‘Native experience’ vs styling select boxes”, Bruce Lawson correctly identified a common tension in the web world:

\n
\n

But why this urge to re-style page elements that end-users are familiar with? … Or is it that we love native look and feel, except when we don’t?

\n
\n

Speaking as the guy who not only wrote JavaScript to help me create an accessible select element alternative, but who also made it the focus of a case study (PNG, 128kB) in AdvancED DOM Scripting, I am fully aware of the desire to have it both ways. I have not often seen the desire for both in a single individual, but it does happen in one particular instance occasionally.

\n

Based on my own experience, I see the following arguments in favor of changing the display of a browser-delivered UI control quite often:

\n
    \n
  1. It doesn’t look good to me.
    2. \n
  2. It is not “on brand”.
    3. \n
  3. It clashes with our brand’s color scheme.
    4. \n
  4. We want the web experience to feel like a platform-specific app.
    5. \n
  5. It doesn’t behave how we think it should.
    6. \n
\n

(n.b. Browsers have done a pretty good job reducing the amount of color and the overall visual strength used in their UI controls to help them better blend in with a wide variety of designs, so clashes as mentioned in #3 happen far less often than they did nearly a decade ago.)

\n

As the weathered, battle tested (and, admittedly, somewhat jaded) front-end dev that I am, I typically push back with one or more of the following:

\n

# In Addressing Desired Design Changes

\n

In terms of aesthetics (addressing arguments 1, 2, and 3), I understand where you’re coming from. Browser-delivered UI controls are not the most appealing things, but they are familiar to your users. A select box they see on your site that looks like the one they see on Wikipedia or their banking site will be immediately recognizable. Sure, the looks and feel may differ from browser to browser, but most people use only a small number of browsers throughout the day—at work, at home, on their device—and if you want to ensure the design of a form control feels “right” in the browser they are using, sometimes it’s best to let go of that control.

\n

# In Addressing OS Parity

\n

I can understand the desire to have a form control in a web page look and feel like the same (or a similar) control within the operating system (argument 4), but I am not sure that’s a rabbit hole you want to go down. Here’s why: Achieving exact design and functional parity between a platform-specific control and a web control quite often requires extra markup, a bunch of CSS, and a bit of JavaScript. Anything is achievable with unlimited time and budget, so it’s completely doable, but it would be good to estimate the cost to see if you still think it is a worthwhile endeavor.

\n

Assuming it is, we then have the question of which operating system to model the control after. Or maybe you want to offer a different take on the control based on the operating system your user is using. In that case, we may need to multiply the original estimate by the number of operating systems you want to support. But it’s worth noting that, in the Android world, different device manufacturers often “skin” the operating system to look different from other ones. Sometimes they even do it on a device-by-device basis. We’ll need to figure out which ones you want to include in your platform-like control matrix and multiply the estimate accordingly.

\n

Then there’s maintenance. We’ll need to test these platform-like controls on each of their corresponding platforms and test the script that determines which experience gets delivered to which device to make sure we’re not accidentally sending the wrong experience. We’ll also need to test the delivery script on every other browser in our test matrix to ensure it is not causing issues there.

\n

What should we do when a new operating system version is rolled out? iOS, for example, has made radical shifts in the design of their platform-specific controls in each major release. We’ll probably want to create unique versions of the control for each version of each OS we support and we’ll need to keep tabs on upgrades so we don’t end up confusing our users if they visit our site in iOS 7 and have a control that looks like it’s from iOS 6. We’ll need to add the number of OS versions into the multiplier as well.

\n

Ok, and finally: How many controls did you want to apply this approach to again?

\n

Or we could use the browser-delivered form control and it will just work.

\n

# In Addressing Altered Behavior

\n

I completely agree that not all browser-delivered UI controls work exactly how I would like, but there are several risks in changing the expected behavior.

\n

First of all, there’s the possibility we could actually end up making the interface more confusing or that the change in behavior might not be exactly what our user’s wanted (either based on what they are used to or our mental model not aligning with theirs). In order to rule out these issues, we should run a few rounds of usability tests. These could be quick café tests or more formal studies depending on the budget.

\n

Assuming our tests go well, we will need to maintain this code and do all of the requisite browser testing. And potentially upgrade our code as new browsers and browser versions come out. Depending on the complexity of the code, this could become a large requirement, but if it is ultimately in the service of making the web a better, more usable interaction environment, it could be worth it.

\n

For what it’s worth, if we go this route and are successful, we should consider getting involved in the spec-writing process at the W3C or WhatWG. We should contribute our recommended changes back to the community and share what we learned. If we make a compelling argument, perhaps our idea will become part of some future standard and we can taper off our browser testing when the change lands in the platform.

\n
\n

As you can probably tell, I’m not a really big fan of changing existing controls as I feel it can amount to a wasted effort. That said, if there are design improvements to be made—“design” in the true sense: being about how usable something is, not just how aesthetically-pleasing it is to someone (e.g. improving contrast, making the control more intuitive, etc.)—I’m willing to accept the change as something we should do and then work to make sure that change has been vetted and, if successful, given away for inclusion in other projects. If it solves a major issue on the web, I want to give that change every opportunity to make it into the appropriate spec by talking to the appropriate folks about it both in-person, in blog posts, and on the appropriate mailing list. If the change solves a problem in a specific browser, I want to see it incorporated into said browser and will file a bug report and try to build momentum around it by engaging the community.

\n

Anyway, that’s my general position on augmenting browser-delivered UI controls. What are your thoughts on the topic?

\n

Note: I no longer use “native” in this context, but it remains in quoted material.

\n","url":"https://www.aaron-gustafson.com/notebook/native-vs-stylable-tug-of-war/","tags":["web design","browsers","design","mobile"],"date_published":"2014-07-17T12:21:47Z"},{"id":"https://www.aaron-gustafson.com/notebook/searching-for-the-right-size/","title":"✍🏻 Searching for the “Right Size”","content_html":"

This recent piece from Wired attributes dwindling tablet sales to cannibalization from larger mobile phones (aka “phablets”) which are nearly as big as 7-8˝ tablets:

\n
\n

Aside from the ability to make a phone call, the difference between a phone and a tablet comes down to 1.5 inches or less. … But the real issue is device makers are running out of good arguments for why these ever more subtle size gradations matter. After a point, the differences come down to personal preference rather than any meaningful new use case. As phones and tablets converge into this tight window, slightly bigger phones could accelerate the decline in tablet demand.

\n
\n

Personally, I’m not sure it matters. We’re in the midst of one big experiment being run by the device manufacturers. We’re in the scattershot. The industry is feeling out the “right” screen size (or sizes) that most people want to use and we are (in large part) footing the bill.

\n","url":"https://www.aaron-gustafson.com/notebook/searching-for-the-right-size/","tags":["mobile"],"date_published":"2014-07-11T00:38:16Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/designing-across-devices-with-progressive-enhancement/","title":"📢 Designing Across Devices with Progressive Enhancement","summary":"Today, browsers are just one of the issues among a sea of considerations like accessibility, device compatibility, and responsive or adaptive design. And with new techniques and devices coming out daily, it’s easy to feel overwhelmed.","content_html":"

Remember the good old days when getting IE6 to “work” was our main worry?

\n

My, we’ve come a long way, baby.

\n

Today, browsers are just one of the issues among a sea of considerations like accessibility, device compatibility, and responsive or adaptive design. And with new techniques and devices coming out daily, it’s easy to feel overwhelmed.

\n

Fortunately, I know how to wrangle all of these elements using progressive enhancement. With his practical approach, he designs for humans on any spectrum ­­ with and without javascript enabled—and soon enough, you will, too.

\n

Create experiences without technological constraints

\n\n

Stop assuming users are just like you

\n\n

Make a content­-first approach work

\n\n

Establish a solid strategy for planning

\n\n

Join us for this seminar if you:

\n\n

If you’re trying to create a better web ­­ and are open to rethinking how you approach designing for any interface, then you need to watch Aaron’s seminar.

\n","social_text":"Today, browsers are just one of the issues among a sea of considerations like accessibility, device compatibility, and responsive or adaptive design. And with new techniques and devices coming out daily, it’s easy to feel overwhelmed.","url":"https://www.aaron-gustafson.com/speaking-engagements/designing-across-devices-with-progressive-enhancement/","tags":["accessibility","inclusive design","mobile","progressive enhancement","responsive web design"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2013-11-21T17:30:00Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/qanda-apple-products-and-mobile-assumptions/","title":"📄 Q&A: Apple Products and Mobile Assumptions","content_html":"

I think there is a tendency in our industry to focus on the latest and greatest technology, which many would say includes Apple products.

\n","url":"http://webstandardssherpa.com/ask-the-sherpas/apple-products-and-mobile-assumptions","tags":["mobile","industry","web design","web development"],"date_published":"2013-01-10T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/slides-from-my-talk-at-how-interactive/","title":"✍🏻 Slides from my talk at HOW Interactive","summary":"These last two days have been a bit of a whirlwind, but I have had a great time meeting and talking to the attendees (and other speakers) here at the HOW Interactive conference in San Francisco . I gave my talk yesterday on progressive…","content_html":"

These last two days have been a bit of a whirlwind, but I have had a great time meeting and talking to the attendees (and other speakers) here at the HOW Interactive conference in San Francisco. I gave my talk yesterday on progressive enhancement (of course) and how it can make designing and devloping for mobile a little more sane. Here are the slides (which you can also see and download on Slideshare) form that talk:

\n
\n

I also provided attendees with a reading list. It’s the one I developed for a private training a few weeks ago with Jeremy and one which I will continue to update as I find more useful resources I want to share.

\n","url":"https://www.aaron-gustafson.com/notebook/slides-from-my-talk-at-how-interactive/","tags":["progressive enhancement","presentations","mobile"],"date_published":"2012-10-30T21:57:27Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/master-mobile-navigation/","title":"📄 Master Mobile Navigation","content_html":"

Users want content. But first you need to ensure they can locate it, whatever their device type. In this article, I discuss top strategies to adapt your navigation to smaller screens.

\n","url":"http://www.creativebloq.com/mobile/master-mobile-navigation-2135807","tags":["mobile","user experience","progressive enhancement","HTML","CSS","responsive web design"],"date_published":"2012-09-15T00:00:00Z"}]}