![\"\"](\"https://www.aaron-gustafson.com/i/posts/2015-06-22/01.jpg\")
Do you want to build web pages but have no prior experience? This friendly guide is the perfect place to start. You'll begin at square one, learning how the web and web pages work, and then steadily build from there. By the end of the book, you'll have the skills to create a simple site with multicolumn pages that adapt for mobile devices.
\n","url":"https://www.oreilly.com/library/view/learning-web-design/9781098137670/","tags":["accessibility","CSS","HTML","JavaScript","progressive enhancement","responsive web design","web design","web development","web standards"],"date_published":"2025-05-01T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/request-with-intent-caching-strategies-in-the-age-of-pwas/","title":"đ Request with Intent: Caching Strategies in the Age of PWAs","content_html":"Caching media files, especially images, seems like an obvious way to improve performance, but should we? To provide a more performant UX without abusing usersâ network connections or hard drives, I put a spin on classic best practices, experiment with media caching strategies, and share smart Cache API tricks.
\n","url":"https://alistapart.com/article/request-with-intent-caching-strategies-in-the-age-of-pwas/","tags":["progressive web apps","responsive web design","performance"],"date_published":"2019-11-21T00:00:00Z"},{"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?
\nIn 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/speaking-engagements/advanced-design-methods/","title":"đ˘ Advanced Design Methods","summary":"Two days of advanced design & layout workshops covering responsive design, progressive enhancement, performance, flexbox, css grid, and more.
","content_html":"Two days of advanced design & layout workshops covering responsive design, progressive enhancement, performance, flexbox, css grid, and more.
\n","social_text":"Two days of advanced design & layout workshops covering responsive design, progressive enhancement, performance, flexbox, css grid, and more.","url":"https://www.aaron-gustafson.com/speaking-engagements/advanced-design-methods/","tags":["web design","accessibility","CSS","JavaScript","progressive enhancement","responsive web design"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2017-11-15T00:09:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/planning-adaptive-interfaces-the-workshop/","title":"âđť Planning Adaptive Interfaces: The Workshop","summary":"For the last few years Iâve been running a workshop alternately titled âPlanning Adaptive Interfacesâ or âBeyond Responsiveâ, depending on the conference. Itâs been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.
","content_html":"For the last few years Iâve been running a workshop alternately titled âPlanning Adaptive Interfacesâ or âBeyond Responsiveâ, depending on the conference. Itâs been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.
\nI think we all recognize how much Ethanâs seminal article âResponsive Web Designâ (and his follow-up book) shook up our industry. It changed the way we look at visual design and kindled (or in some cases re-kindled) an interest in catering an experience to mobile devices. But simply incorporating responsive designâs three core strategiesâfluid grids, flexible media, media queriesâis not the goal; meeting our userâs needs is. Responsive design is not an end in itself⌠itâs just the beginning.
\nWe need to embrace the heterogenous nature of the Webâmyriad connected devices with vastly different screen sizes (if they even have screens), network connectivity, and capabilities in use by countless individuals, each with their own special needsâand craft experiences that will work anywhere at any time. We need to build robust systems that adapt in ways far beyond aesthetics. I designed this workshop to explore the rich variety of use cases that often get overlooked in the course of building web projects and to show how we can begin considering them as early as possible.
\nWhen I was starting out, I gave âworkshopsâ that basically amounted to a half-day or (worse) a full day for folks to listen to me blather on about one topic or another. People liked them, but I wouldnât call them fun. And, in hindsight, I question how much value people got from an extended survey of whatâs possible without the opportunity to put that knowledge to use. Workshops should encourage attendees to get their hand dirty.
\nI kick this workshop off with a relatively brief discussion of the considerations that we should be aware ofâbeyond screen size and pixel density. I also provide examples of how to adapt interfaces so they rise to meet our customersâ needs. Then I throw out a list of common interface patternsâmodals, tabs, etc.âand turn the floor over to the attendees, asking them to build small teams that each examine a single pattern in detail with these considerations in mind. They then spend the rest of the workshop planning out how that interface would adapt to consider factors like accessibility, screen dimensions, device capabilities, JavaScript availability, and so on. All the while, I circulate among the groups, asking and answering questions, pressing them to go a little further with each iteration. Some teams sketch, some prototype, and all spend a lot of time debating, which is awesome!
\nI leave the last hour or so for a group discussion of what each teamâs accomplished. It gives them a chance to talk through their approach, what they learned, what their pain points were, and how they overcame them. Not does it celebrate their work, but it helps the other attendees discover novel ways to approach these common UI constructs.
\nItâs been a blast and I have learned so much from the teams Iâve coached. Each workshop is completely different because each group of attendees is completely different. Iâve run it with groups ranging from 12 to 120, for internal teams at large companies to mixed audiences from all over the world. Everyone who has attended one of these workshops has brought a unique perspective and helped us all get better at our jobs. Thatâs been one of the best parts of this experience for me.
\nIf a workshop like this sounds up your alley, Iâll be giving it a few more times in 2016. Your next opportunity will be at EnhanceConf in London in early March. Later in the year, Iâll be giving it as part of Sparkboxâs Build Right: Maker Series. Iâd love the opportunity to work with you if you can make it!
\n","url":"https://www.aaron-gustafson.com/notebook/planning-adaptive-interfaces-the-workshop/","tags":["conferences","progressive enhancement","responsive web design","pattern libraries","empathy","Adaptive Web Design"],"date_published":"2016-02-21T23:56:05Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/beyond-responsive/","title":"đ˘ Beyond Responsive","summary":"Responsive design is not an end in itself⌠itâs just the beginning.
","content_html":"Responsive web design has taken our industry by storm and with good reason: it helps us improve our reach with less effort. But incorporating responsive design is not the goal, meeting your userâs needs is. Responsive design is not an end in itself⌠itâs just the beginning.
\nEmbracing the heterogenous nature of the webâthe myriad web-enabled devices with vastly different dimensions, screen sizes, networks, and capabilities in use by countless individuals, each with their own special needsâallows you to craft experiences that will work anywhere at any time. It also helps you build robust systems that adapt in ways far beyond aesthetics. This talk will cover a number of considerations that you should be aware of, beyond screen size and pixel density, and provide examples of how to adapt your interfaces so they rise to meet your usersâ needs.
\n","social_text":"Responsive design is not an end in itself⌠itâs just the beginning.","url":"https://www.aaron-gustafson.com/speaking-engagements/beyond-responsive/","tags":["responsive web design","progressive enhancement","web design"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2015-08-12T13:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/where-do-we-go-from-here/","title":"âđť Where Do We Go From Here?","summary":"I had the great pleasure of delivering the closing keynote for the final Responsive Day Out. Hereâs what I had to say.
","content_html":"I had the great pleasure of delivering the closing keynote for the final Responsive Day Out. Hereâs what I had to say.
\nToday has provided an amazing tour of the world of responsive design. Weâve seen how to level-up our workflows and processes. Weâve learned new ways to improve the accessibility of our products. Weâve grappled with modern CSS and HTML capabilities that help us embrace the hugely variable display sizes that swirl and whirl around us.
\nWeâve explored the future of modular code and browsersâ capacity for working without network connectivity. And weâve even taken a trip into the possible future of where the web might go.
\n
Weâve come a long way since Ethanâs article, fluid grids, flexible media, and media queries. Those three tenets sowed a seed that has grown and flourished as we have come to better understand the implications of device proliferation. Weâve seen that the web is capable of going anywhere and doing pretty much anything.
\nI would argue that âResponsive Web Designâ was the first article that really managed to capture the concepts that John Allsopp had discussed so many years before in âA Dao of Web Designâ and distilled them into something the design and development community could really sink their teeth into. It provided a concrete example of the webâs ability to flex and mold itself into whatever shape it needed to take on.
\nIt was the first time many designers had come to terms with the idea that âexperienceâ was not some monolithic thing.
\nSure, many of us in the web standards community had been talking the talk and walking the walk with regard to progressive enhancement. And we were gaining converts, but progress was slow. Ethan demonstratedâdirectly and succinctlyâwhat the progressive enhancement of visual design could look like.
\nProviding an identical experience for each and every human being that tries to access our sites would be impossible. There are simply far too many factors to consider. Weâve got screen size, display density, CPU speed, amount of RAM, sensor availability, feature availability, interface methods ⌠breathe ⌠operating system type, operating system version, browser type, browser version, plug-ins installed, network speed, network latency, network congestion, firewalls, proxies, routers, and probably a dozen other factors my mind is incapable of plucking amid the whirlwind of technical considerations.
\nAnd that doesnât even consider our users.
\nWhen it comes to the people we need to reach for our work to actually matter, we have to consider literacy level, reading acumen, level of domain knowledge, cognitive impairments like learning disabilities and dyslexia, attention deficit issues, environmental distractions, vision impairment, hearing impairment, motor impairment, how much they understand how to use their device, how much they understand how to use their browser, how well-versed in common web conventions they are, and a ton of other âhuman factorsâ.
\nEvery person is different and everyone comes to the web with their own set of special needs. Some are always with them, blindness for example. Others are transient, like breaking your mousing arm. Still others are purely situational and dependent on the device you are using at the time and its technical capabilities or constraints.
\nTrying to devise one monolithic experience for each and every person to have in every context that considers every factor would be impossible. And yet, Sir Tim Berners Lee had a vision for a web that was capable of going anywhere. Was he insane?
\nSir Timâs vision for the web was that content could be created once and accessed from anywhere. Disparate but related pieces of âhypermediaâ scattered across the globe could be connected to one another via links. Moreover, they would be retrievable by anyone on any device capable of reading HTML. For free.
\nUltimately, Sir Tim envisioned universal accessibility.
\nFor a great many of us, ensuring our websites are accessible is an afterthought. We talk a good game when it comes to âuser centeredâ this or that, but often treat the word âaccessibilityâ as a synonym for âscreen readerâ. Itâs so much more than that. âAccessibilityâ is about people. People consume content and use interfaces in many different ways, some similar and some quite dissimilar to how we do it.
\nSure, people with visual impairments often use a screen reader to consume content. But they might also use a braille touch feedback device or a braille printer. They probably also use a keyboard. Or they may use a touchscreen in concert with audio cues. Or they may even use a camera to allow them to âreadâ content via OCR and text-to-speech. And yes, visual impairment affects a decent percentage of the populace (especially as we age), but it is only part of the âaccessibilityâ puzzle.
\nThe contrast between text and the background is an important factor in ensuring content remains readable in different lighting situations. Color choice is an accessibility concern.
\nThe language we use on our sites and in our interfaces directly affects how easy it is for our users to understand what we do, the products we are offering, and why it matters. It also affects how we make our users feel about themselves, their experience, and our companies. Language is an accessibility concern.
\nThe size of our web pages has a direct effect on how long our pages take to download, how much it costs our customers to access them, and (sometimes) even whether or not the content can be reached. Performance is an accessibility concern.
\nI could keep going, but Iâm sure you get the point.
\nAccessibility is about providing good experiences for everyone, regardless of physical or mental abilities, gender, race, or language. It recognizes that we all have special needsâphysical limitations, bandwidth limitations, device limitationsâthat may require us to experience the same interface in different ways.
\nWhen I visit a website on my phone, for example, I am visually limited by my screen resolution (especially if I am using a browser that encourages zooming) and I am limited in my ability to interact with buttons and links because I am browsing with my fingertips, which are larger and far less accurate than a mouse cursor.
\nOn a touchscreen, I may need the experience to be slightly different, but I still need to be able to do whatever it is I came to the site to do. I need an experience, but moreover I need the appropriate experience.
\nEmbracing the reality that experience doesât need to be just one thing will help us reach more people with fewer headaches. Experience canâand shouldâbe crafted as a continuum. This is progressive enhancement: We start with a baseline experience that works for everyoneâcontent, real links, first generation form controls, and forms that actually submit to the server. Then we build up the experience from there.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2015-06-22/02.gif\")
Your browser supports HTML5 form controls? Great! Youâll get a better virtual keyboard when you go to type your email address. You can use CSS? Awesome, let me make that reading experience better for you. Oh, you can handle media queries! Let me adjust the layout so those line lengths are a little more comfortable. Wow, your browser supports Ajax?! Here let me load in some teasers for related content you might find interesting.
\nImagine sitting down in a restaurant only to have the waiter immediately bring you a steak. But youâre a vegetarian. You ask if they offer something you can eat and they politely reply Oh Iâm sorry, meat is a requirement. Why donât you just eat meat? Itâs easy! Youâre really missing out on some tasty food. No waiter who actually cares about your experience would do that.
\nAnd yet weâas an industryâdonât seem to have any problem telling someone they need to change their browser to accommodate us. Thatâs just wrong. Our work is meaningless without users. We should be bending over backwards to attract and retain them. This is customer service 101.
\nThis comes back to Postelâs law, which Jeremy often recounts:
\n\n\nBe conservative in what you do, be liberal in what you accept from others.
\n
We need to be lax when it comes to browser support and not make to many (or better yet any) assumptions about what we can send.
\nOf course this is not an approach everyone in our industry is ready to embrace, so Iâll offer another quote I come back to time and time againâŚ
\n\n\nWhen something happens, the only thing in your power is your attitude toward it; you can either accept it or resent it.
\n
We canât control the world, we can only control our reaction to it.
\nNow those of you whoâve gathered for this final Responsive Day Out (or who are following along at home) probably understand this more than most. We feel the constant bombardment of new devices, screen sizes, and capabilities. The only way Iâve found to deal with all of this is to accept it, embrace the diversity, and view device and browser proliferation as a feature, not a bug.
\nItâs up to us to educate those around us who haveâeither by accident or intentânot accepted that diversity is the reality we live in and things are only going to get crazier. Burying our heads in the sand is not an option.
\nWhen I am trying to help folks understand and embrace diversity, I often reach for one of my favorite thought exercises from John Rawls.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2015-06-22/03.jpg\")
Rawls was a philosopher who used to run a social experiment with students, church groups, and the like.
\nIn the experiment, participants were allowed to create their ideal society. It could follow any philosophy: It could be a monarchy or democracy or anarchy. It could be capitalist or socialist. The people in this experiment had free rein to control absolutely every facet of the society⌠but then heâd add the twist: They could not control what position they occupied in that society.
\nThis twist is what John Harsanyiâan early game theoristârefers to as the âVeil of Ignoranceâ and what Rawls found, time and time again, was that individuals participating in the experiment would gravitate toward creating the most egalitarian societies.
\nIt makes sense: what rational, self-interested human being would treat the elderly, the sick, people of a particular gender, race, creed, or color poorly if they could find themselves in that very same position when the veil is pulled away?
\nThe things we do to accommodate special needs now pay dividends in the future. Look at ramps.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2015-06-22/04.jpg\")
Theyâre a classic example of an accessibility feature for people in wheelchairs that also benefit people who arenât in them: People toting luggage, delivery services hauling heavy things on dollies, parents pushing children (or their dressed up dogs) in strollers, a commuter walking her bike, and that guy who just prefers walking up a gentle incline to expending the effort required to mount a step.
\nWhen we create alternative paths to get from Point A to Point B, people can take the one most appropriate for them, whether by choice or necessity. And everyone can accomplish their goals.
\nWe all have special needs. Some weâre born with. Some we develop. Some are temporary. Some have nothing to do with us personally, but are situational or purely dependent on the hardware we are using, the interaction methods we have available to us, or even the speed at which we can access the Internet or process data.
\nWhat is responsive web design about if not accessibility? Yes, its fundamental tenets are concerned with visual design, but in terms of the big picture, theyâre all about providing the best possible reading experience.
\nAs practitioners of responsive design, we understand the benefits of adapting our interfaces. We understand fallbacks. We understand how to design robust experiences that work under a wide variety of conditions. Every day we broaden the accessibility of our products.
\nThese skills will make us invaluable as technology continues to offer novel ways of consuming and interacting with our websites.
\nWeâre just starting to dip or toesâer, handsâinto the world of motion-based gestural controls. Sure, weâve had them in two dimensions on touch screens for a while now but three dimensional motion-based controls are only beginning to appear.
\nhttps://www.youtube.com/watch?v=VXhhE-l96qQ#41s/78s
\nThe first big leap in this direction was Kinect on the Xbox 360 (and later, Windows). With Kinect, we interact with the computer using body movements like raising a hand (which gets Kinect to pay attention), pushing our hand forward to click/tap, and grasping to drag the canvas in a particular direction.
\nThe Kinect ushered in a major revolution in terms of interfacing with computers, but from an interaction perspective, it presents similar challenges to those of the Wii controller and Sonyâs PlayStation Move. Large body gestures like raising your hand (or a wand controller) can be tiring.
\nhttps://www.youtube.com/watch?v=21LtA5-wiwU#7s/19s
\nTheyâre also not terribly accurate. If you thought that touchscreen accuracy was an issue, hand gestures like those for the Kinect or LEAP Motion pose even more of a challenge.
\nTo accommodate interactions like this (which we currently have no way of detecting) we need to be aware of how easy it is to click on interactive controls. We need to determine if our buttons and links are large enough and whether there is enough space between them to ensure our userâs intent is accurately conveyed to the browser. Two specs which can help address this are Media Queries Level 4 and Pointer Events.
\nIn Media Queries Level 4, we became able to apply style rules to particular interaction contexts. For instance, when we have very accurate control over our cursor (as in the case of a stylus or mouse) or less accurate control (as in the case of a touch screen or physical gesture):
\n@media (pointer: fine) {\n /* Smaller links and buttons are ok */\n}\n@media (pointer: coarse) {\n /* Larger links and buttons are probably a good idea */\n}Of course, we want to offer a sensible default in terms of size and spacing as a fallback for older browsers and devices.
\nWe also have the ability to determine whether the device is capable of hovering over an element and can adjust the interface accordingly.
\n@media (hover: hover) {\n /* hover-related interactions are A-OK */\n}\n@media (hover: on-demand) {\n /* hover-related interactions are potentially difficult,\n maybe do something else instead */\n}\n@media (hover: none) {\n /* No hover possible :-( */\n}We still need to figure out how well all of this ends up working on multimodal devices like the Surface tablet, however. Will the design change as the user switches between input modes? Should it? To that end, the spec also provides any-pointer and any-hover to allow you to query for whether any supported interaction method meets your requirements, but hereâs a word of warning from the spec:
\n\nDesigning a page that relies on hovering or accurate pointing only because
\nany-hoverorany-pointerindicate that an input mechanism with these capabilities is available, is likely to result in a poor experience.
These media query options are starting to roll out in Chrome, Mobile Safari, and Microsoft Edge, so itâs worth taking a look at them.
\nPointer Events is another spec that is beginning to gain some traction. It generalizes interaction to a single event rather than forcing us to silo experience into mouse-driven, touch-driven, pen-driven, (sigh) force-driven, and so on.
\nWe can unobtrusively detect support for Pointer EventsâŚ
\nif (window.PointerEvent) {\n window.addEventListener(\"pointerdown\", detectType, false);\n}âŚand then handle them all in the same way or create branches based on the pointerType:
function detectType(event) {\n switch (event.pointerType) {\n case \"mouse\":\n /* mouse input detected */\n break;\n case \"pen\":\n /* pen/stylus input detected */\n break;\n case \"touch\":\n /* touch input detected */\n break;\n default:\n /* pointerType is empty (could not be detected) or UA-specific custom type */\n }\n}Of course, in addition to considering the level of accuracy our users have while interacting with our screens, we also need to consider the potentially increased distance at which our users are reading our content.
\nTo that end, Iâve been experimenting with the viewport width (vw) unit.
For a long time, Iâve used ems for the layoutâs max-width (so the line length is proportional to the font size). I also use relative font sizes. With that as the foundation, I can use a media query that matches the maximum width and set the base font size at the vw equivalent at the max width.
body {\n max-width: 64em;\n}\n\n@media screen and (min-width: 64em) {\n body {\n font-size: 1.5625vw; /* ( 1em / 64em ) * 100 */\n }\n}Then the whole design will simply zoom the layout when viewed beyond that size.
\nhttps://www.youtube.com/watch?v=6XoN9mMgI38
\nIf you donât want to turn something like that on automatically, you can enable it to be toggled on and off with JavaScript.
\nhttps://www.youtube.com/watch?v=96l_W7ca6SM
\nThings get even crazier when you start to factor in devices like the HoloLens. And no, I have not gotten to play with one yet.
\nhttps://www.youtube.com/watch?v=3AADEqLIALk#87s/117s
\nBut the idea of being able to drop a resizable virtual screen on any surface presents some interesting possibilities as a user and some unique challenges as a designer. HoloLens, of course, brings with it gesture controls as well, so accounting for a variety of input types should get us pretty far.
\nIn a similar vein, we should begin to think about what experiences can and should look like when we are browsing solely with our gaze. Gaze tracking has its origins in the accessibility space as a means of providing interface control to folks with limited or no use of their hands. Traditionally, gaze tracking hardware has been several thousand dollars, putting it out of the reach of many people, but that is starting to change.
\nIn the last few years, the computational power of our devices has increased as the hardware costs associated with supporting gaze tracking have dropped dramatically. Looking around, you can see gaze tracking beginning to move into the public sphere: Many smartphones and smartwatches can recognize when you are looking at them (or at least they do sometimes). This is only a short step away from knowing where on the screen you are looking. And nearly every high-end smartphone is now equipped with a front-facing camera which makes them perfect candidates to provide this interaction method.
\nhttps://www.youtube.com/watch?v=DEk7PlJWQgI#18s/54s
\nThe Sesame Phone was designed to allow people to use a smartphone without using their hands. It uses facial tracking to move a virtual cursor around the screen, allowing users to interact with the underlying operating system as well as individual applications. It supports tap, swipe, and other gestures (via a context menu) and is pretty impressive in my experience. Technology like this enables people suffering from MS, arthritis, Muscular Dystrophy, and more to use a smartphone andâmore importantly to usâbrowse the web.
\nThe Eye Tribe and Fixational are similarly working to bring eye tracking to smartphones and tablets. Eye tracking is similar to face tracking, but the cursor follows your focus. Micro gesturesâblink, wink, etc.âallow you to interact with the device.
\nEven though most gaze tracking software mimics a mouse and has adjustable sensitivity, the accuracy of it as a pointer device is not fantastic. When Iâve used the Sesame Phone, for instance, Iâve have a hard time controlling the position of my head in order to hold the cursor still to hover and click a button. Iâm sure this would improve with practice, but itâs safe to say that in a gaze interaction, larger, well spaced, and more easily targeted links and buttons would be a godsend.
\nSo far, Iâve focused on interaction methods that facilitate navigation and consuming content. But what about filling out a form? I can tell you that typing an email letter-by-letter on a virtual keyboard using your face, sucksâŚ
\nThankfully, most of these gestural implementations are coupled with some form of voice recognition. The Kinect, for instance, will accept verbal commands to navigate and accomplish tasks like filling in forms. The Sesame Phone also supports voice commands for certain basic actions, dictating email, and the like.
\nCoupled with voice, the alternative interaction methods of Kinect and Sesame Phone work really well. But voice interaction can stand on its own too.
\nMost of us are familiar with Appleâs Siri, Google Now, and Microsoftâs Cortana. These digital assistants are great at retrieving information from select sources and doing other assistant-y things like calculating a tip and setting a reminder. As far as interacting with the web, however, they donât⌠yet. We can engage with them, but they canât (necessarily) engage with a web page.
\nExposing the information stored in our webpages via semantic HTML and structured syntaxes like microformats, microdata, and RDFa should eventually make our content available to these assistants, but we donât really know. Their various makers havenât really given us any clue as to how to do that and, as it stands right now, none of them can look up a web page and read it to you. For that you need to invoke a screen reader.
\nEach company offers a first-party screen reader. And all are capable of helping you interact with a page, including helping you fill in forms, without having to see the page. And yet, these technologies have not been coupled with their corresponding assistants. It probably wonât be long before we see that happen.
\nWhen we start to consider how our websites will be experienced in a voice context, the readability of our web pages becomes crucial. Clear well-written prose and a logical source order will be an absolute necessity. If our pages donât make sense when read, whatâs the point?
\nContent strategist Steph Hay views interface as an opportunity to have a conversation with our users. Soon it literally will be.
\nInterestingly, Microsoft has given us a peek at what it might be like to design custom voice commands for our websites beyond what the OS supports with Cortana. In other words, they let us teach their assistant.
\nIn Windows 10, installable web apps can include a Voice Command Definition (VCD) file in the head of the page to enable custom commands:
<meta name=\"msapplication-cortanavcd\" content=\"http://myapp.io/vcd.xml\" />The referenced VCD file is simply an XML file defining the keyword for the web app and commands that can be issued.
\nUsing very basic syntax, The VCD identifies optional pieces of a given phrase and variables Cortana should extract:
\n<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<VoiceCommands xmlns=\"http://schemas.microsoft.com/voicecommands/1.2\">\n <CommandSet xml:lang=\"en-us\" Name=\"groupPost\">\n <CommandPrefix>Group Post</CommandPrefix>\n <Example>Group Post add note</Example>\n <Command Name=\"addNote\">\n <Example>add a note {message} using group post</Example>\n <ListenFor RequireAppName=\"BeforeOrAfterPhrase\">[please] add a note [that] {noteSubject}</ListenFor>\n <Feedback>adding {noteSubject} to Group Post</Feedback>\n <Navigate Target=\"/addNote.htm\"/>\n </Command>\n <PhraseTopic Label=\"noteSubject\" Scenario=\"Dictation\"></PhraseTopic>\n </CommandSet>\n</VoiceCommands>This particular app passes the captured information over to JavaScript for processing. Thatâs right, Cortana has a JavaScript API too. Pretty neat.
\nBut traditional computers and smart mobile devices arenât the only place weâre starting to see voice based experiences. We also have disembodied voices like Amazonâs Echo and the Ubi which are completely headless.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2015-06-22/05.jpg\")
Right now, they both seem squarely focused on helping your house become âsmarterââstreaming music, adjusting the thermostat, etc.âbut it isnât hard to imagine these devices becoming coupled with the ability to browse and interact with the web.
\nIn the near future, voice-based interactions with the web will be entirely possible. They will likely suck a bit at first, but theyâll get better.
\nIâm going to make a somewhat bold prediction: while touch has been revolutionary in many ways toward improving digital access, voice is going to be even more significant. Voice-based interfaces will create new opportunities for people to interact with and participate in the digital world.
\nBecause weâve been thinking about how the experiences we create are consumable across a variety of devices, weâve got the jump on other folks working on the web when it comes to voice. We see experience as a continuum, starting with text.
\nAs voice technology matures, we will be the ones people look to as the experts. We will empower the next generation of websites and applications to become voice-enabled and in so doing, we will improve the lives of billions. Because âaccessibilityâ is not about disabilities, itâs about access and itâs about people.
\nSure, weâll make it easier to look up movie times and purchase tickets to see the latest Transformers debacle, but we will also empower the nearly 900 million people globallyâover 60% of whom are womenâthat are illiterate. And thatâs a population that has been largely ignored on our dominantly textual web.
\nWe will create new opportunities for the poor and disadvantaged to participate in a world that has excluded them. You may not be aware, but 80% of Fortune 500 companiesâthink Target, Walmartâonly accept job applications online or via computers. We will enable people who have limited computer skills or who struggle with reading to apply for jobs with these companies.
\nWe can help bridge the digital divide and the literacy gap. We can create opportunities for people to better their lives and the lives of their families. We have the power to create more equity in this world than most of us have ever dreamed.
\nThis is an incredibly exciting time, not just for the responsive design community, not just the web, but for the world! The future is coming and I canât wait to see how awesome you make it!
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2015-06-22/06.jpg\")
Responsive Day Out 3: The Final Breakpoint was held in Brighton, UK on 19 June 2015.
\nWeâve come a long way since Ethanâs article, fluid grids, flexible media, and media queries. Whatâs next?
","content_html":"Weâve come a long way since Ethanâs article, fluid grids, flexible media, and media queries. Whatâs next?
\n","social_text":"Weâve come a long way since Ethanâs article, fluid grids, flexible media, and media queries. Whatâs next?","url":"https://www.aaron-gustafson.com/speaking-engagements/where-do-we-go-from-here/","tags":["responsive web design","progressive enhancement"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2015-06-19T13: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/adaptive-images-in-expressionengine-with-ce-image/","title":"âđť Adaptive Images in ExpressionEngine with CE Image","summary":"One of the biggest headaches of responsive design has been dealing with images. Thankfully our work on the Responsive Images Issues Community Group has resulted in a rock-solid set of elements and attributes to address all of your adaptive image needs. My company, Easy Designs, recently redesigned Nichols Collegeâs website and that project just happened to coincide adaptive images landing in Blink (the rendering engine that powers Chrome and Opera). Naturally, we jumped at the opportunity to use them.
One of the biggest headaches of responsive design has been dealing with images. Thankfully our work on the Responsive Images Issues Community Group has resulted in a rock-solid set of elements and attributes to address all of your adaptive image needs. My company, Easy Designs, recently redesigned Nichols Collegeâs website and that project just happened to coincide adaptive images landing in Blink (the rendering engine that powers Chrome and Opera). Naturally, we jumped at the opportunity to use them.
Most Nichols College sites run on EllisLabâs ExpressionEngine, a solid little workhorse of a CMS weâve been using for years. We love it because it gives us complete control over the markup it generates. Now EE offers some pretty decent file management and image manipulation utilities out of the box, but the options it provides were not enough to handle our adaptive image needs; we needed backup. Causing Effectâs CE Image add-on is reasonably priced and offered exactly the functionality we needed to make our adaptive image dreams a reality.
\nI wonât bore you with how to set up CE Image as there is documentation on that, but I will walk you through two different responsive image use-cases we had and how we addressed them using this add-on.
\nThe first use case we had was a series of large, focal images. You can find different examples of them on the homepage and landing pages (like this one for Admissions). The first pass on making these images adaptive involved the picture element for which the spec is known. The markup we were generating was based on the pattern outlined for Picturefill, a JavaScript polyfill that implements adaptive images in browsers that donât:
<picture class=\"page__image-header__photo\">\n <!--[if IE 9]><video style=\"display: none;\"><![endif]-->\n <source srcset=\"about_940_343_int_s_c1_full.jpg\" media=\"(min-width: 40em)\" />\n <source srcset=\"about_800_350_int_c1_medium.jpg\" media=\"(min-width: 20em)\" />\n <source srcset=\"about_480_350_int_c1_small.jpg\" />\n <!--[if IE 9]></video><![endif]-->\n <img src=\"{made}\" alt=\"\" />\n</picture>To get to that point, however, we needed to use CE Image to generate (and cache) the specific sizes we needed:
\n<picture class=\"page__image-header__photo\">\n <!--[if IE 9]><video style=\"display: none;\"><![endif]-->\n {exp:ce_img:pair src=\"{content_focal_image}\" filename_suffix=\"_full\"\n width=\"940\" allow_scale_larger=\"yes\" crop=\"yes\" interlace=\"yes\" cache_dir=\"/\"\n }\n <source srcset=\"{made}\" media=\"(min-width: 40em)\" />\n {/exp:ce_img:pair} {exp:ce_img:pair src=\"{content_focal_image}\"\n filename_suffix=\"_medium\" width=\"800\" height=\"600\" crop=\"yes\" interlace=\"yes\"\n cache_dir=\"/\" }\n <source srcset=\"{made}\" media=\"(min-width: 20em)\" />\n {/exp:ce_img:pair} {exp:ce_img:pair src=\"{content_focal_image}\"\n filename_suffix=\"_small\" width=\"480\" height=\"360\" crop=\"yes\" interlace=\"yes\"\n cache_dir=\"/\" }\n <source srcset=\"{made}\" />\n <!--[if IE 9]></video><![endif]-->\n <img src=\"{made}\" alt=\"\" />\n {/exp:ce_img:pair}\n</picture>Not whatâs a lot of code, so letâs just look at one segment of that jumble:
\n{exp:ce_img:pair src=\"{content_focal_image}\" filename_suffix=\"_full\" width=\"940\"\nallow_scale_larger=\"yes\" crop=\"yes\" interlace=\"yes\" cache_dir=\"/\" }\n<source srcset=\"{made}\" media=\"(min-width: 40em)\" />\n{/exp:ce_img:pair}This is an example using CE Imageâs tag pair option, which lets you control the markup output. In the opening tag, we set several properties:
\nsrc is the path to the original image uploaded by content authors;filename_suffix is the suffix we want added to the cached file to differentiate it from others in the cache (and make the files more easily scannable);width is our desired output width for the generated image;allow_scale_larger does exactly what youâd expect: it dictates whether or not CE Image should scale the image to reach the desired width;crop tells CE Image whether itâs okay to crop the image;interlace tells CE Image to use image interlacing (which can speed load time); andcache_dir tells CE Image where to store the cached image (in relation to our global configuration)Then, within the tag pair is the source element with the srcset value set to the path to the file CE Image generated (referenced by the made variable) and the associated media query.
Multiply that a few times for the different sizes and you have the full picture element.
Now thatâs all well and good, but shortly after launch, Eric Portis wrote an amazing post explaining how the srcset and sizes attributes operate and it cleared up a lot of my confusion on the matter. He convinced me that the age-old img element, with these new attributes, would be far more maintainable. With a fire in my belly, I rewrote the markup:
<img class=\"page__image-header__photo\" alt=\"\"\n {exp:ce_img:pair\n src=\"{embed:image}\"\n filename_suffix=\"_small\"\n width=\"480\"\n height=\"320\"\n crop=\"yes\"\n interlace=\"yes\"\n cache_dir=\"/\"\n }\n src=\"{made}\"\n srcset=\"{made} 480w,\n {/exp:ce_img:pair}\n {exp:ce_img:pair\n src=\"{embed:image}\"\n filename_suffix=\"_medium\"\n width=\"800\"\n height=\"600\"\n crop=\"yes\"\n interlace=\"yes\"\n cache_dir=\"/\"\n }\n {made} 800w,\n {/exp:ce_img:pair}\n {exp:ce_img:pair\n src=\"{embed:image}\"\n filename_suffix=\"_full\"\n width=\"940\"\n allow_scale_larger=\"yes\"\n crop=\"yes\"\n interlace=\"yes\"\n cache_dir=\"/\"\n }\n {made} 940w\"\n {/exp:ce_img:pair}\n >The CE Image behavior is exactly the same, but the resulting markup is much clearer:
\n<img\n class=\"page__image-header__photo\"\n alt=\"\"\n src=\"about_480_320_int_c1_small.jpg\"\n srcset=\"\n about_480_320_int_c1_small.jpg 480w,\n about_800_350_int_c1_medium.jpg 800w,\n about_940_343_int_s_c1_full.jpg 940w\n \"\n/>The added bonus of this approach is that I am not hard-coding any media queries and the browser gets to make the ultimate decision of which image to request. All I am doing is telling the browser the image options and their respective widths within the srcset attribute. As all of the images take up 100% of their containers, I didnât even need to use the sizes attribute. Easy peasy.
Not every image adds something to the page. Some are purely optional, a visual enhancement. In order to reduce the size of pages on smaller screens, we often choose to âlazy loadâ certain image assets after page load, when we know there is enough room to display the image or when we feel it would be an enhancement to the design.
\nNow some of you might be wondering: Why not just display:none below a certain threshold? Well, Iâll tell you: images that are hidden with CSS are still requested by the browser. That means users who donât see the images are still paying to download them (whether in terms of time waiting for the page to render or actual money on a metered connection). That kinda sucks for them. We should show our users a bit more respect and only request the images when we need them.
We wrote a lazy-loading image script a few years back and have battle tested it on numerous sites to great success. Itâs all based on a simple markup pattern:
\n<div\n class=\"module__image image--lazy\"\n data-image-src=\"Tim-Smith_220x140_220_140_int_c1.jpg\"\n></div>The data-img-src attribute defines the path to the ânice to haveâ image and then the JavaScript adds the image element into the page when the appropriate conditions are met:
<div\n class=\"module__image image--lazy\"\n data-image-src=\"Tim-Smith_220x140_220_140_int_c1.jpg\"\n data-image-loaded=\"\"\n>\n <img alt=\"\" src=\"Tim-Smith_220x140_220_140_int_c1.jpg\" />\n</div>Pretty simple. It even supports srcset:
<div\n class=\"module__image image--lazy\"\n data-image=\"about_480_320_int_c1_small.jpg\"\n data-image-srcset=\"about_480_320_int_c1_small.jpg 480w,\n about_800_350_int_c1_medium.jpg 800w,\n about_940_343_int_s_c1_full.jpg 940w\"\n></div>The full documentation is up on Github.
\nImplementing this in the context of CE Image was a breeze and builds on the source pattern I showed earlier:
{if testimonial_photo} {exp:ce_img:pair src=\"{testimonial_photo}\" width=\"223\"\nheight=\"140\" allow_scale_larger=\"yes\" crop=\"yes\" interlace=\"yes\" cache_dir=\"/\" }\n<div class=\"module__image image--lazy\" data-image-src=\"{made}\"></div>\n{/exp:ce_img:pair} {/if}We are only just beginning to scratch the surface of whatâs possible with adaptive images and I am sure we will come up with newer, better ways to do this stuff. Heck, there may even be an adaptive images add-on in the pipeline for ExpressionEngine. But, in the meantime, if you are trying to implement adaptive images with ExpressionEngine, CE Image is a good way to go.
\n","url":"https://www.aaron-gustafson.com/notebook/adaptive-images-in-expressionengine-with-ce-image/","tags":["web design","responsive web design","ExpressionEngine","progressive enhancement"],"date_published":"2014-11-21T23:18:23Z"},{"id":"https://www.aaron-gustafson.com/publications/books/responsive-typography-using-type-well-on-the-web/","title":"đ Responsive Typography","content_html":"I can honestly say that Responsive Typography is a book well worth reading. Jasonâs natural and friendly style makes for an easy read and itâs chock-full of actionable recommendations and tips youâll want to start using right away.
\n","url":"http://shop.oreilly.com/product/0636920034063.do","tags":["responsive web design","web design","CSS"],"date_published":"2014-10-06T17:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/responsive-typography/","title":"âđť Responsive Typography","summary":"Iâm incredibly excited to see that Jason Pamentalâs fantastic Responsive Typography is finally available. I had the great pleasure of reviewing an early galley and I can honestly say that itâs a book well worth reading. Jasonâs natural and friendly style makes for an easy read and itâs chock-full of actionable recommendations and tips youâll want to start using right away.
","content_html":"Iâm incredibly excited to see that Jason Pamentalâs fantastic Responsive Typography is finally available. I had the great pleasure of reviewing an early galley and I can honestly say that itâs a book well worth reading. Jasonâs natural and friendly style makes for an easy read and itâs chock-full of actionable recommendations and tips youâll want to start using right away.
\nIn fact, I think Responsive Typography is such an invaluable book, I offered to write the Foreword and Jason (and OâReilly) have been kind enough to let me reprint it here:
\n\n\nBack in my day, all we had was the
\nfontelement.I fully realize that makes me sound like an old man, but Iâm not ready to chase young whippersnappers off my lawn quite yet. But the fact remains that when I taught myself how to build web pages back in the mid-â90s, our design options were fairly limited. Heck, my first experience on the Web was on a text-based browser that provided me access to page upon glorious page of stark, blocky Courier. White text. Black background. 100% responsive.
\nWhen visual browsers finally hit the scene, ushering in images and the
\nfontelement, we web designers finally had the opportunity to move out of monospace. Iâll leave it to Jason to delve into the history of typography on the Web, but the advent of visual browsers opened the floodgates for use (and abuse) of type online. It was the desktop publishing revolution all over again: a direct assault on the sensibilities of anyone with even the slightest understanding of typography.Over the years, weâve made a lot of mistakes with web type: Fonts embedded in images. Fonts embedded in Flash. Fonts embedded in JavaScript. Many of those were attempts to bypass the gridlock created by browser makers, type foundries, and the W3C, who couldnât come to a consensus on how to balance a desire for more type options on the Web while ensuring typographers got paid for all of their hard work. While they bickered, we soldiered on, looking for more accessible and maintainable ways to use more typefaces.
\nAnd while we were busy tinkering with sIFR and CufĂłn, eagerly awaiting the day we could abandon those hacks and have real browser support for actual font formats, an army of little black rectangles had caught a whiff of the awesome content we were serving up to desktop browsers.
\nLike ants at a Sunday picnic, these little black rectangles initially appeared one or two at a time. They were easily ignored, a nuisance. Nothing to take too seriously. But before we knew what was happening, that trickle turned into a flood and those little rectangles were hungry. Instead of taking a crumb here and thereâwhich we tossed to them with a great sense of self-satisfactionâthese ambitious ants were carrying off whole deli trays and the frigginâ New York Times.
\nThese little black rectangles are, of course, the surge of handheld (or at least hand-holdable) devices that have been redefining our concept of âthe Webâ almost daily. They exhibit widely variable screen sizes: from about the size of a matchbook, to ones that are bigger than an extra large pizza. They sport a plethora of pixel densities, new interaction methods, unpredictable network connection speeds, and low-powered processors that canât possibly compete with traditional laptop and desktop CPUs (not to mention a handful of different operating systems and browsers). All of these factors affect howâand even whetherâyour typographic choices will make it to your customers, and itâs a lot to take in.
\nThankfully, Jason has your back. The book youâre now reading is invaluable: itâs chock-full of useful approaches, practical code samples, and advice for dealing with typography in the age of responsive web design.
\nBy the time you finish this brief book, youâll be ready to handle pretty much any device someone may throw at you. But hopefully they wonât. Devices are hard. And expensive.
\nâ Aaron Gustafson
\n
\n   Author, Adaptive Web Design
By the way, if youâre on a typography kick Iâll also recommend an second new book by another Jason I respect greatly: Jason Santa Mariaâs On Web Typography. The two books books compliment each other perfectly, with very little overlap. Theyâd make an awesome bundle.
\n","url":"https://www.aaron-gustafson.com/notebook/responsive-typography/","tags":["web design","writing","responsive web design"],"date_published":"2014-09-20T20:43:22Z"},{"id":"https://www.aaron-gustafson.com/appearances/podcasts/2014-09-05-progressive-enhancement-and-friends/","title":"đ§ Progressive Enhancement and Friends","content_html":"Justin Avery and I chat about responsive design, element queries, progressive enhancement and dumb JavaScript.
\n","url":"https://web.archive.org/web/20210226070435/https://responsivedesign.is/podcasts/rwd-podcast-episode-18-aaron-gustafson/","tags":["progressive enhancement","responsive web design","JavaScript"],"date_published":"2014-09-05T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/responsive-design-and-beyond/","title":"đ˘ Responsive Design and Beyond","summary":"Responsive design is not an end in itself⌠itâs just the beginning.
","content_html":"Responsive web design has taken our industry by storm and with good reason: it helps us improve our reach with less effort. But incorporating responsive design is not the goal, meeting our userâs needs is. Responsive design is not an end in itself⌠itâs just the beginning.
\nAs a fitting way to kick off our new workshop series, Code & Creativity asked two internationally-renown mobile web and responsive design expertsâBrad Frost (of This is Responsive, and Pattern Lab fame) and Iâto come and teach you everything we need to know about working in this multi-device reality.
\nFor the first part of the day, Brad and I surveyed the landscape of responsive design, covering:
\nThen, we broke into small groups to tackle some thorny responsive challenges through discussions, sketching, and even a little coding, while Brad & I provided real-time feedback and pushed attendees to go further. At the end, everyone shared their findings with the class and got additional feedback from the experts.
\n","social_text":"Responsive design is not an end in itself⌠itâs just the beginning.","url":"https://www.aaron-gustafson.com/speaking-engagements/responsive-design-and-beyond/","tags":["progressive enhancement","responsive web design","user experience","web design","web development"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2014-05-02T13:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/beyond-responsive-workshops-this-may/","title":"âđť Beyond Responsive Workshops this May","summary":"\tA lot fo my work lately has been consulting and working with teams to help them to establish or improve upon their responsive strategies.
","content_html":"\n\tA lot fo my work lately has been consulting and working with teams to help them to establish or improve upon their responsive strategies.
\n\n\tI love this sort of work and I live for helping teams and individuals tackle the thorny issues (in code or processes) that make responsive projects a challenge. For a lot of small companies, it can be a challenge to pull ogether enough budget to fly me in for a few days of private working sessions, which is why I am such a huge fan of running public workshops⌠especially ßber-affordable ones like I am leading this May.
\n\n\tThe first will be on my home turf in Chattanooga, Tennessee on May 2nd and I will be co-leadiing the workshop with my esteemed colleague Brad Frost. Itâs the first workshop from our successful Code & Creativity event series and should be a heck of a lot of fun. There are a few tickets left for $399 each on Eventbrite.
\n\n\tThe second workshop will be in DĂźsseldorf, Germany on May 21st. There are a handful of tickets still available for âŹ349 (VAT included) and a ticket also gets you into the incredible Beyond Tellerrand conference which runs on the 19th & 20th. Iâve spoken at this conference twice before and it is one of only a handful of events in the world I enthusiatically recommend attending.
\n\n\tHereâs a rough idea of what Iâll be covering in the two workshops:
\n\n\n\n\t\tResponsive web design has taken our industry by storm and with good reason: it helps us improve our reach with less effort. But incorporating responsive design is not the goal, meeting our userâs needs is. Responsive design is not an end in itself⌠itâs just the beginning.
\n\n\t\tWe need to embrace the heterogenous nature of the webâmyriad web-enabled devices with vastly different dimensions, screen sizes, networks, and capabilities in use by countless individuals, each with their own special needsâand craft experiences that will work anywhere at any time. We need to build robust systems that adapt in ways far beyond aesthetics.
\n\n\t\tEach workshop with a discussion of a number of considerations that we should be aware of, beyond screen size and pixel density, and provide examples of how to adapt our interfaces so they rise to meet our customersâ needs. Then heâll turn it over to you to propose gnarly design and/or interface challenges you are struggling with. Once everyoneâs challenges are collected, attendees will be given the opportunity to form small groups around each and you will spend a portion of the day working on solutions while Aaron mentors each group and pushes you to think more about accessibility, alternate interaction methods, slow networks, and other considerations.
\n\n\t\tThe workshop will wrap up with brief presentations from each group followed by a an open question and answer session.
\n
\n\tI hope youâll join me in Chattanooga or DĂźsseldorf next month. Bring your questions and your challenges and letâs dig in.
\n","url":"https://www.aaron-gustafson.com/notebook/beyond-responsive-workshops-this-may/","tags":["responsive web design","conferences","presentations"],"date_published":"2014-04-15T14:39:00Z"},{"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?
\nMy, weâve come a long way, baby.
\nToday, 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.
\nFortunately, 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.
\nCreate experiences without technological constraints
\nStop assuming users are just like you
\nMake a contentÂ-first approach work
\nEstablish a solid strategy for planning
\nJoin us for this seminar if you:
\nIf 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/notebook/zoom-layouts-v2/","title":"âđť Zoom Layouts v2","summary":"\tSome of you might find it hard to believe, but I began working with adaptive layouts way back in 2005. I was working on project for the Connecticut Department of Transportation and my primary design made heavy use of fixed positioning and white space. Sadly this is the only screenshot I have of the now-defunct project:
![\"\"](\"/i/posts/2013-09-16/drink-drive-lose-ad-challenge.png\"/)
\tThe layout really started to break down on smaller screensâwe had quite a few 800x600 monitors to deal with back in the dayâso, inspired by Joe Clarkâs A List Apart article âBig, Stark & Chunky,â I created an alternate stylesheet that rearranged the page layout, enlarged the text, and improved the reading experience. Sadly, I donât have a screenshot of what that looked like, but hereâs a decent approximation (sans background images), courtesy of the Wayback Machine:
","content_html":"\n\tSome of you might find it hard to believe, but I began working with adaptive layouts way back in 2005. I was working on project for the Connecticut Department of Transportation and my primary design made heavy use of fixed positioning and white space. Sadly this is the only screenshot I have of the now-defunct project:
\n\n\tThe layout really started to break down on smaller screensâwe had quite a few 800x600 monitors to deal with back in the dayâso, inspired by Joe Clarkâs A List Apart article âBig, Stark & Chunky,â I created an alternate stylesheet that rearranged the page layout, enlarged the text, and improved the reading experience. Sadly, I donât have a screenshot of what that looked like, but hereâs a decent approximation (sans background images), courtesy of the Wayback Machine:
\n![\"\"](\"/i/posts/2013-09-16/drink-drive-lose-ad-challenge-small.png\"/)
\n\tWe didnât have media queries in those days, so I relied on JavaScript to do the stylesheet switching. It was pretty good work for the time, but I see a ton of things I would do differently if I had the opportunity to revisit it.
\n\n\tSo why am I bringing this up? Well, I remembered Joeâs article the other day and was thinking about how relevant it is in this, the age of responsive design. I think the idea of high-contrast zoom layouts is incredibly useful, but not just for mobile. When you start to think about the other end of the spectrumâgiant high-definition televisions sitting 8-10 feet from your faceâzoom layouts become really useful again.
\n\n\tTo that end, I have been thinking quite a bit about the viewport-based units available to us in modern browsers and how we can use them to create automated zoom layouts by simply increasing the font size of the body element. Consider this bit of code:
\n@media screen and (min-width: 64em) {\n body {\n font-size: 1.5625vw;\n }\n}\n\n\tThis tiny bit of CSS can ensure that the entire layout is proportionately scaled up based on the screen size being used to access it. To figure out how this bit of code would fit best into your own work, use this formula (replace âXâ with your max width size in ems):
\n\n@media screen and (min-width: 64em) {\n body {\n font-size: 1.5625vw;\n }\n}\n\n\tThe site I developed this technique for is not live yet, so I threw together a simple demo on Codepen. Note: Chrome currently requires a forced repaint on window resize to make it shrink or enlarge the layout. Hopefully that bug will be fixed soon.
\n\n\tIâm still feeling my way around this technique, but I am intrigued by the possibilities it holds. What do you think?
\n","url":"https://www.aaron-gustafson.com/notebook/zoom-layouts-v2/","tags":["responsive web design","CSS","accessibility"],"date_published":"2013-09-16T15:56:00Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/responsive-design-studio/","title":"đ˘ Responsive Design Studio","summary":"A deep dive into the implications of responsive design.
","content_html":"A deep dive into the implications of responsive design.
\n","social_text":"A deep dive into the implications of responsive design.","url":"https://www.aaron-gustafson.com/speaking-engagements/responsive-design-studio/","tags":["accessibility","CSS","HTML","progressive enhancement","responsive web design"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2013-04-29T13:00:00Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/the-real-responsive-process/","title":"đ˘ The Real Responsive Process?","summary":"The web is not a fixed width. So if the medium is fluid, should the process be fixed?
","content_html":"The web is not a fixed width. So if the medium is fluid, should the process be fixed? Fireworks and Photoshop are not flexible enough to demonstrate media queries, button and menu states, HTML5 and JavaScript behaviors, dynamic resizing of elements and navigation flow.
\nDiving into responsive design projects can be daunting. Old design practices are cumbersome when thinking in terms of web systems that will span a wide variety of devices and dimensions. Four industry leaders will delve into how they handle the responsive process or how they donât. A fluid process to match the fluidity of responsive design. Bam! Weâll also explore some of recent successes and failures while establishing why a responsive process is a responsible process.
\nOne web to rule them all?
\n","social_text":"The web is not a fixed width. So if the medium is fluid, should the process be fixed?","url":"https://www.aaron-gustafson.com/speaking-engagements/the-real-responsive-process/","tags":["responsive web design","web design"],"date_published":"2013-03-08T15:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/responsive-tables/","title":"âđť Responsive Tables","summary":"A few smart folks have already put together their thoughts on responsive tables and, while I think the proposed methods are pretty good, I think there might be room for improvement. As such, Iâve been tinkering for a while and came up with the following strategy when it comes to tables.
","content_html":"A few smart folks have already put together their thoughts on responsive tables and, while I think the proposed methods are pretty good, I think there might be room for improvement. As such, Iâve been tinkering for a while and came up with the following strategy when it comes to tables.
\nStep 1: Use data-* attributes to hold information about the column header(s) associated with the markup:
| Name | \nDept, Title | \nPhone | \n|
|---|---|---|---|
| \n Smith,\n Laura\n | \n\n laura.smith@domain.com\n | \nBiology, Director | \n\n 123-456-789\n | \n
| \n Johnson,\n Ron\n | \n\n ron.johnson@domain.com\n | \nPurchasing, Director | \n\n 123-456-7891\n | \n
Step 2: When the screen is below a certain threshold, set the table elements to display: block (thereby linearizing the table), hide the thead where assistive tech wonât see it, and use generated content to expose the data-* attributes. Hereâs a snippet of SASS & Compass that does that:
// make each table separate from other ones\ntable {
\nborder: 0;\n@include trailing-border;\npadding-bottom: 0;\ndisplay: block;\nwidth: 100%;
\n// make sure captions are displayed\ncaption {\ndisplay: block;\n}
\n/*\n* wipe the thead from the face of the earth\n* modern screen readers will expose the\n* generated content\n*/\nthead {\ndisplay: none;\nvisibility: hidden;\n}
\n/*\n* make everything display block so it\n* aligns vertically\n*/\ntbody, tr, th, td {\nborder: 0;\ndisplay: block;\npadding: 0;\ntext-align: left;\nwhite-space: normal;\n}
\n// give each row a little space\ntr {\n@include trailer;\n}
\n/* Labeling\n* adding a data-title attribute to the cells\n* lets us add text before the content to provide\n* the missing context\n*\n* Markup:\n*
// hide empty cells\ntd:empty {\ndisplay: none;\n}\n}\n}
\n<p>Weâve been using this approach on a number of sites currently in development and it works really well. I put together <a href="http://codepen.io/aarongustafson/pen/ucJGv">a demo of this technique</a> so you could play around with it yourself.</p>\n<p><strong>Notes:</strong></p>\n<ol>\n<li>I chose to use a <code class="html">data-*</code> attribute (<code class="html">data-title</code>) instead of <code class="html">title</code> as the <code class="html">title</code> attribute could be read out by assistive technology and in the case of the <code class="html">thead</code> being available as well (when not <code class="html">display: none</code>), resulting in the information being read twice (which is not ideal). <a href="http://www.paciellogroup.com/resources/articles/WE05/#slide9">Thatâs not a certainty however</a>, so you could choose to go the <code class="html">title</code> route if thatâs your preference. I prefer to avoid the potential issue.</li>\n<li>If you have multiple header rows over a cell (say a parent row and then a child row), Iâd recommend making the <code class="html">data-title</code> something like âParent Header - Child Header.<span class="final quote">â</span></li>\n<li>While you could use JavaScript to auto-generate the <code class="html">data-title</code> attributes by referencing the column headers, I feel this is information that should exist even if JavaScript is not available. You may disagree.</li>\n</ol>\n