When we look at the breadth of Web-enabled devices, responsive design is sure to provide a better user experience. Scrolling horizontally, panning and zooming the viewport have their place in user interface design, but forcing the user to do these things just to navigate a website quickly becomes tedious. Fitting the website to the viewport is about more than just layout: it’s also about resolution. In this article, I’ll demonstrate why SVG is a perfect addition to future-friendly Web development.

I go on to demonstrate how SVG can be used in place of normal image techniques. I first experimented with using SVG logos in 2010 but browser support was very limiting back then. Towards the end of 2011 I had another look at SVG logos and was surprised by the progress — that lead to this article!

Of course, I’m not the only one considering these challenges. It’s great to see other designers/developers like Laura Kalbag realising the same potential (check out her site for Future Insights for SVG icons). I expect such practice will become common place soon. Other techniques also exist for scalable graphics, many using CSS alone (I’ve listed a few in my article). 300 pixel-per-inch tablets and laptops within a year or two? Make sure your websites are ready.

* Update 19th Jan: I’m honoured! My article was featured in Peter Cooper’s HTML Weekly and received a shout out from Paul Irish in the brilliant new ShopTalk podcast.

The idea is not to build a website that only works on one device, it’s about taking a different perspective; looking at a website from a unique angle. Only then do we uncover hidden secrets.

The thing is, we’re so device-agnostic these days we forget that real users are only using one device at a time to access our websites. So when I talk about “device optimisation” what I’m really concerning myself with is real world one-to-one, user-on-machine experiences! How perverse.

If we spend the whole time developing a website from bottom to top — from the foundations upwards — we forget to look at it top-down, i.e. the user’s perspective.

It’s impossible to design and build a website with theoretical “best practices” alone. We have to consider the nuances (read: headaches) of individual browsers and devices common today. It’s simply a mindset which occasionally uncovers UX issues we can’t ignore. And though we apply a fix for the one device that highlighted the problem, others may benefit. Even ones that haven’t been manufactured yet.

Consider the time and effort we spend making websites work in IE6–9. Custom stylesheets; a progressive enhancement approach. We do this to avoid issues and to test functionality in older browsers, why not take the idea further?

When we use the latest in snazzy devices like an iPhone to optimise its individual experience we often bring others along for the ride. Because we’re building one website (for one web) it’s easy to check for any adverse side effects in less-abled browsers (and if need be we provide a tiered experience).

Exploring brand new and exciting web standards and features for new devices — despite sparse support at present — should be as important as supporting old and dying devices (if not more). The laggards drop off while the new have a whole life cycle to pass through.

Create an accessible and semantic backbone and then build the presentation layer with a healthy dose of device optimisation. Let’s face it, how many years does a website design last anyway?

See Responsive Tables Demo (2) — in a modern browser! Webkit browsers handle both tables perfectly. Firefox & Opera handle the first version. The second version plays with/abuses the flexible box layout and only works with a -webkit- prefix.

I’m confident with more ingenuity I can get this idea working in IE9. Please note: this is far from perfected!

* Update 10th Jan: as the comments below note this technique (as is here) won’t work on a lot of older mobile browsers. Scrolling functionality could be replicated with JavaScript (if the layout works). Feature detection would be needed to make this viable, falling back to a layout like Chris Coyier’s.

Something to consider: once you go block, you can’t go back! Changing the display of a table and its rows & cells to block level is a lot easier than re-implementing the table model with CSS. Important to note because it’s commonly advised to build responsive websites from small to large (think 320 and up). Good advise, though not gospel. I’ve found with tables it may be better to have the larger traditional table version as default and use max-width media queries to scale down. Food for thought, anyway.

I like this concept. Usability is up for debate. Is it intuitive enough? It keeps data side-by-side and doesn’t take up a lot of space. I’m going to keep experimenting — appreciate the feedback so far!

A real short post for future reference! I’m experimenting with a responsive calendar design and build. See my very rough responsive calendar demo.

I’ve found through trial, error, and much pondering that the idea of a responsive calendar is actually not that complex. My demo needs more considered breakpoints and design tweaks but it proves the concept. I’m thinking about developing it into a fully fledged HTML & CSS baseline for others to build upon.

I’m also looking into more traditional tabular data as that seems to be trickier to tame in responsive web design. After a lot of Googling and a few tweets with Harry Roberts and James Young (two fellas who know their stuff) it’s become apparent that no one has really cracked responsive tables yet.

Chris Coyier at CSS Tricks presented a good idea in August 2011. His solution requires hard-coded content inside CSS, not good at all for many reasons. Chris Garret has evolved the idea very recently using data-* attributes in HTML and the content: attr(data-*) technique in CSS. A great improvement but still limiting. In the end, I’m not convinced the final small-screen view of this technique is really the best solution. The ability to compare related data sets is reduced greatly. That said, I’m at a loss as to where this can be improved.

My calendar demo also hard-coded the labels “Monday” to “Sunday” within the CSS file. That’s only slightly more acceptable until you consider localisation for language support. It’s just asking for trouble later on. With more care I believe the calendar format can be nailed. I’ll keep you posted!

Filament Group blogged a different idea in December 2011 that maintains the table appearance by reducing the columns visible. It relies on JavaScript for the interactive choice of visible columns (making it an acceptable use of standards), but again, only suitable for certain data. I’ve been dreaming up more outlandish uses of JavaScript to change presentation/interaction but as a baseline the visual layout, style and presentation should never require it.

One thing that quickly becomes obvious is that there is no single solution. The ideas above may be perfectly adequate for some cases and completely useless for others.

It could be said that tabular data is boring; avoid at all costs! Fair point I’d say — thinking outside the box! Or table in this instance. But then sometimes you can’t escape semantics. Why not alternate content? Hide the table and present something else, like pie chart as Scott Jehl suggested in response to Chris Coyier’s experiment. A possibility, but if you’re going with a table in the first place it’s probably the only suitable format for that quantity of data.

I’m beginning to think that trying to perfectly resize a table within the visible viewport is not the best idea after all. Responsive web design does not make scrolling illegal! Could the solution lie in the realm of — gasp — horizontal scrolling?

More research and experimentation required, I’ll let you know my findings! Apologies if this post is a bit scatty. It’s gone midnight and if I don’t publish now I doubt I’ll find time until 2013!

2011 has been the best year of my career so far. I left my previous job to join Browser, an unexpected but excellent move! I’ve been refining my front-end development skills and design process. Next year we’ll have big websites to launch that I plan to showcase here. For now, a few thoughts on the future of web design.

Three ideas I suspect will be hot (or hotter) topics in the coming months:

1. Website Accessibility

I’m not just talking about support for varying disabilities — or the proverbial screen reader, as important as that is — I’m talking about access for all users. We’re seeing ever maturing practices in device-agnostic website development. Why? Because web access is hugely diverse in users, devices and browsers. A website cannot be a fixed entity ignorant of that reality. Responsive website design exploded this year alongside the mobile first strategy. If those two ideas aren’t part of your process by now you’re very much behind. HTML semantics were challenged and rightfully defended.

Tech giants including Microsoft, Adobe, Apple and Facebook — all famous for their internet walled gardens — have publicly stated recognition of the web’s future in HTML5. Whether their current plans favour accessibility is debatable but considering the ubiquity of the web and its standards are gaining mainstream understanding, we’re seeing a demand from clients and users alike for web access that isn’t restricted to one device. I’ve been presenting initial design mockups to clients on various devices, big and small, for over a year now and it’s a brilliant experience. They just get it! They immediately start considering the user and what content is important (and not the logo size).

2. Screen Resolution and Scalable Graphics

Responsive design has highlighted to need for responsive images for multiple resolutions. The use of web fonts for icons has also gained popularity, though not quite with me! In my opinion SVG is a sleeping web standard that’s going to see rejuvenation soon. This year has seen cross-browser support for SVG as a source for img elements and the CSS background-image property. Scalability is vital when we have screens ranging from 3–30 inches with pixel densities between 100–300 pixels-per-inch all accessing the same site.

If the rumours of Apple’s high res displays for 2012 are true — and if it’s not next year or not Apple it’s only a matter of time — the single resolution raster graphics used on the web today are in trouble. They’re noticeably poor on high density mobile screens and that difference will only be exaggerated on the larger desktop & laptop screens we’ll soon see climbing the dizzying heights of 300 PPI. CSS3 has gone a long way to provide resolution independent styles but SVG is needed for more complex icons, UI elements, logos and vector graphics elsewhere. Pixel units are a rare sight in modern web development.

3. Interactivity

We can safely say that fixed-width designs are a thing of the past. I’d also include static layouts as a hangover from the printed page paradigm yet they’re still a staple of website design. I’m not suggesting elements should be whizzing around aimlessly but touch screen interfaces are teaching us of a new way to think about accessing content. Is the page reload a thing of the past? With the JavaScript history object we can still maintain the fundamental integrity that URLs give the web while exploring new methods of navigation and interaction. With an inevitable surge in web apps we’re in for a UI and UX treat.

* * *

From a web design perspective this raises several points to consider.

Even though interest for Wikipedia’s page on skeuomorphism has spiked in the designer demographic recently it may not be wise to follow Apple’s native app style for web design influence. It suits single minded apps, not multifaceted websites. One device, not many.

I’m fascinated by the design Google has found new passion and respect for this year (I even replaced my iPhone with a Galaxy Nexus). Even Microsoft — Microsoft! — are looking innovative in this space. Have a play with the Windows Phone demo (that’s one for front-end devs to dissect).

Why are Google and Microsoft taking such a different direction in UI design compared to Apple? They’re designing for multiple experiences with vast differences. That’s the challenge we face on the web and they are two players we should be keeping a very close eye on. Microsoft’s Metro style for example will span across a magnitude of phones and tablets, not to mention their Windows 8 desktop and TVs via the Xbox.

All of these realities require a more thoughtful approach to website development too.

Every year we see stories about the average website size increasing. I have no doubt you’ve witnessed and contributed to that growth, I have! Content is becoming richer, constantly testing bandwidth limitations. There’s no surprised well structured CSS and efficient JavaScript (and jQuery) has been a theme lately. This is another reason why visual design must be content-focused.

On a final note: this week I released a preview of Socialite.js (much more useful than my banter print stylesheet). Socialite.js is a tiny script that significantly defers the loading of social sharing buttons like ‘Tweet’, ‘Like’ and ‘+1′. There’s no point going through all the effort of optimisation only to let a ‘Like’ button delay your entire page by seconds! Read my preview article and expect a production release soon.

See you in January!

Here’s a screenshot from a popular blog to refresh your memory:

They have their place on a website if used intelligently — that’s a big if! They’re difficult to design around and a nightmare for front-end development.

The copy-and-paste code for each button includes a default element and a <script>. On the DOMContentLoaded event the <script> replaces all instances of the default element with an <iframe> — a portal into the sharing shrine of the respective social network.

Many people paste both element and <script> together where the button sits on the page. This is wrong! It’s best practice to move the <script> to document’s end; before the closing </body> — you only need it once. The first script activates all button instances on the page, the second bails immediately. Neither will run until the end of the document when the event fires. No point requesting it early.

These <script>s and subsequent <iframe>s are massive! They request a boat load of resources that get mixed in with everything else still trying to load. Not good at all.

Here are the issues with sharing buttons:

• Their activation scripts run on the DOMContentLoaded and download a mass of resources.
• They all have different defaults, most of which are inaccessible and empty elements.
• It’s not easy to implement multiple instances and very difficult to activate new buttons after load.

I’ve had enough!

I’ve been developing a website that runs head first into all of this nonsense. It’s a responsive design that only displays global sharing buttons on larger screens. Simply hiding them with CSS is not good enough, the browser shouldn’t download them at all. I’m also loading in JSON content to display items in a modal window for easy browsing. The items are prime for sharing but activating new buttons is a real pain.

I’m fed up of seeing websites hang while these gems are downloading. That experience sucks.

I’ve written a solution:

Previewing Socialite.js

Socialite.js handles the activation of sharing buttons for you. All you need to do is write the default element any way you care and then activate it with Socialite, any time you wish!

The basic implementation looks like this:

<a class="socialite twitter" href="http://twitter.com/share" data-url="http://socialitejs.com" data-via="dbushell">
Share on Twitter
</a>

At the end of your document include <script src="socialite.js"></script> and in further scripts — when you’re ready — activate buttons like so:

Socialite.load();

Or be more specific with a context:

Socialite.load(document.getElementById('social-buttons'));

Or activate a single button directly:

Socialite.activate(document.getElementById('like-button'), 'facebook');

If you’re using JavaScript elsewhere (I’m guessing jQuery?) you can run Socialite.load at the end of your $(document).ready() function, or after any event. On “ready” may still start downloading button resources while your page resources are coming in. You could activate buttons on article hover like TechCrunch (which has a very primitive implementation of what Socialite does).

The added benefit of this script is that you can provide more accessible defaults for each button. So instead of Facebook’s empty <div>, or LinkedIn’s empty <script>, you can have a friendly link to the alternate sharing URLs. Socialite maps all data-* attributes to the corresponding customisation properties each button provides (I aim to normalise that soon).

Learn more at Socialitejs.com and grab the code at GitHub.

Socialite is still in development but the basic implementation is working so you should be safe to give it a test drive. A final “version 1″ will be released soon.

Please let me know your experiences!

var resizeTimeout, win = $(window);
win.bind('resize', function()
{
	if (resizeTimeout) clearTimeout(resizeTimeout);
	resizeTimeout = setTimeout(function()
	{
		var width = win.width();
		/* do responsive stuff... */
	}, 100);
});

The basic idea is that you don’t want to be hammering the window resize event because it gets fired repeatedly when a user manually resizes their browser. Instead you should use a short timeout to wait for resizing to end.

You may ask, why am I using JavaScript at all, surely pure CSS media queries are better? For most circumstances they are, but when you’re applying interactivity to a website, that experience can differ greatly depending on the screen size. My latest build involves a lot of Google Maps work but only for larger screens (an alternate — and default before JS kicks in — content design is presented to suit smaller screens). Loading in the whole Google Maps JavaScript library ignorant of usage is a heavy burden on bandwidth.

I’m using this technique to load JavaScript and other content like high-res images very late in the game. If the window never reaches the larger breakpoints no unused resources are ever wasted.

More soon!

Today I found another perfect example!

I’m using a technique based on Ariel Flesler’s excellent jQuery scrollTo plugin. The plugin scrolls the document until a specific element is in view. The set up: I have several tabs on my page that update content below them. I want to scroll to that content as a visual guide for users to indicate what has changed and to bring it center stage. It’s a fully responsive design so on small screens this interaction is very useful.

The simplest jQuery implementation would look like this:

var target = $('#target');
$(window).scrollTo(target, { duration: 500 });

That will do exactly what I want, once bound to a click event — why go any further?

Because that’s going to suck.

The .scrollTo(); method takes a few options but the basic ones I care about are the duration (milliseconds) and an easing function (that “specifies the speed at which the animation progresses at different points within the animation”). I’ve chosen an ease-in-out function that starts slowly and builds up pace before decelerating again, similar to how a car would travel from A–B providing there are no barriers. I assume, I don’t drive so my car analogies are a bit flaky. Just trust me, this easing effect adds a touch of class.

That constant 500 millisecond duration is lazy and unresponsive. The distance I need to scroll is never constant, it depends on where the user has previously scrolled to (prior to clicking a tab). The shorter the distance the quicker we should arrive at the destination.

Here’s a generic evolution of my JavaScript:

var target = $('#target');

/* get the document height and window height */
var doc_height = $(document).height();
var win_height = $(window).innerHeight();

/* bail if the whole document is visible */
if (doc_height <= win_height)
	return false;

/* get the current scroll offset and target offset */
var offset = $(window).scrollTop();
var target_offset = target.offset().top;

/* calculate a positive distance between the offsets */
var distance = Math.abs(offset - target_offset);

/* if we are scrolling down and can go no further... */
if (offset < target_offset) {
	var max_offset = (doc_height - win_height);
	if (target_offset > max_offset)
		distance -= target_offset - max_offset;
}

/* if there is a need to scroll, wait for updates before doing so */
if (distance) {
	setTimeout(function() {
		$('html:not(:animated),body:not(:animated)').animate(
			{ scrollTop: target_offset },
			distance * 2,
			'easeInOutQuint'
		);
	}, 500);
}

The setTimeout delay is purely for my benefit because other actions need to happen before scrolling is initiated. The magic number 2 is simply a multiplier to slow things down. What’s important is that the animation always starting with a duration relative to the distance.

You may ask: “What’s the point, do people really notice such subtleties?”

To which I would reply: “No, but they will notice if they’re missing.”

It’s this sort of care that I believe produces the best possible experience for all devices. Interactivity should aid the user in a way that they’re not even conscious is happening — it should just work. A lot of JavaScript I see on the web today is a massive distraction. I hope this post illustrates the effort needed in interactive design.

Please ignore the irony of the above video if it happens to embed with Flash! YouTube promises HTML5 video in the future through the wonders of this iframe…

Watch all 16 minutes, it’s well worth it.

Two points stand out for me in Roger McNamee’s talk: the decline of indexed search — namely Google, and Apple’s domination in apps and their almost victory over the web at large. He highlights the importance of web standards (“HTML5″) and predicts the demise of Flash, which to be fair has been a very long time coming, but the way McNamee mentions Flash as an aside — almost an after thought — is certainly insightful.

In regards to search, I ranted about how SEO is Killing Website Design in April. Anyone who knows me even remotely will know my complete disdain for anything “SEO”. I think that’s often mistaken for some sort of distaste for “search” and Google in general. That couldn’t be further from the truth! What I can’t stand is the completely illogical notions that anyone talking “SEO” is sure to utter. Warning, semi-rant ahead! “SEO” is a business that preys on the naivety of website owners who should be collaborating instead with designers, developers and copywriters directly. Search engines rank good, relevant content for users. It is so, so simple. Anything that intermediates that connection with snake oil, buzzword bingo and money that doesn’t go directly into either production or intelligent strategy thereof will rarely succeed in the long run. Don’t get me wrong, there are many techniques claimed under the moniker of “SEO” that make up good web development practice, but the majority of such practitioners have no idea what they’re really talking about. If I were to specialise as a website consultant I would keep this term as far away from me as possible, considering the ridiculous levels this common sense distraction has reached.

I think many more people would agree with me today than earlier this year (though a lot did back then). It helps that indexed search has peaked. I run several websites that get between 5–25k uniques per month. As a rough average across the board — bearing in mind my very tech-web-savvy audiences — less than 20% of that traffic is via “search engines” (Google).  The rest is scattered across referring sites and direct traffic. And in one case almost 3% via the RSS feed — go RSS! Of course those stats don’t resemble the web at large but it is a growing trend. Search will always have its place but it is not the end game for a successful website.

The death of Flash is a lot more obvious. I often get reminded on Twitter that Adobe only killed off the mobile runtime but my point is: no mobile = no web. Everyone from Microsoft to Apple to Facebook have publicly supported web standards, i.e. HTML5 & friends. Even Adobe themselves have with Muse and Edge. They made a complete hack of it, but it’s still early doors yet and a very positive sign for future production tools (I’ll remain skeptical for a while longer but the effort is duly noted).

For me this is all about looking forward.

You’ll have probably noticed that idea in a lot of my recent articles. That’s where the fun lies! There’s always time to reevaluate your practices to ensure you’re working on the right track. A large percentage of my time goes into research, experimentation, and collaboration with the web design & development community. Those guys know the score. I urge everyone to do the same, otherwise you’ll probably be stuck trying to optimise keywords in a Flash website in five years time. I wouldn’t wish that future for anyone!

Data — until semantics and presentation turn it into information. If that value is true we can therefore infer that semantics reign supreme in front-end website production.

The thing is, not all content is created equally. There needs to be a pragmatic interpretation of how content is represented. For most users of a web browser its all about what is visible. For those using screen readers it’s all about what is audible.

We have multiple layers of content, and multiple presentations of the same content. We have semantic information that can be aggregated from HTML alone and visual content that offers support for visual users (which make up the majority of users, but not everyone). The visual style applied with CSS often changes content into a different form. For example, it can change a simple hyperlink into a visual button with a graphical icon. That icon would have little value in the raw HTML where a link will suffice. We can also provide multiple versions of the same content, e.g. a video or animation with an alternative description, or better yet, a more thorough written transcript. In this case both versions of the content can be marked up in HTML and prove useful.

The whole reason for HTML semantics is to supply meaning in one specific regard when the content is accessed in its rawest state. It’s an accessible baseline. We can use CSS or JavaScript to enhance that content in presentation — a second level.

There is nothing wrong with being a purist in terms of HTML semantics. That’s commendable. That’s future proofing your content, which is why I strongly disagree with the notions suggested in Divya Manian’s Smashing Magazine article. You just have to realise that semantic HTML is just the first layer of accessible content.

Website design is moving more and more towards visual, interactive presentation of content. That makes the accessible semantic HTML layer all the more important.