I can’t say I’m particularly excited about upgrading to OS X 10.8. The heavily stylised and textured design already looks tired on mobile apps, now we have the pleasure of it on the big screen.

Yay.

Meanwhile, Microsoft blogged about Redesigning the Windows Logo, a task undertaken by Pentagram (read their take on the logo project). Not very exciting either but it does demonstrates a huge commitment to their evolving Metro design language for which, as a whole, I’m a big fan.

It was important that the new logo carries our Metro principle of being “Authentically Digital”. By that, we mean it does not try to emulate faux-industrial design characteristics such as materiality (glass, wood, plastic, etc.).

If it wasn’t for the incredibly cheesy “Authentically Digital” line I’d say that was a deservedly accurate jab at Apple. I make no comment on how usable either system will proved to be, I only note that Microsoft find themselves in the unusual position of taking a refreshing step forward in UI design, while Apple seem hell-bent on designing themselves into a tediously well veneered corner.

Regarding the Web

Last year I highlighted several challenges we’ll face in web design for 2012 with a side note on why we must avoid the Apple influence and instead pay more attention to Microsoft, however untrendy that may be. I also wrote Resolution Independence for Smashing Magazine to primarily champion further scalable graphic usage on the web.

Some may argue that Apple’s design philosophy is about creating the perfect user experience across all devices. Something Metro also aims to achieve. If that were true then surely the web cannot be overlooked? Shipping hundreds of kilobytes of UI graphics is a problem. A problem that doubles in size when you consider continuing rumours of the inevitable super high-res displays. This time it’s 2048×1536 for the iPad 3. You may have noticed how crappy raster graphics look when pixels are doubled up. We already have mobile phones that hit 300PPI. We can get away with providing high-res logos but full websites are an issue. If you’ve ever visited iCloud.com you’ll see what I mean. It hits 1mb per page and most of the graphics aren’t yet suitable for high-res. Bandwidth is a bottleneck that won’t go away.

What does all of this mean?

Apple do not care about the web. They’re creating a digital world in which everything is client side and native. They’ll happily make use of web technologies when it suits (iBooks for example), but the web as a platform? Not for Apple. Is that approach wrong? Not necessarily, I could not say, but it’s something us web designers need to recognise and not replicate.

* * *

Oh, and like me you were probably pissed off by John Naughton’s incredibly ill-informed Graphic designers are ruining the web piece in the Guardian but he does stumble around some genuine points. He just fails to articulate reasoning for either side.

<a class="delete" href="#">Delete Item</a>

The anchor is styled up with sexy CSS3 and functionality is implemented with an asynchronous JavaScript API call. Because we all care about accessibility (and standards) we provide a “no-JS” fallback:

<a class="delete" href="/item/delete/1/">Delete Item</a>

Lovely! It’s great to build on top of what works. “Web apps” are still websites, after all.

Now, I know what you’re thinking, “Delete” is a big commitment! What if the user triggers the link accidentally? What if the user has been conditioned through years of UI exposure to expect a modal window explaining the ramifications, or at least asking for confirmation? We could write a little script (jQuery, naturally) to hijack any element with the class “delete” and throw up a confirmation box. Similar to this:

$('a.delete').on('click', function(e) {
	return confirm('Are you sure?');
});

Replace confirm() with your fancy dialog of choice. The function window.confirm provides a native dialog implemented by the browser. More on that later!

That’s quite nice but searching the whole DOM for links is fairly intensive. There will also be the initial delay of execution while we wait for the DOMContentLoaded event. Users will quick trigger fingers will be able to click “Delete” and see no confirmation request. We also have the issue of microcopy hardcoded in our script (not the best place for it). We could mess around with additional data-* attributes but I have a better idea…

<a class="delete" href="/message/delete/1/"
   onclick="return confirm('Are you sure?')">Delete Item</a>

Boom! No dependancies, no need to worry about fast fingers, and browser support dates back to Netscape. (Event handler attributes like onclick are still a big part of HTML5, in case you were wondering.)

This is perfect for our needs but as you’ve probably noticed the native confirm dialogs are ugly as hell. On mobile devices (see Android 4.0 and iOS below) the dialogs look slightly better in my opinion. More importantly though, they work! Have you ever tried building a custom modal dialog for mobile browsers? Good luck with that!

Going native on mobile is undoubtedly the best experience. Even native mobile apps use native dialogs. Don’t even think about trying to implemented fixed positioning in a mobile web browser it will have you in tears (trust me). The question is: how do we go native on mobile, but provide a custom dialog design for desktop browsers like Chrome, while still gaining the benefits of inline event handlers? Check out the one I designed (based on TJ Holowaychuk’s UIKit):

To provide both native and custom dialogs through confirm() we need to override the function.

Our problem is that the native dialog hangs the browser action in a way that we cannot. Any override we create for window.confirm must return false and then act asynchronously on later events. How can we do this when only a string is passed to the function?

The onclick attribute basically creates an event handler like this:

function(event) {
	return confirm('Are you sure?');
}

Note the event parameter. We need to access this object (a MouseEvent) to obtain the original target element and go from there. We could pass it through like this:

<a onclick="return confirm('Are you sure?', event)">

The native version of confirm will ignore the second argument (JavaScript isn’t fussy). But that’s not very clean, and there is a better way! When we redefine confirm we can actually access this event object.

window.nativeConfirm = window.confirm;
window.confirm = function(message) {
	var event = window.event || window.confirm.caller.arguments[0];
	// ...
};

First we check the window object, old Internet Explorer will find an event chillin’ there. Other browsers can access the function’s caller. If no event exists we just return window.nativeConfirm(message); and be done with it. If the event does exist — and we’ve established that the user experience will be improved with non-native dialogs — we get the target element, read the href attribute, pop open a custom dialog with a callback that redirects on success, and return false to cancel the default onclick action.

My final implementation with extended functionality looks a little something like this:

Delete Item

window.nativeConfirm = window.confirm;
window.confirm = function(message, event, callback)
{
	// grab the event and target element (if they exist)
	var e = event || window.event || window.confirm.caller.arguments[0];
	var el = e.target || e.srcElement;

	// go native if preferred, or no event/element
	if (useNativeConfirm() || !e || !el) {
		return window.nativeConfirm(message);
	}

	// open custom dialog with callback function
	fancyConfirm(message, function(result) {
		if (result && el && el['href']) {
			window.location.href = el['href'];
		}
		if (typeof callback === 'function') {
			callback(result);
		}
	});

	// cancel onclick action
	return false;
};

By including useNativeConfirm() we can do some feature detection and browser investigation to determine what type of dialog to display. For mobile browsers this is essential. I’m still thinking about the best way to make this decision but a Modernizr media query test for small screens is a good start.

To recap the benefits of this technique:

• Allows for native confirmation dialogs that are immediately present and supported by all browsers with no dependancies.
• Is easily implemented within the HTML.
• Has the ability to provide more attractive dialogs for browsers that can handle them while retaining native dialog use elsewhere (i.e. small screen/mobile).

I’ll whip up an example soon. Any thoughts?

Even if you don’t like the idea of redefining window.confirm or using event handler attributes, I’d still recommend avoiding custom dialogs on mobile devices.

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.