Faruk At.eş


Archive for 2010

  1. January 19
  2. February 12
  3. March 19
  4. April 24
  5. May 11
  6. June 9
  7. July 7
  8. August 9
  9. September 4
  10. October 1
  11. November 2
  12. December 2

Showing 2 posts from

Design Day 2010: Technology & The Modern Web

At the end of September, I embarked on a short trip to Sofya, Bulgaria to give a talk on Technology and the Modern Web at the .net Design Day 2010 conference. Because I’m not a fan of presentation slides that are self-evident, putting my talk’s slides on a site like Slideshare is mostly useless. Fortunately, the entirety of the talk was scripted out ahead of time—partly for my own timing needs, but also to send an early version to the interpreters who live-translated me at the conference, so they could familiarize themselves with the subject matter—and as a result, after some necessary context-related editing, I can share my talk in written form, together with the more interesting slides from the deck. Without further ado, I’m pleased to present:

Technology and Web Design.002.jpg

Technology & The Modern Web

I started with welcoming people back from lunch, expressing my hope that they had a light lunch, because there was going to be some standing up and sitting down in my session. Of course, I also thanked the people at .net magazine for inviting me to speak there, and then shared the one and only URL they’d need to write down:

delicious.com/kurafire/designday2010

This URL was also shown again at the end, as it has all the links to every technology, tool and technique I mentioned in my talk, which all surrounded the hot new items du jour: HTML5 and CSS3.

Technology and Web Design.003.jpg

I (safely) assumed that the audience was at least somewhat familiar with both HTML5 and CSS3 already and knew, at least on a surface level, roughly what the two technologies are about and what kind of concepts they’re introducing. But before taking a proper look at what is new and exciting about the Modern Web, I first wanted to establish how it is different from the old web.

Back in the late 90’s and early 2000’s, websites were kind of similar to… this:

Technology and Web Design.004.jpg

An old automobile, simple yet functional. You had your basic components and techniques that made it all work, and, well, that was kind of it.

Over time, as is always the case with science and technology, things got better and more complex, and while that’s generally a good thing, a modern website today is more like this:

Technology and Web Design.005.jpg

This is the Honda FCX Clarity, one of the most advanced, sophisticated cars you can get. It’s got a hydrogen-fuel/electric hybrid engine, a rear center console that doubles as a tray table, GPS navigation, Satellite radio, Auxiliary input jack, a USB Audio interface, 3D gauges, and about a thousand other features that cars didn’t have even just 10–15 years ago.

The average car of way back when in the old days was typically made by just a handful of people; cars today are made by countless of robotic systems, assembly lines and designed and engineered by dozens, often hundreds of people.

It’s much the same with websites these days. We no longer just put something together with some HTML, CSS and Javascript, toss it on a webserver and be done. Sure, we still use those three core technologies, but we also use about a dozen or more tools and technologies around it. In this talk we’ll take a look at some of these tools and technologies, and also explore some techniques we can use to make better, more powerful, more capable and more engaging websites. That’s a lot of ground to cover, so let’s get to it!

As said already, there is a lot of stuff that makes up CSS3, HTML5 and the related technologies that are allowing for all the exciting innovations taking place on the Web today. I’m quickly going to cover some of the more interesting ones in rapid-fire succession. I won’t have time to go in-depth on any of them, but don’t worry: the link, shown at the start and again at the end of this presentation, points to a page containing links to absolutely everything I’m talking about today, so that you can explore them more in-depth when you have all the time you need. Which, let me warn you, will be lots of time.

First, I highlighted some parts of CSS3:

CSS Transitions & Animations

It’s been possible to do animations via Javascript for a really long time now, but with CSS Transitions and Animations we finally can add subtle effects in the presentation layer of our websites, using just a few lines of CSS here and there. These effects can be really subtle, yet still have a remarkably great effect on improving how a website looks and feels.

CSS 2D and 3D Transforms

Transforms allow you to take any element and transform it mathematically. Want to rotate it? Now you can. Want to skew it? Now you can. With 3D transforms, the absolute craziest of things are suddenly possible, but even just 2D transforms can make websites far more interesting without forcing you to use tons of static images.

Canvas & SVG

Now over to HTML5 and related technologies: Canvas and SVG are drawing technologies that allow you to do programmatic drawing using vectors or formulas. Very powerful for certain things, from games to color tools and lots more.

HTML5 localStorage, sessionStorage & applicationCache

One of the major developments on the Web the past five-six years has been web applications, and HTML5 as a set of technologies kind of emerged out of the need to build better and more capable web apps. Things like localStorage and applicationCache allow you to do that, and even keep your web app functioning entirely whilst the user is offline, or save their work when they close their browser.

HTML5 Web Forms

Another major development for making more capable native web apps are new Web Forms innovations. Built-in support for form validation, sliders, date pickers and much more greatly reduce the need for complex Javascript tools and plugins.

Geolocation

Whilst only an emerging technology in the past few years, geolocation is something that will prove increasingly useful and valuable the more we become familiar with it and the more geo-specific concepts emerge. Knowing where the user is can be a really cool thing, and so far we’ve only scratched the surface of what we can do with this.

After that quick run through of some of the big new technologies, it was at this point that I asked all the people who are taller than 1.80m (just below 5’11”) to stand up. I made sure they took a good look around the room, taking in the rest of the audience, etc.

Then came the turn for the people shorter than 1.65m (5’5”) to stand up. Again, they had to look around the room and get themselves a good impression of everything.

Now, before we even set out to design an experience, we should ask ourselves this question: do we all perceive an experience in one and the same way? Was the experience of taking in the room and the rest of the audience the same for the shorter people as it is for the taller people?

I asked whoever thought that the tall people had the exact same experience just then as the short people did to raise their hands. Virtually no one did so, which was great.

Whilst this room remains exactly the same and all of us in it are obviously still the same, the experience between person A and person B can be different. Subtle differences in circumstances — in this case, the person’s height — can make much bigger differences in how something is experienced. Ever been on one of these?

Technology and Web Design.016.jpg

You probably have, but not back when you were just a short little kid. Which goes to show that some experiences are disproportionally different compared to the subtlety of difference in circumstances. In the example of our room, the difference in experience was negligible, but with the roller coaster, a measly 5 centimeters of height can mean the difference between riding the roller coaster or not riding it at all.

Tools can make a difference in some of these experiences, and help us as designers and experience creators define that experience to be as good as we can make it. I use the word “define” consciously, rather than saying that designers “control the experience”, because as Oliver Reichenstein put it:

Technology and Web Design.017.jpg

“The more experience you have in our field the more you are aware of how much the perception of a product varies from person to person. Design defines experience, it doesn’t control it.”

Oliver Reichenstein

Going back to our example of people and their varying heights, an example of a tool that we could use to synchronize the experiences of people both short and tall would be something like, say, a wooden box. The short people stand on the box, and then experience the room the same way as the tall people.

Now, if you think this is a strange example, just replace people’s height with their choice of web browser. The room now becomes our website or web application, and the box that some people will stand on is a Javascript library of sorts that, for example, makes Internet Explorer support rounded corners or the Canvas element.

These kinds of tools are what allows us to define the experience for our audiences, and cater it so that we can provide for them as needed. Nowadays, tools are almost indispensable when building websites, but there’s an important difference between tools that help us do our work, and tools that supplant new technologies or missing functionality in older browsers. Most notably, the latter kind of tools have what I’d call an expiration date.

For example, there are many JavaScript libraries that serve as plugins to add rounded corners in Internet Explorer versions 8 and below. However, virtually all of these come with a significant performance cost, as well as a not insignificant time investment for the developer to implement and test. With increased adoption of modern browsers that support native border-radius CSS, and with more and more clients understanding that websites don’t necessarily have to look the exact same in every possible browser, such JavaScript libraries become less needed and thus, less relevant.

Meanwhile, other tools become more relevant. jQuery has long been a popular JavaScript library to develop with, but the rise in mobile device usage around the world to access the Internet with has made the need for a mobile-optimized version of jQuery greater. At this time, jQuery Mobile is slated for release sometime “Late 2010,” so hopefully that tool will be available very soon.

Another tool that is becoming increasingly relevant and popular is one that I work on myself: Modernizr.

Modernizr is explicitly not designed to supplant missing functionality in older browsers, but rather, to let you as a web designer or developer know exactly which features the current browser does support. It will detect the browser’s support for things like border-radius, box-shadow, CSS transitions, Canvas, SVG, new form elements, geolocation and so forth, and lets you fork your CSS and your JavaScript based on that information. Does the browser have native CSS Transition support? Cool, use these style rules and we’re done. No support? Fine, use this JavaScript-driven fallback.

What’s great about that kind of control is that you can separate native implementations from fallbacks, letting the users with capable browsers get the best performance and user experience, or even offer multiple, entirely different experiences so that you can optimize each for what the user’s browser can handle. Furthermore, if at some point your audience has largely or entirely upgraded to newer browsers, you can very easily just remove all the fallback stuff from your code.

Another great resource is the HTML5 Boilerplate, which combines about 50 best practices and fallback techniques all in one massive template. In fact, the HTML5 Boilerplate contains so much good stuff that you could do an hour-long presentation on it and still only be halfway through explaining it all!

But that’s not what this presentation is for, so I’m going to shift gears here for a moment and talk a bit about modern approaches to User Experience and web design.

Technology and Web Design.021.jpg

Addition vs. Omission

Have you ever had a friend or family member who used to wear glasses all the time, and then one day got contact lenses or laser eye surgery or something like that? Raise your hand if you’ve known someone in your life like that. [almost half of the audience raised their hands]

Well, I used to wear glasses myself, and when I first got them in middle school, everyone immediately noticed them. They were a new addition to an otherwise familiar person. But years later, when I switched to contact lenses, very few people in my life at that time noticed the change. Some didn’t notice it at all until I pointed it out to them.

Humans are great at picking up on new things, but far less so at noticing when things go missing. This isn’t some great mystery, of course: it’s difficult to observe something when it isn’t there. If it was there before, it requires us to reach back into our memory banks, and do a detail-for-detail comparison of what we have stored in memory to what we’re observing now. That’s far more difficult and time-consuming than simply observing some new thing that stands out just by being there.

Now, that’s a simple example, but it is this process that forms the foundation from which we extrapolate our observations when surveying the world around us. It is incredibly natural and easy to simply see the world for what it is in our direct environment, and much, much harder to see the world in ways that go well beyond our direct environment.

Technology and Web Design.022.jpg

For example, I currently live in The Netherlands, and spend much of my time there. It’s almost impossible for me to imagine what life is like on a daily basis in Bulgaria. The country exists well outside of my direct environment, so it’s more difficult for me to understand certain things about it. By traveling to it, by just being there, I have learned a lot about it already, and about the people who live there. Had I lived there for a couple of months before the event, I would probably have given a somewhat different presentation, one more finely tailored towards Bulgarians as my audience. It would be based on having a deeper understanding of the culture in Bulgaria, or in Sofya specifically, and that understanding would very subtly have influenced my decisions whilst putting this talk together, from the design of my slides and their color schemes all the way down to my choices of words, expressions and examples along the way.

Which brings us to my next point: understanding the needs of your audience. This is different in every discipline, different in every part of life, but in web design it used to be simple. Again, like with the old automobile, stuff used to be simple. Let’s look at how we used to support the needs of our audience back in the old days of the Web:

Technology and Web Design.023.jpg

The old approach to supporting the needs of your audience as thoroughly as you could was to assess all the possible audiences you might have: browsers, operating systems and resolutions. These days, that’s a really huge undertaking, and almost certainly not worth the time investment. There are countless of current and legacy browsers to deal with, more than a dozen different Operating Systems, and nowadays there are numerous different mobile devices and screen sizes to take into account as well. Trying to make a support matrix out of all of that is not just an enormous task, it’s simply not worth the time investment anymore, since better, more modern techniques are readily available.

(Just for fun, I tried to make a support matrix showing just mobile browsers & devices only, and already I couldn’t fit the whole thing on one slide.)

Today’s incredibly complex browser landscape requires us to use flexible and adaptive techniques, because only with such techniques do we know that what we create is very likely to work on combinations of browsers, devices and screens we haven’t tested against. At the heart of these techniques lie CSS3 Media Queries.

Media Queries are something which almost any web developer has already worked with. You’ll almost certainly be familiar with this:

<link rel="stylesheet" rel="external" href="main.css" media="screen" />
<link rel="stylesheet" rel="external" href="print.css" media="print" />

CSS3 Media Queries are pretty much just like that—on steroids. They allow you to customize your styles based on things like width and height of both the current viewport and the device itself, aspect ratio, orientation, color depth and much more.

As an example, here is a demo site I made a little while ago:

At sub-800 pixel wide resolutions:

Technology and Web Design.026.jpg

Greater than 1024:

Technology and Web Design.027.jpg

IPhone:

Technology and Web Design.029.jpg

Using CSS3 Media Queries I was able to define entirely different layouts for different screen sizes. It didn’t matter what each resolution was exactly, it was all about specifying minimum requirements. Is the screen at least this wide? Use this CSS. Is it this wide? Use these CSS rules instead. And so forth, and so forth.

Here is a small sample of the CSS3 Media Queries I used:

@media screen and (min-width: 1024px) {
	#stage {
		width: 800px;
		}
	#thumbs {
		left: 820px;
	}
	#thumbs li {
		margin: 0 8px 8px 0;
		min-width: 60px;
		max-width: 240px;
	}
}

These kinds of adaptive, flexible design techniques allow us to make layouts that adapt and change depending on what kind of resolution, device, color depth or screen aspects a visitor has, from the smallest mobile devices all the way to giant 30” desktop screens. This idea has been coined Responsive Web Design by Ethan Marcotte, and in his article on A List Apart he explains all about how to build these powerful, responsive layouts.

Of course, these really great CSS3 Media Queries are not supported in several older browsers stiSteven Kan <steven.kan@gmail.com>ll in use today, but fortunately, technology to the rescue once again: there is a JavaScript library, CSS3 Media Queries JS, which supplants these older browsers with support for the newer media queries, and it already works quite well.

But, as handy as that library is, there are other possible solutions you can use. One of the best development practices you can use today is to design the simplest of layouts for mobile devices and older browsers and write your CSS as you always have, and then use CSS3 media queries to deliver progressively more enhanced versions to people with bigger screens, newer browsers, and so forth. Related to this practice is a blog post by Peter-Paul Koch on the relatively new Viewport meta element. The viewport Meta element defines the browser’s layout viewport, to which CSS declarations such as “width: 50%” are calculated. The viewport can be different from the screen dimensions or the browser window width, so this can get a bit confusion and complicated. PPK’s post explains why the best approach to use this is by doing this:

<meta name=”viewport” content=”width=device-width”>

In a nutshell—which is all we have time for—this just sets the default viewport rendering to be equal to the device width, which produces by far the best results across the many, many different mobile devices in use today. But read PPK’s article for the full details.

If you enjoy using frameworks, there is now a CSS framework that is specifically designed for working with adaptive layouts, called the LESS Framework, version 2. Less 2 automatically creates three layout frameworks for you—one for tiny mobile devices, one for iPad and smaller desktop sized screens, and one for bigger, widescreen displays.

Remember that example of the photo gallery I showed you? Well, if Less 2 had been out before I’d made that, it would have saved me a lot of effort, as it does pretty much exactly what I did for that gallery.

There are also frameworks that help you write your CSS more efficiently. Some of the more popular ones are Less (a different Less than the one just mentioned), Sass and Compass.

Unlike most of all the other tools and technologies mentioned thus far, these generator frameworks run on the server side—or just locally as you’re developing—and allow you to use abstractions and programmatic techniques in your CSS. This can be really useful; even just the most simple use case, defining variables for re-use throughout your CSS, can be of great value in a major website. But the real power of these frameworks comes from allowing you to use functions, mixins and programmatic calculations, even for colors. It’s pretty powerful.

Here’s a quick sample of what something like Sass can do:

$button_bg: #333;
$button_color: #fafafa;
@mixin rounded($r) {
	-webkit-border-radius: $r;
	-moz-border-radius: $r;
	border-radius: $r;
}
.button {
	background: $button_bg;
	color: $button_color;
	@include rounded(2px);
	&:hover,
	&:focus {
		background: lighten($button_bg, 10%);
		color: lighten($button_color, 10%);
	}
	&:active {
	background: darken($button_bg, 12%);
	color: darken($button_color, 12%);
	}
}

And here is the output of what Sass would make of that:

.button {
	background: #333333;
	color: #fafafa;
	-webkit-border-radius: 2px;
	-moz-border-radius: 2px;
	border-radius: 2px;
}
.button:hover, .button:focus {
	background: #4d4d4d;
	color: white;
}
.button:active {
	background: #141414;
	color: #dbdbdb;
}

This is just a tiny example of course, but the benefits of this on larger and more complex stylesheet files should be pretty clear.

Now earlier, when I was discussing the User Experience aspects of making more adaptive and responsive designs, there was a large sub-topic that I didn’t mention, and that is: Accessibility.

Technology and Web Design.042.jpg

Accessibility is an often-overlooked part of software and web design and development, and many people are only somewhat familiar with the details of it. In fact, it’s very hard to find people at all who are truly widely familiar with the many, many intricacies of Assistive Technologies, and the countless of disability-related hurdles that millions of people have to deal with.

Making our website layouts adaptive and flexible for the many different mobile devices and screens that people may be using to view them in is great for improving the user experience, but without doing all of that it’s entirely possible that some users would not even be able to use our website at all.

It used to be that websites consisted of little more than basic headers, paragraphs and a table or image here and there. You know, kind of like that old car again. That was a long time ago, though, as almost every website today is far more complex than that. Furthermore, the rise of web applications has added a couple of additional layers of complexity, and, hurdles, to the mix.

Assistive Technology has historically had a hard time keeping up with these developments, but fortunately awareness of the need for accessible websites and web applications has risen in recent years, leading to many new technologies that help to allow Assistive Technology make sense of the Web of today.

As a web developer we have to do our part in making our sites accessible, and part of that involves testing them out. There are countless disabilities to take into consideration, but even just a small overview of them is beyond the scope of this talk. A big one, though, is blind users who have to rely on screen readers to make sense of the Web. Some technologies help with that.

Firevox, a plugin for Firefox that will read out a website’s contents to you. And if you’re a Mac user, you can use the built-in VoiceOver technology which is a screenreader for the entire OS, and which you can use through Safari to test with as well.

Lastly, there is ARIA, which stands for Accessible Rich Internet Applications. ARIA is a relatively new specification for techniques that web developers can use to make their modern websites and, you guessed it, their Rich Internet Applications accessible to screen readers and other assistive technologies.

ARIA is pretty complicated, but mostly very time consuming to explain, so I’m not even going to dive into that at all. I recommend you read these two great introductions to ARIA to get a good basic knowledge to the techniques:

The value of making things accessible can be hard to quantify, often even more so if you have no major disabilities yourself and thus can hardly imagine having to live life unable to see, unable to hear, or unable to use a mouse or keyboard. However, from time to time we can get a better idea for the value of making things accessible, through the experiences that some people with disabilities share online. One example I’d like to mention is the story of a blind man named Austin Seraphin, who wrote a detailed account of his experience getting an iPhone. Austin’s story is incredibly moving, just… incredibly powerful, and it really shows how you can dramatically change someone’s life by making your product more accessible.

On the web, a lot of that comes from using semantic markup, proper separation of structure and presentation, and exploring ARIA technologies if you’re building a web application.

Lastly, since we’re talking about Modern Web Design, let’s look at some technologies that help us design more modern websites.

A major development of the past year and a half in our industry is web typography. We no longer have to rely on images or complex solutions like sIFR or Cufón to do proper, beautiful type on the web. In fact, we now have an abundance of services to choose from for type on the web:

FontDeck, Typekit, Google Fonts API, Fontspring, Fontsquirrel, and so many more. Just a few years ago, there wasn’t much we could do with native web typography, and now we have almost too many options to choose from. It’s really great—and if you want an overview, check out @font-face Face Off!

If you want to see how powerful this is, just look at Lost World’s Fairs and be amazed.

But great typography isn’t the only thing going on. We’ve been gifted with a plethora of great tools and technologies that help us design better sites. Tools that help us learn how sites work, and tools that help us build sites.

Design on the web has become more grid focused in the past 5 or 6 years, but we don’t want designs to look boxy. To make more interesting designs while still adhering to proper grid design principles, various tools are available to us.

There is the CSS framework that kind of started it all: 960 Grid System, which spurred on various similar frameworks—even the Less framework I mentioned before uses this column-driven concept.

But one set of grid column and gutter widths doesn’t always cut it, and just last week a neat little tool came out that helps with this: Gridulator. With Gridulator you can very quickly and easily customize your own grid images for all your designing needs.

Already busy in the browser? The Grid bookmarklet from Spry Media will be of great use to you, overlaying a completely configurable grid on top of your page.

Need to look into a site a bit more than the grid? Use XRAY, an x-ray like took for exploring site structure and layout.

With all these tools and technologies allowing us to do so much in the browser, it’s no wonder that people have been starting to talk about designing in the browser. Straight up, directly, right there in the browser. Personally, I think that’s definitely where things are heading, and that it’s only a matter of time before we get there. At this time, the browsers are still working real hard just to get up to speed on more complete HTML5 and CSS3 support.

But, things are moving a lot faster now than they were for much of the past ten years, and for all the technologies, tools and techniques we have available to us today, the one thing that will make the biggest difference on the Web, and in the websites we create, is our attitude towards modern web design. It all comes down to us, so we need to ask ourselves: are we going to look ahead and work towards the future, or are we going to keep ourselves stuck in the past?

I know what I will be doing, and so I’d like to leave you with this paraphrasing of a great Wayne Gretzky quote. It pretty much encapsulates my entire philosophy on how to do modern web design:

Technology and Web Design.052.jpg

“I design to where the Web is going to be, not where it is today.”

@KuraFire

Thanks for reading.

Is Canvas the new Flash?

With Apple doubling down on their “Flash is great, except when it comes from Adobe” stance, the future of Flash as a browser plugin continues to be a topic of discussion. There are two main aspects of this to consider: one, Flash as the plugin that enables video on the Web for countless of people still today and tomorrow, and two, Flash as the platform that enables advertisers to suck just a little bit of extra life out of our laptops—and ourselves.

For the first aspect, HTML5 video is the answer. It is also not a topic we’ll go into today, but rest assured that the debate on HTML5 Video vs. Flash video is far from settled. No, today I’m only talking about Flash ads, and the perceived answer of HTML+CSS3 and/or Canvas.

Regarding the idea that Canvas will replace Flash for web ads, Steven Frank has brought up a few interesting questions and concerns. As a web developer/designer who cares quite deeply about all of this, I'd like to address some of his points.

Suppose the ever-increasing Flash backlash is successful, where success is loosely defined as enough people uninstall Flash that it’s no longer considered by web developers to be “something that everyone has”.

Any web developer out there today who considers Flash “something that everyone has” should already re-educate themselves. That time is long, long behind us now, but I digress.

Further suppose then that said web developers adapt to the changing environment, and begin composing their animated advertising travesties in standard HTML5.

This is the ominous corollary to the prospect of a victory against pervasive Flash.

While I’d guess that <canvas> is, at least on the Mac platform, optimized to be more battery efficient than Flash, any continuously running animation is going to drain your notebook’s battery.

Obviously, there is nothing to negate about a continuously running animation using up battery life, but that’s not really the big issue. The problem of Flash ads, when it comes to battery life, is that they use up to 30% CPU time when idling. No animation, just a static image, and yet… up to 30% CPU is being occupied, just for it. The Flash plugin, at least on the Mac platform, is simply not idle enough, even in idle mode. Compare that to Canvas or CSS3 Transitions and Animations, and the latter (standards-based) technologies use up even less CPU when animating than Flash does when idle. That gargantuan difference is enough to have many of us shrug at the notion of Canvas– or CSS3-based ads that move around, though I’m sure some are still concerned about that, so moving on:

And there’s a potentially bigger problem, which is that this type of content would not be as easy to block, because it’s not self-contained in a single plug-in that can be removed or disabled.

Aha, the crux of the matter. It’s true that Canvas and CSS3 ads won’t be self-contained in a plugin, so… are we in a pickle here? Read on!

Turning off JavaScript is practically a non-starter. Compared to Flash, JavaScript is much more widely used to practical effect. While you can probably live without awful ads and gimmicky browser games, JavaScript cannot reasonably be turned off without dramatically crippling your web experience.

So, when advertisers finally come around to making a standards-based page suck, and they will, as soon as the market gives them a reason to do so, is ClickToCanvas inevitable? What happens next?

When ads on the web start to become JavaScript, Canvas and/or CSS3–driven, we most certainly won’t have an easy way to block them anymore. Except for the relatively easy way we already have, which is to block the ad-serving servers and scripts via extensions such as the JavaScript Blacklist.

A “ClickToCanvas” is certainly not out of the question, but it is unlikely to be as needed as ClickToFlash is. The difference between 30% CPU and 1-2% CPU is very serious, as is the difference between one third of battery life and a negligible impact on battery life.

And even then, if we really get annoyed by CSS3 and Canvas ads that keep on rotating, even on sites we insist on visiting regularly, simple things like the user preference file and (as-yet unwritten) extensions allow us to simply disable such animations. The difference between standards-based techniques and proprietary plugins is that there are myriad ways to deal with the former, and only one with the latter. That’s why things like ClickToFlash came with features such as letting Youtube work anyway—because we couldn’t distinguish “good use of plugin” from “bad use of plugin.”

Standards-based ads may be every bit as egregious in design and interaction as the current spawn of Flash-based ads, but their negative impact on battery life will be hugely different, and for those still bothered by the former, many more solutions will be available to make their lives happily ad-free.


Upcoming talks

Here on My own website

Subscribe to this site

Years

2014

2013

2012

2011

2010

2009

2008